Request for review(XS): 7012766: assert(false) failed: DEBUG MESSAGE in MacroAssembler::debug32

[Igor Veresov]

On 1/18/11 5:40 PM, Tom Rodriguez wrote:
>
> On Jan 18, 2011, at 5:23 PM, Igor Veresov wrote:
>
>> On 1/18/11 4:06 PM, Tom Rodriguez wrote:
>>> There are four calls to profile_method in x86 code but I only see two fixed.  Don't the other need fixed?
>> No, in other cases it's not required.
>
> Oh I see.  The old code reloads the methodOop but doesn't keep it around in a register which seems a little odd.  I guess the call site in generate_normal_entry are the odd ones that expect the value to be maintained.  Looks ok then.
>
>>
>>> Actually set_method_data_pointer_for_bc seems strangely coded to me.
>>>
>>> void InterpreterMacroAssembler::set_method_data_pointer_for_bcp() {
>>>    assert(ProfileInterpreter, "must be profiling interpreter");
>>>    Label set_mdp;
>>>    push(rax);
>>>    push(rbx);
>>>
>>>    get_method(rbx);
>>>
>>> Why couldn't it either assume it was valid or correctly set it up?
>>
>> We can do it the following way:
>>
>> http://cr.openjdk.java.net/~iveresov/7012766/webrev.01/
>>
>> It still have redundant push/pop of rbx at two other call sites, we can get rid of them but I feel uneasy about killing registers in template generating methods. Or we can have an optional "bool save_method_in" parameter?
>
> I don't really like that much better.  The original was more straightforward particularly given the difference in the callers.

Ok, I'll keep the original then... Thanks, Tom!

igor

>
> tom
>
>>
>> igor
>>
>>>
>>> tom
>>>
>>> On Jan 18, 2011, at 3:45 PM, Igor Veresov wrote:
>>>
>>>> Interpreter expects to see methodOop in rbx on method entry, which needs to be restored after call to profile_method.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/7012766/webrev.00
>>>>
>>>> Tested: failing nightly
>>>>
>>>> Thanks,
>>>> igor
>>>
>>
>