RFR: 8252505: C1/C2 compiler support for blackholes [v11]

[Vladimir Ivanov]

>>> We need to draw the line in the sand somewhere. I can try to do what
>>> MemBarCPUOrder does, but honestly it feels like a conceptual step back.
>>
>> That's the point we disagree on from the very beginning.
> 
> Here is where I was confused. The discussion never mentioned the word 
> "disagree" up until now.

And I don't remember you used the word "conceptual" in the discussion 
before ;-)

> You asked for clarifications why call-based approach was used, thanked 
> me for explanations, and then went on suggesting other directions for 
> experimentation. It did not read as "I disagree with current approach, 
> here is the approach I would like to see tried", but rather as "Looks 
> okay, and here is something we could also try". There is a world of 
> difference between these two statements.

Point taken. I'll try to be more explicit next time. Sorry for the 
confusion.

>> I think we have much better understanding now what is essential for
>> Blackhole and it can be implemented with something simple yet sufficient
>> to do the job.
> 
> Right! New iteration hopefully does what you suggest. And it is indeed 
> much simpler than call-based approach, thank you.

It looks very good.

Thanks for taking my suggestions into account.

Best regards,
Vladimir Ivanov

>> The nodes ignored during matching aren't removed, but stays intact in
>> the graph surrounded by newly created mach nodes. (Otherwise,
>> MemBarCPUOrder wouldn't have been able to succeed at its job of ordering
>> the memory graph.)
> 
> OK, that is good to know. I thought only Mach nodes are left after the 
> matching. New commits have the Blackhole formatter.
>