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

Hi, thanks for your explain. It helps me get the calculation straight. But
I still consider the detailed implementation in RVM for GenCopy is not
precisely correct. I will make some tinkering to observe the result.
By the way, I found GenCopy lacks maxNonLOSCopyBytes() constraint, which is
defined by GenMS, GenImmx and GenRC. GenCopy would try to allocate large
object into nursery and after a emergency gc, GenCopy would report
OutOfMemory error.
I confirmed this issue using 64bit build, specifying max nursery size 4M,
and it would fail 'chart' benchmark of Dacapo suit.
I add a maxNonLOSCopyBytes being 8k, the test is passed. But I'm not sure
8K is optimum for this plan.

On Sun, Apr 1, 2018 at 9:41 PM, Robin Garner <[email protected]> wrote:

> 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
>
>

------------------------------------------------------------------------------
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