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

[Coleen Phillimore]

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.

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

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