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

[Vladimir Kozlov]

I agree to make improvements to decoding for generated code.

Especially for product VM build. Even so PrintOptoAssembly is diagnostic flag it does nothing in produce build AFAIK 
because "format" code is generated only in debug VM.

And it would be nice if new hex output could be feed (as it is) into some well known tool (objdump?) to disassemble it. 
In such case hex output should be in format acceptable to such tools without big re-formating.

Verbosity of output should be controlled by additional values of flag. I agree that by defult we don;t need so much 
information.

Do not forget CompileOracle command print:

-XX:CompileCommand=print,<method>

Also we need to do something for C1 generated code. PrintOptoAssembly is C2 flag.

Thanks,
Vladimir

On 11/28/18 8:16 AM, 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
> 
> 
> 
> 
>