Re: Classpath future?

[Jeff Sturm]

On Thu, 12 Jul 2001, Etienne M. Gagnon wrote:
> Maybe you should give a look around... There are the ORP, Kissme, and 
> SableVM projects that have shown up lately.

Yep.  It's hard to keep up.

> I disagree with you.  For example, assume a "stop the world copying 
> collector".  Some VM thread is running Native CNI code, and another one 
> is running Java code.

For one thing, the gcj runtime doesn't distinguish native (CNI) and java
code.  At the object level, they are the same.

> The Java thread requests memory (NEW), this 
> triggers gc (low memory condition).  What should the VM do?  Wait for 
> the CNI code to finish?

In a stop-the-world collector, GC will wait for all threads to be
suspended.  It doesn't matter if they are in native code or not.  There is
a short delay here as all threads respond to a signal (or whatever
mechnanism is used to suspend threads).

> It might never do so (base awt thread, or 
> whatever).  So this is not a good idea.  OK, so let the Java thread copy 
> (thus move) objects while garbage collecting.  The problem is, how is 
> that Java thread going to get the content of registers of the CNI 
> threads, to collect all the roots?

The CNI threads must be suspended, like the Java threads.  (Depending on
the GC implementation, they may resume as garbage collection proceeds.
But you are right, each thread's register set is essential to finding
roots.)

> Morever, how is it going to preclude 
> the gcj compiler from "optimizing" field access, so that the Java thread 
> can easily update all the references stored in registers/memory used by 
> the CNI thread?

The simplest thing to do (I'm guessing somewhat, nobody has written a
copying collector for gcj that I'm aware of) is conservatively scan stacks
and registers, pinning any objects that could possibly be referenced on
the stack or by a register so they cannot be moved.

Provided the heap and static data can be precisely scanned, the vast
majority of heap objects can still be moved.

These are essentially the same ideas in Joel Bartlett's Mostly-Copying
Collector for C/C++ <uri:ftp://gatekeeper.dec.com/pub/DEC/CCgc/README>.

It's likely possible to precisely scan registers and stack too, with
quite a bit of help from the compiler.

(My belief is that moving collectors are suboptimal for many uses, but
I'll refrain from getting even further off topic.  Feel free to debate
off-list...)

> Unless you are telling me that the VM should go through 
> a very complex communication protocol to synchronize its work with the 
> CNI modules?  How would you implement this without adding overhead to 
> CNI?

Too expensive.  Native calls should be as cheap as Java calls.

> Or, maybe you are assuming a "non-moving" collector in a single 
> threaded environment?

It's a matter of portability.  Libgcj relies on help from the OS for
threads, incremental GC, etc. so of course these features are not
universally available.

> http://www.usenix.org/events/jvm01/technical.html

Interesting; thanks.

> I again disagree with you.  Unless a JVM is compiled with the 
> appropriate C++ compatibility flags, it might anyway be incompatible 
> with C++'s exception handling.  Exception handling as the other things 
> are pretty simple in JNI, as long as you have read and understood the 
> user manual, specially if the code you write is very short (as it should 
> be in the native part of the class libraries).

Simple, and tedious.  I don't like checking for errors after each and
every JNI function call.  Exception handlers are useful in native code
even if they simply catch any exception before returning to Java and
rethrow as a Java exception.  I don't expect the VM to handle uncaught C++
exceptions (none do, to my knowledge).


Jeff