Re:Python to get Google-backed speedup
by stcredzero on Sunday June 14, 2009 @12:32AM
(#656808)
I'd like to see an optimization involving threads and GC. Some Smalltalk VMs only spawn real threads when there is a system call involved. However, the stack frames involved in the calls are momentarily exempt from GC. This means that the GC never has to wait for threads to synchronize to proceed with operations. But the language gets all of the benefits of real threads.
[ Parent
| on HN ]
I don't understand the "stack frames are exempt from GC" thing -- do you mean the stack frames do not contribute reachability roots to the garbage collection or that the stack frames themselves are not garbage-collected?
Re:Python to get Google-backed speedup
by stcredzero on Sunday June 14, 2009 @12:03PM
(#657206)
Nothing directly involved in the call participates in GC. In VisualWorks Smalltalk, these calls are special. (These are only calls out through the DLLCC facility. I believe they are marked by pragmas.) They might contribute reachability roots, though that might be problematic. I seem to remember that objects created in that stack frame are not garbage collected. Since these methods are marked, the compiler can treat these calls specially. I'm pretty sure that the objects are spawned in a different space. I think this would mean that those stack frames can't mutate objects created before the call. (This would make these calls functional in flavor.) They should be able to refer to such objects, as this will only cause an exception if things go wrong.
The only thing that happens in these methods in VisualWorks Smalltalk is marshalling to call out to DLLs implemented in C.