[concurrency-interest] Thread priority

Stanimir Simeonoff stanimir at riflexo.com
Thu Feb 7 17:50:44 EST 2013


The shorter start-up times can be attributed usually to SSD (or disk cache)
rather than pure compilations. The client jvm/compiler already shares data
(i.e. classes.jsa), so it does boot faster.
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> 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>> 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>
>>
>>         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@**gmail.com<radhakrishnan.mohan at gmail.com>
>> >
>>             <mailto:radhakrishnan.mohan at __**gmail.com <http://gmail.com>
>>
>>             <mailto:radhakrishnan.mohan@**gmail.com<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@**cs.oswego.edu<Concurrency-interest at cs.oswego.edu>
>> >
>>             <mailto:Concurrency-interest at _**_cs.oswego.edu
>>             <mailto:Concurrency-interest@**cs.oswego.edu<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@**cs.oswego.edu<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@**cs.oswego.edu<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@**cs.oswego.edu <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>
>> >
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130208/818f9700/attachment-0001.html>


More information about the Concurrency-interest mailing list