RFR(S): 8228839: Non-CFG nodes have control edges to calls, instead of the call's control projection
nils.eliasson at oracle.com
Wed Aug 21 19:56:02 UTC 2019
I want the workaround in promtly because the issue causes noise in the
bigapps testing which is really annoying, and might be hiding other
The core issue - the PhaseIdealLoop::get_ctrl problem, might turn up
quite large. Many types of MultiNodes, like calls and Membars are at
times set incorrectly (often in loopopts). SafepointNodes are a direct
subclass of MultiNodes but doesn't seem to use a control projection
anywhere. (But calls that are a subclass of SafepointNodes expect it -
It is also quite common that the node retrieved from a
PhaseIdealLoop::get_ctrl(..) is set as control in another node, which
propagates the problem.
I have tried to sanitize the ctrl-mapping by intercepting all MultiNodes
(except SafePointNodes and StartNodes) in PhaseIdealLoop::set_ctrl().
That seems to solve all downstream issues (without causing new
problems). But for a permanent fix I need to go through all the call
sites of set_ctrl() and find out why they don't use the projection.
I also need to investigate why SafepointNodes don't use control
projections, and what it would take to fix it.
On 2019-08-21 17:36, Vladimir Kozlov wrote:
> Hi Nils,
> Did you find in which cases the control edge is set to Call node
> Since the fix for JDK 14 we have time to fix it correctly instead of
> On 8/21/19 3:30 AM, Nils Eliasson wrote:
>> This is a workaround for the problem that sometimes non-CFG nodes
>> have their ctrl (PhaseIdealLoop::get_ctrl(n)) set directly to calls,
>> instead of the call's control projection. I'm working on a patch for
>> that, but it might end up a bit intrusive. This is a workaround that
>> simply checks and adjusts for that case.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228839
>> Webrev: http://cr.openjdk.java.net/~neliasso/8228839/webrev.01/
>> Please review,
>> // Nils
More information about the hotspot-compiler-dev