Re: Contributions of work on Jikes RVM with GNU Classpath

[Mark Wielaard]

Hi,

On Fri, 2002-12-13 at 15:35, John Leuner wrote:
> Some questions about the other patches to Classpath:
> 
> 1. The patches to VMSystem and System
> 
> http://savannah.gnu.org/patch/?func=detailpatch&patch_id=720&group_id=85
> 
> In the old code, System.in, out and err were constructed automatically,
> but the proposed patch would leave it up to the VM to initialise these.
> 
> How about we add a hook in the System static initializer to call
> something like VMSystem.makeStandardStreams()  ?
> 
> The downside of this is that VMs that didn't bother with setting these
> streams before, would now have to implement methods to do so.

But we would provide a standard implementation that just does what the
original code does, so when upgrading your VM to the new Classpath
version you would automatically get the old behaviour back.

But why exactly does a VM need this? A better approach seems to be to
abstract java.io.FileDescriptor.in/out/err for the VM. This is the
approach that libgcj takes.

> 2. To run JRVM with GNU Classpath the native methods in java/io/File,
> FileDescriptor, FileInputStream etc have to be replaced with calls to
> the JRVM support library.
> 
> How are we going to do this? Before we were thinking of doing
> preprocessing of the Classpath java/io/*.java source with JRVM-glue code
> being controlled by a compile-time option.
> 
> Is there another way to get around this?

I would like to take the same approach as we are doing (or going to do)
for the VM glue classes in java.lang (e.g. Throwable and VMThrowable).
For every class that contains native methods rewrite them so they call a
Helper/State class. But unlike the VM glue classes GNU Classpath comes
with a standard JNI based implementation of these Helper/State classes
for GNU or POSIX based machines but VMs like libgcj (CNI), IK.VM.NET
(Managed C++) or JRVM (Java) can provide a different implementation. It
would be a small overhead, but by defining these classes as package
private and final VMs should be able to optimize these extra calls away.
There are about 20 classes (excluding awt and nio which might need
another aproach) that might need to be rewritten this way.

Cheers,

Mark