RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only
Andrew Haley
aph at openjdk.org
Tue Nov 26 10:38:38 UTC 2024
On Mon, 25 Nov 2024 23:28:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4915:
>>
>>> 4913: bind(done);
>>> 4914: }
>>> 4915: #ifdef ASSERT
>>
>> I understand that it greatly increases the reproducibility of the bug, but does such an adhoc code snippet adds much from maintenance perspective? Reusing registers is common in assembly code, so if all places where a register value is destroyed are annotated in a similar way, it would add a lot of noise on source code level.
>
> I'm looking at `MacroAssembler::lookup_secondary_supers_table_var()` and the only thing which can be improved there is an extra comment around line 5116 stressing that `population_count` destroys `slot`.
> I understand that it greatly increases the reproducibility of the bug, but does such an adhoc code snippet adds much from maintenance perspective? Reusing registers is common in assembly code, so if all places where a register value is destroyed are annotated in a similar way, it would add a lot of noise on source code level.
The point isn't so much that it's destroyed, but that it's destroyed on a rarely-used code path, in this case on a code path that is only ever executed on an obsolete machine. We've had the same problem on AArch64, where there are the old and new versions of compare-and-swap, and fixed the testing in the same way.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1858229650
More information about the hotspot-dev
mailing list