[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on 'reference classes'

From: Mark Wielaard
Subject: Re: Thoughts on 'reference classes'
Date: 01 Mar 2003 19:33:49 +0100


On Fri, 2003-02-28 at 00:57, Brian Jones wrote:
> Some degree of control needs to be exercised over the reference
> interface or nothing would ever work with Classpath CVS and JVM
> implementors might not enjoy tracking a rapidly moving target.

Yeah. We need some guidelines on how to introduce new VM interfaces..
But currently the VM interface is clearly suboptimal and very focused on
JNI based VMs. We now have VMs that use much different approaches for
interfacing the VM with their own runtime environment (see the
JNI/CNI/C#/Active Oberon/etc. list of my previous email). So just
deeclaring something native and saying that it should be implemented by
the VM is not enough anymore.

> > This is why I really like the native methods to live in a VMxxx class,
> > because that way I can choose to implement the method inline and still
> > retain the ability to keep using the latest Classpath code (except for
> > the vm/reference classes) as long as the interface between the xxx and
> > VMxxx classes remains stable.
> To make it more clear, perhaps things that are "native" that we
> provide implementations for should be moved to some other type of
> interface scheme such as NativeXXX instead of VMXXX.  Putting these
> things in VMXXX makes it terribly unclear what needs to be implemented
> by a JVM and what is "optional".  Opinions?

I don't know about a better name. But we might want to differientate

- VMData -> is as big as a normal object reference but special from the
point of view of the VM (like RawData in gcj), should never be
manipulated from
- VMState -> Helper class that holds all state a VM needs to hold for a
particular object (guaranteed to be one-on-one with the actual instance
of the object it belongs to).
- VMInterface -> Collection of static (native) callback methods the VM
and Classpath use to transfer control/state to each other.

Maybe this isn't the best categorization, but I think it captures the
intent of the different uses of the VM interface.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]