13 messages in net.java.dev.jna.usersRe: [jna-users] Some questions about ...
FromSent OnAttachments
Albert StrasheimJan 6, 2009 11:33 am 
Timothy WallJan 6, 2009 11:58 am 
Albert StrasheimJan 6, 2009 12:08 pm 
Timothy WallJan 6, 2009 12:12 pm 
Timothy WallJan 6, 2009 12:14 pm 
Albert StrasheimJan 6, 2009 12:21 pm 
Timothy WallJan 6, 2009 12:29 pm 
Albert StrasheimJan 6, 2009 12:37 pm 
Daniel KaufmannJan 6, 2009 4:26 pm 
Albert StrasheimJan 6, 2009 6:38 pm.diff
Albert StrasheimJan 8, 2009 7:30 pm 
Paul LoyJan 9, 2009 1:40 am 
Timothy WallJan 9, 2009 4:45 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [jna-users] Some questions about com.sun.jna.MemoryActions...
From:Timothy Wall (twal@dev.java.net)
Date:Jan 6, 2009 11:58:43 am
List:net.java.dev.jna.users

On Jan 6, 2009, at 2:34 PM, Albert Strasheim wrote:

Hello all

I have a few questions about com.sun.jna.Memory.

I previously used JNA for calling some native functions with a Java matrix library that stored its data using native NIO buffers.

This worked great, but you run into limitations in the NIO API when you go to buffers larger than 2 GB. NIO2 might fix this, but I need a solution in the mean time.

Using com.sun.jna.Memory instead of a NIO buffer seems like it could work. However, I have a few comments about this class.

It seems like it would be more useful if Memory's align and share methods returned Memory instead of Pointer. This change would allow one to call getSize() on the SharedMemory returned when using these methods to check on the size of the new buffer.

It'd also be nice if alignment simply allocated enough memory if it didn't have it. This would probably need to be implemented as an option to align, though, since there are probably cases where you *don't* want to reallocate a buffer.

I also noticed that calling align() on a small buffer with a large byte boundary causes problems:

Memory buf = new Memory(10); System.out.println(buf.align(16384));

prints

allocated@0x4c570000 (-2742 bytes) (shared from allocated@0x4c56f540 (10 bytes))

Yeah. Is there any system-independent way to allocate aligned memory though, short of asking for a block big enough to align it?

Also, this code fails:

Memory buf = new Memory(0);

but the error message isn't quite right:

java.lang.IllegalArgumentException: Allocation size must be >= 0

I would actually think that allowing an allocation size of 0 could be useful to negate the need for other code to deal with this corner case.

Are you suggesting it return null or a valid Pointer object? I don't think either lets you avoid the corner case.

I also think it could be useful if one could explicitly call free() on a Memory instance instead of relying on the finalizer. This becomes useful when one is dealing with many large buffers that use up most of the available memory.

To make things more robust in this case, SharedMemory could be changed to check whether its underlying Memory instance has been freed and if so, throw a runtime error of some sort.

There used to be an explicit "free" in the original JNA CVS codebase, but I removed it because it wasn't referenced internally and made necessary checks for validity everywhere. At the time I thought it was a lot cleaner to not have to worry about Memory being invalid until it was GCd.

In this case, making an ExplicitlyFreeableMemory class if you need it keeps the core implementation simpler.

I could build these ideas into my own "Memory2" class, but I thought it might be useful to think about incorporating them into JNA's Memory for others to use.

Thanks for your time.

Regards,