RFR: 8205683: Refactor heap allocation to separate concerns

[Roman Kennke]

Ah yes, that seems fine. No, we wouldn't nee any barriers there. I
guess, should any GC ever require barriers on this, we'd add it then
(via special decorators or such).

Roman

> Hi Per and Roman
> 
> Right - I specifically did not want to send invalid oops that have yet to be constructed through the Access API. Only after the Klass pointer has been set do we have an oop.
> 
> Thanks,
> /Erik
> 
>> On 27 Jun 2018, at 13:57, Per Liden <per.liden at oracle.com> wrote:
>>
>> 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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180627/4b0abbc2/signature.asc>