[gclist] Sharing GC resources between applications

[Boehm, Hans]

Even in the absence of native code, my impression is that at least
current
VMs don't try very hard to preserve liveness in the presence of
misbehaving code, whereas operating systems usually do.
And it seems significantly harder to do this at the VM level.
A quick glance at some a bit of the work on isolates didn't make it
clear to me whether there was an intent to address this.

As a simple example, to bring this back closer to our topic,
are isolates required to have separate finalizer threads?
If you want to minimize overhead, the answer would probably be no.
If you want fault isolation, the answer needs to be yes.

Hans

> -----Original Message-----
> From: owner-gclist at lists.iecc.com 
> [mailto:owner-gclist at lists.iecc.com] On Behalf Of David F. Bacon
> Sent: Wednesday, March 23, 2005 8:37 AM
> To: David Detlefs; gclist at lists.iecc.com
> Subject: Re: [gclist] Sharing GC resources between applications
> 
> 
> > I'm guessing that David would have no objection if I 
> rewrote the end 
> > of this to say:
> >
> >   ...is a serious drawback today, when VM implementations 
> have not yet
> >   reached the same level of maturity and reliability as operating
> >   systems.  In the long run, this approach essentially treats the VM
> >   *as* the operating system.  A program that panics the OS reveals a
> >   bug in the OS, not the program, no matter what the 
> program did, and
> >   in the same way a program that crashes a VM reveals a bug 
> in the VM.
> >   In the long run, the frequency of such bugs in VMs and OSs will
> >   become the same, at which point this argument against the Isolate
> >   approach no longer holds.
> 
> I object unless you outlaw JNI calls within any 
> Isolate-containing JVM.  Or you use something like software 
> fault isolation
> (http://portal.acm.org/citation.cfm?doid=168619.168635) for 
> all of the native code -- which will be hard if you are 
> running subsystems like database managers.
> 
> > Reasonable people may, of course, differ on how long this will take 
> > :-)
> 
> I differ on how long this will take :-)
> 
> david
> 
>