Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  List of jvm options  (Read 5088 times)
0 Members and 1 Guest are viewing this topic.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Posted 2004-09-18 04:10:29 »

In case you haven't seen this:
  http://misfit.wox.org/jvm-options-list.html
Offline gangrel-br

Junior Member




Java and Scala! Thats the game =)


« Reply #1 - Posted 2004-09-18 14:11:50 »

Whow!!  Shocked

Paulo "JCranky" Siqueira
Offline Malohkan

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #2 - Posted 2004-09-18 14:31:42 »

very cool!  It has some really nice links as well.  However I was hoping that this one, "Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1" would be helpful.... but then I realized it's about the length of a good sized book.  Has anyone written a tutorial on how to best tune garbage collection for high-fps gaming?

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #3 - Posted 2004-09-18 18:04:53 »

Quote
but then I realized it's about the length of a good sized book.  Has anyone written a tutorial on how to best tune garbage collection for high-fps gaming?


Yes - don't generate garbage in the first place.  Gaming is no different to any other high-performance application, whether that be realtime systems (hard or soft), sci-vis, or a server.  All the same principles apply.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Malohkan

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #4 - Posted 2004-09-18 18:13:13 »

How can I manage that when I constantly generate new ships and ammo who's only purpose is to be destroyed soon after?

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Offline pepe

Junior Member




Nothing unreal exists


« Reply #5 - Posted 2004-09-18 18:38:41 »

Quote


Yes - don't generate garbage in the first place.  Gaming is no different to any other high-performance application, whether that be realtime systems (hard or soft), sci-vis, or a server.  All the same principles apply.

If not generating garbage means handling your own reuse lists, you might be wasting cycles and time more than anything, not counting the mess your are adding to your program. Wink
In fact, all depends on how you manipulate objects and allocate them. If you are having lots of rapidly dying objects, generationnal GC does wonders. ( 4% cycles to handle 60MB/s sustained GC is what i call wonders)
If you're having long living objects, object pooling might be a technique to use.
Mostly, you would have to mix methods where appropriate.

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline Malohkan

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #6 - Posted 2004-09-18 19:04:52 »

The only long lasting type of thing I have are screen indicators, and I have a re-sizing array to grow as I need more indicators, and I never nullify or call new Indictor() over them, if I have one that I want to be set to a new one, I just change its members.

Is that what object pooling is?

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #7 - Posted 2004-09-19 17:09:32 »

Sort of. But, in a game terms, nothing is ever shortlived - you have to put geometry into some sort of rendering pipeline to get rendered, physics and AI models to compute.

Object pooling basically means returning your objects to a global collection when you no longer need them. Later on, when you need an object of type "foo" you go to your pool and reuse an existing instance, or create a new one if needed.

Pepe, I strongly disagree that any GC is good. We've entirely eliminated all our own garbage generation in our applications, but the JOGL implementation has a small set of objects it's creating every frame (a duplicate view of a NIO FloatBuffer) and that is causing visible stutters in our rendering loop when the GC kicks in.  60MB/s is an astounding amount of junk that should never be allowed to be created in the first place. What sort of horribly implemented algorithms are you using that generate that sort of traffic? With that level of junk generation I'd be lucky to maintain 20 fps on a modern system, let alone something 2-3 years old. Not only that, but the GC works whenever it feels like it and it's impossible to maintain smooth framerates, which is one of the most problematic issues with GC.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline pepe

Junior Member




Nothing unreal exists


« Reply #8 - Posted 2004-09-19 17:42:59 »

Quote
Pepe, I strongly disagree that any GC is good. We've entirely eliminated all our own garbage generation in our applications, but the JOGL implementation has a small set of objects it's creating every frame (a duplicate view of a NIO FloatBuffer) and that is causing visible stutters in our rendering loop when the GC kicks in.  60MB/s is an astounding amount of junk that should never be allowed to be created in the first place. What sort of horribly implemented algorithms are you using that generate that sort of traffic? With that level of junk generation I'd be lucky to maintain 20 fps on a modern system, let alone something 2-3 years old. Not only that, but the GC works whenever it feels like it and it's impossible to maintain smooth framerates, which is one of the most problematic issues with GC.

I invite you to test Gosub, then. Go to my home page, read the pdf, get the zip or launch the jnlp and do your own tests. That gamechmark effectively generated that amount of garbage, and does not stutter. It runs faster than 20 fps on modern machines( 55 to 65 ), and over 100 using GL pipeline.
Take care to read the pdf for the reasons of the test and implementation. ( don't imply i'm that dumb, just because of the junk i generate Smiley )

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline JasonB

Junior Member





« Reply #9 - Posted 2004-09-19 23:14:19 »

Quote

I invite you to test Gosub, then

I certainly can't see a GC stutter on my Asus 1.6Mhz laptop (with typically crappy laptop video card).  Although it was as jerky as hell until I turned off throttling. ;-)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pepe

Junior Member




Nothing unreal exists


« Reply #10 - Posted 2004-09-20 02:15:19 »

Quote

I certainly can't see a GC stutter on my Asus 1.6Mhz laptop (with typically crappy laptop video card).  Although it was as jerky as hell until I turned off throttling. ;-)
1.6 mhz? Wink huhuhuhu..
Can you tell me what JRE version you were using?
[edit] oh, and what is your framerate?

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline JasonB

Junior Member





« Reply #11 - Posted 2004-09-20 04:01:46 »

java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)

Running on Gentoo linux.

Frame rate is 16fps in non-fullscreen mode.  Fullscreen has some weird artifacts (doesn't take up the full screen (background takes up 3/4 of the screen) and only runs a 5fps.
Online princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2004-09-20 07:17:30 »

I discovered that using that graphical realtime memory analysis tool worked absolute wonders for me when trying to figure out garbage collection tuning.

And then I discovered -XX:MaxGCTime which more or less figures it out for you Smiley

I advocate an approach between both Pepe's and Mithrandirs' extremes. Object pooling actually significantly slows down some of the GC algorithms on the latest JREs due to the way the generational collectors track references back from old generation objects to new generation objects. And the hassle of pooling is nearly always more of a pain in the arse than just letting Java do it. A look under the hood reveals... that the way the JVM actually allocates memory in the first place is that it maintains a whole bunch of little pools of slots of different sizes. Basically doing the work for you.

Mostly what you need to be able to do is tune the young generation collector to ensure that all your garbage gets zapped very frequently and hardly any of it gets to end up in the old generation.

And then you need to stop worrying about GC pauses - because so long as they happen irregularly and infrequently, no-one will notice over general system noise in a normal game.

60MB of garbage is a terribly large amount by the way. You would be definitely wise to tune that down to 600Kb and set the heap parameters appropriately or you'll be needlessly vastly overspecifying the machine spec to achieve the same results! 60MB of garbage has to fit in 60MB of free RAM, remember!

Cas Smiley

Offline pepe

Junior Member




Nothing unreal exists


« Reply #13 - Posted 2004-09-20 07:45:41 »

Quote

I advocate an approach between both Pepe's and Mithrandirs' extremes. Object pooling actually significantly slows down some of the GC algorithms on the latest JREs due to the way the generational collectors track references back from old generation objects to new generation objects. And the hassle of pooling is nearly always more of a pain in the arse than just letting Java do it. A look under the hood reveals... that the way the JVM actually allocates memory in the first place is that it maintains a whole bunch of little pools of slots of different sizes. Basically doing the work for you.
True.  That's exactly what i meant when answering mithrandir. More words make it clearer, i should try to do that also. Wink

Quote

Mostly what you need to be able to do is tune the young generation collector to ensure that all your garbage gets zapped very frequently and hardly any of it gets to end up in the old generation.

No that sure. Having a greater young generation means that you will get longer GC and larger memory use. (which is not something you want, true? Wink )
If you have really rapidly dying and reused data, having a small eden is what looks better.  Less instances of classes take less to be scanned for reuse.

Quote

And then you need to stop worrying about GC pauses - because so long as they happen irregularly and infrequently, no-one will notice over general system noise in a normal game.

That's exactly what happened to me. I had small real GC pauses that i could not see because playing. i had to get a look at the GC log to see them.

Quote

60MB of garbage is a terribly large amount by the way. You would be definitely wise to tune that down to 600Kb and set the heap parameters appropriately or you'll be needlessly vastly overspecifying the machine spec to achieve the same results! 60MB of garbage has to fit in 60MB of free RAM, remember!
The 60MB per second garbage was intentional, and is not meant to be reduced as it was one point of my tests. Nevertheless, it's not a 60MB chunk that gets collected each second, but over a hundred smaller chunks, which is something very different. All that is explained in the pdf i wrote about that experience.

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline Malohkan

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #14 - Posted 2004-09-20 10:06:28 »

I tried adding the VM argument: -XX:MaxGCTime and got:

Unrecognized VM option 'MaxGCTime' Tongue

Edit: In this list I found:
-XX:MaxGCPauseMillis=<value>
so I put in
-XX:MaxGCPauseMillis=10
and after a couple pauses during the beginning of play, I never got any pauses later!  Very cool.  I was staring as hard as I could at the screen and didn't find any pausing for the 3 minutes that I watched.  I couldn't detect them and that was all I was trying to do.  I doubt anyone just playing for fun will notice now Smiley

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Online princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2004-09-20 10:39:44 »

Yes, sorry, didn't type it right Wink

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #16 - Posted 2004-09-23 18:53:47 »

Quote
Object pooling actually significantly slows down some of the GC algorithms on the latest JREs due to the way the generational collectors track references back from old generation objects to new generation objects.


That's the entire idea. You make it so slow that it never has to run at all! Every time you create an object, you use CPU time, every time the GC has to run, you use CPU time. These are, in general, not controllable, and the result is visible stuttering of the display.

An example - we recently took some code that was developed according to Pepe's recommendations. It was for some networking code. Lots of very short term objects, wrappers etc. It was barely able to run 25 entities at 10FPS. After removing every single object allocation and using object pooling, we can now comfortably handle 5000 entities at 25FPS.

Advising people that creating objects is ok because the GC will take care of it is precisely the reason that Java has such a terrible reputation in the first place. You're doing far more harm than good for Java (and your potential jobs) with these sort of statements. I've seen so much awful code out there precisely because of people making similar assumptions like what you guys are here and having people write off Java as a development language because of it. Where, if they had just stuck to their principles that they learnt for C/C++ programming, the Java code would have run just as well. I've seen 2 academic research papers come to just this misconstrued result because of precisely this reason. Both of these were about distributed networking systems. Taking the code that they had, and implementing proper design strategies that elminated garbage generation in the first place had the Java code running faster (more packets/sec handled) than their optimised C++ code.  Just because you can do something, doesn't mean that you should.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #17 - Posted 2004-09-23 19:06:28 »

Quote

Advising people that creating objects is ok because the GC will take care of it is precisely the reason that Java has such a terrible reputation in the first place. You're doing far more harm than good for Java (and your potential jobs) with these sort of statements. I've seen so much awful code out there precisely because of people making similar assumptions like what you guys are here and having people write off Java as a development language because of it. Where, if they had just stuck to their principles that they learnt for C/C++ programming, the Java code would have run just as well. I've seen 2 academic research papers come to just this misconstrued result because of precisely this reason. Both of these were about distributed networking systems. Taking the code that they had, and implementing proper design strategies that elminated garbage generation in the first place had the Java code running faster (more packets/sec handled) than their optimised C++ code.  Just because you can do something, doesn't mean that you should.


Unfortunately, I've seen completely the opposite problem - code that is frequently overly cautiously pre-optimized to avoid GC and do pooling and which didn't need it but ends up MUCH harder to maintain and, when you try ripping it out, actually faster in the long run. It also tends to turn out that the feared GC problems were being caused by something more subtle - or even a completely different bit of code Sad.

Not that I'm disagreeing, just pointing out that it's a problem both ways. I've got into the habit of saying "never pool ... unless you really know what you're doing, and your reason is better than "to stave off the GC" (i.e. something more like: "I happen to know what the GC will do about this and I happen to know - incontrovertibly - better")".

I'm intrigued by your statements on networking where in particular there are a LOT of big costs in object creation/destruction that have more to do with hidden costs of those particular objects, usually because of subtle ties to OS data structures (e.g. the implicit closing of a socket) or not-so-subtle (e.g. creating direct BB's - although we tend to see negligible speed penalties there despite Sun's warnings Huh). IMHO, in general, "intelligent" (i.e. architect/design led) pooling in networking code leads to dramatic improvements more because of the intracacies of network stacks than anything to do with GC.

Although I know what you mean with the app-layer penalties, e.g. DOA's and the awful amount of extra garbage that can transparently spring up from innocent actions on semi-distributed objects or their interactions...But that is a well-known side-effect of transparent distribution (it's listed right here in my 10-year-old off-the-shelf distributed systems book Grin, under "Disadvantages:").

/me still hankers after javadoc keywords @destructioncost and @constructorcost as warnings to say "this object has non-trivial creation / destruction costs or secondary-effects that you may need to be aware of, especially if creating or destroying in large quantities"

malloc will be first against the wall when the revolution comes...
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #18 - Posted 2004-09-24 02:03:19 »

As a simple example of the problems we came across - a lot of networking uses unsigned shorts or bytes. This class was creating wrapper objects for every unsigned data type. So, for example with a class that represented the message to be sent to the wire, as it was being read or written, they would create a new instance of this unsigned wrapper class (ie sematically equivalent to Integer/Float etc). The class was used for a very simple thing - fetch data from inside object, write bytes to disk. In lifetime terms it was a sum total of 3 lines of code - the create call, the fetch method and a single writer. Basically a classic example of what Pepe is recommending we should all do because the object is very short lifespan ans so the generational GC should kick in and remove it quickly. Unfortunately, in practice it fails. Removing this object creation and just using straight ints with the appropriate bit masking gained us an order of magnitude speed improvement (we went from the initial 25 entities to around 300 @ 10 FPS with no other changes).

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Online princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2004-09-24 07:40:29 »

The real world example I have is a direct comparison between Alien Flux and Super Elvis' particle systems.

Alien Flux maintains a huge pool of thousands and thousands of particles ready to leap into action. Super Elvis just news() them and lets them die of their own accord.

Alien Flux's code, as anyone who's looked at it will know, is rather hugely complex.

And when, not long after its release, I show everyone the source code to Super Elvis, you'll see just how vastly simplified the particle system is for not having to worry about pooling.

I used pools for lasers and enemy bullets in Alien Flux too. Now I know that it was basically a waste of effort as the GC is perfectly capable of handling this level of garbage on its own. There are no pools at all in Super Elvis and it hardly stutters at all and I've not even tuned the GC yet on it!

Cas Smiley

Offline crystalsquid

Junior Member




... Boing ...


« Reply #20 - Posted 2004-09-24 08:17:14 »

Is this not a question of scale?

Particles etc. are newed & 'freed' in the order of 10s per frame. I would be surprised if this was a significant cost, especially on newer VMs.

In my software renderer, I do use pools for my edge lists, as I have to reuse in the region of 1000s per frame, and the pool allocator also passes back the correct object based on my rendering flags - so it saves GC as well as centralising the flag parsing. Doing both gave me a noticable speed increase (I am still on 1.1 as well)

As has been mentioned many times before though, pre-emptive optimisation is usually wrong - if it aint broke, don't fix it.

On the other hand, implementing in Java is trickier than C++ as you do not have the requirement to 'delete', so finding the points where you should be releasing objects back into the pool can be non-trivial. Failing to track them all could render your whole pooling scheme as useless without you even knowing...

- Dom
Online princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2004-09-24 11:24:09 »

SE generates a lot more particles than that Smiley But really it's more a question of "expense of construction". You can easily tune the GC now to cope with your normal object lifecycles - if your particles live for 25 frames and you have on average 1000 particles alive you can tune the new generation size to fit. Using that graphicy tool jvmstat to profile the VM is an excellent way to do it.

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #22 - Posted 2004-09-24 12:38:43 »

Quote
There are no pools at all in Super Elvis and it hardly stutters at all


That there is the key statement. hardly is completely unacceptable in a commercial application.  It must be no stutter. At frame cycletime difference of 20ms is detectable by the human eye, less if you're doing high-rate action of change like a roll.  In all of these cases, our clients would look at that and call it a failure. If you released a commercial game like that, it would be a failure.

Quote
You can easily tune the GC now to cope with your normal object lifecycles


In a webstart app? What if your application has to run across multiple JVM versions, each acting differently?  The JVM internals are so unstable that what works well on one dot release doesn't work well on another, nor on the same dot release on two different hardware platforms.  Professional application development has to be robust and generating highly tuned environment setup is going to come back to haunt you in the end as you'll have tuned it so well to your development machine that an end user's one is going to break it completely.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Online princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2004-09-24 14:31:30 »

That's true about the deployment, but life's too short to strive for 100% perfection Wink In my video work stuff, I can't drop a single frame and that's a different kettle of fish. But in Super Elvis we're talking about the odd frame every 30-130 seconds. No-one notices.

Cas Smiley

Offline pepe

Junior Member




Nothing unreal exists


« Reply #24 - Posted 2004-09-25 07:10:11 »

Quote
I've seen so much awful code out there precisely because of people making similar assumptions like what you guys are here and having people write off Java as a development language because of it.
I'm surprised by that statement. What assumptions are you talking about? If you meant my advice that GC can make wonders, this is certainly not an assumption. It is a real life testcase that you can try and verify.
If you read (don't even read carefully, just read), my statement is not 'man, don't bother, GC makes it for you, for any cases". Your answers look like you understood the opposite of what i and others said. There ain't perfect solutions but you need to understand the pros and cons of each and use them wisely. Pooling is not the answer to everything.
My test shows clearly that we can rely on GC for some operations. Cas's do also. Would you share yours so maybe we can refine the conditions where short lived objects can't be handled efficiently by GC?

I've seen so much awful code due to memory pooling. It's unmaintainable, heavy, brings bugs and neglects big advantages of using Java.

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #25 - Posted 2004-09-25 17:46:43 »

Sure. Go to Sourceforge and look for the DIS-Java project. Don't have the name/URL of it right now.  Mostly run by the people at the Naval Postgraduate School.

That's the first project. The second project is Xj3D itself, though that's far harder to quantify. Where we've had to deal with silly amounts of object creation and GC is in Sun's own libraries in java.util. HashSet and HashMap are particularly troublesome as every time you make a query to the classes you create a new Entry instance. As we're making thousands of calls to the HashSet/Map classes per frame (for various reasons), this was causing large amounts of stuttering in the frame rate due to GC.

Quote
I've seen so much awful code due to memory pooling. It's unmaintainable, heavy, brings bugs and neglects big advantages of using Java.


You guys keep saying that but there's no reason why it should be. Object pooling is an extremely simple setup. Most ot the time no more than 20 lines of code for all of the management functions. If it is such a problem, the problem is far more endemic than the object pooling itself. It's an application design issue. Quite simply the person(s) don't know how to design and implement a clean and modular system. Point the fingers at the coders, not the implementation.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline crystalsquid

Junior Member




... Boing ...


« Reply #26 - Posted 2004-09-26 09:07:20 »

My pooling code:

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  
private static myClass free;
private myClass next;

// Function to allocate a new object
static myClass GetNew()
{
    myClass ret = free;
    if(ret == null)
        ret = new myClass();
    else
        free = ret.next;
    return ret;
}

// Function to return object to pool
void Release()
{
    next = free;
    free = this;
}

// Function to flush all 'free' objects in the pool
static void CleanUp()
{
    while(free != null)
    {
         myClass temp = free;
         free = free->next;
         temp->next = null;
    }
}


Thats 30 lines of code (including the blank lines for formatting nicely  Tongue

The 'GetNew()' just replaces new calls, but the 'Release()' call is:
a) non-intuitive to people who haven't used C before.
b) Adds extra code.

- Dom

PS: Pooling still falls under the category of optimisation, and so using it blindly without checking if it is neccesary still comes under the heading of preemptive optimisation and so is EVIL  Wink

<edit: Code indents appear to have gone a bit screwy, sorry>
Offline pepe

Junior Member




Nothing unreal exists


« Reply #27 - Posted 2004-09-26 09:38:18 »

Quote
Where we've had to deal with silly amounts of object creation and GC is in Sun's own libraries in java.util. HashSet and HashMap are particularly troublesome as every time you make a query to the classes you create a new Entry instance. As we're making thousands of calls to the HashSet/Map classes per frame (for various reasons), this was causing large amounts of stuttering in the frame rate due to GC.  

What a weird decision. If i understood correctly, you got bothered by sun's hashmap implementation, and instead of correcting that by doing your own implementation, you took the risk of settling on pooling? I guess that you also had to remove the hashmap calls, or do your own implementation... Well...Any decision can be justified and if this is what was done, i'd like to know why..

Pooling itself is easy, or it can be easy depending on how nice you want to play with the system. Implementing a nice pooling that takes care of memory problems can be more than 20 simple lines. If pooling is to you what CristalSquid just pasted, well, sure, it is easy. It is also very simplistic. Nevertheless, you forget the burden added on the projects or its subparts because of it. When you add pooling, you tend to change architecture to bend to implementation, which is definitly bad. Pooling never comes free.
But, as you said, people might not implement pooling correctly (even if in current case, it can hardly be wrong), which is one of the reasons it is 'dangerous' and why it should not be a commonly proposed solution. Recommending pooling to anyone that does not have complete and update knowledge of GC looks to me as recommending the opposite. It can also do more bad than good.
Nevertheless, i'm not saying your decision of pooling was bad. Personnally, i would not have done GoSub one year ago, as Generationnal GC was not as fine as now. I'd be curious to see how your old sources of the projects would run with current VMs and if pooling would still be necessary.
Anyway, the concept of pooling is now what is done by generationnal GC and the interest of doing double caching looks inexistent to me.

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline abies

Senior Member





« Reply #28 - Posted 2004-09-26 10:15:10 »

Quote
HashSet and HashMap are particularly troublesome as every time you make a query to the classes you create a new Entry instance.


You mean having to create a key wrapper object for each query ? I don't think that calling get(Object) on map creates any object itself.

Have you looked at trove collection classes ? It has specialized collections for primitive types to avoid wrapper creation.

As far as pooling is concerned, http://jade.dautelle.com/ is probably reasonable solution - author is realy fan of object pools and manages to avoid object creation at all in most cases, in quite transparent way.

Artur

Artur Biesiadowski
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #29 - Posted 2004-09-26 14:37:18 »

Quote
What a weird decision. If i understood correctly, you got bothered by sun's hashmap implementation, and instead of correcting that by doing your own implementation, you took the risk of settling on pooling?


Not quite. We reimplemented them using pooling internally for the Entry/MapEntry objects to be pooled. As things were added and removed from the Set/Map, the entry objects were pulled and released back into an internal pool. There is no external access to the pool.

CyrstalSquid - my pooling style is a lot like yours except I never make is accessible to the outside world. If I need something pooled, I don't do it as part of the interface to the object, I have the class that's using the object do it's own pooling. That way pooling is an individual choice of the user. It also keeps the code clean by not exposing pooling to the outside user. Also, your code would fail in a multithreaded access environment as there's no protection against someone looking in to grab an object, and another releasing it at the same time.

Here's an example of the (non-synchronised) pooling from the bottom of our hashset class:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
private Entry getNewEntry()  {
  Entry ret_val;

  int size = entryCache.size();
  if(size == 0)
    ret_val = new Entry();
  else
    ret_val = (Entry)entryCache.remove(size - 1);

  return ret_val;
}

private void releaseEntry(Entry e)  {
  entryCache.add(e);
}

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Pages: [1] 2
  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.

radar3301 (11 views)
2014-09-21 23:33:17

BurntPizza (29 views)
2014-09-21 02:42:18

BurntPizza (19 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (27 views)
2014-09-20 20:14:06

BurntPizza (30 views)
2014-09-19 03:14:18

Dwinin (47 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!