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

Roland Westrelin rwestrel at redhat.com
Mon Sep 3 08:41:21 UTC 2018

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.


More information about the hotspot-gc-dev mailing list