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 storage.
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. -Ken Ben Hutchison wrote: > Miles Sabin wrote: >> On Wed, Jun 18, 2008 at 6:15 AM, Ben Hutchison <[EMAIL PROTECTED]> 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? > > -Ben > _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
