The lowest level memory allocation classes in the OMR compiler have a complicated hierarchy and relationship that many people have struggled to understand and maintain. The complexity came about trying to hold a unified picture of memory allocation between OMR (which just uses a raw malloc allocator) and OpenJ9 (which uses J9MemorySegments allocated from the VM a.k.a. "the system"). Unfortunately, this unity did not materialize and so these lower level allocation classes are not actually shared with OpenJ9.
The set of changes in this commit is motivated by the effort to try to compile the basic JitBuilder files in compiler/ilgen as part of OpenJ9. In this commit, I brought over the code from OpenJ9's SystemSegmentProvider and refactored it so that it could operate in OMR without J9MemorySegments. I changed its name to SegmentProvider and declare the SegmentProvider as the base layer for the higher level allocation support for e.g. regions and STL and other objects in the compiler component.
The SegmentProvider will hold a SegmentAllocator and a RawAllocator. In fact, the SegmentAllocator in OMR is an only slightly beefed up RawAllocator which returns memory wrapped in a structure with the uninspiring name of BackingSegment. The notion of TR::BackingSegment is similar to that of J9MemorySegment in OMR. I deleted the SegmentPool code because nobody was using it. I applied the same kind of simplification to the DebugSegmentProvider (and split some of the original code out into a DebugSegmentAllocator).
SegmentAllocator, SegmentProvider, DebugSegmentAllocator, and DebugSegmentProvider are now all extensible classes and I expect to use them in a similar refactoring extravaganza to be inflicted upon OpenJ9 reasonably soon.
Signed-off-by: Mark Stoodley
该提问来源于开源项目:eclipse/omr