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

[David Holmes]

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