2 Replies Latest reply: Oct 28, 2005 7:31 AM by 3004 RSS

    Use of adaptiveFatSpin / disableFatSpin java options for hyperthreaded CPU

    666705
      Hi!

      Just heard of the java options

      jrockit.vm.useAdaptiveFatSpin / jrockit.vm.disableFatSpin / jrockit.vm.raceShouldAlwaysSpin

      A colleague told that they had gotten considerably better CPU behavior, 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?

      PS! As it is said in another (and only :-) posting regarding these options, they are only valid for multi cpu systems.

      Thanks in advance!

      Regards,
      Vidar
        • 1. Re: Use of adaptiveFatSpin / disableFatSpin java options for hyperthreaded CPU
          666705
          Vidar,

          The various types of locks are described under the heading "Efficient Thread Management" in the following (old but mostly valid) white paper:

          http://www.bea.com/content/news_events/white_papers/BEA_JRockit_wp.pdf

          Bottom line: You may get a lower CPU load by disabling spinlocks, but performance may suffer.
          • 2. Re: Use of adaptiveFatSpin / disableFatSpin java options for hyperthreaded CPU
            3004
            Vidar Moe said the following on 2005-10-28 09:43:
            Hi!

            Just heard of the java options

            jrockit.vm.useAdaptiveFatSpin / jrockit.vm.disableFatSpin /
            jrockit.vm.raceShouldAlwaysSpin
            Yes, those options exist and are unsupported (as in they can change in
            the next release).

            A colleague told that they had gotten considerably better CPU behavior,
            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?
            To tell you exactly what the different options do I would probably
            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:
            http://www.research.ibm.com/people/d/dfb/papers/Bacon97Featherweight.pdf


            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,
            they are only valid for multi cpu systems.

            Thanks in advance!

            Regards,
            Vidar
            Hope this helps.


            /Bj?rn