Stefan Matthias Aust
sma at netsurf.de
Wed Sep 1 21:06:28 UTC 1999
In my attempt to beat Jecel in the egroups posting statistic (at least for
one month :-) another brain-dump: This time about threads. For the
Java-prototype of mySelf I'd like to support thread as this is one of
It's one thing to make the object library thread safe. The other thing is
the VM. It has to be thread safe on its basic level. If threads are
simulated by the VM (as with Smalltalk's and probably also Self's
processes), this isn't an issue. But for Java, it's interesting to use
Java threads which are native on most platforms. This is a big plus if you
want to implement servers or simply want a system that is responsive to the
user while to interfaces external services.
A Self VM is nearly stateless as all it does is pushing objects on a stack,
either literals or activation objects for message sends and blocks. Each
stack has its own stack and probably only a few variables if any. Method
lookup is however critical. While more than one thread can access a
central lookup cache as described in one of my previous emails, no thread
may modify it while others try the same or what to use it. You need either
thread-local caches (which could be a waste of memory) or a multiple-read,
single-write lock. Right?
While this seems easy, what must happen for inline caches? Does any thread
need its own native method cache (assuming ICs are used with native
compilation) or can the cache written in a way that is thread safe?
Is there anything else to consider for VM threads?
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.
More information about the Self-interest