Fix missing diagnostics and tuning knobs in inliner

[vijaysun-omr]

Several inlining parameters can be tuned via command line options or env vars. Recently, I needed to tune some inlining parameters that could not be controlled without changing the source. This PR fixes the cases that I observed by adding env vars. I also added some heuristic trace diagnostics that print when we estimate a call but don't inline it.

[vijaysun-omr]

@hzongaro and @gita-omr this may be of interest to you for review

[hzongaro]

Looks good. Just a couple of minor suggestions.

[hzongaro]

Looks good. Thanks!

[gita-omr]

LGTM

[hzongaro]

Jenkins test sanity.functional,sanity.openjdk xlinux jdk8,jdk17,jdk23

[hzongaro]

JDK 8 sanity.functional failure appears to be infrastructure-related. Rerunning. . . .

Jenkins test sanity.functional xlinux jdk8

[hzongaro]

Jenkins test sanity.functional xlinux jdk8

[hzongaro]

@vijaysun-omr, may I ask you to take a quick look at the failures that occurred in the JDK 23 sanity.openjdk testing? I think it's extremely unlikely that they are related to your changes, but I couldn't find previous examples of those failures.

[a7ehuo]

I took a quick look at the recent JDK23 sanity.openjdk nightly build tests. I don't see the failure from the JDK 23 sanity.openjdk in the nightly build. I'll see if the failure is reproducible without this PR, although I also think it is very unlikely that this change could have caused the failure.

[2025-01-08T23:52:46.840Z] FAILED test targets:
[2025-01-08T23:52:46.840Z] 	jdk_util_0 - Test results: passed: 972; failed: 2; error: 1 
[2025-01-08T23:52:46.840Z] 		Failed test cases: 
[2025-01-08T23:52:46.840Z] 			TEST: java/util/TimeZone/SimpleTimeZoneCloneRaceTest.java
[2025-01-08T23:52:46.840Z]         TEST: java/util/TimeZone/TimeZoneRegression.java
[2025-01-08T23:52:46.840Z]         TEST: java/util/TimeZone/TimeZoneTest.java

[2025-01-08T23:29:50.151Z] STARTED    TimeZoneRegression::Test4109314 'Test4109314()'
[2025-01-08T23:29:50.151Z] java.lang.NullPointerException: Cannot invoke "java.util.TimeZone.getOffset(long)" because "tz" is null
[2025-01-08T23:29:50.151Z] 	at java.base/java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2323)
...
[2025-01-08T23:30:01.835Z] STARTED    TimeZoneTest::TestRuleAPI 'TestRuleAPI()'
[2025-01-08T23:30:01.835Z] java.lang.IllegalArgumentException: Illegal end month 7447504
[2025-01-08T23:30:01.835Z] 	at java.base/java.util.SimpleTimeZone.decodeEndRule(SimpleTimeZone.java:1425)
...
[2025-01-08T23:30:01.838Z] ----------- Stack Backtrace -----------
[2025-01-08T23:30:01.838Z] getOriginalROMMethodUnchecked+0x23 (0x00007F88C175DE43 [libjclse29.so+0x6be43])
[2025-01-08T23:30:01.838Z] getOriginalROMMethod+0x3d (0x00007F88C175DF6D [libjclse29.so+0x6bf6d])
[2025-01-08T23:30:01.838Z] getMethodParametersAsArray+0x1a3 (0x00007F88C1729EF3 [libjclse29.so+0x37ef3])
[2025-01-08T23:30:01.838Z]  (0x00007F884657FEA8 [<unknown>+0x0])

[a7ehuo]

The TimeZone test failures are not reproducible with either the JDK23 nightly build or the build with this PR change

• 108x runs of jdk_util_0 with JDK23 nightly build: Grinder 46433, 46446, 46449
• 108x runs of jdk_util_0 with JDK23 build with this PR change: Grinder 46447, 46450

[hzongaro]

The TimeZone test failures are not reproducible with either the JDK23 nightly build or the build with this PR change

@a7ehuo, thanks for looking into that! As this seems to be a very safe change, all other testing was successful, and it seems very unlikely that the failure was related to this change, I will go ahead and merge this pull request.