RFR: JDK-8207169: X86: Modularize cmpxchg-oop assembler for C1 and C2

Erik Österlund erik.osterlund at oracle.com
Mon Sep 3 08:54:34 UTC 2018


Hi Roman,

Who would clobber those registers between iterations though in your 
tight loop?

/Erik

On 2018-09-03 10:41, Roland Westrelin wrote:
> Hi Erik,
>
>> The C1 basic blocks are built and optimized as part of the HIR and are
>> not to be changed after that. Once the HIR is generated, the LIR inserts
>> operations required for lowering this optimized HIR to machine code.
>> After IR::compute_code() of the HIR, those basic blocks are set in
>> stone. That means that any control flow alterations needed by the
>> LIRGenerator, which comes into play after that, is going to use branches
>> within the HIR basic block instead (as we promised not to change the HIR
>> basic blocks after the HIR is built and optimized). I can see how that
>> might feel like a hack, but that is kind of the way that things are
>> currently done in C1. It is used this way for all barrier sets today
>> (UseCondCardMark for card marking GCs, for G1, ZGC), and it's also used
>> by T_BOOLEAN normalization, switch statements, checking for referents in
>> unsafe intrinsics etc. I suppose the stubs inserted at the LIR level
>> also similarly break the basic block abstraction of the HIR level. These
>> are things that can of course be changed into a more strict basic block
>> model even at the LIR level. But I don't know how much that would help
>> given that this is just the pass before lowering to machine code. But
>> that is a whole different discussion.
> Adding a loop within a basic block is simply not possible. The register
> allocator won't know it's a loop and has no way to know operands are
> live across iterations. So it's not like we even have a choice.
>
> Roland.



More information about the hotspot-gc-dev mailing list