> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 19, 1998 4:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: multi-VMs (was re: native_state troubles)
>
>
> Paul Fisher <[EMAIL PROTECTED]> writes:
> >
> > 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.
>
> which values does the JNI spec say can be cached? field and method
> ID's? this seems problematic, unless you use something like an SHA
> hash to get the id, which I would imagine Sun does not do.
>
I think you hit it on the head. Sun doesn't even think about multiple
VM issues. However, Sun does recommend you cache jclasses, and field and
method IDs. Thus, to maintain compatibility with existing native code, it
would have to be up to the VM to deal with multiple VMs in the same process.
Paul suggested the fieldID contain a pointer to (or even be) a hash of
real fieldIDs per VM. Then (*env)->CallStaticMethod(env,clazz,method,...)
can look up which actual method is currently being used and thus will
maintain compatibility with Sun's (probably misguided) directive about
caching those things.
I like this solution much better than any of mine. It centralizes the
changes that need to be made for people to go from single- to multiple-VM
thinking. In fact, most people don't even have to deal with it this way.
> The reason for this is simple -- the VM's may not even be in the same
> process. The JNI was written so that there are no direct memory
> accesses to java objects/classes/fields/methods. a JNI could marshall
> the data to a different process.
>
It shouldn't really matter, should it? What Paul is proposing won't
break that abstraction, it will just put the burden on the VM to deal with
possible inter-VM problems in the same way the class library is responsible
for dealing with possible multithreading problems. I think that is probably
where it rightfully belongs.
> xtoph
>
