RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux
David Holmes
david.holmes at oracle.com
Fri Oct 10 22:33:42 UTC 2014
On 11/10/2014 2:46 AM, Thomas Stüfe wrote:
> Thank you all for the positive feedback; I really think the feature
> would be useful. Right now I am looking at a core on Linux from a Tomcat
> run and it is nice to see the thread names in a list instead of having
> to manually go thru all threads and examine the stack to guess at the
> function.
>
> I agree with David that the solution is not complete, but I think it
> would be a step in the right direction. Sure it would be nice to have
> all platforms; however, 3 out of 5 is not bad. On AIX, I am
> investigating whether we can add the feature some other way.
>
> The limitation to the current thread is not a hard limitation; Linux and
> Windows implementations work with other threads too. I did not test Mac OS.
>
> I do not think the restriction on Windows is that bad; it is still
> helpful. You want thread names, just run the VM in a debugger from the
> start on.
>
> I even looked for a way to re-establish thread names after the windows
> debugger attaches; but seems to be no way to get informed when a
> debugger attaches. Theoretically one could add a function which iterates
> over all threads, calling os::set_native_thread_name() on them (provided
> we make it work for other threads than the current one), and call that
> function manually within the Debugger. But I think that would be over
> engineered.
>
> 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. 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.
> 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.
Thanks,
David
> Thomas
>
>
> On Fri, Oct 10, 2014 at 5:15 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> We should wait for Gerard to catch up with this before any commit is
> done. He had also already proposed code changes in the bug report.
>
> We also need to determine where these different platform limitations
> are to be documented. Otherwise we will get bug reports (as I'm sure
> I've mentioned in previous discussions) regarding missing names
> (because setName was not called by the current thread on itself) and
> duplicate names (because of the 15 char limit).
>
> On the issue of current thread versus any thread, is
> pthread_setname_np restricted to use by the current thread on
> itself? It is used that way in this patch, but possibly only to
> match the restriction that OSX had introduced. That restriction
> should be removed on platforms where it can be removed.
>
> Thanks,
> David
>
>
> On 10/10/2014 11:58 PM, Volker Simonis wrote:
>
> Hi,
>
> I totally agree with Staffan. This change simply improves the
> current
> situation on Linux and Windows. And it has no drawbacks on other
> platforms.
>
> Can somebody please sponsor this change? And please don't forget to
> add a "Contributed-by: thomas.stuefe at sap.com
> <mailto:thomas.stuefe at sap.com>" as he's no author until
> now - but he's covered by the general SAP OCA.
>
> Thank you and best regards,
> Volker
>
>
> On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty
> <daniel.daugherty at oracle.com
> <mailto:daniel.daugherty at oracle.com>> wrote:
>
> I started this architectural inconsistency when I shepherded in
> the os::set_native_thread_name() API with the MacOS X port so
> our current state of affairs is that we are inconsistent across
> the platforms today.
>
> If I remember our very old discussions, our choices were:
>
> 1) remove os::set_native_thread_name() since it cannot be done
> consistently across platforms
> 2) allow differing implementations of
> os::set_native_thread_name()
> to be added as they are developed by interested parties
> 3) define a Lowest-Common-Denominator (LCD) version of the API
> and add platform implementations that adhere to the LCD; in
> other words, we hobble implementations that can do more for
> the sake of consistency
>
> I don't like #1 or #3. I'm OK with #2 and there's precedent for
> platform specific limitations, e.g., filename and pathname
> length
> differences between the various platforms...
>
> Dan
>
>
>
> On 10/10/14 4:54 AM, Staffan Larsen wrote:
>
>
> Thomas,
>
> I’m happy to see this being worked on and I think the
> code looks good. We
> had similar implementations of this in JRockit and very
> often found them
> useful.
>
> I don’t share David’s concerns. That we can’t do this on
> solaris is not a
> good reason not do it on other platforms. The windows
> limitation that a
> debugger has to be attached is a limitation, but the
> feature is worth a lot
> when you /do/ have a debugger attached. The 15 character
> limitation is too
> bad, but again, better something than nothing.
>
> Thanks,
> /Staffan
>
> On 10 okt 2014, at 11:06, David Holmes
> <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> Hi Thomas,
>
> Based on the bug report Gerard's work stalled
> because of solaris issues.
> We've covered a lot of ground regarding this in the
> past. Personally I'm
> unhappy about a few things - the windows situations
> seem not that useful;
> the linux 15 character limit also renders this
> useless for many cases. Then
> there is the issue of whether this can only be
> applied by the current thread
> to itself, or by any thread to any thread.
>
> I concede there is some value in some cases but
> there are enough warts on
> this to make me cringe about putting it in. (As I
> cringed with the original
> OSX version.)
>
> That's not to say I'm going to oppose it, but I
> certainly don't champion
> it. :)
>
> Cheers,
> David
>
> On 10/10/2014 6:38 PM, Thomas Stüfe wrote:
>
>
> Hi all,
>
> I'd like to contribute implementations for
> os::set_native_thread_name()
> on
> Windows and Linux. We have added this feature to
> the SAP JVM and it has
> been useful for debugging.
>
> http://cr.openjdk.java.net/~__simonis/webrevs/7102541/
> <http://cr.openjdk.java.net/~simonis/webrevs/7102541/>
>
> Associated request:
> https://bugs.openjdk.java.net/__browse/JDK-7102541
> <https://bugs.openjdk.java.net/browse/JDK-7102541>
>
> On Windows, it uses the method described here:
> http://msdn.microsoft.com/en-__us/library/xcb2z8hs.aspx
> <http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx>
> On Linux, it uses pthread_setname_np(2).
>
> Notes for the windows implementation:
> - os::set_native_thread_name() only has any
> effect if there is a
> debugger
> attached to the process at the time of the
> function call. The reason is
> that the debugger must observe the raised
> exception. This means that
> this
> method works fine if the VM is being debugged
> right from the start; for
> cases where the debugger attaches during VM
> life, threads started before
> the attach will show default names.
> - This was tested using Visual Studio 2013
> and Windbg.
>
>
> Notes for the Linux implementation:
> - pthread_setname_np(2) needs glibc 2.12 or
> newer. The change loads
> the
> function dynamically.
> - Thread names are truncated to 15 characters.
> - We can see the thread names with ps (eg "
> ps H -p 1234 -o 'pid tid
> comm'
> ") or with gdb >= 4.7
>
>
> Note that not all threads show names.
> os::set_native_thread_name() was
> only
> called for JavaThread* children before this
> change, this change adds the
> VM
> thread, but there are some threads for which
> this function is not yet
> called; they appear with their default names.
>
> ---
>
> Note that when I was doing this change, I worked
> first on
> https://bugs.openjdk.java.net/__browse/JDK-8060033
> <https://bugs.openjdk.java.net/browse/JDK-8060033>,
> so I was not aware
> that
> Gerard Ziemski had done a lot of the same work
> before. But it looks like
> his changes did not appear in the hotspot?
> Either that or I looked at
> the
> wrong place... Anyway, I hope either his or my
> changes make it into the
> hotspot, because the feature is quite useful.
>
> Kind Regards,
>
> Thomas
>
>
>
More information about the hotspot-dev
mailing list