Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (511)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Will be escape analysis based optimizations integrated into Mustang?  (Read 7508 times)
0 Members and 1 Guest are viewing this topic.
Offline Linuxhippy

Senior Duke


Medals: 1


Java games rock!


« Posted 2005-07-26 20:31:22 »

Hi,

As far as I know it would be possible with escape analysis based optimizations to do at least 2 closed-world optimizations for the price of a very high analysis overhead (=expensive):
1.) Lock elimination (Especially on multiprocessor servers interresting)
2.) Stack allocation

Will escape analysis based optimizations be part of Mustang, because as far as I see no work is done at all on this task although several groups argue that this could be helpful (an enginieer stated that mustang has support for lock-widening but not lock-elimination because that would require escape analysis, gc engineer stated that some where in java's future short lived objects may be even faster but ...).
Or will we have to wait till Dolphin or even longer?

lg Clemens
Offline K.I.L.E.R

Senior Duke




Java games rock!


« Reply #1 - Posted 2005-07-27 14:26:40 »

It was said it will be implemented in Mustang, but like most good things it's probably not going to be implemented in the upcoming version of Java.

I'd put my money on Dolphin.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline arm

Senior Newbie




Java games rock!


« Reply #2 - Posted 2005-09-28 06:18:30 »


Seems that something is boiling under the cover:

 Excerpted from http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6325352

 "call record_for_igvn(phi) only when escape analysis is enabled."


 Excerpted from http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html

"Escape analysis is an optimization that has been talked about for a long time, and it is finally here -- the current builds of Mustang (Java SE 6) can do escape analysis and convert heap allocation to stack allocation (or no allocation) where appropriate. The use of escape analysis to eliminate some allocations results in even faster average allocation times, reduced memory footprint, and fewer cache misses. Further, optimizing away some allocations reduces pressure on the garbage collector and allows collection to run less often."

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline K.I.L.E.R

Senior Duke




Java games rock!


« Reply #3 - Posted 2005-09-28 09:25:24 »

OH MY GOODNESS THANK YOU SUN!!!!
The wait is finally over. Cheesy

I am excited over this. Smiley

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline Linuxhippy

Senior Duke


Medals: 1


Java games rock!


« Reply #4 - Posted 2005-09-28 14:22:14 »

OH MY GOODNESS THANK YOU SUN!!!!
The wait is finally over. Cheesy
I am excited over this. Smiley

Well the ibm-article is definitivly wrong since I already knew it and I also know that escape-analysis based stack allocation is not enabled in current mustang builds. It is/was(?) planned for Mustang thats the reason I guess why the autor mentioned mustang.

lg Clemens
Offline arm

Senior Newbie




Java games rock!


« Reply #5 - Posted 2005-09-29 15:34:03 »

 posted this topic into IBM developerWorks  >  Java technology  >  Forums  >  Java theory and practice forum

"I have read last column of Java theory and practice: "Urban performance legends, revisited".
I have been playing with all recent builds of mustang (java 6), but there is no evidence that escape analysis is implemented or enabled.

Best Regards
ARM"


And Brian Goetz replies

"What evidence would you expect to find? The operation is invisible to the program. Also, optimizations like this are dynamic and may not kick in until a program runs for a long time.
Also, it is often common that advanced optimizations are not all "turned on" by default for pre-release JVMs."

See http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?message=13757590&cat=10&thread=96130&treeDisplayType=threadmode1&forum=181#13757590
Offline Linuxhippy

Senior Duke


Medals: 1


Java games rock!


« Reply #6 - Posted 2005-09-29 19:19:23 »

I wonder from where this guy knows wether escape analysis is already integrated in Mustang - since he's even not a sun engineer.
However mustang code is free (for somebody who does not plan to work on a free jvm project) so it should be possible to find out wether its already implemented.

"What evidence would you expect to find? The operation is invisible to the program.
Well, there are jvm analysis tools and if mustang would do stack-allocation (which it currently doesn't) the heap would not grow at all and there would be at least a 25-??% performance gain for tons of small allocations.

Quote
Also, it is often common that advanced optimizations are not all "turned on" by default for pre-release JVMs.
This is really my hope *please*
However they want to test it, don't they.

lg Clemens
Offline abies

Senior Duke





« Reply #7 - Posted 2005-09-30 12:49:01 »

java -server -XX:+DoEscapeAnalysis

Enjoy Smiley

I don't even see any difference on something like

int sum = 0;
for ( int i =0; i < 10000000; i++ ) {
  sum += new Integer(i%2).intValue();
}

I put it into method and called it 10 times to give hotspot chance to do optimalization.

Artur Biesiadowski
Offline Linuxhippy

Senior Duke


Medals: 1


Java games rock!


« Reply #8 - Posted 2005-09-30 15:10:33 »

java -server -XX:+DoEscapeAnalysis
Enjoy Smiley
I don't even see any difference on something like

Wow that means at least they are activly working on it *wow* - Thanks SUN!
Well, maybe they've just implemented the analysis stuff but not stack-allocation or lock-removeal?

However thanks a lot for let me know that switch, really interresting!

lg Clemens
Offline abies

Senior Duke





« Reply #9 - Posted 2005-09-30 16:12:11 »

If you download debug binaries, also try -XX:+PrintEscapeAnalysis

I'm decoding the output now...

For program
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class Test {
  public static void main(String[] argv) {
    for ( int i =0; i < 10; i++ ) {
      test();
    }
  }

  public static void test() {
    int sum = 0;
    for ( int i = 0; i < 1000000; i++ ) {
      sum += new Integer(i%2).intValue();
    }
  }
}


Output is as follows
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
  1       java.lang.Integer::<init> (10 bytes)
  2       java.lang.Number::<init> (5 bytes)
  1%      Test::test @ 4 (33 bytes)
======== Connection graph for  Test::test
  60  JavaObject  NoEscape       [[ 129F]]   60   Allocate   ===  46  47  48  8  1 ( 53  54 _  57  59  54  1  1  50  49 ) [[ 61  62  63  70  71  72 ]]  rawptr:NotNull ( int+, java/lang/Object:NotNull *, rawptr:NotNull, rawptr:NotNull, rawptr:NotNull, rawptr:NotNull, rawptr:NotNull ) Test::test @ bci:11
  72  LocalVar  NoEscape       [[ 60P]]   72   Proj   ===  60  [[ 73 ]] #5
  3       Test::test (33 bytes)
======== Connection graph for  Test::test
  45  JavaObject  NoEscape       [[ 113F]]   45   Allocate   ===  31  32  33  8  1 ( 38  39 _  42  44  39  1  1  35  34 ) [[ 46  47  48  55  56  57 ]]  rawptr:NotNull ( int+, java/lang/Object:NotNull *, rawptr:NotNull, rawptr:NotNull, rawptr:NotNull, rawptr:NotNull, rawptr:NotNull ) Test::test @ bci:11
  57  LocalVar  NoEscape       [[ 45P]]   57   Proj   ===  45  [[ 58 ]] #5



Edit:
After playing with
java -server  -XX:+PrintOptoAssembly -XX:+PrintIdeal -XX:+DoEscapeAnalysis -XX:+PrintEscapeAnalysis

it seems that there is no difference in generated code - but EscapeAnalysis correctly detects that Integer allocation is local. Most probably you are right - they have implemented analysis, but part which performs stack allocation is missing.

I wonder if  monitors synchronization is skipped for method local objects -  will have to investigate

Artur Biesiadowski
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline abies

Senior Duke





« Reply #10 - Posted 2005-10-04 21:57:02 »

Hats off to Hotspot team. I'm playing with various options, looking at compiler output. Just noticed that String.hashCode has it's loop unrolled (four steps). While it is not most complicated method in the world, fact that Hotspot unrolls loops for you is a nice thing. And to be honest, it unrolls it in good way - fetch all data from memory at one place and then performs 4 steps on registers only (as opposed to more obvious fetch/compute/fetch/compute/etc).

Artur Biesiadowski
Offline Spasi
« Reply #11 - Posted 2005-12-09 13:46:25 »

Lock elimination is now present in Mustand build 63. It still needs -server -XX:+DoEscapeAnalysis.

Edit: Here's an interesting article on Mustang's synchronization optimizations.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #12 - Posted 2005-12-09 16:55:38 »

I was just on my way to this forum to make the same post  Grin

Offline Linuxhippy

Senior Duke


Medals: 1


Java games rock!


« Reply #13 - Posted 2005-12-09 21:02:29 »

any performance numbers for "typical" server-side code and games?
Offline HamsterofDeath

Junior Duke




Java games rock!


« Reply #14 - Posted 2006-01-19 23:26:52 »

anything new yet?
Offline Linuxhippy

Senior Duke


Medals: 1


Java games rock!


« Reply #15 - Posted 2006-01-20 07:52:22 »

yep I found a statement where a hotspot engineer stated that stack-based allocation won't make it into mustang :-(
Offline HamsterofDeath

Junior Duke




Java games rock!


« Reply #16 - Posted 2006-01-20 10:17:48 »

i'll stay a jrockit fanboy then.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2006-01-20 10:54:03 »

Hey, it's only going to eke a few tiny % performance, in certain situations only. No big deal.

Cas Smiley

Offline Linuxhippy

Senior Duke


Medals: 1


Java games rock!


« Reply #18 - Posted 2006-01-20 11:21:27 »

Hey, it's only going to eke a few tiny % performance, in certain situations only. No big deal.

But that are the situation where developers normally use ObjectPools or other strange solutions for their problems.
For server-side programs this would really help I think...

lg Clemens
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2006-01-20 12:37:11 »

No, you use object pools for precisely the other way round - they are for objects that are expensive to construct.

Cas Smiley

Offline Linuxhippy

Senior Duke


Medals: 1


Java games rock!


« Reply #20 - Posted 2006-01-20 17:32:59 »

No, you use object pools for precisely the other way round - they are for objects that are expensive to construct.
Since you can count collection-time to construction time this is quite a valid comparison.
Imagine operations like creating some kind of immutable objects in a loop, like Integers.
Very cheap to construct and almost no way round if the API forces you this way to go - but the masses of small objects count.

lg Clemens
Offline Jeff

JGO Coder




Got any cats?


« Reply #21 - Posted 2006-01-20 18:20:29 »

Pooling on short lived, easily created objects has been a net loss for quite awhile in hotspot.

Let the eden-space do it for you.  It does it better.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline g666

Junior Duke





« Reply #22 - Posted 2006-01-20 19:52:35 »

This is probably a very newbie question but just how long is it before my short object makes it out of eden space? And just how long is short. Should i stop using obj pools for things like particles where say 20-40 might be made each frame and last say 200-1500 ms?

desperately seeking sanity
Offline darkprophet

Senior Duke




Go Go Gadget Arms


« Reply #23 - Posted 2006-01-20 22:43:55 »

Quote
Pooling on short lived, easily created objects has been a net loss for quite awhile in hotspot.
Im going to have to disagree with you there Jeff...

We were doing a Doom3 level loading in our game engine and decided to go with the route of adding events to signal addition of objects to a render bin, we noticed an FPS drop by 10fps from 40 (without events) on good hardware to 30. Pooling the objects and using some clever tricks bought the fps back up to 40...

DP


Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline HamsterofDeath

Junior Duke




Java games rock!


« Reply #24 - Posted 2006-01-20 23:22:33 »

Hey, it's only going to eke a few tiny % performance, in certain situations only. No big deal.

Cas Smiley

i don't care. it sounds cool, and if i imagine it working, it feels cool, so i like it. Cheesy
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #25 - Posted 2006-01-21 00:11:39 »

This is probably a very newbie question but just how long is it before my short object makes it out of eden space? And just how long is short. Should i stop using obj pools for things like particles where say 20-40 might be made each frame and last say 200-1500 ms?

Assuming I have a basic understanding of this from watching the cool jconsole tools and stuff... It works approximately like this :

Your object will sit in the eden space until the eden space is full, then only objects that are still alive are copied out of the eden space into the survivor space and the free memory pointer is reset to the beginning of the eden space.  Big objects that don't fit in the eden space are automatically allocated in the older generation space.  The survivor space may not actually exist (i.e. it could be part of the eden space to begin with), but conceptually it is simply there to delay promotion into the older generation for objects that were only recently allocated before eden filled.  When an object survives N collections of the eden space  it is promoted.  Therefore the older generation tends to fill  much slower, possibly it never fills and never needs collecting because only a few objects make it there and they are the ones that are alive forever as far as your application is concerned (most likely a few objects 'die' in the older generation but a collection is never needed so they just sit there until your program ends).

That's actually a gross oversimplification... there are all sorts of other ratios and rules to tune the GC and various things depend on the GC algorithm you choose to use, and I certainly don't know all the details.

The KEY is to use tools to view the memory profile and TUNE things to fit the characteristics of your application.  For example the size of the young generation and the old generation will affect collection times and how quickly objects are promoted.  you have to strike the most optimal balance you can.  The latest GC stuff in HotSpot will actually self-tune to a degree... you just have to tell it what your target collection times are and it can adjust various ratios on it's own in an attempt to meet that time.  This may mean that collections occur much more frequently, but they take far less time on each run... e.g. if you collect every other frame, but the collection only takes 1ms then your game won't likely be effected.. but if you collect every 200 frames and the collection takes 100ms.. you just got an ugly bump in your frame rate.

Offline Niwak
« Reply #26 - Posted 2006-01-21 07:46:48 »

I have been trying a few different approach to avoid the garbage collection making the fps of my engine unsteady ;
- Limit the amount of created garbage : this can be thought of a good solution but in fact it makes me design my API in an unnatural way . I think this can be kept in mind when writing the code but should not be something that leads to design choice.
- Use object pools : at first, I thought it was a good solution but in the end I was wrong and removed them ;
  . first, object pools degrade the quality of the API of my engine (this is very important for me to keep things simple an readable),
  . object pool can be slow since they need some sort of explicit garbage collection like reference counting. (For example, with reference counting, a render frame that consists of 3000 of render commands which each holds 1 render state which holds 6 matrices leads you to decrement the references on 1 + 3000 + 3000 x 1 + 3000 x 1 x 6 reference counted object when you collect the render frame !).
  . object pool have a very bad impact on the memory requirements of the application (you need your object pools to be typed therefore you end up with lots of object pools which do not share there free memory area)
  . object pool increase the work needed to maintain your code since they are a source of memory leak.
- Tune the garbage collector : it did just work. I have an average of 1 ms or less per frame for garbage collection which I consider very low (memory management has to have a cost) and far lower than that was costing me object pools.

Object pools design can be an interesting option for object for which the cost of creation or destruction is high.
I'm still wondering if this is the case with direct buffer (I have some test where it seems that they are the cause of very long 'other full gc', but I have not finished profiling this).

There is a good online chapter about GC tuning from Killer Game Programming reference somewhere in this forum.
Offline Niwak
« Reply #27 - Posted 2006-01-21 11:51:26 »

To return on the main subject, I can see one big interest of escape analysis ; it is the use of the new iteration contruct in Java 5.
I used it everywhere but it was creating lots of iterators and I therefore moved back to the simple ArrayList iteration.
It is not satisfying since it constrain my API to explicitly returns ArrayList instead of List.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #28 - Posted 2006-01-21 13:03:54 »

Should work just fine for the old iteration constructs too.

Cas Smiley

Offline HamsterofDeath

Junior Duke




Java games rock!


« Reply #29 - Posted 2006-01-21 16:29:33 »

if you need the best performance, do it like this
1  
2  
3  
4  
for (int i = lengthOfList;--i>=0;)
{
   doStuff();
}


comparisons against 0 are fast because only 1 value has to be loaded into the register (instead of the loop variable and the list size) AND you already got it there because of the "--".

1  
2  
3  
4  
5  
6  
try  {
while (true)
{
   doStuff(i++);
}
} catch ()


may be faster for very long lists, or on IBM's vm, which is a lot faster regarding exceptions.

however, in 97% of all cases, the performance doesn't matter that much (0.5 seconds or 0.52 seconds after a click on a button, who cares)

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (50 views)
2014-10-17 03:59:02

Norakomi (40 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (36 views)
2014-10-15 16:18:58

TehJavaDev (67 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (57 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (44 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!