[15] RFR: 8242895: failed: sanity at src/hotspot/share/opto/escape.cpp:2361

[Jamsheed C M]

Hi all,

I had incorrectly added extra check in assert after offset computation 
in address_offset . For addps with non constant offsets (like [1])

Not changing the old assert even though I am not expecting first 
addp/second addp(for array addressing) case for init captured store.

http://cr.openjdk.java.net/~jcm/8242895/webrev_fix_EA_asserts_corrected/

Best regards,

Jamsheed

[1]

assert(offs != Type::OffsetBot ||
- adr->in(AddPNode::Address)->in(0)->is_AllocateArray(),
+ adr->in(AddPNode::Address)->in(0)->is_AllocateArray() || 
is_captured_store(adr),
             "offset must be a constant or it is initialization of array");

On 13/07/2020 11:14, Jamsheed C M wrote:
>
> Hi,
>
> I reworked the fix. I compute offset for all init captures stores, but 
> treats this special init captured stores similar to unsafe(as these 
> objects are usually GlobalEscape and doesn't have any perf implications).
>
> revised webrev: http://cr.openjdk.java.net/~jcm/8242895/webrev_fix_EA.01/
>
> testing: mach1-5( logs in jbs)
>
> Best regards,
>
> Jamsheed
>
> On 09/07/2020 19:36, Jamsheed C M wrote:
>>
>> Hi,
>>
>> request to hold the review. need to change the code for dealing with 
>> unsafe access. as current capture code go for more execution time 
>> analyzing things.
>>
>> Best regards,
>>
>> Jamsheed
>>
>> On 09/07/2020 13:01, Jamsheed C M wrote:
>>>
>>> Hi all,
>>>
>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8242895
>>>
>>> Request for review changes made to offset computation and field 
>>> write detection for init captured stores due to phis addition 
>>> between alloc and init. This happen if init node in different outer 
>>> loop wrt to alloc node and there is a loop opt.  This was required 
>>> as a result of enhancement [1].
>>>
>>> Normally init are not associated with multiple alloc node during EA 
>>> phase, but changes done for [1] caused the code shapes of the form 
>>> [2]  to generate inits associated with multiple alloc node.
>>>
>>> This had implication in offset computation and field write detection 
>>> related to initializing stores.
>>>
>>> Attempt to fix in EA:
>>>
>>>      webrev: http://cr.openjdk.java.net/~jcm/8242895/webrev_fix_EA/
>>>
>>> Alternate fix:
>>>
>>>      Minimize the scenario in compiler generated code by throwing 
>>> only j.l.Error from slowpath(all exception async/sync are handled in 
>>> runtime exit).
>>>
>>>      Stub epilog doesn't poll or throw any exceptions. Disable full 
>>> loop opt before EA for detectable patterns and bailout EA for late 
>>> detected patterns.
>>>
>>>      webrev: http://cr.openjdk.java.net/~jcm/8242895/webrev_deopt/
>>>
>>> Please advice.
>>>
>>> Testing : mach tier1-5 (logs in jbs)
>>>
>>> Best regards,
>>>
>>> Jamsheed
>>>
>>>
>>> [1] JDK-8231291 
>>> <https://bugs.openjdk.java.net/browse/JDK-8231291>C2: loop opts 
>>> before EA should maximally unroll loops
>>>
>>> [2] that have its init node in different outer loop wrt to alloc node.
>>>
>>>
>>> loop begin
>>>
>>>    try{
>>>
>>>    return new obj()/  throw new obj()/ uncommon trap after 
>>> allocation, in a loop
>>>
>>>    } catch(ex) {
>>>
>>>    }
>>>
>>> loop end
>>>
>>>   42     public static IntA test(int n) {
>>>    43         for (int i=0; i<2; i++) {
>>>    44             try {
>>>    45                   return new IntA(n + i);
>>>    46             } catch (Exception e) {
>>>    47             }
>>>    48         }
>>>    49
>>>