RFR(XS) 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions.<init>

[Vladimir Kozlov]

Okay. Then you fix looks correct.

Thanks,
Vladimir

On 10/22/14 5:04 PM, Igor Veresov wrote:
> Thanks for looking at it!
>
> rematerialize() has bit of a different meaning, I don't think we should do the check there. What it really means is that the node is a pure function (side effect free). It is used in the matcher (if I'm not mistaken) to clone things, which is easy then since we're still in the SSA form. It is also used in split_Rematerialize(), where we do the cloning correctly (with spilling of inputs). And all other places are safe as far as I can tell.
>
> igor
>
>> On Oct 22, 2014, at 1:37 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> You point fix seems correct.
>>
>> The question is should we do the new check inside MachNode::rematerialize() instead? Or don't rematerialized such nodes at all?
>>
>> MachNode::rematerialize() is called from Node::rematerialize() which is used in a lot of places in RA (PhaseChaitin). We need to make sure all those places are safe for MachConstant nodes.
>>
>> Thanks,
>> Vladimir
>>
>>> On 10/22/14 3:16 PM, Igor Veresov wrote:
>>> The problem manifests itself in various instances are constant table base register corruption. The cause is that when we’re rematerializing constant table loads (which are is_Con()) in PhaseAggressiveCoalesce::insert_copies() we are stretching the lrg of the constant table base. If that lrg is a multidef then I think we're in trouble. The fix is not rematerialize constant table loads here. We, however, will rematerialize those when splitting lrgs in split_Rematerialize(), which requires creation of a spill copy for each multidef input. I’d like to also point out that matcher aggressively clones constants (including constant table loads), which puts them close to the use in the majority of cases. So the proposed change has no measurable performance impact, which I verified with performance runs.
>>>
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/
>>>
>>> Thanks,
>>> igor
>>>