RE: multi-VMs (was re: native_state troubles)

1998-08-25 Thread Bernd Kreimeier
John Keiser writes: > When you get around to dealing with multiple VMs--I know you have a lot > on your plate right now--I suggest you allow a configure option: --single-vm > or --multi-vm. Second that. Actually, I came to think of Japhar more as a (potential) toolkit to built and tailor

RE: multi-VMs (was re: native_state troubles)

1998-08-22 Thread John Keiser
The way I see the problem, you have two logistical choices: 1. Guarantee that multiple VMs is compatible with single VMs--i.e., any program written to Sun's specs and guidelines will work under the "multiple VM" feature of Japhar 2. Say that multiple VMs is a Japhar-specific feature

Re: multi-VMs (was re: native_state troubles)

1998-08-21 Thread Bernd Kreimeier
Paul Fisher writes: > > which values does the JNI spec say can be cached? > jfieldID's and jmethodID's. See page 17 of the JNI spec. "Accessing > Fields and Methods". As long as you keep a live reference to the > underlying class, the VM ensures that your jfieldIDs and jmethodIDs > are val

Re: multi-VMs (was re: native_state troubles)

1998-08-21 Thread Bernd Kreimeier
[EMAIL PROTECTED] writes: > > > 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 ... >

Re: multi-VMs (was re: native_state troubles)

1998-08-19 Thread Paul Fisher
[EMAIL PROTECTED] writes: > which values does the JNI spec say can be cached? jfieldID's and jmethodID's. See page 17 of the JNI spec. "Accessing Fields and Methods". As long as you keep a live reference to the underlying class, the VM ensures that your jfieldIDs and jmethodIDs are valid. Se

RE: multi-VMs (was re: native_state troubles)

1998-08-19 Thread John Keiser
> -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: > > &g

Re: multi-VMs (was re: native_state troubles)

1998-08-19 Thread toshok
"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:

Re: multi-VMs (was re: native_state troubles)

1998-08-19 Thread toshok
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 a

RE: multi-VMs (was re: native_state troubles)

1998-08-19 Thread John Keiser
> -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 m

Re: multi-VMs (was re: native_state troubles)

1998-08-19 Thread Paul Fisher
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% s

RE: multi-VMs (was re: native_state troubles)

1998-08-19 Thread John Keiser
> From: Paul Fisher [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Fisher > > "John Keiser" <[EMAIL PROTECTED]> writes: > > > Jeez, multiple VMs are a friggin *nightmare* -- this whole class > > caching issue is just one facet. > > native_state uses common practices that JavaSoft recommends for > wri