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

[Kim Barrett]

> On Jun 8, 2017, at 8:57 AM, Milan Mimica <Milan.Mimica at infobip.com> wrote:
> 
> 
> Milan Mimica, Senior Software Engineer / Division Lead
>> From: Kim Barrett <kim.barrett at oracle.com>
>> Sent: Saturday, May 27, 2017 01:00
>> 
>> 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.
> 
> Filled and sent.

Thanks.

>> 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].
> 
> Okay. There are two patches.

Thanks for splitting this into a refactoring followed by the use of
that refactoring.  That should make reviewing and discussion easier.

I'm looking at the refactoring part, but am running out of time today.

We should probably have a new RFE for the refactoring.  I'll take care
of that tomorrow.

Note that the refactoring patch doesn't apply cleanly to jdk10/hs tip.
There's a merge conflict with the fix for JDK-8168467 (resolved
2017/03/15).  After dealing with that, the refactoring looks good to
me on an initial pass.  I want to take a more careful look tomorrow.

You'll need an Oracle sponsor, since you are not (yet) a committer,
and also because these changes affect hotspot, so need to eventually
be pushed via jprt.  I can be the sponsor for the refactoring.

What testing has been done?  And are there any tests you can point to
that are directly affected?  (I already know about
TestArrayAllocatorMallocLimit.java.)  I'll probably want to run some
tests using our internal test facilities as part of sponsoring.

I haven't looked at the second patch at all yet.

> - refactor_array_allocator.diff
> Pass MEMFLAGS down to the concrete allocator via
> call stack instead of using template var. Indeed it feels right, especially
> because some methods don't even use MEMFLAGS.
> 
> - heapBitMap_nmt.diff
> Changed CHeapBitMap to use configurable NMT pool. Changed
> all (not just 'fine' bitmaps) G1 usages of CHeapBitMap to specify mtGC. Had to
> add a pair CHeapBitMap constructors to make test_bitMap.cpp happy. That doesn't
> feel right, but I don't know what to do, except to rewrite the test.
> 
> Btw, what are your plans on c++>=11? For example I could use delegating
> constructors here, or std::is_same.

I think that’s unlikely to happen soon, though there is interest.  But there’s also a
fair amount of work involved, which needs to be balanced against other tasks.

I think going beyond c++11 isn’t even feasible right now, as some of the relevant
compilers don’t yet have a version that supports c++14.

There’s in-progress work to add some metaprogramming utilities, including
IsSame, as we keep encountering places where such would be useful.  I’m
expecting that to show up pretty soon.