- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Status of the VM?

by Jan Vrany

Maybe I'm missing something obvious, but from my point of view the fundamental difference here is that with JVM's JPDA triggering of event actually **does not** affect the monitored system. If these events are handled by the image, it is quite tricky to figure out which one is caused by "application" and which one is caused by the event handling machinery. For instance, if (non-empty) method is called after a GC, this handler may trigger another GC, which may... That brings me to another, if you do in-image profiling (event handling), data could be quite different than what would you get using out-of-image profiler. <personal experience:> I've used (and implemented some :-) both - Smalltalk in-image tools and out-of-image tools, namely JPDA and DTRACE/STAP. For serious profiling and monitoring, I always use out-of-image approach if possible. Jan On 01/03/14 23:34, ClÃ©ment Bera wrote: > Hey, > > It's fun because I looked at the JVM list and most point looked > irrelevant as you described. > > It seems that the only thing we miss is the GC hook: we could have a > selector in special object array to call at each GC on the 'Smalltalk' > object to trigger a method in the image that would be by default an > empty method. > > Field access is a solved problem with slots, definitely. > > > 2014-03-01 22:35 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > > Hi Stefan, > > > On Sat, Mar 1, 2014 at 12:55 PM, Stefan Marr > <smalltalk(a)stefan-marr.de <mailto:smalltalk@stefan-marr.de>> wrote: > > Hi: > > On 01 Mar 2014, at 19:44, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto: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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassFileLoa…> > not needed. classes are loaded by Smalltalk code, not the VM. > * *Class Load > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassLoad>* > not needed. ditto > * *Class Prepare > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassPrepare>* > not needed. ditto > * *Compiled Method Load > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMeth…>* > not needed. methods are loaded by Smalltalk code, not the VM. > * *Compiled Method Unload > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMeth…>* > not needed. ditto > * Data Dump Request > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DataDumpRequ…> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DynamicCodeG…>* > not needed. methods are loaded by Smalltalk code, not the VM. > * *Exception > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ExceptionCat…>* > not needed. ditto > * Field Access > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldAccess> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldModific…> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FramePop> > Hmm. Possibly. IIRC, I think method wrappers provide a > manageable way to do this. > * Garbage Collection Finish > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageColle…> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageColle…> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MethodEntry> > Not sure we need this because all method calls are virtual and > hence one can use proxies (MNU hook) or method wrappers. > * Method Exit > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MethodExit> > Ditto. > * Monitor Contended Enter > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorConte…> > Not relevant. Smalltalk doesn't have synchronized methods. > * Monitor Contended Entered > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorConte…> > Ditto. > * *Monitor Wait > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorWait>* > Ditto. > * *Monitor Waited > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorWaited>* > Ditto. > * Native Method Bind > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#NativeMethod…> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ObjectFree> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ResourceExha…> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#SingleStep> > Not relevant. We already have ways of making Smalltalk > single-step, heh, heh. > * Thread End > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ThreadEnd> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ThreadStart> > Ditto. > * VM Death Event > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMDeath> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMInit> > The existing startUp registration mechanism seems adequate to me... > * VM Object Allocation > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMObjectAlloc> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMStart>* > 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 > >

March 2, 2014

Re: [Pharo-dev] Status of the VM?

by ClÃ©ment Bera

Hey, It's fun because I looked at the JVM list and most point looked irrelevant as you described. It seems that the only thing we miss is the GC hook: we could have a selector in special object array to call at each GC on the 'Smalltalk' object to trigger a method in the image that would be by default an empty method. Field access is a solved problem with slots, definitely. 2014-03-01 22:35 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Stefan, > > > On Sat, Mar 1, 2014 at 12:55 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > >> Hi: >> >> On 01 Mar 2014, at 19:44, Alexandre Bergel <alexandre.bergel(a)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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassFileLoa…> > not needed. classes are loaded by Smalltalk code, not the VM. > - *Class Load > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassLoad>* > not needed. ditto > - *Class Prepare > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassPrepare>* > not needed. ditto > - *Compiled Method Load > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMeth…>* > not needed. methods are loaded by Smalltalk code, not the VM. > - *Compiled Method Unload > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMeth…>* > not needed. ditto > - Data Dump Request<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DataDumpRequ…> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DynamicCodeG…>* > not needed. methods are loaded by Smalltalk code, not the VM. > - *Exception > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ExceptionCat…>* > not needed. ditto > - Field Access<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldAccess> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldModific…> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FramePop> > Hmm. Possibly. IIRC, I think method wrappers provide a manageable > way to do this. > - Garbage Collection Finish<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageColle…> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageColle…> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MethodEntry> > Not sure we need this because all method calls are virtual and hence > one can use proxies (MNU hook) or method wrappers. > - Method Exit<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MethodExit> > Ditto. > - Monitor Contended Enter<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorConte…> > Not relevant. Smalltalk doesn't have synchronized methods. > - Monitor Contended Entered<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorConte…> > Ditto. > - *Monitor Wait > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorWait>* > Ditto. > - *Monitor Waited > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorWaited>* > Ditto. > - Native Method Bind<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#NativeMethod…> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ObjectFree> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ResourceExha…> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#SingleStep> > Not relevant. We already have ways of making Smalltalk single-step, > heh, heh. > - Thread End<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ThreadEnd> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ThreadStart> > Ditto. > - VM Death Event<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMDeath> > 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMInit> > The existing startUp registration mechanism seems adequate to me... > - VM Object Allocation<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMObjectAlloc> > 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 > <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMStart>* > 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 >

March 1, 2014

Re: [Pharo-dev] [squeak-dev] [ANN] Fuel 1.9.3

by Max Leske

On 01.03.2014, at 18:46, phil(a)highoctane.be wrote: > So Debugger -> Smalltalk tools debugger needed... > Thanks Phil, I missed that somehow. Debugger is now SpecDebugger. Iâll fix it. > Le 1 mars 2014 14:19, "Sebastian Sastre" <sebastian(a)flowingconcept.com> a Ã©crit : > great job you guys > > sebastian > > o/ > > On 01/03/2014, at 02:23, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > >> Thanks for the update. >> Cheers, >> >> HernÃ¡n >> >> >> 2014-02-26 18:13 GMT-03:00 Max Leske <maxleske(a)gmail.com>: >> Dear fellow Smalltalkers >> >> Mariano, Martin and myself are happy to announce Fuel version 1.9.3 which includes the follwing changes to 1.9 (1.9.1 and 1.9.2 were never officially announced): >> >> - (feature) the #fuelReplacement selector offers the ability to statically replace an object (e.g. with nil) during analysis. This can lead to significantly smaller graphs and improved speed when serializing large graphs >> - (feature) serialize the same graph that was analyzed instead of retrazing the graph during serialization. This prevents changes in the graph from happening between analysis and serialization >> - (change) store source when serializing CompiledMethod objects. Needed because Opal does not allow decompilation >> - (fix) migrate variables across hierarchy >> - (feature) Object>>serializeToFileNamed: shortcut for serializing arbitrary objects >> - (fix) better compression for LargeNegativeIntegers (https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteg…) >> >> Pharo30 already includes most of these changes (integration request: https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3) >> >> This release runs with: >> - Pharo: 1.1.1, 1.1.2, 1.2, 1.2.2, 1.3, 1.4, 2.0, 3.0 >> - Squeak: 4.1, 4.2, 4.3, 4.4, 4.5 >> >> The documentation is not up to date yet but we will remedy that situatoin within the next couple of days (http://rmod.lille.inria.fr/web/pier/software/Fuel) >> If you encounter any bugs or have suggestions, please contact us on the Fuel mailing list (http://lists.gforge.inria.fr/cgi-bin/mailman/roster/pharo-fuel) or create a new issue in our bug tracker (https://code.google.com/p/fuel/) >> >> We want to thank everyone who contributed to this release (by keyboard or opinion) and also all of those people who actively use Fuel. >> >> Cheers, >> Max >>

March 1, 2014

Re: [Pharo-dev] Status of the VM?

by Eliot Miranda

Hi Stefan, On Sat, Mar 1, 2014 at 12:55 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi: > > On 01 Mar 2014, at 19:44, Alexandre Bergel <alexandre.bergel(a)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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassFileLoa…> not needed. classes are loaded by Smalltalk code, not the VM. - *Class Load <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassLoad>* not needed. ditto - *Class Prepare <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ClassPrepare>* not needed. ditto - *Compiled Method Load <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMeth…>* not needed. methods are loaded by Smalltalk code, not the VM. - *Compiled Method Unload <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#CompiledMeth…>* not needed. ditto - Data Dump Request<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DataDumpRequ…> 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 <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#DynamicCodeG…>* not needed. methods are loaded by Smalltalk code, not the VM. - *Exception <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#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 <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ExceptionCat…>* not needed. ditto - Field Access<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldAccess> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FieldModific…> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#FramePop> Hmm. Possibly. IIRC, I think method wrappers provide a manageable way to do this. - Garbage Collection Finish<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageColle…> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageColle…> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MethodEntry> Not sure we need this because all method calls are virtual and hence one can use proxies (MNU hook) or method wrappers. - Method Exit<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MethodExit> Ditto. - Monitor Contended Enter<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorConte…> Not relevant. Smalltalk doesn't have synchronized methods. - Monitor Contended Entered<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorConte…> Ditto. - *Monitor Wait <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorWait>* Ditto. - *Monitor Waited <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#MonitorWaited>* Ditto. - Native Method Bind<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#NativeMethod…> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ObjectFree> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ResourceExha…> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#SingleStep> Not relevant. We already have ways of making Smalltalk single-step, heh, heh. - Thread End<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ThreadEnd> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#ThreadStart> Ditto. - VM Death Event<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMDeath> 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<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMInit> The existing startUp registration mechanism seems adequate to me... - VM Object Allocation<http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMObjectAlloc> 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 <http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#VMStart>* 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

March 1, 2014

Re: [Pharo-dev] Status of the VM?

by Stefan Marr

Hi: On 01 Mar 2014, at 19:44, Alexandre Bergel <alexandre.bergel(a)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 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. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

March 1, 2014

Re: [Pharo-dev] Status of the VM?

by Alexandre Bergel

Excellent! Eager to try it!!! Alexandre > Le 01-03-2014 Ã 16:01, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > > >> On Sat, Mar 1, 2014 at 10:44 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Ok, thanks for the update. >> >> 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. > > The computer is a formidable thing in which everything happens ;-). The VM is just mechanism. The real magic is up in the image ;-). > > What's exciting about ClÃ©ment's and my work is that it will allow adaptive optimization, so a much faster system, but that optimization will be done at the image level and will optimize from compiled methods to compiled methods with inlining, on-the-fly. So this optimization will /not/ be in the VM. No one's done this before so we really will be pushing innovation. > >> >> Go go go! > > On y va! > >> >> Alexandre >> >> >> On Mar 1, 2014, at 2:19 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> > Hello, >> > >> > This is true but this is a work in progress. Right now this feature is not stable. I will keep you in touch. I think in May I may have something stable enough (I will work with Eliot on April) but it will not be on the default VM. It will be available in the default pharo VM at some point but not now (maybe in a year ?). >> > >> > However, you may or may not be able to use it for your profiling tools. The idea is that you can get branch and send information from the previous executions of the method. However, the method needs to be cogged to have information available and once the cogged method is discarded the information is lost. It is really nice for hot spots but I don't know how it could work for a profiling tool. >> > >> > >> > >> > >> > >> > 2014-03-01 17:06 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> > Hi! >> > >> > Stef told me the coming VM will expose some data about the execution to the image. This will be great for our profiling tools. >> > What is the status? >> > >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- > best, > Eliot

March 1, 2014

Re: [Pharo-dev] Help needed! ClassTest>>#testRenaming

by btc＠openinworld.com

'From Pharo3.0 of 18 March 2013 [Latest update: #30778] on 1 March 2014 at 10:10:40.919902 am'! Object subclass: #TemporaryTestResourceBuilder instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Manifest-Tests'! !TemporaryTestResourceBuilder commentStamp: '<historical>' prior: 0! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! TemporaryTestResourceBuilder class instanceVariableNames: 'workingCopy'! !TemporaryTestResourceBuilder class commentStamp: '<historical>' prior: 0! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:27'! temporaryTestPackageName ^ 'ZZZZ-Dynamic-Manifest-Tests-Resources'.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:28'! defineTemporaryPackage RPackageOrganizer default registerPackageNamed: self temporaryTestPackageName. workingCopy := MCWorkingCopy forPackage: (MCPackage new name: self temporaryTestPackageName). ! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 10:01'! defineTemporaryMFClassA "Define the class" Object subclass: #MFClassA instanceVariableNames: '' classVariableNames: '' category: self temporaryTestPackageName. (Smalltalk at: #MFClassA) compileSilently: 'method |foo| self halt. '. ^Smalltalk at: #MFClassA.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 2/24/2014 01:46'! unloadTemporaryPackage workingCopy unload.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:26'! testPackageName ^ 'ZZZZ-Dynamic-Manifest-Tests-Resources'.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 10:01'! defineTemporaryMFClassB "Define the class" Object subclass: #MFClassB instanceVariableNames: '' classVariableNames: '' category: self temporaryTestPackageName. (Smalltalk at: #MFClassB) compileSilently: 'method2 |foo| '. (Smalltalk at: #MFClassB) compileSilently: 'method3 |foo| self halt. '. ^Smalltalk at: #MFClassB.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:27'! temporaryTestPackageName ^ 'ZZZZ-Dynamic-Manifest-Tests-Resources'.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:28'! defineTemporaryPackage RPackageOrganizer default registerPackageNamed: self temporaryTestPackageName. workingCopy := MCWorkingCopy forPackage: (MCPackage new name: self temporaryTestPackageName). ! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 10:01'! defineTemporaryMFClassA "Define the class" Object subclass: #MFClassA instanceVariableNames: '' classVariableNames: '' category: self temporaryTestPackageName. (Smalltalk at: #MFClassA) compileSilently: 'method |foo| self halt. '. ^Smalltalk at: #MFClassA.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 2/24/2014 01:46'! unloadTemporaryPackage workingCopy unload.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 09:26'! testPackageName ^ 'ZZZZ-Dynamic-Manifest-Tests-Resources'.! ! !TemporaryTestResourceBuilder class methodsFor: 'as yet unclassified' stamp: 'BenComan 3/1/2014 10:01'! defineTemporaryMFClassB "Define the class" Object subclass: #MFClassB instanceVariableNames: '' classVariableNames: '' category: self temporaryTestPackageName. (Smalltalk at: #MFClassB) compileSilently: 'method2 |foo| '. (Smalltalk at: #MFClassB) compileSilently: 'method3 |foo| self halt. '. ^Smalltalk at: #MFClassB.! ! 'From Pharo3.0 of 18 March 2013 [Latest update: #30778] on 1 March 2014 at 10:10:35.531902 am'! TestCase subclass: #SmalllintManifestCheckerTest instanceVariableNames: 'checker mfClassA mfClassB' classVariableNames: '' poolDictionaries: '' category: 'Manifest-Tests'! !SmalllintManifestCheckerTest commentStamp: 'TorstenBergmann 2/19/2014 08:34' prior: 0! SUnit tests for SmalllintManifestChecker! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:45'! testToDoOf | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (( checker toDoOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassB>>#method3)]). self deny: (( checker toDoOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassB>>#method2)]).! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:56'! testIsToDo | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker isToDo: (mfClassB>>#method3) forRuleId: (RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName) versionId: 1). self deny: (checker isToDo: (mfClassB>>#method2) forRuleId: (RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName) versionId: 1). ! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:57'! testCriticsOf | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new) size = 3. self assert: (( checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new ) anySatisfy: [:each| each = (mfClassB>>#method3)]). self assert: (( checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassA>>#method)]).! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:56'! testIsFalsePositive | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker isFalsePositive: (mfClassB>>#method3) forRuleId: (RBCodeCruftLeftInMethodsRule uniqueIdentifierName) versionId: 1). self deny: (checker isFalsePositive: (mfClassA>>#method) forRuleId: (RBCodeCruftLeftInMethodsRule uniqueIdentifierName) versionId: 1). ! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'StephaneDucasse 3/21/2013 13:51'! cleaningResources Smalltalk globals at: #ManifestManifestResourcesTests ifPresent: [ :cl | cl removeFromChanges; removeFromSystemUnlogged ]! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'BenComan 3/1/2014 10:02'! setUp | bm | " self cleaningResources. " TemporaryTestResourceBuilder defineTemporaryPackage. mfClassA := TemporaryTestResourceBuilder defineTemporaryMFClassA. mfClassB := TemporaryTestResourceBuilder defineTemporaryMFClassB. bm := TheManifestBuilder of: mfClassA. bm installFalsePositiveOf: RBCodeCruftLeftInMethodsRule uniqueIdentifierName version: 1. bm addFalsePositive: mfClassB >> #method3 of: RBCodeCruftLeftInMethodsRule uniqueIdentifierName version: 1. bm installToDoOf: RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName version: 1. bm addAllToDo: {(mfClassB >> #method3). (mfClassA >> #method)} of: RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName version: 1. checker := SmalllintManifestChecker new! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'BenComan 3/1/2014 09:51'! tearDown TemporaryTestResourceBuilder unloadTemporaryPackage.! ! !SmalllintManifestCheckerTest methodsFor: 'private' stamp: 'BenComan 2/24/2014 01:59'! package MCWorkingCopy managersForClass: mfClassA do: [:p | ^ p packageSet packages first]. " should be equivalent to RPackageOrganizer default packageNamed: #'Manifest-Resources-Tests' "! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:45'! testToDoOf | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (( checker toDoOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassB>>#method3)]). self deny: (( checker toDoOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassB>>#method2)]).! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:56'! testIsToDo | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker isToDo: (mfClassB>>#method3) forRuleId: (RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName) versionId: 1). self deny: (checker isToDo: (mfClassB>>#method2) forRuleId: (RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName) versionId: 1). ! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:57'! testCriticsOf | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new) size = 3. self assert: (( checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new ) anySatisfy: [:each| each = (mfClassB>>#method3)]). self assert: (( checker criticsOf: RBOnlyReadOrWrittenTemporaryRule new) anySatisfy: [:each| each = (mfClassA>>#method)]).! ! !SmalllintManifestCheckerTest methodsFor: 'tests' stamp: 'BenComan 2/24/2014 01:56'! testIsFalsePositive | rule | rule := RBCompositeLintRule allGoodRules. checker rule: rule; environment: self package asEnvironment; run. self assert: (checker isFalsePositive: (mfClassB>>#method3) forRuleId: (RBCodeCruftLeftInMethodsRule uniqueIdentifierName) versionId: 1). self deny: (checker isFalsePositive: (mfClassA>>#method) forRuleId: (RBCodeCruftLeftInMethodsRule uniqueIdentifierName) versionId: 1). ! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'StephaneDucasse 3/21/2013 13:51'! cleaningResources Smalltalk globals at: #ManifestManifestResourcesTests ifPresent: [ :cl | cl removeFromChanges; removeFromSystemUnlogged ]! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'BenComan 3/1/2014 10:02'! setUp | bm | " self cleaningResources. " TemporaryTestResourceBuilder defineTemporaryPackage. mfClassA := TemporaryTestResourceBuilder defineTemporaryMFClassA. mfClassB := TemporaryTestResourceBuilder defineTemporaryMFClassB. bm := TheManifestBuilder of: mfClassA. bm installFalsePositiveOf: RBCodeCruftLeftInMethodsRule uniqueIdentifierName version: 1. bm addFalsePositive: mfClassB >> #method3 of: RBCodeCruftLeftInMethodsRule uniqueIdentifierName version: 1. bm installToDoOf: RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName version: 1. bm addAllToDo: {(mfClassB >> #method3). (mfClassA >> #method)} of: RBOnlyReadOrWrittenTemporaryRule uniqueIdentifierName version: 1. checker := SmalllintManifestChecker new! ! !SmalllintManifestCheckerTest methodsFor: 'running' stamp: 'BenComan 3/1/2014 09:51'! tearDown TemporaryTestResourceBuilder unloadTemporaryPackage.! ! !SmalllintManifestCheckerTest methodsFor: 'private' stamp: 'BenComan 2/24/2014 01:59'! package MCWorkingCopy managersForClass: mfClassA do: [:p | ^ p packageSet packages first]. " should be equivalent to RPackageOrganizer default packageNamed: #'Manifest-Resources-Tests' "! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! SmalllintManifestCheckerTest class instanceVariableNames: 'mfClassA'! !SmalllintManifestCheckerTest class commentStamp: '<historical>' prior: 0! ! !SmalllintManifestCheckerTest class methodsFor: 'as yet unclassified' stamp: 'BenComan 2/24/2014 01:59'! DoIt ^ MCWorkingCopy managersForClass: mfClassA do: [:p | ^ p first] ! ! !SmalllintManifestCheckerTest class methodsFor: 'as yet unclassified' stamp: 'BenComan 2/24/2014 01:59'! DoIt ^ MCWorkingCopy managersForClass: mfClassA do: [:p | ^ p first] ! !

March 1, 2014

Re: [Pharo-dev] Status of the VM?

by Eliot Miranda

On Sat, Mar 1, 2014 at 10:44 AM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Ok, thanks for the update. > > 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. > The computer is a formidable thing in which everything happens ;-). The VM is just mechanism. The real magic is up in the image ;-). What's exciting about ClÃ©ment's and my work is that it will allow adaptive optimization, so a much faster system, but that optimization will be done at the image level and will optimize from compiled methods to compiled methods with inlining, on-the-fly. So this optimization will /not/ be in the VM. No one's done this before so we really will be pushing innovation. > Go go go! > On y va! > > Alexandre > > > On Mar 1, 2014, at 2:19 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Hello, > > > > This is true but this is a work in progress. Right now this feature is > not stable. I will keep you in touch. I think in May I may have something > stable enough (I will work with Eliot on April) but it will not be on the > default VM. It will be available in the default pharo VM at some point but > not now (maybe in a year ?). > > > > However, you may or may not be able to use it for your profiling tools. > The idea is that you can get branch and send information from the previous > executions of the method. However, the method needs to be cogged to have > information available and once the cogged method is discarded the > information is lost. It is really nice for hot spots but I don't know how > it could work for a profiling tool. > > > > > > > > > > > > 2014-03-01 17:06 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > Hi! > > > > Stef told me the coming VM will expose some data about the execution to > the image. This will be great for our profiling tools. > > What is the status? > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- best, Eliot

March 1, 2014

Re: [Pharo-dev] Status of the VM?

by Alexandre Bergel

Ok, thanks for the update. 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. Go go go! Alexandre On Mar 1, 2014, at 2:19 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > This is true but this is a work in progress. Right now this feature is not stable. I will keep you in touch. I think in May I may have something stable enough (I will work with Eliot on April) but it will not be on the default VM. It will be available in the default pharo VM at some point but not now (maybe in a year ?). > > However, you may or may not be able to use it for your profiling tools. The idea is that you can get branch and send information from the previous executions of the method. However, the method needs to be cogged to have information available and once the cogged method is discarded the information is lost. It is really nice for hot spots but I don't know how it could work for a profiling tool. > > > > > > 2014-03-01 17:06 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Stef told me the coming VM will expose some data about the execution to the image. This will be great for our profiling tools. > What is the status? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 1, 2014

Re: [Pharo-dev] [squeak-dev] [ANN] Fuel 1.9.3

by phil＠highoctane.be

So Debugger -> Smalltalk tools debugger needed... Le 1 mars 2014 14:19, "Sebastian Sastre" <sebastian(a)flowingconcept.com> a Ã©crit : > great job you guys > > sebastian > > o/ > > On 01/03/2014, at 02:23, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Thanks for the update. > Cheers, > > HernÃ¡n > > > 2014-02-26 18:13 GMT-03:00 Max Leske <maxleske(a)gmail.com>: > >> Dear fellow Smalltalkers >> >> Mariano, Martin and myself are happy to announce Fuel version 1.9.3 which >> includes the follwing changes to 1.9 (1.9.1 and 1.9.2 were never officially >> announced): >> >> - (feature) the #fuelReplacement selector offers the ability to >> statically replace an object (e.g. with nil) during analysis. This can lead >> to significantly smaller graphs and improved speed when serializing large >> graphs >> - (feature) serialize the same graph that was analyzed instead of >> retrazing the graph during serialization. This prevents changes in the >> graph from happening between analysis and serialization >> - (change) store source when serializing CompiledMethod objects. Needed >> because Opal does not allow decompilation >> - (fix) migrate variables across hierarchy >> - (feature) Object>>serializeToFileNamed: shortcut for serializing >> arbitrary objects >> - (fix) better compression for LargeNegativeIntegers ( >> https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteg… >> ) >> >> Pharo30 already includes most of these changes (integration request: >> https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3) >> >> This release runs with: >> - Pharo: 1.1.1, 1.1.2, 1.2, 1.2.2, 1.3, 1.4, 2.0, 3.0 >> - Squeak: 4.1, 4.2, 4.3, 4.4, 4.5 >> >> The documentation is not up to date yet but we will remedy that situatoin >> within the next couple of days ( >> http://rmod.lille.inria.fr/web/pier/software/Fuel) >> If you encounter any bugs or have suggestions, please contact us on the >> Fuel mailing list ( >> http://lists.gforge.inria.fr/cgi-bin/mailman/roster/pharo-fuel) or >> create a new issue in our bug tracker (https://code.google.com/p/fuel/) >> >> We want to thank everyone who contributed to this release (by keyboard or >> opinion) and also all of those people who actively use Fuel. >> >> Cheers, >> Max >> > >

March 1, 2014