How about  a garbage collector per running thread and one for the VM 
itself?  The one for the VM would manage the others.  This would imply a 
"protected" memory scheme per thread.  The thread class itself could be 
modified to have garbage collecting methods and would manage memory 
allocated by the thread's operations.  The master GC would manage freeing 
the actual thread and thread's GC.   Just thinking out loud.  I know less 
about GC than I do about Smalltalk ;-)

Cheers,
S



>At 03:18 PM 11/14/98 -0500, you wrote:
>>A multi-threaded interpreter would be a good idea anyway. For example, if
>>there were a way to make the interprter multi-threaded, performance would
>>really be enhanced under the BeOS on multi-processor systems, since it is a
>>pervasively multi-threaded OS which will map threads to available
>>processors. Has any work been done on multi-threaded interpreters? I can
>>see all sorts of issues such as how to handle garbage collection.
>
>There are many very sticky issues of doing a multi-threaded,
>multi-processor Smalltalk. For example, the current garbage collector needs
>to move objects in memory. If your running multiple threads on the VM, you
>need to bring all these threads to a known state, so memory is not
>relocated out from under a thread. Or else you need to use garbage
>collection architecture that doesn't move things. There are a variety of
>issues like this. Fancy multi-processor safe VM architectures also may run
>slower when running on a single processor.
>
>Something that would be MUCH easier, would be to arrange for calling
>external code in a different thread. For example, you would have a pool of
>threads that were used to run slow OS calls. This would give mostly the
>same advantages as a true multithreaded VM, for single processor machines.
>It would also bypass many of the problems.
>
>A quick example of how this would work:
>
>	1) you enter a primitive to do some "slow" OS call
>
>	2) the primitive allocates a worker thread to run the OS call from 
>a pool
>and copies any data to a stable 	location, like the worker thread's 
>stack
>
>	3) the worker thread is told to run the OS call, while the main thread
>returns to executing Smalltalk code
>
>	4) Smalltalk code now waits on a Semaphore, for the completion of 
>the OS call
>
>	5) when the worker thread returns it signals the waiting Smalltalk
>process, transfering any return info, 	and then goes back into the free
>thread pool
>
>	6) the blocked Smalltalk process wakes up and goes on his way
>
>In this example, other Smalltalk processes are free to execute while the
>one Smalltalk process is blocked waiting. These is some overhead of the
>data copying and thread context switching, so this is inappropriate for
>calls that will allways execute fast. It also gets some use out of multiple
>processors, although you still can't run Smalltalk code on more than one
>processor. This method would also be EXTREEMLY easier to implement in
>Squeek. I think this "worker thread" architecture is especially appropriate
>from use in generic external C calling primitives. A big question is: do
>most people want multi-thread support so they can run Smalltalk compute
>intensive apps on multiple processors? Or do they just want to be able to
>make external calls without all Smalltalk processes blocking?
>
>- Jan
>
>
>___________________________________________________________________
>            Paradigm Matrix Inc., San Ramon California
>   "video products and development services for Win32 platforms"
>Internet: Jan Bottorff janb at pmatrix.com
>          WWW          http://www.pmatrix.com
>Phone: voice  (925) 803-9318
>       fax    (925) 803-9397
>PGP: public key  <http://www-swiss.ai.mit.edu/~bal/pks-toplev.html>
>     fingerprint  52 CB FF 60 91 25 F9 44  6F 87 23 C9 AB 5D 05 F6
>___________________________________________________________________



-------------------------------------------------------------------
VisualNewt Software
http://www.VisualNewt.com/

-------------------------------------------------------------------
Makers of Newt'sPaper(tm) - the premiere newsreader for the Newton
and Newt'sWeather(tm) - the Newton's weather solution.

-------------------------------------------------------------------