RFR(S): 8235673: [C1, C2] Split inlining control flags
Nils Eliasson
nils.eliasson at oracle.com
Wed May 27 11:58:45 UTC 2020
+1
Best regards,
Nils
On 2020-05-15 13:54, Tobias Hartmann wrote:
> Hi Martin,
>
> yes, looks good to me.
>
> Best regards,
> Tobias
>
> On 15.05.20 13:41, Doerr, Martin wrote:
>> Hi Vladimir, Nils and Tobias,
>>
>> Can I consider http://cr.openjdk.java.net/~mdoerr/8235673_C1_inlining/webrev.02/ reviewed by you?
>> Submission repo testing was successful.
>>
>> Thanks and best regards,
>> Martin
>>
>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>> Sent: Donnerstag, 14. Mai 2020 22:29
>>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
>>> dev at openjdk.java.net
>>> Subject: Re: RFR(S): 8235673: [C1, C2] Split inlining control flags
>>>
>>> On 5/14/20 12:14 PM, Doerr, Martin wrote:
>>>> Hi Vladimir,
>>>>
>>>>> But we can use it in Test5091921.java. C1 compiles the test code with
>>>>> specified value before - lets keep it.
>>>> Ok. That makes sense for this test. Updated webrev in place.
>>> Good.
>>>
>>>>> And this is not related to these changes but to have range(0, max_jint) for
>>> all
>>>>> these flags is questionable. I think
>>>>> nobody ran tests with 0 or max_jint values. Bunch of tests may simple
>>>>> timeout (which is understandable) but in worst
>>>>> case they may crash instead of graceful exit.
>>>> I was wondering about that, too. But I haven't changed that. The previously
>>> global flags already had this range.
>>>> I had also thought about guessing more reasonable values, but reasonable
>>> limits may depend on platform and future changes.
>>>> I don't think we can define ranges such that everything works great while
>>> we stay inside and also such that nobody will ever want greater values.
>>>> So I prefer keeping it this way unless somebody has a better proposal.
>>> I did not mean to have that in these change. Current changes are fine for me.
>>>
>>> I was thinking aloud that it would be nice to investigate this later by
>>> someone. At least for some flags. We may keep
>>> current range as it is but may be add dynamic checks based on platform and
>>> other conditions. This looks like starter
>>> task for junior engineer or student intern.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>> Thanks and best regards,
>>>> Martin
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>>>> Sent: Mittwoch, 13. Mai 2020 23:34
>>>>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
>>>>> dev at openjdk.java.net
>>>>> Subject: Re: RFR(S): 8235673: [C1, C2] Split inlining control flags
>>>>>
>>>>> On 5/13/20 1:10 PM, Doerr, Martin wrote:
>>>>>> Hi Vladimir,
>>>>>>
>>>>>> thanks for reviewing it.
>>>>>>
>>>>>>>> Should I set it to proposed?
>>>>>>> Yes.
>>>>>> I've set it to "Finalized". Hope this was correct.
>>>>>>
>>>>>>>> I've added the new C1 flags to the tests which should test C1 compiler
>>> as
>>>>>>> well.
>>>>>>>
>>>>>>> Good. Why not do the same for C1MaxInlineSize?
>>>>>> Looks like MaxInlineSize is only used by tests which test C2 specific
>>> things.
>>>>> So I think C1MaxInlineSize would be pointless.
>>>>>> In addition to that, the C2 values are probably not appropriate for C1 in
>>>>> some tests.
>>>>>> Would you like to have C1MaxInlineSize configured in some tests?
>>>>> You are right in cases when test switch off TieredCompilation and use only
>>> C2
>>>>> (Test6792161.java) or tests intrinsics.
>>>>>
>>>>> But we can use it in Test5091921.java. C1 compiles the test code with
>>>>> specified value before - lets keep it.
>>>>>
>>>>> And this is not related to these changes but to have range(0, max_jint) for
>>> all
>>>>> these flags is questionable. I think
>>>>> nobody ran tests with 0 or max_jint values. Bunch of tests may simple
>>>>> timeout (which is understandable) but in worst
>>>>> case they may crash instead of graceful exit.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>>> Best regards,
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>>>>>> Sent: Mittwoch, 13. Mai 2020 21:46
>>>>>>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
>>>>>>> dev at openjdk.java.net
>>>>>>> Subject: Re: RFR(S): 8235673: [C1, C2] Split inlining control flags
>>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> On 5/11/20 6:32 AM, Doerr, Martin wrote:
>>>>>>>> Hi Vladimir,
>>>>>>>>
>>>>>>>> are you ok with the updated CSR
>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8244507)?
>>>>>>>> Should I set it to proposed?
>>>>>>> Yes.
>>>>>>>
>>>>>>>> Here's a new webrev with obsoletion + expiration for C2 flags in
>>>>> ClientVM:
>>> http://cr.openjdk.java.net/~mdoerr/8235673_C1_inlining/webrev.02/
>>>>>>>> I've added the new C1 flags to the tests which should test C1 compiler
>>> as
>>>>>>> well.
>>>>>>>
>>>>>>> Good. Why not do the same for C1MaxInlineSize?
>>>>>>>
>>>>>>>> And I've added -XX:+IgnoreUnrecognizedVMOptions to all tests which
>>>>> set
>>>>>>> C2 flags. I think this is the best solution because it still allows running
>>> the
>>>>> tests
>>>>>>> with GraalVM compiler.
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Doerr, Martin
>>>>>>>>> Sent: Freitag, 8. Mai 2020 23:07
>>>>>>>>> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot-
>>> compiler-
>>>>>>>>> dev at openjdk.java.net
>>>>>>>>> Subject: RE: RFR(S): 8235673: [C1, C2] Split inlining control flags
>>>>>>>>>
>>>>>>>>> Hi Vladimir,
>>>>>>>>>
>>>>>>>>>> You need update your CSR - add information about this and above
>>>>> code
>>>>>>>>> change. Example:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8238840
>>>>>>>>> I've updated the CSR with obsolete and expired flags as in the
>>> example.
>>>>>>>>>> I would suggest to fix tests anyway (there are only few) because
>>> new
>>>>>>>>>> warning output could be unexpected.
>>>>>>>>> Ok. I'll prepare a webrev with fixed tests.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>>>>>>>>> Sent: Freitag, 8. Mai 2020 21:43
>>>>>>>>>> To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-
>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>> Subject: Re: RFR(S): 8235673: [C1, C2] Split inlining control flags
>>>>>>>>>>
>>>>>>>>>> Hi Martin
>>>>>>>>>>
>>>>>>>>>> On 5/8/20 5:56 AM, Doerr, Martin wrote:
>>>>>>>>>>> Hi Vladimir,
>>>>>>>>>>>
>>>>>>>>>>> thanks a lot for looking at this, for finding the test issues and for
>>>>>>>>> reviewing
>>>>>>>>>> the CSR.
>>>>>>>>>>> For me, C2 is a fundamental part of the JVM. I would usually never
>>>>>>> build
>>>>>>>>>> without it ��
>>>>>>>>>>> (Except if we want to use C1 + GraalVM compiler only.)
>>>>>>>>>> Yes it is one of cases.
>>>>>>>>>>
>>>>>>>>>>> But your right, --with-jvm-variants=client configuration should still
>>> be
>>>>>>>>>> supported.
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>>> We can fix it by making the flags as obsolete if C2 is not included:
>>>>>>>>>>> diff -r 5f5ed86d7883 src/hotspot/share/runtime/arguments.cpp
>>>>>>>>>>> --- a/src/hotspot/share/runtime/arguments.cpp Fri May 08
>>> 11:14:28
>>>>>>>>> 2020
>>>>>>>>>> +0200
>>>>>>>>>>> +++ b/src/hotspot/share/runtime/arguments.cpp Fri May 08
>>>>> 14:41:14
>>>>>>>>>> 2020 +0200
>>>>>>>>>>> @@ -562,6 +562,16 @@
>>>>>>>>>>> { "dup option", JDK_Version::jdk(9),
>>>>>>>>> JDK_Version::undefined(),
>>>>>>>>>> JDK_Version::undefined() },
>>>>>>>>>>> #endif
>>>>>>>>>>>
>>>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>>>> + // These flags were generally available, but are C2 only, now.
>>>>>>>>>>> + { "MaxInlineLevel", JDK_Version::undefined(),
>>>>>>>>>> JDK_Version::jdk(15), JDK_Version::undefined() },
>>>>>>>>>>> + { "MaxRecursiveInlineLevel", JDK_Version::undefined(),
>>>>>>>>>> JDK_Version::jdk(15), JDK_Version::undefined() },
>>>>>>>>>>> + { "InlineSmallCode", JDK_Version::undefined(),
>>>>>>>>>> JDK_Version::jdk(15), JDK_Version::undefined() },
>>>>>>>>>>> + { "MaxInlineSize", JDK_Version::undefined(),
>>>>>>>>>> JDK_Version::jdk(15), JDK_Version::undefined() },
>>>>>>>>>>> + { "FreqInlineSize", JDK_Version::undefined(),
>>>>>>>>>> JDK_Version::jdk(15), JDK_Version::undefined() },
>>>>>>>>>>> + { "MaxTrivialSize", JDK_Version::undefined(),
>>>>>>>>>> JDK_Version::jdk(15), JDK_Version::undefined() },
>>>>>>>>>>> +#endif
>>>>>>>>>>> +
>>>>>>>>>>> { NULL, JDK_Version(0), JDK_Version(0) }
>>>>>>>>>>> };
>>>>>>>>>> Right. I think you should do full process for these product flags
>>>>>>> deprecation
>>>>>>>>>> with obsoleting in JDK 16 for VM builds
>>>>>>>>>> which do not include C2. You need update your CSR - add
>>> information
>>>>>>>>> about
>>>>>>>>>> this and above code change. Example:
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8238840
>>>>>>>>>>
>>>>>>>>>>> This makes the VM accept the flags with warning:
>>>>>>>>>>> jdk/bin/java -XX:MaxInlineLevel=9 -version
>>>>>>>>>>> OpenJDK 64-Bit Client VM warning: Ignoring option
>>> MaxInlineLevel;
>>>>>>>>>> support was removed in 15.0
>>>>>>>>>>> If we do it this way, the only test which I think should get fixed is
>>>>>>>>>> ReservedStackTest.
>>>>>>>>>>> I think it should be sufficient to add -XX:C1MaxInlineLevel=2 in
>>> order
>>>>> to
>>>>>>>>>> preserve the inlining behavior.
>>>>>>>>>>> (TestStringIntrinsics2: C1 doesn't have String intrinsics anymore.
>>>>>>>>>> compiler/c2 tests: Also written to test C2 specific things.)
>>>>>>>>>>> What do you think?
>>>>>>>>>> I would suggest to fix tests anyway (there are only few) because
>>> new
>>>>>>>>>> warning output could be unexpected.
>>>>>>>>>> And it will be future-proof when warning will be converted into
>>> error
>>>>>>>>>> (if/when C2 goes away).
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Martin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: hotspot-compiler-dev <hotspot-compiler-dev-
>>>>>>>>>>>> bounces at openjdk.java.net> On Behalf Of Vladimir Kozlov
>>>>>>>>>>>> Sent: Donnerstag, 7. Mai 2020 19:11
>>>>>>>>>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>>>> Subject: Re: RFR(S): 8235673: [C1, C2] Split inlining control flags
>>>>>>>>>>>>
>>>>>>>>>>>> I would suggest to build VM without C2 and run tests.
>>>>>>>>>>>>
>>>>>>>>>>>> I grepped tests with these flags I found next tests where we
>>> need
>>>>> to
>>>>>>> fix
>>>>>>>>>>>> test's command (add
>>>>>>>>>>>> -XX:+IgnoreUnrecognizedVMOptions) or add @requires
>>>>>>>>>>>> vm.compiler2.enabled or duplicate test for C1 with
>>> corresponding
>>>>> C1
>>>>>>>>>>>> flags (by ussing additional @test block).
>>>>>>>>>>>>
>>>>>>>>>>>> runtime/ReservedStack/ReservedStackTest.java
>>>>>>>>>>>> compiler/intrinsics/string/TestStringIntrinsics2.java
>>>>>>>>>>>> compiler/c2/Test6792161.java
>>>>>>>>>>>> compiler/c2/Test5091921.java
>>>>>>>>>>>>
>>>>>>>>>>>> And there is issue with compiler/compilercontrol tests which use
>>>>>>>>>>>> InlineSmallCode and I am not sure how to handle:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>> http://hg.openjdk.java.net/jdk/jdk/file/55e9cb6b23ec/test/hotspot/jtreg/c
>>>>>>>>>>>> ompiler/compilercontrol/share/scenario/Command.java#l36
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/4/20 9:04 AM, Doerr, Martin wrote:
>>>>>>>>>>>>> Hi Nils,
>>>>>>>>>>>>>
>>>>>>>>>>>>> thank you for looking at this and sorry for the late reply.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've added MaxTrivialSize and also updated the issue
>>> accordingly.
>>>>>>>>> Makes
>>>>>>>>>>>> sense.
>>>>>>>>>>>>> Do you have more flags in mind?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Moving the flags which are only used by C2 into c2_globals
>>>>> definitely
>>>>>>>>>> makes
>>>>>>>>>>>> sense.
>>>>>>>>>>>>> Done in webrev.01:
>>>>>>>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mdoerr/8235673_C1_inlining/webrev.01/
>>>>>>>>>>>>> Please take a look and let me know when my proposal is ready
>>> for
>>>>> a
>>>>>>>>> CSR.
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: hotspot-compiler-dev <hotspot-compiler-dev-
>>>>>>>>>>>>>> bounces at openjdk.java.net> On Behalf Of Nils Eliasson
>>>>>>>>>>>>>> Sent: Dienstag, 28. April 2020 18:29
>>>>>>>>>>>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>>>>>> Subject: Re: RFR(S): 8235673: [C1, C2] Split inlining control flags
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for addressing this! This has been an annoyance for a
>>>>> long
>>>>>>>>> time.
>>>>>>>>>>>>>> Have you though about including other flags - like
>>>>> MaxTrivialSize?
>>>>>>>>>>>>>> MaxInlineSize is tested against it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also - you should move the flags that are now c2-only to
>>>>>>>>>> c2_globals.hpp.
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Nils Eliasson
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2020-04-27 15:06, Doerr, Martin wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> while tuning inlining parameters for C2 compiler with JDK-
>>>>> 8234863
>>>>>>>>> we
>>>>>>>>>>>> had
>>>>>>>>>>>>>> discussed impact on C1.
>>>>>>>>>>>>>>> I still think it's bad to share them between both compilers.
>>> We
>>>>>>> may
>>>>>>>>>> want
>>>>>>>>>>>> to
>>>>>>>>>>>>>> do further C2 tuning without negative impact on C1 in the
>>> future.
>>>>>>>>>>>>>>> C1 has issues with substantial inlining because of the lack of
>>>>>>>>>> uncommon
>>>>>>>>>>>>>> traps. When C1 inlines a lot, stack frames may get large and
>>> code
>>>>>>>>> cache
>>>>>>>>>>>> space
>>>>>>>>>>>>>> may get wasted for cold or even never executed code. The
>>>>>>> situation
>>>>>>>>>> gets
>>>>>>>>>>>>>> worse when many patching stubs get used for such code.
>>>>>>>>>>>>>>> I had opened the following issue:
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235673
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And my initial proposal is here:
>>>>>>>>>>>>>>>
>>>>> http://cr.openjdk.java.net/~mdoerr/8235673_C1_inlining/webrev.00/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Part of my proposal is to add an additional flag which I called
>>>>>>>>>>>>>> C1InlineStackLimit to reduce stack utilization for C1 methods.
>>>>>>>>>>>>>>> I have a simple example which shows wasted stack space
>>> (java
>>>>>>>>>> example
>>>>>>>>>>>>>> TestStack at the end).
>>>>>>>>>>>>>>> It simply counts stack frames until a stack overflow occurs.
>>> With
>>>>>>> the
>>>>>>>>>>>> current
>>>>>>>>>>>>>> implementation, only 1283 frames fit on the stack because the
>>>>>>> never
>>>>>>>>>>>>>> executed method bogus_test with local variables gets inlined.
>>>>>>>>>>>>>>> Reduced C1InlineStackLimit avoids inlining of bogus_test and
>>>>> we
>>>>>>> get
>>>>>>>>>>>> 2310
>>>>>>>>>>>>>> frames until stack overflow. (I only used C1 for this example.
>>> Can
>>>>>>> be
>>>>>>>>>>>>>> reproduced as shown below.)
>>>>>>>>>>>>>>> I didn't notice any performance regression even with the
>>>>>>> aggressive
>>>>>>>>>>>> setting
>>>>>>>>>>>>>> of C1InlineStackLimit=5 with TieredCompilation.
>>>>>>>>>>>>>>> I know that I'll need a CSR for this change, but I'd like to get
>>>>>>>>> feedback
>>>>>>>>>> in
>>>>>>>>>>>>>> general and feedback about the flag names before creating a
>>>>> CSR.
>>>>>>>>>>>>>>> I'd also be glad about feedback regarding the performance
>>>>>>> impact.
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Command line:
>>>>>>>>>>>>>>> jdk/bin/java -XX:TieredStopAtLevel=1 -
>>>>> XX:C1InlineStackLimit=20 -
>>>>>>>>>>>>>> XX:C1MaxRecursiveInlineLevel=0 -Xss256k -Xbatch -
>>>>>>> XX:+PrintInlining
>>>>>>>>> -
>>>>>>> XX:CompileCommand=compileonly,TestStack::triggerStackOverflow
>>>>>>>>>>>>>> TestStack
>>>>>>>>>>>>>>> CompileCommand: compileonly
>>>>> TestStack.triggerStackOverflow
>>>>>>>>>>>>>>> @ 8 TestStack::triggerStackOverflow (15
>>>>> bytes)
>>>>>>>>>>>> recursive
>>>>>>>>>>>>>> inlining too deep
>>>>>>>>>>>>>>> @ 11 TestStack::bogus_test (33 bytes)
>>> inline
>>>>>>>>>>>>>>> caught java.lang.StackOverflowError
>>>>>>>>>>>>>>> 1283 activations were on stack, sum = 0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> jdk/bin/java -XX:TieredStopAtLevel=1 -
>>>>> XX:C1InlineStackLimit=10 -
>>>>>>>>>>>>>> XX:C1MaxRecursiveInlineLevel=0 -Xss256k -Xbatch -
>>>>>>> XX:+PrintInlining
>>>>>>>>> -
>>>>>>> XX:CompileCommand=compileonly,TestStack::triggerStackOverflow
>>>>>>>>>>>>>> TestStack
>>>>>>>>>>>>>>> CompileCommand: compileonly
>>>>> TestStack.triggerStackOverflow
>>>>>>>>>>>>>>> @ 8 TestStack::triggerStackOverflow (15
>>>>> bytes)
>>>>>>>>>>>> recursive
>>>>>>>>>>>>>> inlining too deep
>>>>>>>>>>>>>>> @ 11 TestStack::bogus_test (33 bytes)
>>> callee
>>>>>>> uses
>>>>>>>>>> too
>>>>>>>>>>>>>> much stack
>>>>>>>>>>>>>>> caught java.lang.StackOverflowError
>>>>>>>>>>>>>>> 2310 activations were on stack, sum = 0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> TestStack.java:
>>>>>>>>>>>>>>> public class TestStack {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> static long cnt = 0,
>>>>>>>>>>>>>>> sum = 0;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public static void bogus_test() {
>>>>>>>>>>>>>>> long c1 = 1, c2 = 2, c3 = 3, c4 = 4;
>>>>>>>>>>>>>>> sum += c1 + c2 + c3 + c4;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public static void triggerStackOverflow() {
>>>>>>>>>>>>>>> cnt++;
>>>>>>>>>>>>>>> triggerStackOverflow();
>>>>>>>>>>>>>>> bogus_test();
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> public static void main(String args[]) {
>>>>>>>>>>>>>>> try {
>>>>>>>>>>>>>>> triggerStackOverflow();
>>>>>>>>>>>>>>> } catch (StackOverflowError e) {
>>>>>>>>>>>>>>> System.out.println("caught " + e);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> System.out.println(cnt + " activations were on stack,
>>> sum
>>>>> = "
>>>>>>> +
>>>>>>>>>>>> sum);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
More information about the hotspot-compiler-dev
mailing list