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

[Tom Rodriguez]

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.

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
>> 
>