Thread.dump_to_file time

[Alan Bateman]

On 07/09/2023 18:01, Dr Heinz M. Kabutz wrote::
>
>
> To summarize, to go from the current to using print() and 
> BufferedOutputStream, gives us 79% improvement for plain and a 77% 
> improvement for json. If we also GZip them, we get a 71% improvement 
> in both cases.
>
>
> I would propose that we change this as soon as possible - I'm happy to 
> make the change and also submit the findings and the test program to 
> the JDK. Furthermore, I would propose that perhaps as a second project 
> that we consider how to compress these files. One option is with GZip 
> (would require quite a few changes, including to jcmd) and another 
> would be to change the format of the json file to deduplicate thread 
> stacks. If we follow the "virtual thread per task" model, we will have 
> many many virtual threads with the exact same stack and it might be 
> more productive to have a better json model for such cases.
>
>
Thanks for the data. I created JDK-8315702 [1] when you brought this 
here up a few days ago. It replaces the use of formatter for the thread 
info and thread stacks, and uses a BOS for the file case. If I read your 
mail/experiments correctly then I think it's the combination that is 
column 4 in your table.

We mulled over doing de-duplication, compression and other "in process" 
digesting of thread stacks but decided against doing anything at the 
time. For now, the approach is dump everything to a file and let tools 
parse the JSON output. This project is not wedded to this or any format, 
and part of the exploration was a streaming API so that "in process" 
agent like tooling could consume. So it's more about enablement rather 
than trying to address everyone's needs. For now, we've kicked the work 
to expose an API down the road as there are many other things to do. The 
jcmd GC.heap_dump command was extended with -gz=<level> option in JDK 15 
so there is more precedent to doing gzip compression there.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8315702