RFR: 8225429: Regression in disassembly quality

Tom Rodriguez tom.rodriguez at oracle.com
Mon Jun 10 17:33:24 UTC 2019


> Sure, I get that, but there are other issues. In particular, code comments
> are disabled in product by macros such as
> 
> #ifdef PRODUCT
> #define BLOCK_COMMENT(str) /* nothing */
> #define STOP(error) stop(error)
> #else
> #define BLOCK_COMMENT(str) block_comment(str)
> #define STOP(error) block_comment(error); stop(error)
> #endif
> 
> I have no idea why these macros exist: unless debugging is enabled code
> comments are gated by
> 
> void CodeBuffer::block_comment(intptr_t offset, const char * comment) {
>    if (_collect_comments) {
>      _code_strings.add_comment(offset, comment);
> 
> Maybe this is just historical baggage or it's a micro-optimization to
> save space and a few machine cycles.

The block comment support definitely went through many iterations and 
tweaks.  The ifdef's seem to be about binary size since the actual 
recording support was already disabled in product.  Though that seems 
like a pretty micro-optimization.  Block comment recording should 
probably be under a flag since it stores a bunch of extra strings 
associated with the code blobs which is completely unnecessary unless 
you are printing.  It would cool if it could be driven by 
PrintNMethods/PrintAssembly/PrintStubCode but having a separate flag 
might be more convenient.  Anyway, as you say there are some issues to 
be teased out in enabling block comments all the time.

> 
> Anyway, I pushed http://cr.openjdk.java.net/~aph/8225429-2/ to
> jdk-submit. This sets the default for both product and debug builds
> the same.
> 
> If it passes I'll push it to jdk-jdk.

Sounds good to me.

tom


More information about the hotspot-dev mailing list