Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [8u-dev] Review request : JDK-8068416: LFGarbageCollectedTest.java fails with OOME: GC overhead limit exceeded
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 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
