RFR: 8205683: Refactor heap allocation to separate concerns

[Per Liden]

Hi Roamn,

On 06/27/2018 01:49 PM, Roman Kennke wrote:
> Hi Erik,
> 
> why is this change needed:
> 
> -void java_lang_Class::set_oop_size(oop java_class, int size) {
> +void java_lang_Class::set_oop_size(HeapWord* java_class, int size) {
>     assert(_oop_size_offset != 0, "must be set");
>     assert(size > 0, "Oop size must be greater than zero, not %d", size);
> -  java_class->int_field_put(_oop_size_offset, size);
> +  *(int*)(((char*)java_class) + _oop_size_offset) = size;
>   }
> 
> It seems to subvert any barriers that GCs might want to employ?

This was changed because we don't have an oop here yet. In other words, 
the memory behind mem is not a properly constructed object at this point 
(hence a valid oop can't point to it yet). I think set_oop_size() is a 
bit special in that sense, and I don't think you'll ever want a barrier 
there, right?

/Per

> 
> Roman
> 
> 
>> Hi,
>>
>> After a bunch of stuff was added to the CollectedHeap object allocation
>> path, it is starting to look quite ugly. It has function pointers passed
>> around with arguments to be sent to them, mixing up allocation,
>> initialization, tracing, sampling and exception handling all over the
>> place.
>>
>> I propose to improve the situation by having an abstract MemAllocator
>> stack object own the allocation path, with suitable subclasses,
>> ObjAllocator, ClassAllocator and ObjArrayAllocator for allocating the 3
>> types we support allocating on the heap. Variation points now simply use
>> virtual calls, and most of the tracing/sampling code can be moved out
>> from the allocation path. This should make it easier to understand what
>> is going on here, and the different concerns are more separated.
>>
>> A collector can override the virtual member functions for allocating
>> objects, arrays, and classes, and inject their own variation points into
>> this framework. For example for installing a forwarding pointer in the
>> cell header required by Brooks pointers, if you are into that kind of
>> stuff.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8205683
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8205683/webrev.02/
>>
>> Thanks,
>> /Erik
> 
> 
>