Escape Analysis

[Mark Thornton]

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!

:-)

[K.I.L.E.R]

I'm am definitely drooling.
Did my blog have an effect on this decision?

[princec]

Aha, that'd be nice. One less performance gotcha to worry about.

Cas

Games published by our own members! Check 'em out!

[Linuxhippy]

Would be really great to see some progress in this topic!

[phazer]

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 ?  

[princec]

Nah, I'm always princec.

Cas

[Spiff]

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.

[princec]

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

[Raghar]

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.

[princec]

I wish I'd called them "Mapped Objects" now.

Cas

Games published by our own members! Check 'em out!

[Raghar]

Yes it would be better idea. Less problem with programmers that are used to an exact C meaning of the word struct.

[Deadcow]

Hi there,

princec, there is maybe a way to implement this functionality without any addition to the java language :

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33

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 ?

[princec]

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

[K.I.L.E.R]

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?

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

[princec]

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

[K.I.L.E.R]

How do you know they aren't doing this already? If not they probably planned this when adding annotations.

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

[dleskov]

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

[princec]

<--- I recommend Jet, it really is as good as they claim. Pro version could be a little cheaper though eh?

Cas

[Azeem Jiva]

<--- I recommend Jet, it really is as good as they claim. Pro version could be a little cheaper though eh?

Cas

Can you give me some numbers?  Say against Java5, how much of an improvement do you see in your apps?  

[phazer]

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

Cool. You don't have any plans to offer a free license for open source projects?

[princec]

I've not compared it to Java "5". In fact the last version of Jet I used was 3.15 which is 2 years old and it consistently outperformed the 1.4 server VM for games programming - utterly beating it at load times and managing parity during execution time.

Cas

[dleskov]

<--- I recommend Jet, it really is as good as they claim. Pro version could be a little cheaper though eh?

We are running an v3.7 introductory offer by April 15th. Pro license price is 1/3 off, and you can get Windows and Linux versions together at the price of one of them. Upgrade prices are also reduced. If this is cheap enough, go download the eval, but mind that you have less than 20 days left.

[dleskov]

Can you give me some numbers?  Say against Java5, how much of an improvement do you see in your apps?  

We are running various benchmarks against the latest version of HotSpot client and server and JRockit right now and will publish them on our Web site soon. We will also publish all scripts, project files and instructions required to run the tests on your system.

If you do not trust vendor benchmarks, why not try it yourself against your own tests or, even better, a real app?

[dleskov]

Cool. You don't have any plans to offer a free license for open source projects?

First of all, note that Excelsior is revenue-funded, and providing support costs money. So we have to be careful about giving away stuff if we want to preserve the quality of our support.

We have plans to offer a special license for non-commercial and non-institutional usage, regardless of whether the project is open source. Considering the first paragraph, it will be  cheap, but likely not free. But we would surely give it to you for free in exchange for something valuable to us. For instance, you may participate in our beta test program or promote our product on your Web site or elsewhere, etc.

We also have plans for subscriptions and pay-as-you-go licensing, so as to remove the upfront cost barrier on commercial usage patterns such as shareware.

[phazer]

First of all, note that Excelsior is revenue-funded, and providing support costs money. So we have to be careful about giving away stuff if we want to preserve the quality of our support.

Yes, I fully understand that (I work on a commercial Java product myself). I'm in no position to argue what licensing schemes you should have, but a suggestion would be that you provide a free, case-by-case, no-support license for open source projects. The license could require the projects to explicitly state that the binary was produced with Jet, giving you free publicity for your product. I think both parties could benefit from such a license.

[dleskov]

I'm in no position to argue what licensing schemes you should have, but a suggestion would be that you provide a free, case-by-case, no-support license for open source projects. The license could require the projects to explicitly state that the binary was produced with Jet, giving you free publicity for your product. I think both parties could benefit from such a license.

This is quite possible. As I said, we do not need money in all cases. Publicity is more important.

We think a bug in our product must be fixed regardless of whether the user who has encountered is a paying customer. So in fact we do provide support to all users, the differences are in priority, responce times, escalation level, etc.