RFR: 8205683: Refactor heap allocation to separate concerns

[Roman Kennke]

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?

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