Hi Helmut, The problem I saw before was due to enabling all of the capabilities of jvmti. Since then I backed off to only the capabilities I use. With this change my original benchmarks do not show any slowdown. This was one of the reasons I chose to try this approach to stepping rather than use jvmti. There is still the question of does adding the debug test in front of every call add much time. This is on my list of things to find out.
As to how Rtalk( mine) compares with Smalltalk. Well that really depends on the benchmark chosen. The big issue I see is my decision to use boxed integers for all uses vs the use of primitive integers by both the jvm and Smalltalk. For my Hanoi benchmark ( lots of ints ) I run about 10x slower than Smalltalk ( vs java being 50% faster than Smalltalk). But if I code in java as Rtalk does by using boxed integers hidden within other objects the java time becomes 5x slower than Smalltalk. So I think some looking at the use of integers would be the big benchmark gain. Some easy things would be an integer cache (as garbage is a big part of the time lost) and having the compiler use primitives for hidden loop counters and iterators. Having said that, for complex applications which spend lots of time in primitives ( string handling and float vectors) Rtalk is actually faster than Smalltalk. My application is a DSL compiler with a runtime which spend most of its time handling byteArrays and floatVectors so I am expecting to see the jvm version being faster. An added advantage I see is the ability to use java as the language to write user primitives in. This would make implementing local speed up methods quite easy I will let you know as it progresses regards mark mlvm-dev-boun...@openjdk.java.net wrote on 11/27/2011 01:07:50 AM: > From: Helmut Eller <eller.hel...@gmail.com> > To: mlvm-dev@openjdk.java.net > Date: 11/27/2011 01:24 AM > Subject: Re: Implementing a Smalltalk debugger with JSR292 > Sent by: mlvm-dev-boun...@openjdk.java.net > > * Mark Roos [2011-11-27 06:16] writes: > > > The approach we took has two facets, we ( mainly oscar ) coded a C++ > > jvmti agent with a JNI interface which allowed us to call some JVMTI > > apis from within the jvm being debugged and we added some logic to the > > callsite to handle the stepping. > > What's the cost of this approach? In a previous post you said that > enabling the debug agent degraded performance of the JVM considerably. > If the debugger enabled in "production mode"? How does the efficiency > of your system compare to native Smalltalks? > > Helmut > > _______________________________________________ > 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