What Do You Think? JDK-8213084: Rework and enhance Print[Opto]Assembly output

[Tobias Hartmann]

Hi Lutz,

This looks very helpful, +1 from my side. Or "Absolutely awesome, why didn't we get that earlier?",
on the scale you've provided :)

Best regards,
Tobias

On 28.11.18 17:16, Schmidt, Lutz wrote:
> Dear Community, 
> 
> may I please point your attention to https://bugs.openjdk.java.net/browse/JDK-8213084. 
> 
> We have invested a significant amount of work in enhancing and "pretty printing" the output created by the command line parameters -XX:+PrintAssembly and -XX:+PrintOptoAssembly. Before porting this work to OpenJDK, I need to make sure the effort doesn't immediately disappear in a puff of smoke. So please honestly share your opinion (range from "Forget that bs, don't touch the code!" to "Absolutely awesome, why didn't we get that earlier?").
> 
> Instead of complicated verbal explanations, I chose to provide before/after examples (some snippets attached to this e-mail, the entire output as attachments in the bug). The C2-compiled method is always the same: spec.benchmarks._201_compress.Compressor::compress()V from the SPECjvm98 suite. 
> 
> I will focus on the PrintAssembly output here. The only major PrintOptoAssembly enhancement is that the method's bytecodes are dumped in addition. Most of the OptoAssembly formatting is hidden in the Node->format() methods (generated by adlc). 
> 
> So what are the main changes (it's your decision to call them enhancements)?
> ----------------------------
>  - Columnar alignment of instruction mnemonics, operands, and code comments is more consistent.
>  - Empty lines have been reduced to the required minimum.
>  - Constants are printed in hex, int, and float formats.
>  - The instruction offset (from code begin) is printed in addition to the address.
>  - On architectures with predictable instruction length (all but x86*, arm), the instruction bytes can be printed in hex (as of now: compile time setting).
>  - The metadata sections (oops, Metadata, pc-bytecode offsets, ...) are more compact and cleanly aligned
> 
> What if no disassembler library is available?
> ---------------------------------------------
> Up until now, the -XX:+PrintAssembly option is converted into -XX:+PrintOptoAssembly if no suitable disassembler library is found. The actual instruction stream is not printed. 
> 
> The enhanced code will fall back to an "abstract" disassembly, in essence an enriched hex dump of the instruction byte stream. On architectures with predictable instruction length (see above), the hex digits are grouped by instruction boundaries. Merging with code comments is possible, but there is no obvious benefit. With the right tool at hand, the abstract disassembly can be converted to human-readable form.
> 
> The abstract disassembly is not only written for nmethods after JIT compilation, but as well for native methods, blobs, stubs, the interpreter, and all other places where the disassembler is called. This fallback has proven to be very helpful, in particular in customer situations where a disassembler library can't easily be installed. 
> 
> Please check out the attached (plain text) files for some sample output.
> 
> How intrusive will the change be?
> ---------------------------------
> Shared code in asm/, code/, compiler/, opto/, will be affected. The majority of changes will be in nmethod.cpp. Platform code is only modified for formatting tweaks (add a <space> here, convert a <tab> there, ...).
> 
> Looking forward to your comments, whatever they may be. And, please, cross-post to other lists if you see a requirement.
> 
> Best,
> Lutz
> 
> 
> 
> 
>