Re: Contributions of work on Jikes RVM with GNU Classpath

[Mark Wielaard]

Hi, (Added classpath back to the CC)

On Sun, 2002-12-15 at 21:28, John Leuner wrote:
> > > 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 these fields are final. Will the standard implementation be some
> Java classes which just create the streams as is done now?

Yes, and then sets them with setOut/In/Err(). The only downside might be
that you cannot use System.out.println() early in the boot process
anymore for debugging purposes.
 
> > 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.

But I still think this is a better solution.
 
> > 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.
> 
> I hadn't considered such a big change, but it makes perfect sense.

And I think the only way we can support JNI, CNI, Managed C++, or Active
Oberon Language which Jaos seems to use :) But this is something for
next year since I don't have time at the moment to work on it. But that
should not hold back anybody looking for a fun project.

Cheers,

Mark