Re: [rvm-research] Gen.virtualMemoryExhausted() does not work properly for GenCopy

Robin Garner <[email protected]> Sun, 1 Apr 2018 23:41:33 +1000
Newsgroups gmane.comp.java.jikes.rvm.devel
Message-ID <CADjFg8TaAyXhNVzaGA4rYk8wKdEu=AacNNEwr2Unc4LO88HG+A@mail.gmail.com>
Hi, I haven't time right now to look at the code, but I thought it might
help if I explain some of the background.

There are two fundamental constraints being evaluated.  Firstly, MMTk needs
to ensure that it can do a collection without exceeding the maximum heap
size, either the fixed size set on the command line or the dynamic size
chosen by the heap size manager.  The appropriate formula is nursery*
COPY_EXPANSION + toSpace < heapSize/2.

The second constraint comes from the virtual size of each of the memory
regions, and this is more complex to calculate.  There are two cases:

In a 64-bit address space and a statically partitioned 32-bit address space
(which we don't use any more), each of the regions (nursery, from-space,
to-space) occupies a fixed size range of virtual memory.  In this case,
the formula is similar to the heap size constraint, i.e. nursery*
COPY_EXPANSION + toSpace < toSpaceVirtSize.

In a standard 32-bit build, to-space and from-space (and the LOS, code
spaces etc) all occupy the same discontinuous address space.  This means
the usable virtual address space for toSpace should be half the available
space, because we need to allow for fromSpace out of the same virtual
address allocation.  Off the top of my head, this is why you would see a
"/2" in the calculation.

In any case, the virtualMemoryExhausted() part of the calculation should
only come into play on rare occasions, or when you've chosen an unfeasibly
large "-Xmx" value.  Back before discontiguous spaces it was a frequent
cause of GC, but these days not (or at least it shouldn't be).  Most GCs
will be triggered when the heap size constraint is reached.


Having said this, the calculation is subtle, so I wouldn't entirely
discount the possibility of an error.  I'll double check the code next
chance I get.

cheers,
Robin

On Thu, Mar 29, 2018 at 5:29 PM, Lingyu Zhu <[email protected]> wrote:

> Gen.colletionRequired() uses method virtualMemoryExhausted() as one
> condition to trigger GC. This means GenCopy checks if (nursery + toSpace) *
> COPY_EXPANSION larger than half available pages of toSpace, which in turn
> leads to prematurely triggering minor GC. Instead, I think the correct
> condition is  nursery * COPY_EXPANSION larger than available pages of
> toSpace.
>
> On the other hand, Gen.requiresFullHeapcollection() use
> virtualMemoryExhausted() as one condition to determine whether triggering
> full gc. It compares collection reserved pages with *toSpace* available
> pages. However, till virtualMemoryExhausted() is called, the Mature has not
> flipped. So It should compare reserved pages with *fromSpace* available
> pages.
>
> Also, I can't figure out why HALF of available mature space rather than
> whole available mature space is checked.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers