RFR: JDK-8204941: Refactor TemplateTable::_new to use MacroAssembler helpers for tlab and eden

[coleen.phillimore at oracle.com]

This looks good to me as well.  Except sparc and other platforms still 
have the duplicated tlab and eden allocation in TemplateTable::_new(), 
but aarch64 has code similar to this.  It seems like something we could 
not clean up unless we need to.

thanks,
Coleen

On 6/15/18 12:49 PM, Vladimir Kozlov wrote:
> Looks good to me.
>
> Thanks,
> Vladimir
>
> On 6/13/18 4:53 AM, Roman Kennke wrote:
>> TemplateTable::_new (in x86) currently has its own implementation of
>> tlab and eden allocation paths, which are basically identical to the
>> ones in MacroAssembler::tlab_allocate() and
>> MacroAssembler::eden_allocate(). TemplateTable should use the
>> MacroAssembler helpers to avoid duplication.
>>
>> The MacroAssembler version of eden_allocate() features an additional
>> bounds check to prevent wraparound of obj-end. I am not sure if/how that
>> can ever happen and if/how this could be exploited, but it might be
>> relevant. In any case, I think it's a good thing to include it in the
>> interpreter too.
>>
>> The refactoring can be taken further: fold incr_allocated_bytes() into
>> eden_allocate() (they always come in pairs), probably fold
>> tlab_allocate() and eden_allocate() into a single helper (they also seem
>> to come in pairs mostly), also fold initialize_object/initialize_header
>> sections too, but 1. I wanted to keep this manageable and 2. I also want
>> to factor the tlab_allocate/eden_allocate paths into BarrierSetAssembler
>> as next step (which should also include at least some of the mentioned
>> unifications).
>>
>> http://cr.openjdk.java.net/~rkennke/JDK-8204941/webrev.00/
>>
>> Passes tier1_hotspot
>>
>> Can I please get a review?
>>
>> Roman
>>