Running multiple VM on one image

Stephen Pair spair at advantive.com
Tue Dec 14 11:03:41 UTC 1999


I think I would start by thinking about how to support multiple users
without the need for multiple VMs.  My gut feeling is that these two issues
should be orthogonal.  You could for instance assign a user to a Squeak
Process, and also to the objects users create.  You would then need some
sort of object level security support from the VM...but all within a single
VM and image.

Forcing one VM per user could lead to scalability issues.  IIRC GemStone has
(or had) some similar issues (but I think they used a separate object memory
for each user as well).

It's not a simple problem.  Sounds like fun though!

- Stephen

> -----Original Message-----
> From: Martin Luptak [mailto:mlu at whitestein.com]
> Sent: Tuesday, December 14, 1999 4:21 AM
> To: Squeak mailing list
> Subject: Re: Running multiple VM on one image
>
>
> Stephen,
>
> the main idea of running multiple VM on one image is a multiuser acces
> to one image. There would be one VM per user, each process is owned by
> somebody. I've been thinking about multiple images (each one running
> with its own VM), but there's problem with shared stuff. I would like to
> avoid replication of classes, because this would rapidly increase the
> size of image. If there would be lots of users, this might be critical
> (almost everybody need to use GUI and kernel classes). Other benefit
> would be preemptive multiprocessing (of course just between users),
> better load balancing (if there's multiprocessor architecture) and fail
> proof of the whole system (in the case of process failure there would be
> just one VM to fail). So the question is: is it possible to run more
> than one VM on one image (like shared memory between threads or
> something like this) and mapping different Smalltalk processes to
> different VMs (on VM startup for a user, only processes assigned to this
> user will be restarted).
> Is there someone attempting this or something similar?
>
> Martin.
>





More information about the Squeak-dev mailing list