> -----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 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.
I love the idea and I don't think Japhar has thought of it. Thanks. This
could make life ten thousand times easier. :)
--John Keiser
