Fwd: Structured Concurrency - Stacktrace in tree hierarchical structure

[Abdul Muneer K]

I attached the test program and corresponding thread dump.
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.
Similarly 31 and 32 under 29, 33 and 34 under 32, 26 and 28 under 23
respectively.
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.

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.

Thanks and Regards,
Muneer

On Thu, Nov 28, 2024 at 12:17 AM Alan Bateman <alan.bateman at oracle.com>
wrote:

>
>
> On 27/11/2024 18:14, Abdul Muneer K wrote:
>
> Hi,
> I prepared a StructuredTaskScope in a tree hierarchical structure as below:
>                         TaskA
>                            __|__
>                  TaskB             Tasks
>                ___|__.               __|___
>            TaskD.  TaskE.   TaskF .     TaskG
>
> [Not sure it will show as a tree while sending email because of
> formatting, basically it's a three level full tree.]
>
> 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.
> I ran below command to get thread dumps in json format:
> jcmd <pid> Thread.dump_to_file -format=json <file>
>
> 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.
> Is it designed like that because of any limitations? Or am I missing an
>
> 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?
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241128/bb966823/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StructuredConcurrencyHierarchy.java
Type: application/octet-stream
Size: 3347 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241128/bb966823/StructuredConcurrencyHierarchy-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thread_dump_json8
Type: application/octet-stream
Size: 18112 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241128/bb966823/thread_dump_json8-0001.obj>