Uploaded image for project: 'JikesRVM'
  1. RVM-157

Space virtual address management (discontiguous spaces)


    • Type: Improvement
    • Status: Closed
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: MMTk
    • Labels:


      Copied from core list:


      • a "space" is defined as a region (contiguous or not) of memory managed under a single memory management policy
      • mapping between objects and spaces is a (very) performance critical feature of MMTk
      • these mappings may arise in write barriers (most critical) and the GC tracing loop (somewhat critical)
      • the two obvious approaches for such mappings are via a lookup or via an address range check (both currently supported)
      • we believe (though have not verified!) that lookups will be too expensive for really performance critical tasks (such as write barriers)
      • we use space identifiers to encode the mapping (either for use in the table look up or for unpacking and use in address range check)
      • the current implementation leverages some very nice optimizations in our opt compiler to achieve very good performance
      • MMTk is intended to support research, so we're not interested in ditching support for address range checking (contiguous spaces)
      • supporting dynamic address space mapping (ie moving the entire image around) is an important and slightly/somewhat related goal, but the biggest problem at the moment is bootimage relocatability

      Current design

      • two kinds of space supported by the design:
        a. contiguous spaces
      • identified in terms of an address range
      • address range statically defined in terms of size (either fraction or concrete)
      • spaces assigned address ranges at build time via class initializers
      • spaces may identify constraints (must be in high memory etc)
      • address space carved up based on constraints of spaces and ordering of initializers
        b. discontiguous spaces
      • comprised of 4MB chunks
      • identified via a table lookup
      • these two are intended to co-exist.
      • for example, the likely situation would be that a nursery would exist as a contiguous space in high memory and all otehr spaces would share the remaining address space via discontiguous spaces

      Current implementation

      • contiguous spaces are (obviously) fully supported
      • discontinuous spaces are not supported
      • mappings should work correctly already
      • main missing feature is a 4MB-granularity allocator with which to carve up available address space
      • this should not be hard to implement, using an instance of org.mmtk.utility.GenericFreeList managing 4MB address range chunks as its "unit"

      Future design

      • Daniel pointed out that we're currently conflating address range managment with space management
      • he suggests two layers:
        a. an address range manager which allocates "address ranges" which may have "holes" in them due to libraries or whatever
        b. spaces which are generally discontiguous and are associated with just one "address range"
      • spaces are allocated in 4MB chunks, but always from within the address range with which they are always associated
      • if a space was "solitary" (guaranteed to be the only occupant of the address range), then address range checks could be used to do the object - space mapping




            • Assignee:
              zyridium Daniel Frampton
              zyridium Daniel Frampton
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: