Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (121)
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  
  Overhead of 'local' allocations?  (Read 3019 times)
0 Members and 1 Guest are viewing this topic.
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Posted 2002-11-19 06: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

Junior Duke




No Exit


« Reply #1 - Posted 2002-11-19 08: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

Junior Duke




ROCK!!!


« Reply #2 - Posted 2002-11-19 13: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! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2002-11-19 13: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

Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #4 - Posted 2002-11-19 14: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

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2002-11-20 09: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

Offline rgeimer

Senior Newbie





« Reply #6 - Posted 2002-11-20 16: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

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2002-11-21 12:38:23 »

It all depends on how the JVM uses the L1 & L2 caches when it's doing GC.

Cas Smiley

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.

theagentd (16 views)
2014-10-25 15:46:29

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

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

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

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

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

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

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

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

BurntPizza (45 views)
2014-10-11 23:10:45
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!