Java-Gaming.org Java4K winners: [ by our judges | by the community ]         
Featured games (67)
games approved by the League of Dukes 		Games in Showcase (∞)
games submitted by our members



News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Java-Gaming.org > Game Development > Performance Tuning > Overhead of 'local' allocations?
Pages: [1]
  Print  
  Overhead of 'local' allocations?  (Read 2002 times)
0 Members and 1 Guest are viewing this topic.
Offline Herkules

JGO Kernel
*****

Posts: 1522
Medals: 1


Friendly fire isn't friendly!
« on: 2002-11-19 01:29:38 »
Hi community!

When I was young and used to code in C++, I loved the possibility to allocate objects locally on the stack. E.g.

1  
CMatrix temp( getPosition() );


In Java, the direct counterpart would be

1  
Matrix4f temp = new Matrix4f( getPosition() );


Well, there is the bad word 'new' in it. I'm afraid to create garbage by that. An alternativ is to hold a and reuse a preallocated instance:

1  
2  
3  
4  
5  
6  
private final Matrix4f mTemp = new Matrix4f();


...

    mTemp.set( getPosition() );


But this is ugly, not threadsafe and consumes memory that is only temporarily used.

Now, how big is the overhead of that special kind of 'new' for temporary objects? Can the compiler or the JVM determine that it's local, allocate it on the stack and remove it quickly when the scope is left?

I read some things about HotSpot dealing with different kinds of objects concerning their lifetimes, but I'm not ready to understand it and apply it to this case. Anybody to help me out?
HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline William

Full Member
**

Posts: 178


No Exit
« Reply #1 on: 2002-11-19 03:31:40 »
Quote
Can the compiler or the JVM determine that it's local, allocate it on the stack and remove it quickly when the scope is left?  

That determination is known as escape analysis but I do not think the current JVM from Sun implements that technique. I have read somewhere that some JVMs (possibly JET) already implement simple escape analysis though, so hopefully Sun's VM team can catch up.
Offline leknor

Full Member
**

Posts: 218


ROCK!!!
« Reply #2 on: 2002-11-19 08:05:09 »
Quote
Now, how big is the overhead of that special kind of 'new' for temporary objects? Can the compiler or the JVM determine that it's local, allocate it on the stack and remove it quickly when the scope is left?

I read some things about HotSpot dealing with different kinds of objects concerning their lifetimes, but I'm not ready to understand it and apply it to this case. Anybody to help me out?

Check out section 7.6 in Jeff's book.

There is also quite a bit of discussion on this in the old forum but it isn't very organized. I'd start with a search for 'nursery'.
Games published by our own members! Go get 'em!
Offline princec
« League of Dukes »

JGO Kernel
*****

Posts: 8089
Medals: 96


Eh? Who? What? ... Me?
« Reply #3 on: 2002-11-19 08:42:57 »
Escape analysis is the way to go. My bet is that it's going to be in 1.5.

My suspicion is that 90% of the garbage created in properly written Java applications (ie. not the nasty hacks we game-types are being forced to use) is stack-allocatable and therefore should incur zero garbage collection penalty and have 100% deterministic allocation time. JET uses this technique to great effect although I've yet to get some GC stats out of it (and besides, I've eliminated all my allocations now... Lips Sealed

For now you should use the horrible preallocation hack because no matter how clever you are with the -X flags you still get unexpected (or worse, regular) pauses and it looks shite.

A side effect is that you should probably avoid using any of the other useful APIs in Java in your rendering code too as these have a nasty tendency of creating tons of garbage in the hope that one day something will come along and make it cost-free...

Cas Smiley
Play Revenge of the Titans - Play Titan Attacks - Play Droid Assault
Offline Herkules

JGO Kernel
*****

Posts: 1522
Medals: 1


Friendly fire isn't friendly!
« Reply #4 on: 2002-11-19 09:30:35 »
Quote
A side effect is that you should probably avoid using any of the other useful APIs in Java in your rendering code too as these have a nasty tendency of creating tons of garbage in the hope that one day something will come along and make it cost-free...


.... yes, but I actually HAVE them anyway, not only rendering but also networking, GUI, logging,... where I suspect many more object are allocated/discarded than I do myself.

So I'm particularly interested in the fact how local objects behave in relation to real heap objects in respect to performance.

Now I learned that obviously they have to be treated by the GC.
I once read Jeffs (and Steve Wilsons, not to forget) book and the chapter mentioned, but it was based on Java 1.3. Or even 1.2? Have things changed over time?
HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline princec
« League of Dukes »

JGO Kernel
*****

Posts: 8089
Medals: 96


Eh? Who? What? ... Me?
« Reply #5 on: 2002-11-20 04:57:20 »
Yep, things have changed - we've now got the concurrent collector (-Xconcgc), which is the major difference between 1.3 and 1.4.

In theory it uses idle cycles to do bits of garbage collection. In practice it's really only a great deal of use when there's a spare processor where it really helps.

It's still no match for escape analysis.

Most of the optimisations for the Sun GC are to do with more common Java usage which is running big servers with massive heaps and lots of turmoil and in running client Swing GUIs which spend a lot of time sitting relatively idle. Both situations are somewhat different to what we generally want for games.

Cas Smiley
Play Revenge of the Titans - Play Titan Attacks - Play Droid Assault
Offline rgeimer

Jr. Member
**

Posts: 51
« Reply #6 on: 2002-11-20 11:17:06 »
>In theory it uses idle cycles to do bits of garbage
>collection. In practice it's really only a great deal of use
> when there's a spare processor where it really helps.

I wonder how Intel's "Hyperthreading" chips perform with concurrent gc. Anybody every try it?
Offline princec
« League of Dukes »

JGO Kernel
*****

Posts: 8089
Medals: 96


Eh? Who? What? ... Me?
« Reply #7 on: 2002-11-21 07:38:23 »
It all depends on how the JVM uses the L1 & L2 caches when it's doing GC.

Cas Smiley
Play Revenge of the Titans - Play Titan Attacks - Play Droid Assault
Pages: [1]
  Print  
 
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.095 seconds with 20 queries.