[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VM support for GetDirectBufferAddress
From: |
Michael Koch |
Subject: |
Re: VM support for GetDirectBufferAddress |
Date: |
Thu, 6 Jan 2005 18:21:27 +0100 |
User-agent: |
KMail/1.7.1 |
Am Donnerstag, 6. Januar 2005 18:01 schrieb Archie Cobbs:
> Michael Koch wrote:
> >>Hmm.. since this code will be so Classpath-specific, perhaps
> >>Classpath should provide the code to handle it.
> >
> > this means putting another layer into this. The VM needs only to
> > do aa simple malloc() operation and the give the result to a
> > constructor of java.nio.DirectByteBufferImpl (that's the code
> > fore
> > NewDirectByteBuffer() in human language). Its too trivial.
>
> Agreed. I was only talking about the two GetDirectBuffer*()
> functions.
>
> > The other
> > two methods are similar trivial. Putting a special layer into
> > this is too much overhead IMO. What we can do s to provide
> > default implementations for these methods. Then was VM supporting
> > JNI can use them. Each VM not supporting JNI don't needs them
> > anyway.
>
> If they have to handle views, they don't seem "trivial" to me, but
> then again I'm unfamiliar with this stuff.
I have a patch here which makes it easy. I just don't wanna commit it
before the release.
> What is the "trivial" algorithm I need to implement then? It
> doesn't seem obvious, and seems dependent on the particulars of
> Classpath's java.nio classes. But maybe I'm missing something.
for GetDirectBufferAddress: Return the pointer stored in
java.nio.Buffer.address (doesn't exist yet).
for GetDirectBufferCapacity: Return the value of
java.nio.Buffer.capacity or -1 if java.nio.Buffer.address is NULL.
> I'd be perfectly happy using the default implementation if one
> existed, at least to get an initial implementation done.
I will provide it.
Michael
--
Homepage: http://www.worldforge.org/
- Re: VM support for GetDirectBufferAddress, (continued)