I'm testing and debugging before the 0.14 release. The major benefit is faster compile times and better generated code. There's around a 10% gain or loss for the macro benchmarks depending on what's compiled.
The bug was triggered by the below code. Originally it was compiling "^[42] value". The set-up shown below is what generates the fault without needing to compile the code. The fault was odd because it wasn't crashing, and wasn't stuck in an infinite loop but the image had locked up.
I was investigating by interrupting execution with gdb and looking at both the Smalltalk stack using "p printCallStack()" and the C stack using "where". Normally, if compiled code was corrupting the object memory it would crash fairly quickly. That it kept executing, which could be seen because the Smalltalk stack kept changing was weird. If the GC's got a corrupt view of the object memory then normally it'll end up really corrupting it when it decides to try to interpret the middle of an object as an object header.
The "Error signal." at the front of the test is because running the test will lock up the image. This allows the rest of the suite to be run.
testInterruptCausesCrashes "Crashing is a failure" | processes | Error signal. self compileExpression: 'self createPoint'. processes := (1 to: 10) collect: [:each| [[(ExuperyProfiler spyOn: [(Delay forMilliseconds: 500) wait]) queueCompilationCommandsOn: SharedQueue2 new] repeat] fork. "Force a garbage collect on every allocation" SmalltalkImage current vmParameterAt: 5 put: 1. 10000 timesRepeat: [self example]. Exupery log: 'after running example'. "Reset garbage collects to a sensible value" SmalltalkImage current vmParameterAt: 5 put: 4000. processes do: [:each| each terminate].
createPoint "^ 10 @ 20"
What I think is happening is the 10 profiling processes end up consuming all the time and starving the user level process so it never completes and never resets the garbage collector's collection rate to a sane value. Having produced the lockup twice without any compiled code, I'm reasonably happy that this is the case.
Bryce