Re: Implementing a Smalltalk debugger with JSR292
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 > 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
Re: Implementing a Smalltalk debugger with JSR292
Hi Rémi Thanks for the comments. I like the idea of using switchPoints and have been thinking about them both for this and for the general purpose of method invalidation. Right now I keep a list of all callsites and when necessary I dump them all. I thought of replacing this with a switchpoint but then I lose the ability to selectively invalidate ( by selector usually ) unless I have a switchpoint per selector. I have some experiments planned to compare the approaches. thanks mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Implementing a Smalltalk debugger with JSR292
On 11/27/2011 07:16 AM, Mark Roos wrote: One of the key parts of Smalltalk is the 'live' debugger. Unlike the general dynamic language features which are well supported by the additions from JSR292 the debugger requires support which may not have been considered as necessary to support dynamic languages. So we were not sure we would be able to provide that portion of the Smalltalk experience on the jvm. The good news is that we were able to implement almost all of the Smalltalk debugger features using only the services provided in the released jdk7. I thought I would take a moment to describe how we did it to both demonstrate the approach and to solicit suggestions for improvements. The Smalltalk debugger is 'live' in that it exists as a separate thread within the same process/memory space as the thread being debugged. This allows one to manipulate and inspect all objects from the same viewpoint as the debugged thread. Smalltalk offers the ability to inspect all instances of a class(type), all references to a specific object, the variables on all levels of the stack, senders and implementers of methods, and the ability to single step through method sends. There is also the ability to restart a thread from any level of the stack but we opted to wait on the coro patch before implementing this ( I also don't use it as it can have quite a few side effects ). 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. Implementers and senders of methods is handled via reflection on the classes and methods present so that was easy. To support all instances and all references requires heap inspection which we get from using the jvmti heap functions. This had some issues with some of the support classes for invoke dynamic but we were able to use a two pass tagging approach to make sure we found all of the references to our objects. This has to find objects both in arrays and in instance vars. Inspecting the stack was straight forward once we filtered the stack trace to only have our method sends present. As an option one can also inspect the full jvm trace. Using the jvmti variable access api allows the locating the variable which is then placed into a static field of out debugger support class. This field is then access by Smallltalk via a primitive (in Smalltalk a primitive is the way we share with the underlying environment). Once we have this object we can manipulate its instance vars from the Smalltalk side as well. When an error is thrown the thread is suspended ( we added some jvmti thread management apis just to get away from the deprecated methods) and a new thread is launched with an instance of the debugger and a pointer to the thread to debug. At this point one can only inspect the thread locals and anything else in the object memory. The thread is not restartable so we kill it ( by sending ThreadDeath ). But it the error is a halt or breakpoint we can then step the thread along. We tried this with jvmti but is was broken and seems to add quite a bit of delay to everything. Plus its a callback approach which looked like a lot of work. So instead we tweaked the call site logic to add a debug check. I liked the way this worked a lot. For a dynamic look up we already have a callsite with a target of one or more GWTs to select the implementation which matches the receiver class. What we have to do to implement a debugger is to place before the first GWT a test which determines if this is the time to suspend. Unfortunately GWTs are added to the end so we need a way to keep the test at the beginning (thanks to John and Réme suggestion) we can simply have a callsite have a target which is another callsite. The first callsite points at the test logic and the second gets the GWT chain. One nice thing is that we can revert to the single site version using a debug flag. The code to get the initial target for the bootstrap callsite looks like: *private**void*setBootstrapTarget(MethodHandle mh){ // get the appropriate initial call site sequence *if*( RtDebugger./_debugEnable/){ // for debugging we need to have a sequence of methodHandles that is always the first // code executed when a _callsite_ is invoked. This checks to see if we should // hold here for a debug step or continue. _realSite= *new*MutableCallSite(mh); // this is the extra call site to hold the gwts MethodHandle invoker = _realSite.dynamicInvoker(); MethodHandles.Lookup lookup=MethodHandles./lookup/(); MethodHandle debugEntry= *null*; MethodType mt=MethodType./methodType/(*void*.*class*, RtObject.*class*); *try*{ debugEntry = lookup.findStatic(RtDebugger.*class*, "debugEntry", mt); } *catch*(Throwable e) { e.printStackTrace(); }
Re: Implementing a Smalltalk debugger with JSR292
* 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
Implementing a Smalltalk debugger with JSR292
One of the key parts of Smalltalk is the 'live' debugger. Unlike the general dynamic language features which are well supported by the additions from JSR292 the debugger requires support which may not have been considered as necessary to support dynamic languages. So we were not sure we would be able to provide that portion of the Smalltalk experience on the jvm. The good news is that we were able to implement almost all of the Smalltalk debugger features using only the services provided in the released jdk7. I thought I would take a moment to describe how we did it to both demonstrate the approach and to solicit suggestions for improvements. The Smalltalk debugger is 'live' in that it exists as a separate thread within the same process/memory space as the thread being debugged. This allows one to manipulate and inspect all objects from the same viewpoint as the debugged thread. Smalltalk offers the ability to inspect all instances of a class(type), all references to a specific object, the variables on all levels of the stack, senders and implementers of methods, and the ability to single step through method sends. There is also the ability to restart a thread from any level of the stack but we opted to wait on the coro patch before implementing this ( I also don't use it as it can have quite a few side effects ). 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. Implementers and senders of methods is handled via reflection on the classes and methods present so that was easy. To support all instances and all references requires heap inspection which we get from using the jvmti heap functions. This had some issues with some of the support classes for invoke dynamic but we were able to use a two pass tagging approach to make sure we found all of the references to our objects. This has to find objects both in arrays and in instance vars. Inspecting the stack was straight forward once we filtered the stack trace to only have our method sends present. As an option one can also inspect the full jvm trace. Using the jvmti variable access api allows the locating the variable which is then placed into a static field of out debugger support class. This field is then access by Smallltalk via a primitive (in Smalltalk a primitive is the way we share with the underlying environment). Once we have this object we can manipulate its instance vars from the Smalltalk side as well. When an error is thrown the thread is suspended ( we added some jvmti thread management apis just to get away from the deprecated methods) and a new thread is launched with an instance of the debugger and a pointer to the thread to debug. At this point one can only inspect the thread locals and anything else in the object memory. The thread is not restartable so we kill it ( by sending ThreadDeath ). But it the error is a halt or breakpoint we can then step the thread along. We tried this with jvmti but is was broken and seems to add quite a bit of delay to everything. Plus its a callback approach which looked like a lot of work. So instead we tweaked the call site logic to add a debug check. I liked the way this worked a lot. For a dynamic look up we already have a callsite with a target of one or more GWTs to select the implementation which matches the receiver class. What we have to do to implement a debugger is to place before the first GWT a test which determines if this is the time to suspend. Unfortunately GWTs are added to the end so we need a way to keep the test at the beginning (thanks to John and Réme suggestion) we can simply have a callsite have a target which is another callsite. The first callsite points at the test logic and the second gets the GWT chain. One nice thing is that we can revert to the single site version using a debug flag. The code to get the initial target for the bootstrap callsite looks like: private void setBootstrapTarget(MethodHandle mh){ // get the appropriate initial call site sequence if( RtDebugger._debugEnable){ // for debugging we need to have a sequence of methodHandles that is always the first // code executed when a callsite is invoked. This checks to see if we should // hold here for a debug step or continue. _realSite = new MutableCallSite(mh); // this is the extra call site to hold the gwts MethodHandle invoker = _realSite.dynamicInvoker(); MethodHandles.Lookup lookup=MethodHandles.lookup(); MethodHandle debugEntry= null; MethodType mt=MethodType.methodType(void.class, RtObject.class); try { debugEntry = lookup.findStatic(RtDebugger.class, "debugEntry", mt); } catch (Throwable e) { e.printStackTrace(); } invoker = MethodHandles.fol