Request for review (S): 7174928: JSR 292: unresolved invokedynamic call sites deopt and osr infinitely

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Jun 12 16:12:15 PDT 2012


This looks good.

Vladimir

Christian Thalinger wrote:
> On Jun 12, 2012, at 1:14 PM, Roland Westrelin wrote:
> 
>>> Good point.  I looked at this again and the only other code using this (and where I got this pattern from in the first place) is NewMultiArray.  And there it's used correctly:
>>>
>>> CodeEmitInfo* patching_info = NULL;
>>> if (!x->klass()->is_loaded() || PatchALot) {
>>>   patching_info = state_for(x, x->state_before());
>>>
>>>   // cannot re-use same xhandlers for multiple CodeEmitInfos, so
>>>   // clone all handlers.  This is handled transparently in other
>>>   // places by the CodeEmitInfo cloning logic but is handled
>>>   // specially here because a stub isn't being used.
>>>   x->set_exception_handlers(new XHandlers(x->exception_handlers()));
>>> }
>>> CodeEmitInfo* info = state_for(x, x->state());
>> If you look at some of the stubs constructors, you'll find this pattern:
>>
>> _info = new CodeEmitInfo(info);
>>
>> and the CodeEmitInfo copy constructor does:
>>  // deep copy of exception handlers
>>  if (info->_exception_handlers != NULL) {
>>    _exception_handlers = new XHandlers(info->_exception_handlers);
>>  }
>>
>> which is the same as:
>> x->set_exception_handlers(new XHandlers(x->exception_handlers()));
>>
>> So in your case with the DeoptimizeStub you don't need the explicit set_exception_handlers(), right?
> 
> Correct.  Now the comment for NewMultiArray makes sense.  I removed that code, changed the comment in do_NewMultiArray and updated the webrev.
> 
> -- Chris
> 
>> Roland.
> 


More information about the hotspot-compiler-dev mailing list