[8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: "GC overhead limit exceeded"
Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9. Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84. Thanks -Konstantin
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise. Regards, Sean. On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
Konstantin, do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it. Igor On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
Igor, It seems I have given you wrong information. This test fails with OOME against JDK 9 also, I managed to reproduce the failure now. It was hard to reproduce it because of randomness, I need to rerun the test 50 times. Although the test seems to fail with OOME more often against JDK 8u, but I think it is just factor of randomness in the test. So I do not think it is a product bug then. -Konstantin On 06/03/2015 11:47 PM, Igor Ignatyev wrote:
Konstantin,
do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
Konstantin, could you please run the test on JDK 9 w/ the seed values which lead to failures on JDK 8u? and please update the bug w/ gotten information. Thanks, Igor On 06/04/2015 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME against JDK 9 also, I managed to reproduce the failure now. It was hard to reproduce it because of randomness, I need to rerun the test 50 times. Although the test seems to fail with OOME more often against JDK 8u, but I think it is just factor of randomness in the test.
So I do not think it is a product bug then.
-Konstantin
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:try to reproduce failres
Konstantin,
do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
Igor, I have added comment to https://bugs.openjdk.java.net/browse/JDK-8068416 Tried 10 seeds, for all of them test fails with OOME for both 8u60 and 9. -Konstantin On 06/04/2015 12:15 PM, Igor Ignatyev wrote:
Konstantin,
could you please run the test on JDK 9 w/ the seed values which lead to failures on JDK 8u? and please update the bug w/ gotten information.
Thanks, Igor
On 06/04/2015 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME against JDK 9 also, I managed to reproduce the failure now. It was hard to reproduce it because of randomness, I need to rerun the test 50 times. Although the test seems to fail with OOME more often against JDK 8u, but I think it is just factor of randomness in the test.
So I do not think it is a product bug then.
-Konstantin
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:try to reproduce failres
Konstantin,
do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
Konstantin, Have you looked into the heap dump to understand why the test provokes an OOM? Limiting test iterations is counter-productive, because it defeats the purpose of the test. Probably, the failure is caused by BMHs which aren't collected (see JDK-8078602 [1]). In that case I'd prefer the test to be excluded until BMHs are converted to VM anonymous classes. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8078602 On 6/4/15 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME against JDK 9 also, I managed to reproduce the failure now. It was hard to reproduce it because of randomness, I need to rerun the test 50 times. Although the test seems to fail with OOME more often against JDK 8u, but I think it is just factor of randomness in the test.
So I do not think it is a product bug then.
-Konstantin
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:
Konstantin,
do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
Vladimir In all cases when OOME happens the test operates with BoundMethodHandle$SpeciesData class, so it indeed may be caused by JDK-8078602. But is it a good idea of excluding the test? LFGarbageCollectedTest.java fails not every time and may catch other product issues if they happen. We can just leave it unchanged and close JDK-8068416 as a duplicate of JDK-8078602. -Konstantin On 06/04/2015 12:50 PM, Vladimir Ivanov wrote:
Konstantin,
Have you looked into the heap dump to understand why the test provokes an OOM? Limiting test iterations is counter-productive, because it defeats the purpose of the test.
Probably, the failure is caused by BMHs which aren't collected (see JDK-8078602 [1]). In that case I'd prefer the test to be excluded until BMHs are converted to VM anonymous classes.
Best regards, Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8078602
On 6/4/15 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME against JDK 9 also, I managed to reproduce the failure now. It was hard to reproduce it because of randomness, I need to rerun the test 50 times. Although the test seems to fail with OOME more often against JDK 8u, but I think it is just factor of randomness in the test.
So I do not think it is a product bug then.
-Konstantin
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:
Konstantin,
do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
Konstantin,
In all cases when OOME happens the test operates with BoundMethodHandle$SpeciesData class, so it indeed may be caused by JDK-8078602. It's not necessarily an evidence. Most of method handles are BMHs. So, I'd suggest to inspect the heap dump.
But is it a good idea of excluding the test? LFGarbageCollectedTest.java fails not every time and may catch other product issues if they happen. We can just leave it unchanged and close JDK-8068416 as a duplicate of JDK-8078602. No, intermittent test failures are not acceptable. Unless there's a way to limit produced BMHs count, the test should be excluded until JDK-8078602 is fixed.
Best regards, Vladimir Ivanov
-Konstantin
On 06/04/2015 12:50 PM, Vladimir Ivanov wrote:
Konstantin,
Have you looked into the heap dump to understand why the test provokes an OOM? Limiting test iterations is counter-productive, because it defeats the purpose of the test.
Probably, the failure is caused by BMHs which aren't collected (see JDK-8078602 [1]). In that case I'd prefer the test to be excluded until BMHs are converted to VM anonymous classes.
Best regards, Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8078602
On 6/4/15 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME against JDK 9 also, I managed to reproduce the failure now. It was hard to reproduce it because of randomness, I need to rerun the test 50 times. Although the test seems to fail with OOME more often against JDK 8u, but I think it is just factor of randomness in the test.
So I do not think it is a product bug then.
-Konstantin
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:
Konstantin,
do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
Vladimir On 06/04/2015 02:19 PM, Vladimir Ivanov wrote:
Konstantin,
In all cases when OOME happens the test operates with BoundMethodHandle$SpeciesData class, so it indeed may be caused by JDK-8078602. It's not necessarily an evidence. Most of method handles are BMHs. So, I'd suggest to inspect the heap dump. I will inspect the heap dump. If it is really JDK-8078602, I will exclude the test.
-Konstantin
But is it a good idea of excluding the test? LFGarbageCollectedTest.java fails not every time and may catch other product issues if they happen. We can just leave it unchanged and close JDK-8068416 as a duplicate of JDK-8078602. No, intermittent test failures are not acceptable. Unless there's a way to limit produced BMHs count, the test should be excluded until JDK-8078602 is fixed.
Best regards, Vladimir Ivanov
-Konstantin
On 06/04/2015 12:50 PM, Vladimir Ivanov wrote:
Konstantin,
Have you looked into the heap dump to understand why the test provokes an OOM? Limiting test iterations is counter-productive, because it defeats the purpose of the test.
Probably, the failure is caused by BMHs which aren't collected (see JDK-8078602 [1]). In that case I'd prefer the test to be excluded until BMHs are converted to VM anonymous classes.
Best regards, Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8078602
On 6/4/15 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME against JDK 9 also, I managed to reproduce the failure now. It was hard to reproduce it because of randomness, I need to rerun the test 50 times. Although the test seems to fail with OOME more often against JDK 8u, but I think it is just factor of randomness in the test.
So I do not think it is a product bug then.
-Konstantin
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:
Konstantin,
do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote: > Hello, > > Please review the test bug fix > https://bugs.openjdk.java.net/browse/JDK-8068416 > Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ > Test fails only against JDK 8u and passes against JDK 9. > > Fix is to reduce the number of iterations to 40. With that > number of > iterations the test passes on those hosts where it failed before. > The number of iterations the test start to fail is 65. > Before the fix the number of iterations was 84. > > Thanks > -Konstantin
Vladimir I looked at heap dump using jhat tool. Heap contained 2452 occurences of java.lang.invoke.BoundMethodHandle$Species_* classes by the moment OOME happened. So looks like java.lang.invoke.BoundMethodHandle$Species_* classesare not unloading as it is said in JDK-8078602 [1]. So I will exclude the test with "@ignore 8078602" tag. [1] https://bugs.openjdk.java.net/browse/JDK-8078602 -Konstantin On 06/04/2015 02:28 PM, Konstantin Shefov wrote:
Vladimir
On 06/04/2015 02:19 PM, Vladimir Ivanov wrote:
Konstantin,
In all cases when OOME happens the test operates with BoundMethodHandle$SpeciesData class, so it indeed may be caused by JDK-8078602. It's not necessarily an evidence. Most of method handles are BMHs. So, I'd suggest to inspect the heap dump. I will inspect the heap dump. If it is really JDK-8078602, I will exclude the test.
-Konstantin
But is it a good idea of excluding the test? LFGarbageCollectedTest.java fails not every time and may catch other product issues if they happen. We can just leave it unchanged and close JDK-8068416 as a duplicate of JDK-8078602. No, intermittent test failures are not acceptable. Unless there's a way to limit produced BMHs count, the test should be excluded until JDK-8078602 is fixed.
Best regards, Vladimir Ivanov
-Konstantin
On 06/04/2015 12:50 PM, Vladimir Ivanov wrote:
Konstantin,
Have you looked into the heap dump to understand why the test provokes an OOM? Limiting test iterations is counter-productive, because it defeats the purpose of the test.
Probably, the failure is caused by BMHs which aren't collected (see JDK-8078602 [1]). In that case I'd prefer the test to be excluded until BMHs are converted to VM anonymous classes.
Best regards, Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8078602
On 6/4/15 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with OOME against JDK 9 also, I managed to reproduce the failure now. It was hard to reproduce it because of randomness, I need to rerun the test 50 times. Although the test seems to fail with OOME more often against JDK 8u, but I think it is just factor of randomness in the test.
So I do not think it is a product bug then.
-Konstantin
On 06/03/2015 11:47 PM, Igor Ignatyev wrote:
Konstantin,
do you have an explanation why the test passes on jdk 9? from my point of view, it indicates there is a product bug in 8u which should be fixed and your fix just hides it.
Igor
On 06/03/2015 10:14 PM, Seán Coffey wrote: > I bumped into this failure myself today. I think you've got a typo. > 440 should be 40. Looks like a good approach otherwise. > > Regards, > Sean. > > On 03/06/2015 17:33, Konstantin Shefov wrote: >> Hello, >> >> Please review the test bug fix >> https://bugs.openjdk.java.net/browse/JDK-8068416 >> Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ >> Test fails only against JDK 8u and passes against JDK 9. >> >> Fix is to reduce the number of iterations to 40. With that >> number of >> iterations the test passes on those hosts where it failed before. >> The number of iterations the test start to fail is 65. >> Before the fix the number of iterations was 84. >> >> Thanks >> -Konstantin >
Hi Sean, there should be exactly 440, because 11 cycles is one iteration. -Konstantin On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo. 440 should be 40. Looks like a good approach otherwise.
Regards, Sean.
On 03/06/2015 17:33, Konstantin Shefov wrote:
Hello,
Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8068416 Webrev is http://cr.openjdk.java.net/~kshefov/8068416/webrev.00/ Test fails only against JDK 8u and passes against JDK 9.
Fix is to reduce the number of iterations to 40. With that number of iterations the test passes on those hosts where it failed before. The number of iterations the test start to fail is 65. Before the fix the number of iterations was 84.
Thanks -Konstantin
participants (4)
-
Igor Ignatyev
-
Konstantin Shefov
-
Seán Coffey
-
Vladimir Ivanov