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

[Dmitry Samersoff]

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
>>>>>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.