True multithreading, a la the Java VM???

Griggs, Travis tgriggs at keyww.com
Tue Jun 6 21:14:38 UTC 2000


Mark Guzdial wrote:

> At 11:19 AM +0500 6/6/00, jchludzinski at worldkey.net wrote:
> >When will Squeak support true multithreading, a la the Java VM.
> >Every Java thread
> >has associated with it a pthread or NT-thread.  Is there any intent
> >to do this with
> >Squeak (to allow blocking system calls)?  This seems like one of
> >those obviously good
> >things!
>
> This was one of the the items that we explored in my class last term
> when we studied the Squeak and Java VMs.  People who know this MUCH
> better than me will correct my misunderstandings, please, but it
> looks definitely like a mixed-bag to go with native threading.
>
> If you put the threading down into the VM, it may get faster, but it
> also becomes a whole lot less flexible (as opposed to the more
> minimized model in Squeak's VM).  There are also associated issues to
> explore:
> - Process interactions, like semaphores.  Java has lots of overhead
> in order to let the VM completely handle threading.  There is a
> lock/unlock operation available on each and every object in the Java
> VM (i.e., essentially each object becomes a monitor), which is an
> awful lot of VM-level overhead, it seems to me.
> - Exceptions.  If you're going to have exceptions with native
> threading, then the exceptions have to be implemented in the VM, too.
> For one, that's more complex, but more significantly, the VM tends to
> do things more heavy-handed (in order to be small and fast, as you
> want).  In the Java VM, the hunt for an exception handler has the VM
> literally rip contexts off the stack, eliminating the possibility of
> continuing out of the exception.  Handling the search for an
> appropriate context at the image level provides more flexibility.

Another large issue of course is the GC. You can either keep it pretty simple
and stall all threads any time GC activity takes place and thereby degrade any
real gain from native threading, or you can start doing something really
complex. As you do this, object allocation is probably going to get more
expensive. In Smalltalk, where object creation is something that is done ALOT,
especially relative to other wannabe OO systems, this could have negative
affects as well.

--
Travis Griggs (a.k.a. Lord of the Fries)
Member, Fravenic Skreiggser Software Collective
Key Technology
P-P-P-Penguin  Power!





More information about the Squeak-dev mailing list