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