[self-interest] Re: Threads

Jecel Assumpcao Jr jecel at lsi.usp.br
Fri Sep 3 14:18:12 UTC 1999

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

More information about the Self-interest mailing list