"John Keiser" <[EMAIL PROTECTED]> writes:
>
> > -----Original Message-----
> > From: Paul Fisher [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher
> > Sent: Wednesday, August 19, 1998 4:28 PM
> > To: Classpath
> > Subject: Re: multi-VMs (was re: native_state troubles)
> >
> >
> > I haven't been keeping up with all the multi-VM discussions, so these
> > questions might sound stupid. Please be gentle. :)
> >
> > "John Keiser" <[EMAIL PROTECTED]> writes:
> >
> > > And even when they do, it is literally impossible for current code
> > > to automagically work in a multi-VM situation
> >
> > Are you 100% sure of this? NSA caches values which the JNI spec says
> > _explicitly_ can be cached. It's an optimization that everyone does,
> > and Sun recommends that people do it.
> >
>
> That's because Sun doesn't implement multiple VMs. I am fairly certain they
> have not thought of the good idea you have just below; caching a jclass
> under normal circumstances only works for a single VM.
>
> > IDs are opaque objects whose values are set and stored through
> > function calls. Is it absolutely impossible for the VM to do the work
> > to figure out if the value stored in the ID is valid?
> >
> > For instance, say you have something along the lines:
> >
> > type jfieldID {
> > int *VM; // VMs in which this value has been cached
> > ...
> > }
> >
> > JNI routines that use a jfieldID would do:
> >
> > if (is_not_cached_for_current_vm(jID))
> > update_jfieldID(jID);
> >
>
> Hmm, now that is an interesting and very good idea. Have to bring it up
> with Japhar. Would bring them up to spec and make legacy code compatible
> with multiple VMs ...
I'm still unconvinced that this is what we want to do... I mean,
there's really *no* reason that a person couldn't somehow (a rather
pathological case, yes.) get japhar and the JDK running in the same
process. yes, yes, I know. this is an edge case. but here's an
example where fieldID caching across VM's just wouldn't make sense.
I think it's overly limitting (from a VM) standpoint - to support
caching/sharing of ID's.
> I think it is definitely the best option.
>
> > For that matter, why can't ID's be shared across VMs?
> >
>
> Different VMs could use different ClassLoaders (and hence different
> classes). If classes aren't shared across VMs, neither are the jclasses,
> jfieldIDs, and jmethodIDs associated with them. Japhar may share classes
> that they can guarantee are the same across different.
at present, we don't really implement classloader stuff properly
anyway :) and each vm has it's own hashtable for classes loaded with
the system classloader. So, no, we don't now.
xtoph
