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

[serguei.spitsyn at oracle.com]

Ok.

Thanks, Dmitry!
Serguei

On 10/2/13 3:40 PM, Dmitry Samersoff wrote:
> Serguei,
>
> UTE attempts to run windows specific (dotnet) tests[1] and it cause huge
> failure rate.
>
>    I'd contacted SQE (Leonid) and he is in process of investigation
> whether it is result of wrong MAC setup or bug in latest UTE.
>
> I'd checked - none of these failures is related to my fix.
>
> [1]
>
> "/Users/dsamerso/ute/local/common/testbase/sqe/8/vm/vm/bin/bin/macos-amd64/runtime/invoker.exe"
> (in directory
> "/Users/dsamerso/UTEwork/ResultDir/allocLargeConcurent_copy_8"):
> error=2, No such file or directory" during execution of
> "${TONGA_EXECUTE}  ${TEST_ARGS} 1>${test_work_dir}/${test_name}.eout"
>
> -Dmitry
>
>
> On 2013-10-02 23:05, serguei.spitsyn at oracle.com wrote:
>> Dmitry,
>>
>> Thank you for running the tests, it is good to be safe.
>>
>> In general it is Ok to judge on the fix quality basing on the test
>> result differences.
>> But I'm surprised the TEST FAIL rate is so high (is it normal for Mac OS?).
>> You may want to take a look how many of them are unexpected.
>> It is in the file tonga.output/testlist.unexpected.
>>
>> Thanks,
>> Serguei
>>
>> On 10/2/13 11:43 AM, Dmitry Samersoff wrote:
>>> Serguei,
>>> reads
>>> I run all runtime tests on MAC OS X - lots of tests fails[1], but this
>>> numners is exactly the same with or without my fix.
>>>
>>> I'd considered it as a good result and plan to push changes tomorrow.
>>>
>>> Do you have any concerns?
>>>
>>> [1]
>>> TOTAL TESTS IN RUN: 1043
>>> TEST PASS: 502; 48% rate
>>> TEST FAIL: 541; 51% rate
>>> TEST UNDEFINED: 0; 0% rate
>>> TEST INCOMPLETE: 0; 0% rate
>>> TESTS NOT RUN: 0
>>>
>>> TOTAL TEST IN TESTLIST: 1043
>>>
>>> -Dmitry
>>>
>>>
>>>
>>>
>>> On 2013-09-24 23:34, serguei.spitsyn at oracle.com wrote:
>>>> 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
>>>>>>>
>