Uploaded image for project: 'JikesRVM'
  1. JikesRVM
  2. RVM-1026

Address conflict caused by overlapping of normal spaces with nursery

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: 3.1.3
    • Fix Version/s: 3.1.4
    • Component/s: MMTk
    • Labels:
      None
    • Environment:

      All

      Description

      Reported by Tomoharu Ugawa on the researchers mailing list (see http://sourceforge.net/mailarchive/message.php?msg_id=30656088 for original post).

      Slightly edited quote from the original post:

      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) [edit: RVM-1025] is fixed. MS is not a subclass of Gen. Thus, loading MS class
      does not trigger loading Gen.

      Suggestion for a fix (made via private mail, slightly edited): Tomoharu's suggestion is to recreate the free-list map whenever a new nursery space is created.

        Attachments

          Activity

            People

            • Assignee:
              rgarner Robin Garner
              Reporter:
              ebrangs Erik Brangs
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: