Re: [9, 8u40] RFR (M): 8063135: Enable full LF sharing by default
On 11/18/2014 11:23 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8063135/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8063135 Broken array index here: 69 TRACE_METHOD_LINKAGE = (Boolean) values[3]; 70 COMPILE_THRESHOLD = (Integer) values[5]; Also, how does it pass the tests? It should fail with AIOBE during MethodHandleStatics::, since 53 final Object[] values = new Object[7]; ... 72 PROFILE_LEVEL = (Integer) values[7]; Thanks, -Aleksey. signature.asc Description: OpenPGP digital signature ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [9, 8u40] RFR (XXS): 8059880: Get rid of LambdaForm interpretation
On 11/19/2014 12:01 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8059880/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059880 Yes, for the love of God, GO FOR IT. -Aleksey. signature.asc Description: OpenPGP digital signature ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[9, 8u40] RFR (XXS): 8059880: Get rid of LambdaForm interpretation
http://cr.openjdk.java.net/~vlivanov/8059880/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8059880 Once full LambdaForm sharing is on by default, amount of instantiated LambdaForms drastically reduces. On Octane it varies from 1k to 3k depending on the subbenchmark (was up to 300k before LF sharing-related changes). It allows to skip interpretation step without inducing slowdown at startup. Every LambdaForm is precompiled once it is instantiated. Avoiding LF interpretation significantly reduces worst-case stack usage (4-5 stack frames per interpreted LF to 1 stack frame per compiled LF). The fix is to set COMPILE_THRESHOLD down to 0. It triggers LF precompilation for every LF. Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, octane Thanks! Best regards, Vladimir Ivanov ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: MemberName$Factory.resolve() and the Eclipse debugger.
Does anyone here know the best way to engage with the Eclipse developers on this kind of thing? We will try their mailing list ( http://dev.eclipse.org/mhonarc/lists/jdt-debug-dev/), but it's eerily quiet George On Tue, Nov 18, 2014 at 3:29 PM, MacGregor, Duncan (GE Energy Management) < duncan.macgre...@ge.com> wrote: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=449791 > > > On 18/11/2014 14:06, "Marcus Lagergren" > wrote: > > >Nicely done, Duncan. Do you have a link to the issue report? > > > >Regards > >Marcus > > > >> On 03 Nov 2014, at 16:48, MacGregor, Duncan (GE Energy Management) > >> wrote: > >> > >> I’ve reported an Eclipse bug. Doesn’t look like their debugger has ever > >> done quite the right thing, unless the behaviour of the JVM has changed > >> significantly. > >> > >> On 03/11/2014 15:33, "Christian Thalinger" > >> wrote: > >> > >>> Interesting. Thanks for digging deep. > >>> > On Oct 31, 2014, at 8:36 AM, MacGregor, Duncan (GE Energy Management) > wrote: > > Okay, I now know why the JVM is stuck for so long, just not why > Eclipse > is > doing what it does. > > At certain points during the loading of our application Eclipse will > make > a large number (upto 1) jdwp classesForSignature requests, each of > which causes the jdwp lib to trawl over a large number of classes > (several > 10s of thousands), resulting in upto a couple hundred million jvmti > GetClassSignature calls, and is particularly pointless because it > fails > to > find any of these classes. > > That last bit gave me a clue. These large numbers of > classesForSignature > requests occur when classes have been GCed, and a request is being > issued > for every single class that has been successfully Gced. Since we¹re > careful to ensure that all the code we dynamically execute at startup > is > done in temporary class loaders so that the everything can be Gced > away, > and since variance LF stuff can also be Gced, the problem is much > worse > than it would be in other applications. > > It¹s really bad in earlier 8 updates without the LF editor work > because > there¹s more classes and more getting Gced, so I¹ve seen 3 minute long > pauses with that version. > > I guess this should be reported as a bug to the Eclipse debug team, > but > I > wonder if classesForSignature can¹t be made faster in some way. > > Regards, Duncan. > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >>> > >>> ___ > >>> mlvm-dev mailing list > >>> mlvm-dev@openjdk.java.net > >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >> > >> ___ > >> mlvm-dev mailing list > >> mlvm-dev@openjdk.java.net > >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > >___ > >mlvm-dev mailing list > >mlvm-dev@openjdk.java.net > >http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[9, 8u40] RFR (M): 8063135: Enable full LF sharing by default
http://cr.openjdk.java.net/~vlivanov/8063135/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8063135 Turn on full LambdaForm sharing and get rid of custom LambdaForm shapes. 8059877 [1] eliminated most of the regressions caused by LF sharing. The rest will be addressed separately [2]. Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, octane Thanks! Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8059877 [2] https://bugs.openjdk.java.net/browse/JDK-8063137 ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: MemberName$Factory.resolve() and the Eclipse debugger.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=449791 On 18/11/2014 14:06, "Marcus Lagergren" wrote: >Nicely done, Duncan. Do you have a link to the issue report? > >Regards >Marcus > >> On 03 Nov 2014, at 16:48, MacGregor, Duncan (GE Energy Management) >> wrote: >> >> I’ve reported an Eclipse bug. Doesn’t look like their debugger has ever >> done quite the right thing, unless the behaviour of the JVM has changed >> significantly. >> >> On 03/11/2014 15:33, "Christian Thalinger" >> wrote: >> >>> Interesting. Thanks for digging deep. >>> On Oct 31, 2014, at 8:36 AM, MacGregor, Duncan (GE Energy Management) wrote: Okay, I now know why the JVM is stuck for so long, just not why Eclipse is doing what it does. At certain points during the loading of our application Eclipse will make a large number (upto 1) jdwp classesForSignature requests, each of which causes the jdwp lib to trawl over a large number of classes (several 10s of thousands), resulting in upto a couple hundred million jvmti GetClassSignature calls, and is particularly pointless because it fails to find any of these classes. That last bit gave me a clue. These large numbers of classesForSignature requests occur when classes have been GCed, and a request is being issued for every single class that has been successfully Gced. Since we¹re careful to ensure that all the code we dynamically execute at startup is done in temporary class loaders so that the everything can be Gced away, and since variance LF stuff can also be Gced, the problem is much worse than it would be in other applications. It¹s really bad in earlier 8 updates without the LF editor work because there¹s more classes and more getting Gced, so I¹ve seen 3 minute long pauses with that version. I guess this should be reported as a bug to the Eclipse debug team, but I wonder if classesForSignature can¹t be made faster in some way. Regards, Duncan. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> ___ >>> mlvm-dev mailing list >>> mlvm-dev@openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> ___ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >___ >mlvm-dev mailing list >mlvm-dev@openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: MemberName$Factory.resolve() and the Eclipse debugger.
Nicely done, Duncan. Do you have a link to the issue report? Regards Marcus > On 03 Nov 2014, at 16:48, MacGregor, Duncan (GE Energy Management) > wrote: > > I’ve reported an Eclipse bug. Doesn’t look like their debugger has ever > done quite the right thing, unless the behaviour of the JVM has changed > significantly. > > On 03/11/2014 15:33, "Christian Thalinger" > wrote: > >> Interesting. Thanks for digging deep. >> >>> On Oct 31, 2014, at 8:36 AM, MacGregor, Duncan (GE Energy Management) >>> wrote: >>> >>> Okay, I now know why the JVM is stuck for so long, just not why Eclipse >>> is >>> doing what it does. >>> >>> At certain points during the loading of our application Eclipse will >>> make >>> a large number (upto 1) jdwp classesForSignature requests, each of >>> which causes the jdwp lib to trawl over a large number of classes >>> (several >>> 10s of thousands), resulting in upto a couple hundred million jvmti >>> GetClassSignature calls, and is particularly pointless because it fails >>> to >>> find any of these classes. >>> >>> That last bit gave me a clue. These large numbers of classesForSignature >>> requests occur when classes have been GCed, and a request is being >>> issued >>> for every single class that has been successfully Gced. Since we¹re >>> careful to ensure that all the code we dynamically execute at startup is >>> done in temporary class loaders so that the everything can be Gced away, >>> and since variance LF stuff can also be Gced, the problem is much worse >>> than it would be in other applications. >>> >>> It¹s really bad in earlier 8 updates without the LF editor work because >>> there¹s more classes and more getting Gced, so I¹ve seen 3 minute long >>> pauses with that version. >>> >>> I guess this should be reported as a bug to the Eclipse debug team, but >>> I >>> wonder if classesForSignature can¹t be made faster in some way. >>> >>> Regards, Duncan. >>> >>> ___ >>> mlvm-dev mailing list >>> mlvm-dev@openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> ___ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
