[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Classpath build process and VM-specific issues
From: |
Michael Koch |
Subject: |
Re: Classpath build process and VM-specific issues |
Date: |
Mon, 5 Apr 2004 15:43:34 +0200 |
User-agent: |
KMail/1.5.4 |
Am Montag, 5. April 2004 15:10 schrieb Andrew Haley:
> Michael Koch writes:
> > > To be honest I think we should not have RawData in Classpath.
>
> The trouble with RawData (as it is used in gcj) is that it breaks the
> Java type system. Its bizarre semantics mean that you have something
> that looks like an object reference but you can't use it as one. You
> can't convert it to an instance of Object, for example. A garbage
> collector can't inspect it. A VM that doesn't expect this behaviour
> might crash. If we use RawData like that in Classpath, a VM may need
> to be modified. It might not even be possible. For that reason, I
> believe that we should not use RawData in Classpath, although some VM
> implementors might choose to.
>
> I think we need a better abstraction. Perhaps a Pointer class that
> may be subclassed to swtPeerPointer, nativeIntPointer, and so on.
> That will get over the enormous and painful maintenance problem with
> SWT, where you have no idea what type a pointer is, because
> everything is implicily void*. This is truly Evil.
>
> If some VM implementers want to use a RawData reference as a raw
> pointer, fine. But IMO our reference JNI shouldn't.
>
> > > It is used in VMClass, but it seems no VM implementor actually
> > > likes how that is setup now. And it is used in some of the new
> > > nio implementation classes. But I have a hard time seeing how
> > > our reference JNI implementation will make use of it. All places
> > > where it is used have unimplemented native jni parts. How are
> > > you planning to use this? Maybe we could add state (a Object or
> > > byte[] field to the class) that holds the real data (==
> > > address).
>
> Better.
>
> > > And some access method to get add the address it represents
> > > (that then might be optimized by a particular VM). But that
> > > would mean that it isn't the same type as the one from libgcj
> > > (or Ptr from kaffe) since those classes are not actually
> > > accessed through normal java code or through JNI, but handled
> > > specially through CNI or Kaffe native/vm code.
> > >
> > > As Andrew says we could maybe just use long if we want to store
> > > an address. Andrew also worked hard on getting SWT (Eclipse) 64
> > > bit clean. What I have seen from the (huge) patch this was
> > > mainly done by turning addresses as stored by JNI from int to
> > > long. BTW, was this work ever accepted into Eclipse?
> >
> > The RawData pointer will get the real address to a native memory
> > region. It can be directly used and has always the pointer size of
> > the platform.
>
> Uh, I don't understand what you mean, sorry. Why is a Java reference
> the same size as a native pointer? Perhaps I misunderstood you.
AFAIK a java refernce is a pointer and this pointer can point
everywhere. Right ? Tell me when I'm wrong.
Michael
- Re: Classpath build process and VM-specific issues, Mark Wielaard, 2004/04/04
- Re: Classpath build process and VM-specific issues, Michael Koch, 2004/04/04
- Re: Classpath build process and VM-specific issues, Andrew Haley, 2004/04/05
- Re: Classpath build process and VM-specific issues, Etienne Gagnon, 2004/04/05
- Re: Classpath build process and VM-specific issues, Andrew Haley, 2004/04/05
- Re: Classpath build process and VM-specific issues, Etienne Gagnon, 2004/04/05
- Re: Classpath build process and VM-specific issues, Michael Koch, 2004/04/05
- Re: Classpath build process and VM-specific issues, Andrew Haley, 2004/04/05
- Re: Classpath build process and VM-specific issues, Michael Koch, 2004/04/05
- Re: Classpath build process and VM-specific issues, Andrew Haley, 2004/04/05