[PATCH] JDK-8176571: Fine bitmaps should be allocated as belonging to mtGC

[Kim Barrett]

> On May 25, 2017, at 1:56 PM, Milan Mimica <Milan.Mimica at infobip.com> wrote:
>> Some procedural points: we would need you to sign a contributor
>> agreement if you are not covered yet in some way to be able to take
>> your contributions.
> 
> Sure will do. If we ever come near to having an acceptable patch.

The initial patch you offered seems covered by the Participant role [1], but I
suspect a fix for this bug will end up being a bit more substantial than the
simple patches we can accept without a Contributor Agreement in place.  We
appreciate your interest in working on this and are happy to help, but we
really do need to check off this process item before going any deeper.

[1] http://openjdk.java.net/bylaws

>> It is a bit awkward to have a generic utility class to always report
>> everything as belonging to GC :-)
> 
> I would argue that having everything reported as mtInternal is equally wrong.

An "equally wrong" change isn't really an improvement.

> Can I propose to move the class into G1 scope? What is the point of a utility
> class not used in any other place?

BitMap is a generic utility, and allocating their data in the CHeap is
not tied to G1 in any interesting way. That CHeapBitMap is presently
only used by G1 is really an artifact of development history; there
are likely already other places that could or should use CHeapBitMap,
but that class was added relatively recently.

>> There is another option, having an additional field in CHeapBitmap that
>> indicates from what pool the memory should be assigned to.
>> From a memory POV that additional (4-byte) member should be zero-cost
>> for the remembered sets due to padding (see class PerRegionTable in
>> heapRegionRemSet.cpp, immediately after the CHeapBitmap there is an
>> int-sized member followed by a pointer).
> 
> Sicne ArayAllocator needs a compile-time constant we don't have this option.
> There is going to be at least some pulling of code into header files.

Yes, some refactoring seems required in order to properly fix JDK-8176571.
That’s what I meant by:

On May 22, 2017, at 4:41 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> There doesn't seem to be a good path into the functionality provided
> by ArrayAllocator<> that has such a runtime MEMFLAGS value [...] The
> lack of a runtime-only path for propagating that information would
> need to be added [sic. fixed].