This content has been marked as final. Show 2 replies
The various types of locks are described under the heading "Efficient Thread Management" in the following (old but mostly valid) white paper:
Bottom line: You may get a lower CPU load by disabling spinlocks, but performance may suffer.
Vidar Moe said the following on 2005-10-28 09:43:
Hi!Yes, those options exist and are unsupported (as in they can change in
Just heard of the java options
jrockit.vm.useAdaptiveFatSpin / jrockit.vm.disableFatSpin /
the next release).
A colleague told that they had gotten considerably better CPU behavior,To tell you exactly what the different options do I would probably
ie. more idle time, when adding the disableFatSpin java option.
Could anyone enligthen me on exactly what these options do, and why it in some
cases can lead to less work for the CPU?
have to explain the whole java lock code in JRockit. It also differs
slightly depending on which version of JRockit you are running. I will
assume that you know what thin (deflated)/fat (inflated) locks are, or
else you can always read up on the general ideas in:
Assuming that you are running JRockit J2SE 5.0, the following is true.
jrockit.vm.disableFatSpin, will turn of all optimistic spinning when
fat locks are contended. (More information below)
jrockit.vm.useAdaptiveFatSpin and jrockit.vm.raceShouldAlwaysSpin
changes the behavior when trying to reacquire a fat lock when it is
contended. (The behavior is complex and involves heuristics that don't
make much sense without intimate knowledge of the JRockit source code)
The reason that you can get "better" CPU behavior if you turn off
optimistic spinning is that the threads will block directly when a
lock is held by somebody else. This can be beneficial, depending on
your application and how it interacts with locks, but for most
applications, locks are only held for short periods of time, and it is
highly likely that the thread holding the lock will release it soon.
So soon in fact that it often costs less to spin for a while waiting
for him to finish instead of doing a block, which would force a
complete context switch and maybe some OS-signaling. If the
application on the other hand has a very small number of highly
contended locks that are held for a long time, you can get an
excessive amount of spinning.
PS! As it is said in another (and only :-) posting regarding these options,Hope this helps.
they are only valid for multi cpu systems.
Thanks in advance!