[concurrency-interest] Thread priority

Stanimir Simeonoff stanimir at riflexo.com
Thu Feb 7 11:56:49 EST 2013


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> 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
>> 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>>>
>>> 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<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>
>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at 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>
>>>
>>
>>
>>
>> ______________________________**_________________
>> Concurrency-interest mailing list
>> Concurrency-interest at 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>
>>
>>
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130207/ba24a0ff/attachment-0001.html>


More information about the Concurrency-interest mailing list