RFR(S): 8200720: Print accumulated number of allocated bytes in thread dump (original) (raw)

JC Beyler jcbeyler at google.com
Thu Apr 5 16:01:45 UTC 2018


Hi Gunter,

I really am new to the Java scene so I really am not speaking about the implementation and its potential integration into the code. Or even would the feature be accepted or not, however, from what I've seen in the webrev you provided:

On another note, depending on what your users want, this might not be relevant:

We actually implemented a similar approach but it was on top of the sampling technique I'm pushing currently. It provides the same information you do but also the bytes allocated still live for a given thread due to how our internal system is implemented (because our users preferred to know how much a thread was holding instead of how much a thread allocated). With the work I'm doing here (via JDK-8171119), it might be reasonable and do-able to have the sampling system provide this information on the native agent side (and thus you can do your implementation and provide the data to your users without this change). Would this perhaps be of interest to you? We could build an example test and you can test it on your side and I can test it on mine and we can see how far off either technique is in regards to the information about per thread allocation?

I have not done the overhead calculation of this in a long time, we could wrap that together and see if that's acceptable. I'm not sure you get a 0% as you do but it would be small.

Thanks, Jc

On Thu, Apr 5, 2018 at 3:28 AM Haug, Gunter <gunter.haug at sap.com> wrote:

Hi,

can I please have a review and a sponsor for the following enhancement: http://cr.openjdk.java.net/~ghaug/webrevs/8200720 https://bugs.openjdk.java.net/browse/JDK-8200720 We at SAP have extended the thread dumps (obtained by jstack or jcmd) by several fields providing thread specific information. These extensions are quite popular with our support team. With some knowledge of the architecture of the application, they often allow for quick and simple diagnosis of a running system. Therefore we would like to contribute these enhancements. I took the quite simple accumulated number of bytes allocated by a thread as an example. This only works with TLAB active. Provided it is known how the application should behave, a misbehaving thread can identified easily. There is no measurable overhead for this enhancement. However, it may be a problem that the format of the output is changed. Tools parsing the output may have to be changed. Here is an example of the output generated: --------------------------------------------------------- "main" #1 prio=5 osprio=31 allocated=243048448B tid=0x00007fca98000800 nid=0x1d03 waiting on condition [0x0000000109baa000] java.lang.Thread.State: TIMEDWAITING (sleeping) at java.lang.Thread.sleep(java.base/Native Method) ... --------------------------------------------------------- As mentioned above, we have a whole bunch of other enhancements to the thread dump similar to this one and would be willing to contribute them if there is any interest. Thanks and best regards, Gunter



More information about the hotspot-dev mailing list