RFR: 8022808: Kitchensink hangs on macos
Staffan Larsen
staffan.larsen at oracle.com
Mon Aug 19 10:14:26 PDT 2013
I thought that was the recommended way of calling OS functions. We seem to have both styles, though.
/Staffan
On 19 aug 2013, at 17:33, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
> hi Staffan,
>
> Why are we using the the "::" C++ name space before mach/pthread C APIs calls?
>
>
> 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
>
More information about the serviceability-dev
mailing list