RFR: 8252505: C1/C2 compiler support for blackholes [v11]
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Thu Dec 3 12:28:54 UTC 2020
>>> 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.
>
More information about the hotspot-dev
mailing list