RFR(s): 8144573: TLABWasteIncrement=max_jint fires an assert on SPARC for non-G1 GC mode

[sangheon]

Hi Thomas,

Thanks for looking at this.

On 01/07/2016 01:11 AM, Thomas Schatzl wrote:
> Hi Sangheon,
>
> On Wed, 2016-01-06 at 15:50 -0800, sangheon wrote:
>> Hi Igor,
>>
>> Thank you for reviewing this.
>>
>> On 01/05/2016 08:29 PM, Igor Veresov wrote:
>>> I’m not sure we care a lot about tiny bits of performance in the
>>> this instance… But, in case use wanted to keep the original code
>>> for the simm13 case you could check the range of the constant and
>>> still emit the code that was there before. It also seems suboptimal
>>> to do set64 in MacroAssembler::tlab_refill() on all paths - the
>>> result of the original add in the delay slot doesn’t seem to be
>>> used if we jump to discard_tlab, right?
>> You are right.
>> If the branch is taken, original add in the delay slot is not used.
>>
>> The reason of always calling 'set64' was to keep its behavior. i.e.
>> same
>> order of doing something before branch within delay slot. But as you
>> said, it is less tighter code.
>>
>>>     So, may be you could do something like:
>>>
>>> brx(Assembler::lessEqual, false, Assembler::pt, discard_tlab);
>>> if
>>> (is_simm13(ThreadLocalAllocBuffer::refill_waste_limit_increment()))
>>> {
>>>     delayed()->add(t2,
>>> ThreadLocalAllocBuffer::refill_waste_limit_increment(), t2);
>>> } else {
>>>     delayed()->nop();
>>>     set64(ThreadLocalAllocBuffer::refill_waste_limit_increment(),
>>> t3, G0);
>>>     add(t2, t3, t2);
>>> }
>> Okay, checking its value first seems good idea.
>>
>>> Similarly, tighter code can be emitted for the interpreter in
>>> templateTable_sparc.cpp.
>> Okay, done.
>>
>> Webrev: http://cr.openjdk.java.net/~sangheki/8144573/webrev.01
>    looks good.
>
> Could you move the "// increment waste limit to prevent getting stuck
> on this slow path" above the if-clause in both cases and remove the
> other mentions of that to make the comments in both macroAssembler and
> templateTable uniform?
Okay, I will fix them before pushing.

Thanks,
Sangheon


>
> I do not need another review for the comment change.
>
> Thanks,
>    Thomas
>