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

[Thomas Schatzl]

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?

I do not need another review for the comment change.

Thanks,
  Thomas