http://forums.java.net/jive/thread.jspa?threadID=480&tstart=0
It seems there are plans to add this for JDK 6.0.
So Cas, place your bets on whether it will actually happen!
http://forums.java.net/jive/thread.jspa?threadID=480&tstart=0
It seems there are plans to add this for JDK 6.0.
So Cas, place your bets on whether it will actually happen!
I’m am definitely drooling.
Did my blog have an effect on this decision?
Aha, that’d be nice. One less performance gotcha to worry about.
Cas
Would be really great to see some progress in this topic!
There is some (very little) info about this in the HotSpot team chat transcript:
"Spiff: The memory overhead for small Java objects can be a killer for some applications. For example, a Triangle object which holds 3 Point3f’s. Since HotSpot has an 8-byte per-object overhead plus 8-byte alignment, each of those Point3f’s occupy 24 bytes, where they would occupy 12 bytes with C/C++. Are there any plans to perhaps inline (memory-wise) small objects, say if you can guarantee that you’ll only refer to them through their containing parent object?
Ross Knippel: On the compiler side, we’re planning on doing escape analysis, which may allow these objects to be scalarized and therefore never created. There are no current plans to inline one object into another. "
The full transcript is available at http://java.sun.com/developer/community/chat/JavaLive/2005/jl0315.html.
Btw, Spiff == princec ? ;D
Nah, I’m always princec.
Cas
Spiff == Spiff.
I’ve been bitten by small-object overheads. There are workarounds (such as creating a float array for all vertices and having multiple triangles index into that array) but it would still be nicer to be able to have small objects w/out the overhead.
You appear to have gotten a little confused about what you actually want in that post… object overhead is insignificant in terms of memory efficiency in the situations where escape analysis is useful. EA is used to prevent taxing the garbage collector unnecessarily. What you want is Structs!
Cas
Why so ugly word as struct? Formated array in nicer.
" where they would occupy 12 bytes with C/C++. "
Actually they don’t. You should add a pointer to an array so it would be 16 to 20 bytes.
From my knowledge about graphic programming I know the preffered way is a batch processing, so you’d have float array/s anyway. I however forgot what’s better for CPU/GFX pipeline. Three float arrays, or one (or multiple) layered arrays.
Yes, I have also discovered a small object overhead aka 1000 times nothing killed donkey. It hurted a little my binary model for compression, but I think the solution is actually more L2 cache efficient, so it’s not as harsh problem.
I wish I’d called them “Mapped Objects” now.
Cas
Yes it would be better idea. Less problem with programmers that are used to an exact C meaning of the word struct.
Hi there,
princec, there is maybe a way to implement this functionality without any addition to the java language :
package java.nio;
public abstract class ObjectBuffer extends Buffer {
public ObjectBuffer( int capacity ) { ... }
public ObjectBuffer( ByteBuffer buffer ) { ... }
public ObjectBuffer duplicate();
public ObjectBuffer slice();
// ... name it
}
package org.lwjgl....;
@Pack(4)
public VertexBuffer extends ObjectBuffer {
public VertexBuffer( int capacity ) { ... }
public VertexBuffer( ByteBuffer buffer ) { ... }
public @Mapped float x;
public @Mapped float y;
public @Mapped float z;
public @Mapped float nx;
// ...
// error, only primitive types can be mapped.
public @Mapped Object o;
}
the @Mapped fields’ values depend on the current ObjectBuffer position.
Does it suits your needs ?
I was coming to the conclusion that the Java language no longer needs to be modified thanks to annotations. With annotations the JVM could do some clever internal compilation to remove all the unnecessary bounds checking and read/write fields directly from a DirectByteBuffer.
Cas
Can you expand on this a little?
I’m interested in what I think you mean.
The only problem is that I don’t know if what you mean is the same thing as what I think you mean.
Can you use annotations to create arrays without bounds checking currently?
[quote]I was coming to the conclusion that the Java language no longer needs to be modified thanks to annotations. With annotations the JVM could do some clever internal compilation to remove all the unnecessary bounds checking and read/write fields directly from a DirectByteBuffer.
Cas
[/quote]
Most annotations do nothing. What they do do, however, is embed a little hint in the bytecode for the VM. So if you stated that an object extended, say, MappedObject, then you could mark the mapped fields with the @Offset(position) annotion, and the VM could use this information to write highly optimised machine code to do the memory access for you. Otherwise the VM would simply have to generate the bytecode behind the scenes to labouriously call get/set on the underlying buffers for all the field accesses - which would be the fallback anyway.
Cas
How do you know they aren’t doing this already? If not they probably planned this when adding annotations.
[quote]Most annotations do nothing. What they do do, however, is embed a little hint in the bytecode for the VM. So if you stated that an object extended, say, MappedObject, then you could mark the mapped fields with the @Offset(position) annotion, and the VM could use this information to write highly optimised machine code to do the memory access for you. Otherwise the VM would simply have to generate the bytecode behind the scenes to labouriously call get/set on the underlying buffers for all the field accesses - which would be the fallback anyway.
Cas
[/quote]
For those interested in trying out escape analysis in Java today, we have just released Excelsior JET 3.7, which has escape analysis much improved and object explosion implemented.
<— I recommend Jet, it really is as good as they claim. Pro version could be a little cheaper though eh?
Cas
[quote]<— I recommend Jet, it really is as good as they claim. Pro version could be a little cheaper though eh?
Cas
[/quote]
Can you give me some numbers? Say against Java5, how much of an improvement do you see in your apps?
[quote]For those interested in trying out escape analysis in Java today, we have just released Excelsior JET 3.7, which has escape analysis much improved and object explosion implemented.
Download
[/quote]
Cool. You don’t have any plans to offer a free license for open source projects?