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

Are Thread Pooling, Database Connection Pooling, etc. still considered good practices?

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... :)

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

My understanding is that this is incredibly dependant upon OS architecture (perhaps even upon the particular JVM??).

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.

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... :)

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).

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.

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

Ah, yes. That makes much more sense.

But is that new generation allocated within the specified heap, or outside?

Thanx!

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.