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

[Thomas Stüfe]

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

Thanks, Thomas