Re: [rvm-research] Bugs with nursery creation

Sorry guys, I completely missed this thread.    I will try to review the patch in the next day or so and respond to the list.

--Steve


On 13/04/2013, at 1:16 AM, T.Ugawa wrote:

> Hello,
> 
> Here is the statement of origin.
> 
> -----
>        STATEMENT OF ORIGIN FOR A SINGLE CONTRIBUTOR
> 
> I, Tomoharu Ugawa: 
> 
> (a) represent that either:
> 
>  (i) I am the only author and owner of the contributed software 
>      (described as/entitled fix for a bug with nursery creation),
>      which was neither derived nor copied from any other software,
>  or 
> 
> (ii) that any exception to (i) is software which was obtained under the 
>      EPL (Eclipse Public License), 
> 
> and   
> 
> (b)  hereby agree to license this contributed software under the EPL.
> -----
> 
> Best regards
> Tomoharu
> 
> On 2013/04/12, at 12:45, Robin Garner <[email protected]> wrote:
> 
>> Hi Richard,
>> 
>> I've been looking at the issue.  I was looking at doing Erik's fix combined with Tomoharu's guard against adjusting the map after finalization.
>> 
>> Tomoharu, could you send the paperwork for making a contribution?
>> 
>> Thanks,
>> Robin
>> 
>> Sent from my iPhone
>> 
>> On 11/04/2013, at 7:34 PM, "Richard Jones" <[email protected]> wrote:
>> 
>>> 
>>> Hi Steve, Robin
>>> 
>>> I wonder if you saw this message in the Jikes RVM researchers list. Any thoughts would be welcome. Tomoharu's patch seems to fix the first problem. His suggestion for fixing the second is to recreate the free-list map whenever a new nursery space is created.
>>> 
>>> Regards
>>> Richard
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: Erik Brangs <[email protected]>
>>>> Subject: Re: [rvm-research] Bugs with nursery creation
>>>> Date: 6 April 2013 19:19:06 BST
>>>> To: "General discussion of Jikes RVM design, implementation, issues, and plans" <[email protected]>
>>>> Reply-To: "General discussion of Jikes RVM design, implementation, issues, and plans" <[email protected]>
>>>> 
>>>> 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
>>>> _______________________________________________
>>>> Jikesrvm-researchers mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>> 
> 


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter