Fwd: native threads

Bryce Kampjes bryce at kampjes.demon.co.uk
Thu Apr 14 22:29:26 UTC 2005


Colin Putney writes:
 > - Using native threads makes garbage collection really difficult, 
 > particularly if you want to minimize pauses. Given that Squeak is 
 > commonly used in multimedia applications, where GC pauses interfere with 
 > smooth audio processing and animation, native threads would be problematic.

Garbage collection pauses may be a good reason to introduce VM level
native threads. Making a parallel old space collector would remove
pauses from the global GC. This is a problem for some multimedia work.
Imagine you're using Squeak to process midi from a live keyboard, a
half second pause will be very noticable when playing. A friend has 
this problem.

Large Seaside images may also take an uncomfortably long time for a
full garbage collect.

I suspect that a parallel GC wouldn't be harder, and may be easier,
than an incremental GC. Once we have a parallel GC then adding a few
native interpreter threads shouldn't be too hard.

The papers that I looked at suggested that parallel new space
collection was normally done by stop and copy collectors. So all
the interpreters are stopped, new space is collected then the
interpreters are restarted.

However, parallelisation would require changing the write barrior
implementation to card marking. This would also reduce the interpreter
(or compiled codes) write barrior overhead. My write barrior
implementation takes 24 instructions, a card marking write barrior
would take 1-3 instructions.

Bryce



More information about the Squeak-dev mailing list