I don’t think synchronization (using the synchronized keyword) is anywhere near 5-10% of CPU usage.
It used to be somewhat high (16 ms)? in Java 1.0 or 1.1. But I believe it has gone down significantly in Java 1.2. I don’t have any benchmarks to support this claim, however…
Plus, you have neglible overhead if you already own the synchronization lock. The actual sync overhead is grabbing the lock.
On the other hand, debugging deadlocks and other threading bugs is a lot more work… 
Why syncronise too much? Once per while is enought in most cases. Using too much syncronise, when you are sure syncronisation should be just on start and possible without syncronise keyword, is harmfull.
BTW Java uses lazy syncronisation so if you accidentaly overuse syncronise, it wouldn’t have much effect on
your program.
I think AI should be done in different thread than graphic, if for nothing else than for calculations in free computer time. Two and more processors should be very nice for this. First quick and dirty analysis, just in case. Then more detailed and highly smart one. I could imagine that such programs would run incredibly calm on more processors.
What about graphic. Did anyone tried multithreaded graphic?
So, will hyperthreading help with GC pauses…
Any experience on that (I got myself a new setup, but I don’t have time for any testing for now)
Maybe, maybe not - depends what sort of GC pause it is.
Cas 
[quote]I’m dubious whether multiple CPUs will ever become mainstream.
Additional, more specialised processors will ofcourse become more common (a Generic AI chip? :o), but until we reach the speed limitations of silicon I can’t see parrellel CPUs becoming the norm.
thoughts?
[/quote]
Ahhhh, a generic AI chip. If only :-[
Go look in the mirror for proof its possible 