JAVA IS SLOW!

[gregorypierce]

Unfortunately there people who continue to propagate some of these myths regardless of any evidence you offer them. Apart from these trolls, there are many other who inexplicably don't even bother to look in the obvious place for information despite it being free.
So while more information on how to write effective code is always welcome, don't expect it to have much impact on the propagation of myths. These myths are harder to kill than the demons in any game.

Yeah, but once we get past the trolls and the lazy - we get to people who genuinely want to understand.

For example - if I create a ByteBuffer and pack it with ints and my architecture does specific things with byte alignment, what does the VM do. Is there any way to influence this behavior. How do I notice this behavior. Same with things like images, textures, image formats (I know OSX is quite picky with these) etc.

How are objects created and destroyed with autoboxing - what's going on beneath the covers in the virtual machine.

When I make a call to a JNI function that creates object, how is this different than if they were created in my native Java code.

If I wanted to create lots of short lived objects yet have a large eden space (because maybe I do lots of operations that require object instantiation for some reason), why are the pause times growing since those objects should pretty much be going away immediately.

Is there a way to organize collections such that the objects you put in collections can set in the young generation longer even though the collection itself may be tenured.

How do I configure all of these performance operations in webstart or in a Java applet.

I could sit all day with someone while trying to do performance tuning and ask a million questions even though I've read through the available materials.

[Jeff]

For example - if I create a ByteBuffer and pack it with ints and my architecture does specific things with byte alignment, what does the VM do.

Nothing to my knowledge.  The VM lays down data byte by byte according to the Java spec.  You need to format
the data yourself if you are handing it to hardware that needs a given format.

How are objects created and destroyed with autoboxing - what's going on beneath the covers in the virtual machine.

Nothing.  Thsi is purely a compiler thing.  Syntactic sugar.

When I make a call to a JNI function that creates object, how is this different than if they were created in my native Java code.

Its the same code underneath.  The only issues being those of locking as with any JNI manipultion of Java objects.

If I wanted to create lots of short lived objects yet have a large eden space (because maybe I do lots of operations that require object instantiation for some reason), why are the pause times growing since those objects should pretty much be going away immediately.

Got me, Id need to see some numbers and the test and we could run it by the VM guys.

Is there a way to organize collections such that the objects you put in collections can set in the young generation longer even though the collection itself may be tenured.

The young generation gets celaned up when the eden fills.  You can increase the eden size with command line parameters. The flip side is that the bigger the eden the more it may have to potentially moe when an eden clean DOES happen.

The VM itself also adjusts the eden size on the fly trying to maintaina  good balance.  Im not sure if there are tweakable nobs on that, like there are in the -XX flags but also likely they're meanings ae nto intuitively obious.  Again I can ask the Vm guys for mreo info if you want.

How do I configure all of these performance operations in webstart or in a Java applet.

Can't yet.  They are working on adding command line flag support to Webstart. Applets rally have no place to add that

I could sit all day with someone while trying to do performance tuning and ask a million questions even though I've read through the available materials.

Well, ask them here and I'l ltry to find answers wher I cna. Also, if you can get to JavaOne, the BOF sessions are great for questions like this because you get direct access to the developers.

In particulqr we are going to have game BOF at JavaOne.  If you guys would like to giv eme a list of the grousp you'ld like to see ther to answer questions I can try to twist some arms into showing up

[gregorypierce]

I will most likely make it to JavaOne this year - as soon as Sun puts up some information on pricing I will get someone to put in the request... EARLY.

Now here is the interestion question I had. Since according to the papers, garbage collection ONLY happens when a generation fills up (when dealing with the generational collectors). What stops me from therefore just creating one gigantic eden space of like 32MB. Yes that space will suffer from heap fragmentation over time, but if I know that I can fit all of my data for a level into 32MB and then just force the collection at the end of the level or when a player dies using System.gc() - this seems to be ideal for a game and shouldn't require the need for any GC at all. After all that's what we used to do on consoles, pack it all in and save some temporary heap space for some dynamic things. Then at the end of the level we could just dump it all.

On a console this would have been more problematic, but on the PC where I know I have at least 64MB available - I should be able to just create one big-ass eden space where all of my objects are likely to fit and garbage collection should never happen - right? That's more in tune with the garbage collection strategy that a game or other multimedia application is likely to need.

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

[Jeff]

I will most likely make it to JavaOne this year - as soon as Sun puts up some information on pricing I will get someone to put in the request... EARLY.

Now here is the interestion question I had. Since according to the papers, garbage collection ONLY happens when a generation fills up (when dealing with the generational collectors).

AIUI thats not quite true. Its true for the eden. its NOT true for the trains which are incrementally collected.  Thast why its called an "inceremtnal gc" when you turn them on

What stops me from therefore just creating one gigantic eden space of like 32MB. Yes that space will suffer from heap fragmentation over time, but if I know that I can fit all of my data for a level into 32MB and then just force the collection at the end of the level or when a player dies using System.gc() - this seems to be ideal for a game

Nope you want exactly the opposite in that situation.  I explained this in the other thread on this.

[gregorypierce]

Hmmm... okay. I guess I didn't understand the paper as well as I thought. Since I want my objects to reach tenure faster - what's the best way to do this? The reason I was thinking the opposite is that I want to gc to run as infrequently as possible. Since the gc would only run when eden was full - seemed to make sense to just increase the size of eden and let my objects sit there. If the gc is only going to run when its full I would have expected that it would just be looking at the numbers of bytes allocated versus the eden size to know whether or not it needed to do anything, but clearly its doing 'something' and I'm not sure what its doing.

Essentially what I want to do is get my objects into a position where the VM isn't really wasting any time to collect them because quite simply I know they don't need to be collected. The issue with the gc in these scenarios is that it is counter to all of the gc algorithms. I understand my memory needs better than the gc, and there is no way to tell the gc - "you don't need to run ever n milliseconds because you're just wasting your time and wrecking my performance".

Now that I've described basically what I'm after (I want to preallocate 80-90% of the objects in a level that I KNOW I'm going to need), what's the best gc strategy for that since it doesn't seem to be one that's covered. All of the existing gc strategies seem to assume a memory graph that's the exact opposite of what I need to do. I don't really have alot of dynamic memory needs - I don't need to wait for my objects to take the train to tenure - I don't need the gc to even run very often as most just about everything that I put into memory will be staying there. I'm not planning on creating lots of temporary objects, I don't apparently need to worry about compacting the heap - so I just need a way to get the gc to work with a memory graph that the current VM strategies don't seem to cover at all.

[princec]

You want a very small Eden and an incremental collector, and at opportune moments, to give the GC a hint when to collect with a System.gc() - at the end of the level.

Cas

[Jeff]

Thansk, frogot to mention System.gc.

In most cases today using System.gc() is harmful, but this is exactly the kidn of situation it is intended for, when you want to tell the VM, "I'd really like you to spend some significant time gc-ing right now!"