RFR(S): 8205107: assert(c->Opcode() == Op_SafePoint) failed: broken outer loop
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Jun 19 17:18:00 UTC 2018
On 6/19/18 9:01 AM, Vladimir Kozlov wrote:
> On 6/19/18 7:22 AM, Nils Eliasson wrote:
>> I looked at it in a bit more detail.
>>
>> The call is a java/lang/Integer::valueOf that is considered a macro
>> node so it is kept around until macro expansion which happens after
>> the place where we hit the assert. So the call will go away.
>
> I assume you are talking about eliminate_boxing_node() in macro expansion.
>
>>
>> However SafepointNode::Identity does check:
>>
>> if( n0->is_Call() && n0->as_Call()->guaranteed_safepoint() ) {
>> // Useless Safepoint, so remove it
>>
>> And CallNode::guaranteed_safepoint() is:
>>
>> // Are we guaranteed that this node is a safepoint? Not true for
>> leaf calls and
>> // for some macro nodes whose expansion does not have a safepoint
>> on the fast path.
>> virtual bool guaranteed_safepoint() { return true; }
>>
>> No check for call/macro-nodes is implemeted despite the comment! If I
>> fix this the problem goes away.
>
> It returns false for Allocate nodes which are macro nodes. That is what
> comment says.
>
> In case of boxing node I think we should add to CallStaticJavaNode class
>
> // Boxing call which is not used and will be removed.
> virtual bool guaranteed_safepoint() { return
> C->eliminate_boxing() && is_boxing_method() &&
> (proj_out_or_null(TypeFunc::Parms) == NULL); }
Sorry, test should be reversed because it guarantee SP if call is *not*
removed:
virtual bool guaranteed_safepoint() { return
!(C->eliminate_boxing() && is_boxing_method() &&
(proj_out_or_null(TypeFunc::Parms) == NULL)); }
Vladimir
>
> Vladimir
>
>>
>> // Nils
>>
>>
>>
>> On 2018-06-18 15:41, Roland Westrelin wrote:
>>>> Roland, why we need to keep Safepoint in Outer loop if we have call?
>>> I double checked with a simple test case and we don't keep the safepoint
>>> if there's a call so it's indeed strange that we would need Nils' patch.
>>>
>>> Roland.
>>
More information about the hotspot-compiler-dev
mailing list