Hi Stefan,

On Sat, Mar 1, 2014 at 12:55 PM, Stefan Marr <smalltalk@stefan-marr.de> wrote:

Hi:

On 01 Mar 2014, at 19:44, Alexandre Bergel <alexandre.bergel@me.com> wrote:

> The VM is a formidable thing in which everything happen. Exposing to the image what’s going on in it is really pushing the innovation.

Perhaps something that could be relevant in case someone decides to implement such an interface in Cog:
Just one, pretty old example: http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#EventIndex

Interesting list.  Assuming the list refers to events one can handle in Smalltalk, then let me go through these and see which we need, don't need or already have: 

Event Index

• Breakpoint
  we already have this.  An illegal bytecode will send an error message to the current context.  See my MethodMassage package.  We use this at Cadence to implement coverage.
• Class File Load Hook
  not needed.  classes are loaded by Smalltalk code, not the VM.
• Class Load
  not needed. ditto
• Class Prepare
  not needed.  ditto
• Compiled Method Load
  not needed.  methods are loaded by Smalltalk code, not the VM.
• Compiled Method Unload
  not needed.  ditto
• Data Dump Request
  to what extent is snapshot adequate?  
  Has been used for adequate image debugging (and of course we can serialize processes so people are using things like Fuel to save the stack traces of processes that encounter errors).
  Not adequate for VM debugging: the heap may be invalid and not saveable; shapshot load does more than merely fill memory; it swizzles etc, and these operations can and will fail on an invalid heap.  Personally I think things like -blockOnError which causes the VM to block rather than exit on error, allowing one to attach gdb to a crashed VM process is more useful.
  
• Dynamic Code Generated
  not needed.  methods are loaded by Smalltalk code, not the VM.
• Exception
  not needed.  Smalltalk's exception system has resume semantics, not retry, so there's no need to ask to see an exception at source; the source of the exception can be examined after the fact (unlike Java, which has restart semantics).  In fact folks like Avi Bryant (and I believe him) think that the business opportunity with hadoop/map-reduce is indeed Smalltalk's exception semantics which allow live debugging of errors.
• Exception Catch
  not needed.  ditto
• Field Access
  Quite possibly.  If one is using classical Smalltalk there is no linguistic hook for field access.  With Pharo's slots then presumably transforming methods to insert traps on field access is trivial (and databases like GemStone have done similar things with brute bytecode manipulation).  With Newspeak, which has no direct inst var access, this can be subsumed by MethodEntry (see below).  So whether this is needed or not depends on either language evolution or good bytecode manipulation tools; if these are available this is not needed.
• Field Modification
  Quite possibly.  Again the approaches outlined above can be done (as gemStone has done in the past).  But we nearly have this.  I've implemented per-instance immutability for the old Newspeak VM (a variant of the Squeak interpreter) and this is easy to fold into Cog (and indeed the Interpreter VM).  GemStone engineers prefer per-instance immutability than their own bytecode modification.  I think I agree.  I'd rather depend on immutability (which has other uses such as immutable literals) than a special VM hook.
• Frame Pop
  Hmm.  Possibly.  IIRC, I think method wrappers provide a manageable way to do this.
• Garbage Collection Finish
  Indeed.  There are hacks to get this.  Further there are many ways to implement this.  e.g. is it a callback on finishing a form of GC, or is it merely the signalling of a semaphore which has some Smalltalk process waiting on it (as is the case in VW)?
• Garbage Collection Start
  OK, but what are you going to do when you catch this?  Arguably there's no memory with which to do anything at the point that you get this.  Give me a scenario and I'll consider it.
• Method Entry
  Not sure we need this because all method calls are virtual and hence one can use proxies (MNU hook) or method wrappers.
• Method Exit
  Ditto.
• Monitor Contended Enter
  Not relevant.  Smalltalk doesn't have synchronized methods.
• Monitor Contended Entered
  Ditto.
• Monitor Wait
  Ditto.
• Monitor Waited
  Ditto.
• Native Method Bind
  OK.  Not really relevant if we refactor dll loading and function lookup as in Alien (and VW) so that the image does the work and allows one to implement the hook without VM support.
• Object Free
  Hmmm.  Is this for finalization or something else?  In either case I think that Ephemerons fit the bill and Cog Spur supports ephemerons.  So we'll have this before the end of the year.
• Resource Exhausted
  Hmmm, I think this is not relevant.  Resources such as memory produce catchable primitive failures.  Likewise for OS resources.  if things are engineered right then exhaustion fo things like file handles should produce exceptions in the image.
• Single Step
  Not relevant.  We already have ways of making Smalltalk single-step, heh, heh.
• Thread End
  If this applies to Process, then easy.  Change fork: et al to add code on thread termination.  Native threads are a different issue.  But as yet a non-issue.  We don't have them yet, although a prototype VM is there to revive when resources allow.
• Thread Start
  Ditto.
• VM Death Event
  Seems like a non-sequitur to me.  If the VM has died then there's nothing reliable the system above it can do.  However, see below...
• VM Initialization Event
  The existing startUp registration mechanism seems adequate to me...
• VM Object Allocation
  AGain lots of hooks to allow this.  The link os pretty vague on what this might mean.  They mention using other mechanisms to instrument this.
• VM Start Event
  Again, the existing startUp registration mechanism seems adequate to me...

However, if this list refers to sub-image level debugging (and that's something I do all the time) then again this isn't relevant.  We have the simulator which is a fabulous tool for intercepting any and all of the above.  Gdb is less convenient but can be used by someone knowledgeable.

You can get access to many different information in terms of ‘events’ on the JVM.
For building a profiler, more than sufficient. And, at least in my personal opinion also something that would be desirable for Cog, perhaps in a slightly more modern design, but with a similar flavor.

So how about responding to the above breakdown with a sketch of what events remain, and then speculate on how they might be packaged as events.

--
best,

Eliot