RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux

[Staffan Larsen]

I’ve tagged the bug to add a release note - just need to provide the text for it.

Thomas: I can sponsor the fix if you send me a “hg export” changeset with the correct check-in comments.

Thanks,
/Staffan


On 12 okt 2014, at 17:19, David Holmes <david.holmes at oracle.com> wrote:

> On 12/10/2014 7:15 PM, Thomas Stüfe wrote:
>>        As for Linux, I think one could even dynamically probe for the
>>        largest
>>        allowed thread name at the start of the VM (calling
>>        pthread_setname_np
>>        with ever-smaller names until it stops saying ERANGE). That way
>>        we could
>>        retain downward compatibility while still profit from larger names
>>        should the glibc people decide to enlarge that name buffer. But
>>        again,
>>        that may be over engineered.
>> 
>> 
>>    This is likely to be a discrete range rather than a continuous one -
>>    I don't expect to find different linux versions each choosing a
>>    different value.
>> 
>> 
>> The same binary could run on both old and new Linux machines with
>> different task name length limits. It would be nice to have the VM
>> automatically adapt to future improvements while retaining downward
>> compatibility.
>> 
>> After reading up a bit on Gerards glibc feature request
>> https://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=16578,
>> it seems that pthread lib on Linux implements thread naming by using
>> kernel task names; task names are limited by TASK_COMM_LEN. It is
>> possible to increase that define, but there are bug reports out that
>> increasing TASK_COMM_LEN caused memory corruptions. So I concede that
>> while it is possible that the pthread name length may change, it is not
>> probable.
>> 
>>    My main concern is that some very commonly used threading libraries
>>    will encounter this 15 char limit eg:
>> 
>>    ForkJoinPool.commonPool-__worker-<N>
>>    pool-<N>-thread-<M>
>> 
>>    and custom Executors and FJPools tend to use even longer name.
>> 
>> 
>> This is true and you are right. I think the feature is still useful
>> enough, not so much for java developers but for OpenJDK developers, who
>> are much more likely to debug natively and for whom a common case is to
>> quickly identify OpenJDK special threads (Vm Thread, GC threads etc) in
>> a forest of common java threads.
>> 
>> It is also useful for cases where the libjvm.so is embedded into another
>> launcher as "just another library", and you want to tell apart jvm
>> threads from threads which have nothing to do with the jvm.
>> 
>>        As for missing documentation, this should be already a problem
>>        now, as
>>        the function is implemented on one platform and the other
>>        platforms are
>>        stubbed out? I don't see how the change would change that.
>> 
>> 
>>    At the moment the missing documentation concerns only one platform.
>>    Now it concerns three platforms that all (potentially) behave
>>    differently; with a fourth and fifth potentially on the way. So I
>>    think the documentation issue needs to resolved.
>> 
>> 
>> I agree with you and if you tell me the format and/or where to put it, I
>> can write a short documentation.
> 
> I would like to see a release note entry; though that is an Oracle specific entity :( Not sure where else this can be readily documented - suggestions welcome.
> 
> Thanks,
> David
> 
>> Thanks, Thomas