Re: RFC: JDK-8031043: ClassValue's backing map should have a smaller initial size
Am 08.01.2014 21:45, schrieb Christian Thalinger: [...] > If we’d go with an initial value of 1 would it be a performance problem for > you if it grows automatically? that means the map will have to grow for hundreds of classes at startup. I don't know how much impact that will have bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: State of lambda forms stealing stack frames?
Jochen, There's some work going on to reduce heap and stack usage for LambdaForm-based JSR292 implementation in 8update. Backporting it to 7u will be also considered. Best regards, Vladimir Ivanov On 1/7/14 7:55 PM, Jochen Theodorou wrote: > Am 06.01.2014 19:48, schrieb Andrew Haley: > [...] >> I think that wnat is happening is that you (and Groovy) are >> unfortunate to be a victim of a design decision that was made a year >> or so ago. Back then, invokedynamic was handled by a ton of >> hard-to-maintain C++ code. The HotSpot team decide to throw much of >> it away and generate bytecode instead, in the hope that the optimizer >> would be able to "see through" all the invocations and smash it all >> down to a single call in many cases. Generally speaking, this does >> work. However, it can take a while before the optimizer kicks in, and >> by this time your stack has already overflowed. > > yes, I am aware of the decision... only I was not realizing this problem > back then. > >> Having said all of that, the lambdas must be fairly amazing to require >> such a lot of work. I don't know what fib$_closure1 looks like. > > fib$_closure1.doCall is the the doCall method of the generated > groovy.lang.Closure which is used for the memoization. As of why it does > produces such an extremely complex handle is unclear to me too actually. > I think part of the output is related to fallbacks in case the > arguments, receiver and such do not fit, also the is a guard with catch, > that may produce some of it. > > > bye Jochen > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFC: JDK-8031043: ClassValue's backing map should have a smaller initial size
On Jan 9, 2014, at 2:46 AM, Jochen Theodorou wrote: > Am 08.01.2014 21:45, schrieb Christian Thalinger: > [...] >> If we’d go with an initial value of 1 would it be a performance problem for >> you if it grows automatically? > > that means the map will have to grow for hundreds of classes at startup. > I don't know how much impact that will have If it’s only hundreds it’s probably negligible. You could do a simple experiment if you are worried: change ClassValueMap.INITIAL_ENTRIES to 1, compile it and prepend it to the bootclasspath. > > bye Jochen > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > > ___ > 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: RFC: JDK-8031043: ClassValue's backing map should have a smaller initial size
It depends how JRuby is deployed. If the same code runs in every JRuby runtime, then there would be one value attached to a given class per runtime. Generally, this does not exceed a few dozen JRuby instances for an individual app, and most folks don't deploy more than a few apps in a given JVM. - Charlie On Thu, Jan 9, 2014 at 1:16 PM, Christian Thalinger wrote: > > On Jan 9, 2014, at 2:46 AM, Jochen Theodorou wrote: > >> Am 08.01.2014 21:45, schrieb Christian Thalinger: >> [...] >>> If we’d go with an initial value of 1 would it be a performance problem for >>> you if it grows automatically? >> >> that means the map will have to grow for hundreds of classes at startup. >> I don't know how much impact that will have > > If it’s only hundreds it’s probably negligible. You could do a simple > experiment if you are worried: change ClassValueMap.INITIAL_ENTRIES to 1, > compile it and prepend it to the bootclasspath. > >> >> bye Jochen >> >> -- >> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead >> blog: http://blackdragsview.blogspot.com/ >> german groovy discussion newsgroup: de.comp.lang.misc >> For Groovy programming sources visit http://groovy-lang.org >> >> ___ >> 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: RFC: JDK-8031043: ClassValue's backing map should have a smaller initial size
On Jan 9, 2014, at 5:25 PM, Charles Oliver Nutter wrote: > It depends how JRuby is deployed. If the same code runs in every JRuby > runtime, then there would be one value attached to a given class per > runtime. Generally, this does not exceed a few dozen JRuby instances > for an individual app, and most folks don't deploy more than a few > apps in a given JVM. Interesting. Thanks for the information. > > - Charlie > > On Thu, Jan 9, 2014 at 1:16 PM, Christian Thalinger > wrote: >> >> On Jan 9, 2014, at 2:46 AM, Jochen Theodorou wrote: >> >>> Am 08.01.2014 21:45, schrieb Christian Thalinger: >>> [...] If we’d go with an initial value of 1 would it be a performance problem for you if it grows automatically? >>> >>> that means the map will have to grow for hundreds of classes at startup. >>> I don't know how much impact that will have >> >> If it’s only hundreds it’s probably negligible. You could do a simple >> experiment if you are worried: change ClassValueMap.INITIAL_ENTRIES to 1, >> compile it and prepend it to the bootclasspath. >> >>> >>> bye Jochen >>> >>> -- >>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead >>> blog: http://blackdragsview.blogspot.com/ >>> german groovy discussion newsgroup: de.comp.lang.misc >>> For Groovy programming sources visit http://groovy-lang.org >>> >>> ___ >>> 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
