Pls review 7091418: FX priority class from Solaris should be available to JVM )

[Paul Hohensee]

Thanks!

Paul

On 1/25/12 6:31 PM, David Holmes wrote:
> Thanks Paul. Thumbs up from me.
>
> David
>
> On 26/01/2012 9:08 AM, Paul Hohensee wrote:
>> New webrev at
>>
>> http://cr.openjdk.java.net/~phh/7091418.01/
>>
>> It incorporates your suggestion.
>>
>> I need another review, pls. Any takers?
>>
>> Thanks,
>>
>> Paul
>>
>> On 1/25/12 2:30 AM, David Holmes wrote:
>>> On 25/01/2012 5:55 AM, Paul Hohensee wrote:
>>>> Thanks for the review.
>>>
>>> You're most welcome :)
>>>
>>>> Inline...
>>>
>>> <snip>
>>>
>>>>> The second part is the "map Thread.MAX_PRIORITY to the critical
>>>>> priority" part. On Solaris you use UseCriticalJavaThreadPriority to
>>>>> actually update the priority mapping 10 -> critical. But you don't do
>>>>> this on the other platforms. This is what I object to - if you are
>>>>> going to make this a cross-platform setting then it should be
>>>>> implemented fully on all platforms. It doesn't matter that by default
>>>>> the end result is the same, the code should be there so that if you
>>>>> could define the critical priority at runtime things would work as
>>>>> expected.
>>>>
>>>> I didn't do it on non-Solaris platforms (at least not in the code)
>>>> because on those platforms CriticalPriority is the same as
>>>> MaxPriority. No runtime mapping needed. For compiler threads and the
>>>> CMS background thread on non-Solaris platforms, using critical
>>>> priority will up their priority, which is new.
>>>
>>> All I'm looking for on linux for example is that in prio_init() you 
>>> add:
>>>
>>> if (UseCriticalJavaThreadPriority) {
>>> os::java_to_os_priority[MaxPriority] =
>>> os::java_to_os_priority[CriticalPriority] ;
>>> }
>>>
>>> That way if someone decides they want to try changing the priority
>>> table from
>>>
>>> -5 // 11 CriticalPriority
>>>
>>> to
>>>
>>> -25 // 11 CriticalPriority
>>>
>>> then UseCriticalJavaThreadPriority will "just work".
>>>
>>> Thanks,
>>> David
>>> -----
>>>