Re: Thoughts on 'reference classes'

From:

Mark Wielaard

Subject:

Re: Thoughts on 'reference classes'

Date:

01 Mar 2003 19:33:49 +0100

Hi,
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
between:
- 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.
Cheers,
Mark