RFR: Use BarrierSetC2::ideal_node() API for CmpPNode::Ideal()

Roman Kennke rkennke at redhat.com
Tue Nov 6 13:09:00 UTC 2018


Ok. Please try.

We still need the ideal(..) abstraction for CallLeafNode::Ideal()
though. And it seems to me natural and consistent and potentially useful
to also provide a similar abstraction for Identity(), because the two
belong together afaiu. So I'll propose this upstream too.

And from there we could put our LoadNode::Identity() changes behind
ShenandoahBSC2. Which has the advantage that it's trivial to prove that
it's not disturbing any non-Shenandoah code paths. But please try to put
this stuff in shared code first if you think that's useful.

Makes sense?

Roman

>> However, with the abstraction for BSC2::ideal_node(..) that I proposed,
>> we can easily move our CmpPNode::Ideal(..) stuff into ShenandoahBSC2,
>> and avoid discussing that part upstream ;-) And Erik said he'd like such
>> an abstraction anyway, so why not.
> 
> Both changes make some sense as non GC specific changes. So it seems to
> me they belong in shared code. We can always fall back to making them
> shenandoah specific if they are not accepted.
> 
> ROland.
> 



More information about the shenandoah-dev mailing list