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

[Haug, Gunter]

Hi Stefan,

Thank you for your reply and sorry for being late with mine.
Probably I made a poor choice with the field I took as an example. There is absolutely no reason to add a separate accounting mechanism for bytes allocated by a thread. We implemented our version many years ago, sorry that I didn't check this again. In this particular case we could just use the existing one and get rid of ours.

However, as mentioned, we output more data (cpu time, number of defined classes, number of files opened, number of socks opened, number of bytes read/written via file and socket io and pthread-id) in the thread dump. The question is: is it desirable or even acceptable to add this information (or in fact any information) to the thread dump output?

Thank you,
Gunter

On 06.04.18, 10:24, "hotspot-dev on behalf of Stefan Johansson" <hotspot-dev-bounces at openjdk.java.net on behalf of stefan.johansson at oracle.com> wrote:

    Hi Gunter,
    
    On 2018-04-05 12:28, Haug, Gunter 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
    > 
    
    There is already accounting of allocated bytes on Thread:
       jlong _allocated_bytes;  // Cumulative number of bytes allocated on
                                // the Java heap
    
    The value is updated at TLAB refills and allocations outside the TLAB, 
    so it already includes the type allocations JC is mentioning. Any reason 
    this can't be used instead of adding your new accounting?
    
    To include bytes allocated in the current TLAB you can call:
       Thread::cooked_allocated_bytes();
    
    Thanks,
    Stefan
    
    > 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 os_prio=31 allocated=243048448B tid=0x00007fca98000800 nid=0x1d03 waiting on condition  [0x0000000109baa000]
    >     java.lang.Thread.State: TIMED_WAITING (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
    >