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

Schmidt, Lutz lutz.schmidt at sap.com
Mon Dec 3 15:51:07 UTC 2018


Thanks, Vladimir!

PrintAssemblyOptions is a ccstr flag. Thus, supported values are (can be) self-explanatory. Saw that flag before, but never paid attention to it. From what I saw when quickly looking over its uses, cleanup/extension should be hassle-free. 

Regards,
Lutz 

On 03.12.18, 16:23, "Vladimir Kozlov" <vladimir.kozlov at oracle.com> wrote:

    On 12/3/18 7:00 AM, Schmidt, Lutz wrote:
    > Hi Vladimir,
    > 
    > thank you for your thoughts.
    > 
    > You are right, PrintOptoAssembly doesn't help in PRODUCT builds. I see its output to be helpful mostly in cases where you can recreate an issue with a debug VM. As stated below, the enhancements will mostly be for PrintAssembly which is available in PRODUCT builds.
    > 
    > The hex output, as a substitute when hsdis.so is not available, needs some tool support to be helpful. The tools job would be similar to that of objdump, but reading hex digits instead of binary data. We have enhanced our own JVM to behave like such a tool. I am considering to contribute that enhancement, but under a separate, subsequent RFE.
    
    Good. Yes, it would be nice have a Hotspot's tool which would work on all systems.
    
    > 
    > How would you like to control verbosity? PrintAssembly is a Boolean flag. Changing it to "int" to allow for more values might face some opposition. We could also invent a new flag, like "diagnostic(uintx, PrintAssemblyVerbosity, 0)". I can remember you saying "no new flag, please!" in another discussion.
    
    There is PrintAssemblyOptions flag you can use I think. (The usage of this flag needs to be cleaned up - it is used as 
    Boolean in few places).
    
    > 
    > I did not (knowingly) fiddle around with the decision whether to print or not. Therefore, CompilerOracle commands should be recognized and honored as before.
    
    Okay.
    
    > 
    > PrintAssembly will have an effect on C1 generated code as well. There will be either disassembled output or a hex dump, like there is for C2-compiled methods.
    
    Good.
    
    > 
    > I hope to have covered all your questions/concerns.
    
    Thanks,
    Vladimir
    
    > 
    > Thanks,
    > Lutz
    > 
    > 
    > 
    > On 30.11.18, 18:34, "Vladimir Kozlov" <vladimir.kozlov at oracle.com> wrote:
    > 
    >      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
    >      >
    >      >
    >      >
    >      >
    >      >
    >      
    > 
    



More information about the hotspot-compiler-dev mailing list