RR(S): JDK-8022616 u4 should not be used as a type for thread_id

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Tue Sep 24 12:34:43 PDT 2013


On 9/24/13 12:01 PM, Dmitry Samersoff wrote:
> Sergey,
>
> I'm rely on JPRT in testing. Also I run some tests on FreeBSD.

It should not be too hard to run the same subset of tests on Mac OS, right?

>
>   So if you think I should run extra tests, let me know which one, I'll
> run it.
>
>   Actually the fix doesn't change MacOS X implementation - just move a
> call to ::pthread_mach_thread_np to different place so I don't expect
> any problem.

It is what we think about the code change. :)
In fact, the change is non-trivial.
It is a good idea to test it anyway.
Not sure the JPRT covers this well.

Thanks,
Serguei

>
> -Dmitry
>
>
> On 2013-09-24 22:53, serguei.spitsyn at oracle.com wrote:
>> This looks good module Staffan comment on guarantee.
>>
>> How do you test it?
>> Also, should it be tested on Mac OS as well?
>>
>>
>> Thanks,
>> Serguei
>>
>> On 9/24/13 12:57 AM, Dmitry Samersoff wrote:
>>> Please review changes:
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022616/webrev.02/
>>>
>>> Story:
>>>
>>> Tracing framework expect u4 as an id of thread
>>>
>>> pthread_t chosen as a tread id for variety of BSD platforms couldn't be
>>> converted to u4 so it cause compilation failure on BSD x64
>>>
>>> Solution:
>>>
>>> Change thread_id to pid_t and get this id  directly from kernel, the
>>> same manner as Linux code does. Mac Os X still uses mach_port instead of
>>> thread id.
>>>
>>> Tested on FreeBSD and OpenBSD and also code passed jprt.
>>>
>>> -Dmitry
>>>
>



More information about the hotspot-runtime-dev mailing list