[concurrency-interest] Thread priority

Gregg Wonderly gregg at cytetech.com
Thu Feb 7 13:01:49 EST 2013


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>> 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>> |
>         Architect | 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>>> 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.__oswego.edu
>             <mailto:Concurrency-interest at 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>
>
>
>
>
>             _________________________________________________
>             Concurrency-interest mailing list
>             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>
>
>
>
>
>         _________________________________________________
>         Concurrency-interest mailing list
>         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>
>
>
>     _________________________________________________
>     Concurrency-interest mailing list
>     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>
>
>



More information about the Concurrency-interest mailing list