[8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option
Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9. Thanks -Konstantin
Have you tried to reduce iteration granularity? Probably, checking execution duration on every test case is more robust. Best regards, Vladimir Ivanov On 5/27/15 5:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9.
Thanks
-Konstantin
Vladimir, This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters". Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug. By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed. -Konstantin On 27.05.2015 19:54, Vladimir Ivanov wrote:
Have you tried to reduce iteration granularity?
Probably, checking execution duration on every test case is more robust.
Best regards, Vladimir Ivanov
On 5/27/15 5:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9.
Thanks
-Konstantin
Got it, thanks. Can we ignore errors caused by code cache overflow for now? Best regards, Vladimir Ivanov On 5/28/15 12:03 PM, Konstantin Shefov wrote:
Vladimir,
This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters".
Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug.
By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed.
-Konstantin
On 27.05.2015 19:54, Vladimir Ivanov wrote:
Have you tried to reduce iteration granularity?
Probably, checking execution duration on every test case is more robust.
Best regards, Vladimir Ivanov
On 5/27/15 5:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9.
Thanks
-Konstantin
Vladimir, What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? -Konstantin On 28.05.2015 21:22, Vladimir Ivanov wrote:
Got it, thanks.
Can we ignore errors caused by code cache overflow for now?
Best regards, Vladimir Ivanov
On 5/28/15 12:03 PM, Konstantin Shefov wrote:
Vladimir,
This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters".
Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug.
By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed.
-Konstantin
On 27.05.2015 19:54, Vladimir Ivanov wrote:
Have you tried to reduce iteration granularity?
Probably, checking execution duration on every test case is more robust.
Best regards, Vladimir Ivanov
On 5/27/15 5:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9.
Thanks
-Konstantin
What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?
Best regards, Vladimir Ivanov
On 28.05.2015 21:22, Vladimir Ivanov wrote:
Got it, thanks.
Can we ignore errors caused by code cache overflow for now?
Best regards, Vladimir Ivanov
On 5/28/15 12:03 PM, Konstantin Shefov wrote:
Vladimir,
This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters".
Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug.
By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed.
-Konstantin
On 27.05.2015 19:54, Vladimir Ivanov wrote:
Have you tried to reduce iteration granularity?
Probably, checking execution duration on every test case is more robust.
Best regards, Vladimir Ivanov
On 5/27/15 5:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9.
Thanks
-Konstantin
Hi Vladmir It seems we have only this bug that manifests the problem. As I understand, this is a product issue, not test. -Konstantin On 29.05.2015 14:49, Vladimir Ivanov wrote:
What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?
Best regards, Vladimir Ivanov
On 28.05.2015 21:22, Vladimir Ivanov wrote:
Got it, thanks.
Can we ignore errors caused by code cache overflow for now?
Best regards, Vladimir Ivanov
On 5/28/15 12:03 PM, Konstantin Shefov wrote:
Vladimir,
This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters".
Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug.
By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed.
-Konstantin
On 27.05.2015 19:54, Vladimir Ivanov wrote:
Have you tried to reduce iteration granularity?
Probably, checking execution duration on every test case is more robust.
Best regards, Vladimir Ivanov
On 5/27/15 5:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9.
Thanks
-Konstantin
Konstantin,
It seems we have only this bug that manifests the problem. As I understand, this is a product issue, not test. My question was about the symptoms - how the test can fail. If the test ignores NSME & VME exceptions, will it always pass w.r.t. code cache overflows?
Code cache overflow is definitely a JVM problem, but we don't plan to address it in the near future. So, either the test should be excluded or adjusted to be tolerant to code cache overflows. Best regards, Vladimir Ivanov
-Konstantin
On 29.05.2015 14:49, Vladimir Ivanov wrote:
What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?
Best regards, Vladimir Ivanov
On 28.05.2015 21:22, Vladimir Ivanov wrote:
Got it, thanks.
Can we ignore errors caused by code cache overflow for now?
Best regards, Vladimir Ivanov
On 5/28/15 12:03 PM, Konstantin Shefov wrote:
Vladimir,
This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters".
Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug.
By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed.
-Konstantin
On 27.05.2015 19:54, Vladimir Ivanov wrote:
Have you tried to reduce iteration granularity?
Probably, checking execution duration on every test case is more robust.
Best regards, Vladimir Ivanov
On 5/27/15 5:50 PM, Konstantin Shefov wrote: > Hello, > > Please review the test bug fix > https://bugs.openjdk.java.net/browse/JDK-8062904 > Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ > Test fails only against JDK 8u and passes against JDK 9. > > Thanks > > -Konstantin
Hi Vladimir On 02.06.2015 21:51, Vladimir Ivanov wrote:
Konstantin,
It seems we have only this bug that manifests the problem. As I understand, this is a product issue, not test. My question was about the symptoms - how the test can fail. If the test ignores NSME & VME exceptions, will it always pass w.r.t. code cache overflows?
Code cache overflow is definitely a JVM problem, but we don't plan to address it in the near future.
So, either the test should be excluded or adjusted to be tolerant to code cache overflows.
The test has the code cache overflow failure only when run with "-Xcomp", all other failures has been fixed by https://bugs.openjdk.java.net/browse/JDK-8058733 So my suggestion is either to exclude this test when run with -Xcomp or (better) to reduce iteration number to 1 when -Xcomp, so that no code cache overflow in this case. -Konstantin
Best regards, Vladimir Ivanov
-Konstantin
On 29.05.2015 14:49, Vladimir Ivanov wrote:
What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?
Best regards, Vladimir Ivanov
On 28.05.2015 21:22, Vladimir Ivanov wrote:
Got it, thanks.
Can we ignore errors caused by code cache overflow for now?
Best regards, Vladimir Ivanov
On 5/28/15 12:03 PM, Konstantin Shefov wrote:
Vladimir,
This fix is not for timeout issue, this fix is for "java.lang.VirtualMachineError: out of space in CodeCache for adapters".
Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug.
By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed.
-Konstantin
On 27.05.2015 19:54, Vladimir Ivanov wrote: > Have you tried to reduce iteration granularity? > > Probably, checking execution duration on every test case is more > robust. > > Best regards, > Vladimir Ivanov > > On 5/27/15 5:50 PM, Konstantin Shefov wrote: >> Hello, >> >> Please review the test bug fix >> https://bugs.openjdk.java.net/browse/JDK-8062904 >> Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ >> Test fails only against JDK 8u and passes against JDK 9. >> >> Thanks >> >> -Konstantin
Vladimir, I have verified the failure again. Even if I use random seed that causes failure against JDK 8u60, the test passes against JDK 9 with this seed. So JDK-8062904 ([1]) is really reproduced only against JDK 8u, not JDK 9. And failure happens only with -Xcomp option. I think it is a product failure. [1] https://bugs.openjdk.java.net/browse/JDK-8062904 -Konstantin On 06/03/2015 12:44 PM, Konstantin Shefov wrote:
Hi Vladimir
On 02.06.2015 21:51, Vladimir Ivanov wrote:
Konstantin,
It seems we have only this bug that manifests the problem. As I understand, this is a product issue, not test. My question was about the symptoms - how the test can fail. If the test ignores NSME & VME exceptions, will it always pass w.r.t. code cache overflows?
Code cache overflow is definitely a JVM problem, but we don't plan to address it in the near future.
So, either the test should be excluded or adjusted to be tolerant to code cache overflows.
The test has the code cache overflow failure only when run with "-Xcomp", all other failures has been fixed by https://bugs.openjdk.java.net/browse/JDK-8058733 So my suggestion is either to exclude this test when run with -Xcomp or (better) to reduce iteration number to 1 when -Xcomp, so that no code cache overflow in this case.
-Konstantin
Best regards, Vladimir Ivanov
-Konstantin
On 29.05.2015 14:49, Vladimir Ivanov wrote:
What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?
Best regards, Vladimir Ivanov
On 28.05.2015 21:22, Vladimir Ivanov wrote:
Got it, thanks.
Can we ignore errors caused by code cache overflow for now?
Best regards, Vladimir Ivanov
On 5/28/15 12:03 PM, Konstantin Shefov wrote: > Vladimir, > > This fix is not for timeout issue, this fix is for > "java.lang.VirtualMachineError: out of space in CodeCache for > adapters". > > Timeout issue is other bug and should be filed separately. > I do not know why SQE added RULES with timeout to this bug. > > By the way, if -Xcomp is set on JDK 8u, test works if not more than > one > iteration is allowed. The same thing was for JDK 9 until > JDK-8046809 had > been fixed. > > -Konstantin > > On 27.05.2015 19:54, Vladimir Ivanov wrote: >> Have you tried to reduce iteration granularity? >> >> Probably, checking execution duration on every test case is more >> robust. >> >> Best regards, >> Vladimir Ivanov >> >> On 5/27/15 5:50 PM, Konstantin Shefov wrote: >>> Hello, >>> >>> Please review the test bug fix >>> https://bugs.openjdk.java.net/browse/JDK-8062904 >>> Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ >>> Test fails only against JDK 8u and passes against JDK 9. >>> >>> Thanks >>> >>> -Konstantin >
Konstantin,
The test has the code cache overflow failure only when run with "-Xcomp", all other failures has been fixed by https://bugs.openjdk.java.net/browse/JDK-8058733 So my suggestion is either to exclude this test when run with -Xcomp or (better) to reduce iteration number to 1 when -Xcomp, so that no code cache overflow in this case. I'd like to get an answer to my previous question: "How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?"
Most notably, have you seen VM crashes w/ -Xcomp running that test? Best regards, Vladimir Ivanov
-Konstantin
Best regards, Vladimir Ivanov
-Konstantin
On 29.05.2015 14:49, Vladimir Ivanov wrote:
What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?
Best regards, Vladimir Ivanov
On 28.05.2015 21:22, Vladimir Ivanov wrote:
Got it, thanks.
Can we ignore errors caused by code cache overflow for now?
Best regards, Vladimir Ivanov
On 5/28/15 12:03 PM, Konstantin Shefov wrote: > Vladimir, > > This fix is not for timeout issue, this fix is for > "java.lang.VirtualMachineError: out of space in CodeCache for > adapters". > > Timeout issue is other bug and should be filed separately. > I do not know why SQE added RULES with timeout to this bug. > > By the way, if -Xcomp is set on JDK 8u, test works if not more than > one > iteration is allowed. The same thing was for JDK 9 until > JDK-8046809 had > been fixed. > > -Konstantin > > On 27.05.2015 19:54, Vladimir Ivanov wrote: >> Have you tried to reduce iteration granularity? >> >> Probably, checking execution duration on every test case is more >> robust. >> >> Best regards, >> Vladimir Ivanov >> >> On 5/27/15 5:50 PM, Konstantin Shefov wrote: >>> Hello, >>> >>> Please review the test bug fix >>> https://bugs.openjdk.java.net/browse/JDK-8062904 >>> Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ >>> Test fails only against JDK 8u and passes against JDK 9. >>> >>> Thanks >>> >>> -Konstantin >
Vladimir On 06/05/2015 01:16 PM, Vladimir Ivanov wrote:
Konstantin,
The test has the code cache overflow failure only when run with "-Xcomp", all other failures has been fixed by https://bugs.openjdk.java.net/browse/JDK-8058733 So my suggestion is either to exclude this test when run with -Xcomp or (better) to reduce iteration number to 1 when -Xcomp, so that no code cache overflow in this case. I'd like to get an answer to my previous question: "How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?"
Most notably, have you seen VM crashes w/ -Xcomp running that test? I have seen no crashes with -Xcomp in our tests results base, only NoSuchMethodException and VirtualMachineError. This failure does not occur with JDK 9 on -Xcomp, I used the same random seeds (-Dseed), and the problem exists only with JDK 8u, not JDK 9.
Because there is no failure with JDK 9 I can suppose there could be a product issue in JDK 8u. -Konstantin
Best regards, Vladimir Ivanov
-Konstantin
Best regards, Vladimir Ivanov
-Konstantin
On 29.05.2015 14:49, Vladimir Ivanov wrote:
What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?
Best regards, Vladimir Ivanov
On 28.05.2015 21:22, Vladimir Ivanov wrote: > Got it, thanks. > > Can we ignore errors caused by code cache overflow for now? > > Best regards, > Vladimir Ivanov > > On 5/28/15 12:03 PM, Konstantin Shefov wrote: >> Vladimir, >> >> This fix is not for timeout issue, this fix is for >> "java.lang.VirtualMachineError: out of space in CodeCache for >> adapters". >> >> Timeout issue is other bug and should be filed separately. >> I do not know why SQE added RULES with timeout to this bug. >> >> By the way, if -Xcomp is set on JDK 8u, test works if not more >> than >> one >> iteration is allowed. The same thing was for JDK 9 until >> JDK-8046809 had >> been fixed. >> >> -Konstantin >> >> On 27.05.2015 19:54, Vladimir Ivanov wrote: >>> Have you tried to reduce iteration granularity? >>> >>> Probably, checking execution duration on every test case is more >>> robust. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 5/27/15 5:50 PM, Konstantin Shefov wrote: >>>> Hello, >>>> >>>> Please review the test bug fix >>>> https://bugs.openjdk.java.net/browse/JDK-8062904 >>>> Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ >>>> Test fails only against JDK 8u and passes against JDK 9. >>>> >>>> Thanks >>>> >>>> -Konstantin >>
Konstantin,
I'd like to get an answer to my previous question: "How reliable the test is if it ignores NoSuchMethodException & VirtualMachineError? Are there other manifestations of the problem?"
Most notably, have you seen VM crashes w/ -Xcomp running that test? I have seen no crashes with -Xcomp in our tests results base, only NoSuchMethodException and VirtualMachineError. Good. Thanks for the info.
This failure does not occur with JDK 9 on -Xcomp, I used the same random seeds (-Dseed), and the problem exists only with JDK 8u, not JDK 9.
Because there is no failure with JDK 9 I can suppose there could be a product issue in JDK 8u. That's strange. There should be no difference in MethodHandle stub management between 8u & 9 now (once allocated they stay forever). 9 has segmented code cache feature and it can lead to observable differences in behavior.
How many iterations does the test perform on 8u & 9? What if you increase the number? Also, I'd suggest you to monitor code cache usage during the run and when the test finishes. Best regards, Vladimir Ivanov
participants (2)
-
Konstantin Shefov
-
Vladimir Ivanov