If not OOM, we will never ever look at “tuning parameters”… are you?

* Search typically has SLAs measured in milliseconds – a light-touch GC is needed to maintain this.
* Indexing activity typically has SLAs measured in minutes or hours – the impact of a stop-the-world type GC at this scale is of much less consequence

GC policies are for an entire VM so it can be advantageous to split search and indexing activity into seperate VMs to use a GC policy that meets the differing performance requirements outlined above.
The most efficient form of GC is to kill the JVM and there is typically no advantage to keeping any of the objects created as part of an indexing session alive. So for systems where content is only updated in scheduled intervals which is measured in minutes a dedicated indexing process can be spun up and killed for each batch of indexing activity.

Jay – This one I have on the top of my head: You can take a look with JConsole or using JMX (there is a garbage collection section)

With ergonomics, its pretty much just going to be the serial or throughput – throughput for something detected as server class (I found a table for that somewhere but need to dig it up) otherwise serial. With throughput, I think java 5 defaults to the non parallel new gen collector and java 6 defaults to parnew.

Both methods will list the old gen and new gen collectors – using different names than often used elsewhere though. For the old gen, throughput (now more often called parallel) will use MarkSweep. Serial will use MarkSweepCompact. The low pause collector will use ConcurrentMarkSweep. The new collectors also have different names: copy, scavenge, parnew, etc

Thanks,
-Jay