Re: Classpath build process and VM-specific issues

[Mark Wielaard]

Hi,

On Mon, 2004-03-29 at 18:42, Etienne Gagnon wrote:
> Etienne Gagnon wrote:
> >   vmData = new byte[PTR_SIZE];
> > or
> >   vmData = new RawData();
> > or whatever.
> > So what's the problem, with this?
> 
> And for those who want to do:
> 
>    vmData = [internalVMpointer]
> 
> They can deal with it in many ways, such as:
> 
> 1- make sure [internalVMpointer] points to
>     a non-GC'ed memory, so that GC can  identify
>     it as special;
> 2- Set their internal compiler/interpreter to deal
>     specially with all accesses to vmData (and use
>     flow analysis to track the value propagation).
> 
> I really think "Object" is the most "general" approach, as Classpath has
> decided to have a "unique, good-for-all-vms" source base approach.

I think I agree when it comes to specific VM state in the VM-interface
classes since those should not even "leak" into the rest of the code at
all. For general state as hold for some native JNI call (which GNU
Classpath also provides for java.net, java.nio, java.io, java.util, etc)
I don't think this is the right approach though. There a combination of
VMClass-shadow-object with possibly a long to hold native JNI (address)
state seems a better approach. There providing a VMClass-shadow-object
also allows VMs that don't use out JNI/Posix/C implementation for these
methods to completely override/replace these classes with their own
implementation (and defines a clear interface that has to be provided).

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part