RFR: 8022808: Kitchensink hangs on macos

[Dmitry Samersoff]

On 2013-08-19 20:11, Gerard Ziemski wrote:
> hi Staffan,
> 
> A search on the topic of Mac thread id reveals that pretty much everyone
> (including Apple itself) uses pthread_mach_thread_np() for thread id, so
> it looks like you're correct to use it.
> 
> I do have some more quick feedback/questions:
> 
> 1. Could the "just checking" string in guarantee() be set to something
> more informative, like "thread id doesn't exist"?
> 
> 2. Why are we using the the "::" C++ name space before mach/pthread C
> APIs calls? I understand that you might be just following the existing
> pattern in the file, I'm just wondering if you, or anyone knows why.

C++ :: means global scope and it solves naming conflict if you would
have pthread_mach_thread_np() in your namespace and don't specify
namespace explicitly.

It's very good practice to always use :: for all os functions we call.

-Dmitry

> 3. Also not directly related to your fix, but do you know why we need
> both "set_thread_id" and "set_unique_thread_id"
> 
> 
> cheers
> 
> 
> On 8/19/2013 4:08 AM, Staffan Larsen wrote:
>> We are using the mach thread port name as the os thread identifier on
>> OS X. We get this value by calling mach_thread_self(), but we (I)
>> didn't realize that this "port" resource is reference counted and
>> mach_thread_self() increases the reference count, but we never call
>> mach_port_deallocate() to decrease the reference count. This leads to
>> a resource leak and eventually mach_thread_self() will return 0 to
>> indicate that we are out of ports. Running out of ports causes the
>> pthreads implementation (which is built on top of mach) to spin
>> forever in some calls (most notably in this case pthread_kill()).
>>
>> One way to fix this is to make sure we call mach_port_deallocate() for
>> each call to mach_thread_self(). However, this adds extra complexity
>> to the code and also makes it slower. Another solution is to ask
>> pthreads for the mach port name that it already has. Pthreads provides
>> the function pthread_mach_thread_np() for this purpose. In this case
>> there is no need to deallocate the port since pthread_mach_thread_np()
>> will not increase the reference count (and pthreads will call
>> deallocate on the port once the thread terminates).
>>
>> This fix has been verified by seeing that the number of ports the
>> process has allocated does not increase in Activity Monitor (or top).
>> It has also passed JPRT testing on all platforms.
>>
>> webrev: http://cr.openjdk.java.net/~sla/8022808/webrev.00/
>> (there is not publicly visible bug for this)
>>
>> Thanks,
>> /Staffan
> 


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