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