RFR: 8295475: Move non-resource allocation strategies out of ResourceObj [v2]

[Thomas Stuefe]

On Tue, 18 Oct 2022 14:40:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Shenandoah
>
> I like this in principle, I always found the "and also C-heap" usage of ResourceObj odd. But deciding allocation area via inheritance feels a bit restrictive. Since I then cannot have instances of a class live in different areas, I need to decide at class design time where it will live. Which also has implications for allowed lifetime (e.g. no RA before VM initialization). 
> 
> In practice, it never was a big deal, since everything can live on the stack or via composition in other objects, and ResourceObj can live on the C-heap too. But with the proposed patch ResourceObj  would only live on RA, and cannot live on the C-heap nor in hand-created Arenas.
> 
> I admit I have no good solution either. We could make allocation more flexible by accumulating all operator new variants in just a single base class, AnyObj. The problem is that we'd need to track the allocation type at runtime. So we'd trade performance for flexibility.

> @tstuefe Your sentiment is also represented internally. On the other side, I like having the convenience of having a default allocation for certain classes, or most classes even, but then there are outliers like these AnyObj classes. Designing a better allocation scheme for these rather than inheriting them through their base classes is something we've been talking about. Maybe we should have an RFC email so you can reply.

Thinking about this some more, I always could just wrap a class in a suitable holder if the class allocation scheme does not fit. The holder could even be a utility class, e.g.:

allocation.hpp:


template <class T, MEMFLAGS f>
struct CHeapHolder: public CHeapObj<f> { T v; };


x.cpp:

class X: public ResourceObj { ... };
typedef CHeapHolder<X, mtTest> XInCHeap;


Since that is easy, and considering that most of our objects have a clear 1:1 relation to the area they live in, maybe we should not bother carrying the type info and figuring out deletion at runtime.

-------------

PR: https://git.openjdk.org/jdk/pull/10745