[concurrency-interest] Thread priority

Gregg Wonderly gregg at cytetech.com
Thu Feb 7 23:19:23 EST 2013


On 2/7/2013 4:50 PM, Stanimir Simeonoff wrote:
> The shorter start-up times can be attributed usually to SSD (or disk cache)
> rather than pure compilations.

That is probably true for some cases.  In my case, I tried both ways, 
repeatedly, and it was demonstrably faster.  In particular, one of my apps uses 
a security manager, and the security management schemes in Java are very 
expensive, using countless locks and thread strangling which benefits heavily 
from early compilation.

> The client jvm/compiler already shares data (i.e.
> classes.jsa), so it does boot faster.

I don't think there is much data being shared in my applications.  During 
startup, there are just thousands of objects being created and managed.

Gregg

> Something like this should be a good start regarding the "advanced" XX options
> about JIT.
> $ java -XX:+PrintFlagsFinal -version | grep Compi | less
>
> Stanimir
>
> On Thu, Feb 7, 2013 at 8:01 PM, Gregg Wonderly <gregg at cytetech.com
> <mailto:gregg at cytetech.com>> wrote:
>
>     Interesting points.  My experience has been, that setting it to 100 on many
>     of my small desktop apps makes them startup much faster, and I don't seem to
>     notice any performance problems with deoptimization occuring.  I haven't
>     really done definitive analysis to prove it works just as good, but for
>     desktop apps, launch time is often a very important productivity issue.
>
>     Gregg Wonderly
>
>
>     On 2/7/2013 10:56 AM, Stanimir Simeonoff wrote:
>
>         Besides the iteration counts the JVM (may) add profiling data. For instance:
>         call sites. If the method is compiled w/ a single class only and then
>         another is
>         loaded the method has to be deoptimized and optimized again - obviously
>         unwanted
>         behavior. The same holds true for inline caches.
>
>         To put it simply: w/o the profiling data the resulting machine code may
>         not be
>         of high quality. More also if the compiling threshold is too low - that
>         would
>         result in a lot of "code cache" used and it increases memory footprint +
>         it may
>         reach the memory limit for the code cache as many invocations do not
>         reach c2
>         (10k). There was such a bug introduced w/ the tiered compilation in 6.0.25 -
>         basically it reached the 32mb of code cache super fast - and a lot of code
>         didn't reach C2 at all (or even c1 and remained interpreted). I had to
>         increase
>         the code cache limits to ~256mb (staring off 32mb) to reach to quota and
>         decided
>         to turn off tiered compilation altogether. There was a rare bug as well,
>         replacing c1 w/ c2 code resulted in crashing the process.
>         So, having low threshold is probably good for some microbenchmarks but
>         not so
>         much for real applications.
>
>         Stanimir
>
>         On Thu, Feb 7, 2013 at 6:08 PM, Gregg Wonderly <gregg at cytetech.com
>         <mailto:gregg at cytetech.com>
>         <mailto:gregg at cytetech.com <mailto:gregg at cytetech.com>>> wrote:
>
>              I've always wondered why these kinds of "large" invocation counts
>         are used.
>                In many methods, there will be a single entry in most
>         applications, and
>              "loops" inside of that method could be optimized much sooner.  In
>         many of my
>              desktop applications, I set the invocation count (on the command
>         line) to
>              100 or even 25, and get faster startups, and better performance for the
>              small amount of time that I use the apps.  For the client VM, it really
>              seems strange to wait so long (1000 invocations), to compile with
>              instrumentation.  Then waiting for 10 times that many invocations
>         to decide
>              on the final optimizations seems a bit of a stretch.
>
>              Are there real data values from lots of different users which
>         indicate that
>              these "counts" are when people are ready to be more productive?  I
>         know that
>              there are probably lots of degenerative cases where optimizations
>         will be
>              missed without enough data.  But it would seem better to go to
>         native code
>              early, and adapt occasionally, rather than wait until you can be
>         sure to be
>              perfect.
>
>              Gregg Wonderly
>
>
>              On 2/7/2013 9:49 AM, Nathan Reynolds wrote:
>
>                  With tiered compilation, once a method reaches 1,000 invocations
>                  (configurable?), it is compiled with instrumentation.  Then
>         when it reaches
>                  10,000 invocations (configurable), it is fully optimized using the
>                  instrumentation profiling data.  For these operations, the JIT
>         threads
>                  should
>                  run at a higher priority.  However, there are some
>         optimizations which
>                  are too
>                  heavy to do at a high priority.  These optimizations should be
>         done at a low
>                  priority.  Also, methods, which haven't quite reached the 1,000
>                  invocations but
>                  are being execute, could be compiled with instrumentation at a
>         low priority.
>
>                  The low priority work will only be done if the CPU isn't maxed
>         out.  If any
>                  other thread needs the CPU, then the low priority compiler
>         thread will be
>                  immediately context switched off the core.  So, the low
>         priority compilation
>                  will never significantly hurt the performance of the high priority
>                  threads.  For
>                  some work loads, the low priority threads may never get a
>         chance to run.
>                  That's
>                  okay because the work isn't that important.
>
>                  Nathan Reynolds
>
>         <http://psr.us.oracle.com/____wiki/index.php/User:Nathan_____Reynolds
>         <http://psr.us.oracle.com/__wiki/index.php/User:Nathan___Reynolds>
>
>         <http://psr.us.oracle.com/__wiki/index.php/User:Nathan___Reynolds
>         <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>>> |
>                  Architect | 602.333.9091 <tel:602.333.9091> <tel:602.333.9091
>         <tel:602.333.9091>>
>
>                  Oracle PSR Engineering <http://psr.us.oracle.com/> | Server
>         Technology
>
>                  On 2/7/2013 12:21 AM, Stanimir Simeonoff wrote:
>
>                      Thread priorities are usually NOT applied at all.
>                      For insance:
>                            intx DefaultThreadPriority                     = -1
>                          {product}
>                           intx JavaPriority10_To_OSPriority              = -1
>                        {product}
>                            intx JavaPriority1_To_OSPriority               = -1
>                          {product}
>                            intx JavaPriority2_To_OSPriority               = -1
>                          {product}
>                            intx JavaPriority3_To_OSPriority               = -1
>                          {product}
>                            intx JavaPriority4_To_OSPriority               = -1
>                          {product}
>                            intx JavaPriority5_To_OSPriority               = -1
>                          {product}
>                            intx JavaPriority6_To_OSPriority               = -1
>                          {product}
>                            intx JavaPriority7_To_OSPriority               = -1
>                          {product}
>                            intx JavaPriority8_To_OSPriority               = -1
>                          {product}
>                            intx JavaPriority9_To_OSPriority               = -1
>                          {product}
>
>                      in other words unless specified :
>         -XXJavaPriority10_To_____OSPriority=
>
>                      it won't be mapped.
>
>                      If applied the JVM compiler/GC threads may become starved
>         which you
>                      don't
>                      want, so they have to work above normal prir (that request root
>                      privileges).
>                      Alternatively the normal java threads have to run w/ lower prir
>                      which means
>                      other process will have higher priority - also unpleasant.
>
>                      Stanimir
>
>                      On Thu, Feb 7, 2013 at 5:20 AM, Mohan Radhakrishnan
>                      <radhakrishnan.mohan at gmail.com
>         <mailto:radhakrishnan.mohan at gmail.com>
>                      <mailto:radhakrishnan.mohan at __gmail.com
>         <mailto:radhakrishnan.mohan at gmail.com>>
>                      <mailto:radhakrishnan.mohan@
>         <mailto:radhakrishnan.mohan@>____gmail.com <http://gmail.com>
>
>                      <mailto:radhakrishnan.mohan at __gmail.com
>         <mailto:radhakrishnan.mohan at gmail.com>>>> wrote:
>
>                           Hi,
>                                     Can the Thread priority setting in the API
>         still be
>                      reliably
>                           used uniformly across processors ? There are other
>         concurrency
>                      patterns in
>                           the API but this setting is still there.
>
>
>                           Thanks,
>                           Mohan
>
>                           ___________________________________________________
>                           Concurrency-interest mailing list
>                      Concurrency-interest at cs.__oswe__go.edu <http://oswego.edu>
>                      <mailto:Concurrency-interest at __cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>>
>                      <mailto:Concurrency-interest@
>         <mailto:Concurrency-interest@>____cs.oswego.edu <http://cs.oswego.edu>
>                      <mailto:Concurrency-interest at __cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>>>
>
>         http://cs.oswego.edu/mailman/____listinfo/concurrency-interest
>         <http://cs.oswego.edu/mailman/__listinfo/concurrency-interest>
>
>         <http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>         <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>>
>
>
>
>
>                      ___________________________________________________
>                      Concurrency-interest mailing list
>                      Concurrency-interest at cs.__oswe__go.edu <http://oswego.edu>
>                      <mailto:Concurrency-interest at __cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>>
>         http://cs.oswego.edu/mailman/____listinfo/concurrency-interest
>         <http://cs.oswego.edu/mailman/__listinfo/concurrency-interest>
>
>         <http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>         <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>>
>
>
>
>
>                  ___________________________________________________
>                  Concurrency-interest mailing list
>                  Concurrency-interest at cs.__oswe__go.edu <http://oswego.edu>
>                  <mailto:Concurrency-interest at __cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>>
>         http://cs.oswego.edu/mailman/____listinfo/concurrency-interest
>         <http://cs.oswego.edu/mailman/__listinfo/concurrency-interest>
>                  <http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>         <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>>
>
>
>              ___________________________________________________
>              Concurrency-interest mailing list
>              Concurrency-interest at cs.__oswe__go.edu <http://oswego.edu>
>         <mailto:Concurrency-interest at __cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>>
>         http://cs.oswego.edu/mailman/____listinfo/concurrency-interest
>         <http://cs.oswego.edu/mailman/__listinfo/concurrency-interest>
>              <http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>         <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>>
>
>
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list