Re: Benchmarking Smalltalk on JVM
On 02/02/2012 04:45 AM, Mark Roos wrote: > From Rémi > Without the descriptors of invokedynamic and the code of the > BSM, it's >hard to tell. > > Yes but they have no invoke dynamics and I was just wondering if my > indy part was causing the > issue. Your answer told me that I should be OK so that was helpful. > This same code was much > faster on jdk8-b20 for some reason. It can be an escape analysis change. As far as I know, escape analysis don't work through indy call but if Charles see same performance as Java, escape analysis has to work ?? > > I will play around and see where the time is going . Would be nice to > have an way to get the 8086 object code. https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly > > thanks > > mark Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Benchmarking Smalltalk on JVM
On 02/02/2012 04:45 AM, Mark Roos wrote: > from Rémi > > if you know it will never escape,you should use an int directly. > > Well I am trying to build a Smalltalk system which has no static types so > I have to box the ints. Since the code I showed was programmer entered I > need to stay with the boxes. > > There are cases where the compiler generates the index code and there > I do > use static ints if I can be sure they are not passed. or you can box only just before it's passed. The MutableInteger trick only works because the VM does the escape analysis for you but the escape analysis done by the VM is more britlle than the one you can write, by example, you know that increment() is a pure function, the VM has to inline it to know. So if one call is not inlined in the middle of the body of the loop, then the VM will not remove your MutableInteger. > It does cause some > issues when I open a debugger on the stack so I may want to keep then > boxed > anyway and thus the MutableInteger ??, yes your debugger has to support it, but if you want a typed smalltalk you will need that anyway. > > mark > Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [jvm-l] JVM cannot find invoker
Am 02.02.2012 12:21, schrieb Jochen Theodorou: > Am 01.02.2012 12:38, schrieb Rémi Forax: > [...] >> This is weird, >> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass >> for me, >> with jdk7u2 and jdk8b23. > > I guess I will try jdk8b23 next and hope the bug vanishes over time > somehow But if that also does not work... so... now I am stuck... jdk8b23 has the problem too and I have Cedric confirming the same bug on his machine for jdk7u2 and for 1.7.0_147-icedtea Looks like I will have to fill my very first JVM bug report 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: [jvm-l] JVM cannot find invoker
On Feb 2, 2012, at 2:34 PM, Jochen Theodorou wrote: > Am 02.02.2012 12:21, schrieb Jochen Theodorou: >> Am 01.02.2012 12:38, schrieb Rémi Forax: >> [...] >>> This is weird, >>> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass >>> for me, >>> with jdk7u2 and jdk8b23. >> >> I guess I will try jdk8b23 next and hope the bug vanishes over time >> somehow But if that also does not work... > > so... now I am stuck... jdk8b23 has the problem too and I have Cedric > confirming the same bug on his machine for jdk7u2 and for 1.7.0_147-icedtea > > Looks like I will have to fill my very first JVM bug report Do you have a test case you can share? -- Chris > > 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: Benchmarking Smalltalk on JVM
On Thu, Feb 2, 2012 at 4:47 AM, Rémi Forax wrote: > It can be an escape analysis change. > As far as I know, escape analysis don't work through indy call but > if Charles see same performance as Java, escape analysis has to work ?? My comment was about using an iterator/cursor for iteration (no object creation visible to Ruby) rather than numeric indices (Fixnum created per iteration). When object overhead is equivalent between Ruby and Java we can match perf. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Benchmarking Smalltalk on JVM
Some nice comments from Rémi So if one call is not inlined in the middle of the body of the loop, then the VM will not remove your MutableInteger. This could be what is causing the difference in time. I have seen some mails that indicate indy GWT depth ( methodHandle stacks ) impacts the inlining budget. So a change in the size of my polymorphic cache could have a big impact. I would think that a GWT test is cheap to inline though. You are correct that I can replace the indy calls on Mutable integer with my own inline byte codes which I think it a good idea. and ??, yes your debugger has to support it, but if you want a typed smalltalk you will need that anyway. My intent for 'typed' Smalltalk code is to replace the 1000 lines or so of java code I have to have to support primitive methods. If I could generate the jvm byte codes from a Smalltalk syntax I would cut the need to write java just to get the performance improvements available from having static type information. My debugger issue is with unboxed primitives which I would like to hide as much as possible until Fixnums appear thanks mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [jvm-l] JVM cannot find invoker
Am 02.02.2012 14:37, schrieb Christian Thalinger: > > On Feb 2, 2012, at 2:34 PM, Jochen Theodorou wrote: > >> Am 02.02.2012 12:21, schrieb Jochen Theodorou: >>> Am 01.02.2012 12:38, schrieb Rémi Forax: >>> [...] This is weird, All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass for me, with jdk7u2 and jdk8b23. >>> >>> I guess I will try jdk8b23 next and hope the bug vanishes over time >>> somehow But if that also does not work... >> >> so... now I am stuck... jdk8b23 has the problem too and I have Cedric >> confirming the same bug on his machine for jdk7u2 and for 1.7.0_147-icedtea >> >> Looks like I will have to fill my very first JVM bug report > > Do you have a test case you can share? you can use this: https://github.com/groovy/groovy-core/tree/indy If you run "ant clean test" the tests will fail with several errors, about 20 of them are because of a single place that is causing the internal error btw, it seems the error appears on 32bit as well as 64bit JVMs. Every help is very much appreciated. 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: [jvm-l] JVM cannot find invoker
Am 02.02.2012 19:40, schrieb Jochen Theodorou: [...] > Every help is very much appreciated. On further investigation the error seems really to be related to one of the parameters being an instance of a class with a private modifier set. The key point in that is maybe that the class is not an inner class. Normal Java doesn't allow for this kind of class afaik. The JVM seemed not to have a problem with this before, but indy seems to have. If I read the spec right the private modifier should not be allowed 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
Smalltalk and tiered compile data
So I ran some tests using a simple benchmark using the jdk8-b23 from the Openjdk google code. Without tiered compile I get: ( times in nanoseconds ) 52101000 53973000 20932000 with tiered on 493788000 521448000 513287000 34293 15048000 But if I invalidate all call sites before the benchmark with tiered I see: 449127000 288584000 80717000 36255000 and without tiered 4921 744625000 27179000 26377000 24514000 in all cases more runs after show no changes for 30 runs. So tiered starts very very very slow but ends better. Both seem to have a hard time if call sites have their targets reset. any thoughts on how I might get the best always? Especially for callsite resets. And why would the startup be 10x slower for tiered? By the way the data for jdk7u4 is similar but its best times are slower. regards mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
