Brian Goetz has an article that once again delves into the world of the JVM, and the myths that we still hold true about writing garbage collection-friendly classes. The article looks into the evils of object pooling, finalizers, explicit garbarge collection, and more.
Excerpt
"The moral of the story is that performance advice is highly situational (and has a short shelf life). Performance advice is by definition reactive -- it is designed to address a particular problem that occurred in a particular set of circumstances. If the underlying circumstances change, or they are simply not applicable to your situation, the advice may not be applicable, either. Before you muck up your program's design to improve its performance, first make sure you have a performance problem and that following the advice will solve that problem."
Read Hints, tips, and myths about writing garbage collection-friendly classes
-
Article: When good performance advice goes bad (12 messages)
- Posted by: Dion Almaer
- Posted on: February 15 2004 22:41 EST
Threaded Messages (12)
- confused a bit by Xiang Yu on February 16 2004 13:49 EST
- Re: confused a bit by Bruno Borges on February 16 2004 15:47 EST
-
Re: confused a bit by Vlad Ender on February 16 2004 05:03 EST
- Thread creation. by Gavin King on February 17 2004 03:35 EST
- Re: confused a bit by Brian Goetz on February 19 2004 03:49 EST
-
Re: confused a bit by Vlad Ender on February 16 2004 05:03 EST
- Re: confused a bit by Bruno Borges on February 16 2004 15:47 EST
- finalize... wtf? by Bruno Borges on February 16 2004 15:52 EST
- Re: finalize... wtf? by Reg Whitton on February 17 2004 04:05 EST
- Re: finalize... wtf? by Juozas Baliuka on February 17 2004 05:35 EST
- Re: finalize... wtf? by Reg Whitton on February 17 2004 04:05 EST
- Speaking of copying collectors... by Will Hartung on February 17 2004 13:53 EST
- Speaking of copying collectors... by Matthias Ernst on February 17 2004 15:50 EST
-
Re: Speaking of copying collectors... by Will Hartung on February 17 2004 04:59 EST
- Re: Speaking of copying collectors... by Burek Jogurt on February 17 2004 05:51 EST
-
Re: Speaking of copying collectors... by Will Hartung on February 17 2004 04:59 EST
- Speaking of copying collectors... by Matthias Ernst on February 17 2004 15:50 EST
-
confused a bit[ Go to top ]
- Posted by: Xiang Yu
- Posted on: February 16 2004 13:49 EST
- in response to Dion Almaer
Are Thread Pooling, Database Connection Pooling, etc. still considered good practices? -
Re: confused a bit[ Go to top ]
- Posted by: Bruno Borges
- Posted on: February 16 2004 15:47 EST
- in response to Xiang Yu
read again... :)
"When the object creation cost is high, such as with database connections or threads, or the pooled object represents a limited and costly resource, such as with database connections, this makes sense."
This means that Brian is talking about using pools unnecessarily for little things... Create a database connection cost time, and in that case, using a pool is the best choice... But in many other cases, there is guys out there using pools for everything... IMHO, pool is good, but for some and slow things... :) -
Re: confused a bit[ Go to top ]
- Posted by: Vlad Ender
- Posted on: February 16 2004 17:03 EST
- in response to Bruno Borges
My experience suggests that thread creation (at least on my PC :) ) is fairly cheap - sub ms I think.
On the other hand the pooling here still provides another important feature - request throttling. If my application was allowed to create as many threads as it wanted, unchecked, the performance could degrade significantly.
With a pool, I'm more in control and can handle my SLAs better (assuming they allow for throwing away requests now and then).
DB connections (or any net connections for the matter) are still quite expensive to create, so pooling there will be likely a good idea for quite a while. The throttling plays a role as well, albeit lesser one than with threads.
Regards,
Vlad -
Thread creation.[ Go to top ]
- Posted by: Gavin King
- Posted on: February 17 2004 03:35 EST
- in response to Vlad Ender
My experience suggests that thread creation (at least on my PC :) ) is fairly cheap - sub ms I think. <
My understanding is that this is incredibly dependant upon OS architecture (perhaps even upon the particular JVM??). -
Re: confused a bit[ Go to top ]
- Posted by: Brian Goetz
- Posted on: February 19 2004 15:49 EST
- in response to Vlad Ender
My experience suggests that thread creation (at least on my PC :) ) is fairly cheap - sub ms I think.
Thread creation is cheaper on some architectures and more expensive on others, but that's not the only reason to use a thread pool. The real reason for using a thread pool is to manage resource usage. You can't create infinitely many threads, and even if you could, you wouldn't want to create more threads than your hardware could service. Thread pools are a mechanism for bounding resource usage and applying a consistent resource management/scheduling policy; their performance benefits (at least today) come not so much from amortizing thread creation costs over multiple requests, but in sizing an application's resource footprint to the available hardware resources. (See http://www-106.ibm.com/developerworks/java/library/j-jtp0730.html for more details on this subject.)
On the subject of DB connections, not only are they generally expensive to set up (requiring socket connections, authentication, many round trips, etc), but also they may be limited by external factors, like licensing -- perhaps you have a license for N connections. In that case, you'd better pool them. -
finalize... wtf?[ Go to top ]
- Posted by: Bruno Borges
- Posted on: February 16 2004 15:52 EST
- in response to Dion Almaer
IMHO, there is NO reason to overwrite finalize() in normal situations... Besides, there was only one time I needed to overwrite that method: turn a dead object alive again ... :)
If there is someone with other situation, please, reply... :) -
Re: finalize... wtf?[ Go to top ]
- Posted by: Reg Whitton
- Posted on: February 17 2004 04:05 EST
- in response to Bruno Borges
Normal situations - may be not. However, I have seen them used quite effectively in development. In pooled database connections, the finalize method was overwritten to log a message and stack trace if it was garbage collected before it was returned to the pool. -
Re: finalize... wtf?[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: February 17 2004 05:35 EST
- in response to Reg Whitton
Normal situations - may be not. However, I have seen them used quite effectively in development. In pooled database connections, the finalize method was overwritten to log a message and stack trace if it was garbage collected before it was returned to the pool.
Sometimes it is better not to use DB pool too. It depends on deployment,configuration,platform, but I found there are more problems with pools than with plain connections (one per thread). -
Speaking of copying collectors...[ Go to top ]
- Posted by: Will Hartung
- Posted on: February 17 2004 13:53 EST
- in response to Dion Almaer
Here's a question that has lingered in my head but I haven't seen answered.
In the Sun JVM (notably on Solaris, but perhaps in Win/Linux as well), you can specify the heap parameters:
java -Xms512M -Xmn512M com.example.BigServer
So, here is the puzzle.
Since the JVM is using a copying collector, will the JVM, in time, create TWO 512MB heaps on the system. i.e. Will the JVM start, malloc 512MB, fill it with objects, and then, when GC hits, will it malloc yet another 512MB, and then copy the objects into that space? So, that JVM requires 1GB simply for the heap on a running system?
It's confusing as the heap size parameters have little to do with the actual memory consumption of a Java process (when you include binary code, and any native modules, etc).
I haven't seen this mentioned anywhere, so I was hoping somebody could clarify it for me. -
Speaking of copying collectors...[ Go to top ]
- Posted by: Matthias Ernst
- Posted on: February 17 2004 15:50 EST
- in response to Will Hartung
Will, modern collectors are generational with different strategies for very young objects and longer-living ones. Copying collectors are only used for the young generation which is more like 8 to 30M. For the rest, a variant of mark and sweep is typically employed.
Matthias -
Re: Speaking of copying collectors...[ Go to top ]
- Posted by: Will Hartung
- Posted on: February 17 2004 16:59 EST
- in response to Matthias Ernst
Ah, yes. That makes much more sense.
But is that new generation allocated within the specified heap, or outside?
Thanx! -
Re: Speaking of copying collectors...[ Go to top ]
- Posted by: Burek Jogurt
- Posted on: February 17 2004 17:51 EST
- in response to Will Hartung
The heap is partitioned in the old and new generation. That is all these generations are just the way the heap (the one heap) is organized.