<div dir="ltr"><div>Hey Abdul,</div><div><br></div><div><i>[Disclaimer: I am just a Loom user like you.]</i></div><div><br></div><div>I don't know if the JSON-formatted output is intended to be human-readable. Yet it certainly should be easy to decode by a machine, and the current flat structure fits the bill perfectly well, IMHO.</div><div><br></div><div>As a matter of fact, several frameworks, *cough* Log4j *cough*, initially implemented JSON layouts where the stack trace is dumped in a nested fashion. This was mostly due to the irresistible convenience of `objectMapper.convertToString(exception)` offered by Jackson and similar POJO-to-JSON encoders. Later on it was figured that such a nested representation introduces other challenges to persist and query; either programmatically, using an RDBMS, or a document store (e.g., Elasticsearch). Today many major players I know of (<a href="https://logging.apache.org/log4j/2.x/manual/json-template-layout.html" target="_blank">JSON Template Layout of Log4j</a>, <a href="https://docs.spring.io/spring-boot/api/rest/actuator/threaddump.html" target="_blank">`/threaddump` endpoint of Spring Boot Actuator</a>) switched to a flat stack trace representation.</div><div><br></div><div>I get the sense that the serviceability improvements for Loom are still underway, and eventually, users will be equipped with better tools, eliminating the need to manually interpret JSON.</div><div><br></div><div>Cheers!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 28, 2024 at 12:49 PM Abdul Muneer K <<a href="mailto:abdul.kolarkunnu@gmail.com">abdul.kolarkunnu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I attached the test program and corresponding thread dump.<div>In this json tree structure, if tids 29 and 30 come under its owner tid 20 in a tree structure, we can understand thread hierarchy easily from the thread dump json file.</div><div>Similarly 31 and 32 under 29, 33 and 34 under 32, 26 and 28 under 23 respectively. </div><div>Now all pairs of threads are coming under a single node "threadContainers", it's not easy to understand the tree hierarchy from that. It's possible to track the hierarchy based on the owner/parent fields, but it's hard to follow if the hierarchy is long. </div><div><br></div><div>Also another comment, now all the virtual thread's name is coming as an empty string in the thread dump. If the fork API can accept a name also as an argument and pass that name as the thread name interanlly, we can track the threads or tasks based on its name in the thread dump.</div><div><br></div><div>Thanks and Regards,</div><div>Muneer</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 28, 2024 at 12:17 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <br>
    <br>
    <div>On 27/11/2024 18:14, Abdul Muneer K
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">Hi,</div>
            <div dir="ltr">
              <div>
                <div>I prepared a StructuredTaskScope in a tree
                  hierarchical structure as below:</div>
                <div>                        TaskA</div>
                <div>                           __|__</div>
                <div>                 TaskB             Tasks</div>
                <div>               ___|__.               __|___</div>
                <div>           TaskD.  TaskE.   TaskF .     TaskG</div>
                <div><br>
                </div>
                <div>[Not sure it will show as a tree while sending
                  email because of formatting, basically it's a three
                  level full tree.]</div>
                <div><br>
                </div>
                <div>I captured the stack trace using the below command
                  while running this sample code with some delays on
                  each task, so that I can capture thread dumps with all
                  of these tasks in the running state.</div>
                <div>I ran below command to get thread dumps in json
                  format:</div>
                <div>jcmd <pid> Thread.dump_to_file -format=json
                  <file></div>
                <div><br>
                </div>
                <div>I got the thread dump, my expectation was, threads
                  will follow the same tree structure in thread dump
                  also. We can track it based on the fields "owner" and
                  "parent". But, it will be difficult to follow based on
                  these fields if we have too many threads.</div>
                <div>Is it designed like that because of any
                  limitations? Or am I missing an</div>
                <br>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I don't think I understand your question. Are you asking about the
    traversal order used when streaming it to a file or are you asking
    if the owner and parent keys are the right way to reconstitute the
    tree?<br>
    <br>
    -Alan<br>
  </div>

</blockquote></div>
</blockquote></div>