Value Types for Java
Kenneth.Russell at Sun.COM
Wed Jun 18 09:08:37 PDT 2008
It's possible to do what you want with the existing NIO Buffer classes
and a helper tool. GlueGen (http://gluegen.dev.java.net/) generates Java
classes to access C data structures. These accessor classes wrap
ByteBuffers and provide setter / getter methods for accessing the fields
of the structs. It maintains parallel ByteBuffer, IntBuffer, etc. views
of the same memory to avoid multiple memory fetches for multi-byte
primitive values. It supports arrays of C structures by providing a Java
array of objects, each of which refers to a slice of the underlying C
It's not efficient. The need to dereference through the NIO Buffers
means that each memory fetch gets expanded into something like three or
four, assuming the HotSpot compiler can't common up some of those
fetches for multiple accesses to the same object.
When talking to the graphics card via an API like OpenGL there is less
need to view the data in the form of structures.
http://jogl.dev.java.net/ and http://jogl-demos.dev.java.net/ have links
to various demos and JavaOne presentations. For several years we have
consistently been able to achieve at least 90% of C speed in 3D
graphical applications written in Java.
Still, value types would be very useful for exactly the cases you
describe. I would be concerned about the semantic change of
pass-by-value and what that would mean for the easy readability and
understanding of Java source code.
Ben Hutchison wrote:
> Miles Sabin wrote:
>> On Wed, Jun 18, 2008 at 6:15 AM, Ben Hutchison <benh at ibsglobalweb.com> wrote:
>>> Also, in terms of what it doesn't do:
>>> 1. Hard to see any way to extend to interpret a ByteBuffer region as an
>>> array of some value type, a feature ultimately needed for bulk interop
>>> with external IO/processes, I feel.
>> What do you mean here? That a ByteBuffer be viewable as an array of
>> (value) objects?
> Yes. Viewable and updatable.
> The example case I have in mind is an interaction between a Java
> process and a 3D graphics driver. Eg a Java process would be
> writing/updating triangle data in the buffer, and the graphics driver
> rendering it. (I admit it might be difficult to get this to work even
> with value type support, given that Java's philosophy says precise
> memory level representation is undefined by spec)
>> Again, I'm really not sure what it is that you want
>> to do that you can't already.
> Your earlier idea seemed to be that heterogeneous value types would
> translate into multiple side-by-side arrays accessed in unison. Most
> external processes you might want to interact with aren't going to
> "think" that way. They would typically expect to find fields of a
> related struct next to each other.
> (Granted you did mention a single array encoding for homogenous types,
> but I am concerned thats too fragile in practice - the moment it becomes
> heterogenous, the encoding scheme totally changes.)
> So, you could have one encoding of a given value type to/from
> ByteBuffer, and another otherwise, but that seems messy.
> You surely agree that your proposal represents a (worthy) workaround to
> work in current JVM architectures, and not the ideal solution?
More information about the mlvm-dev