Hi!
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 Java's powers.
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?
bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.
Stefan Matthias Aust wrote:
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 Java's powers.
As long as you keep asking questions and nobody else steps forward to answer them, you'll always be behind me in the number of posts :-)
About the power of Java, on single processor machines I see no advantage in using native threads.
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?
I would make the compiler lock the method it is (re)compiling. But it would also put the change information in a shared queue. So when the compiler is invoked in another thread and finds its method is already being compiled, it just dumps its arguments to the queue (the map that missed in the PIC and the PIC itself) and aborts (suspending the thread until the first compiler is done). The compiler in the other thread would check the queue when cleaning up and would include any new info found there in the native method. Meanwhile, other threads can be executing the old native code and PICs and as long as the inline caches don't miss it makes no difference that the method is being recompiled in parallel. When the compiler finishes its job, the old code is replaced with the new code/PICs as an atomic operation.
Very complex, as you can see, but it is certainly possible to make Self run well on multiprocessing machines.
Is there anything else to consider for VM threads?
Most current Self code tries to keep the number of threads to a minimum. To make the best use of VM threads, it would be nice to change that.
-- Jecel
self-interest@lists.selflanguage.org
-
Jecel Assumpcao Jr -
Stefan Matthias Aust