Re: [rvm-research] Bugs with nursery creation

Hi,

thanks for the bug reports.

On 28.03.2013 14:12, UGAWA Tomoharu wrote:
> (1) Nursery is reserved for non-generational collectors
> 
> This is caused by a (possibly redundant) class dependency.
> 
> org.mmtk.utility.options.PretenureThresholdFraction depends on
> org.mmtk.plan.generational.Gen as it refers to DEFAULT_PRETENURE_THRESHOLD_FRACTION
> defined in Gen for the default value of this command line option.
> Thus, javac recognises this dependency, and Gen is put in the primordial
> list (Primordial.txt).
> 
> The class PretenureThresholdFraction is instantiated in the constructor of
> org.mmtk.plan.Plan.  Thus this class is instantiated regardless of whether
> the collector is generational or not.
> 
> I checked this with the configuration FastAdaptiveMarkSweep.
> Executing vm with -X:gc:verbose=3 option, I observed there is nursery.

I can confirm that this is indeed the case.

> For the time being, I removed the reference to the constant defined in Gen from
> the PretenureThresholdFraction class.  (I attached the patch).

Moving the pretenure constant to the PretenureThresholdFraction class
seems to solve the problem for FastAdaptiveMarkSweep.

I have not applied your patch because I'd prefer it if someone more
familiar with MMTk handled this issue. Also, I don't understand the
addition of pretenure constants to CopyMS and GenRC. Moreover, the
values of those constants seem to be invalid:
PretenureThresholdFraction's validate() method claims to allow only
values in [0.0f,1.0f].

> 
> (2) Overlapping normal space with nursery
> 
> This is caused by the execution order of two initialisers:
> - the constructor of org.mmtk.plan.Plan
> - the class initialiser of org.mmtk.plan.generational.Gen
> 
> In the constructor of Plan, the free list of chunks (Map.regionMap) is created
> by calling the Map.finalizeStaticSpaceMap() method, and the address range available
> for normal space is fixed.  If the nursery space is created beforehand, the
> address ranged for the nursery is excluded from the available address range.
> However, if the class initialiser of Gen is executed after the constructor of
> Plan is executed, the address range for the nursery is not taken into account when
> computing the available address range because the nursery is created in the class
> initialiser of Gen.
> 
> For generational collectors, this seems to rarely happen because of the class
> hierarchy.  Loading Plan and Gen is usually triggered by the compilation of expression
>> VM.activePlan.global()
> in the boot image compilation.
> This expression triggers class loading of the active plan, org.mmtk.plan.GenImmix
> for example.  GenImmix extends Gen, which is a subclass of Plan.
> Thus, when GenImmix is loaded, Plan and Gen are also loaded, and class initialiser of
> Gen is executed prior to the constructor of Plan.
> However, if compiler happens to compile an expression that triggers class loading
> of Plan before Gen is loaded, the nursery is not taken into account when computing
> the available address range for normal spaces.
> 
> For a non-generational collector, say MS for mark sweep, this is more likely to occur
> unless the problem (1) is fixed.  MS is not a subclass of Gen.  Thus, loading MS class
> does not trigger loading Gen.

Any suggestions for improvements (or patches) are appreciated.

> The following program fills up the memory and is expected to die with an out of memory
> exception.  However, when I executed with FastAdaptiveMarkSweep with more than 850 MB
> of heap (-Xmx850m), it crashed outputting a log of a VM internal bug saying:
>> Conflicting virtual address request for space "ms" at 0xa4c00000

I've seen crash logs that look like this in the regression tests so this
is definitively a problem that occurs "in the wild".


Kind regards,

Erik Brangs

------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html