Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8072809

Further cleanups after Generation array removal: gen_process_roots and OopsInGenClosure::set_generation



    • Enhancement
    • Resolution: Other
    • P4
    • tbd
    • 9
    • hotspot
    • gc


      GenCollectedHeap::gen_process_roots() is a bit of a mess now. It first calls SharedHeap::process_roots. It then does completely different things, depending on the value of the first (level) argument. That's not at all obvious from the way the code is written though. Retaining the structure from the old iteration through _gens[] is not helpful in the new world where we have exactly two generations.

      There are two overloads for gen_process_roots(). The first does most of the work. The second constructs an additional closure and calls the first with that closure plus some other argument adjustments. If all client callers call the second; the first could be hoisted into the second and eliminated as a separate function.

      We can determine the level value for all callers. This and the fact that this function does very different things according to the level suggests splitting this function into two distinct functions.

      Caller levels are as follows:

      - MarkSweep always calls with level = 1 (assertion)
      - CMS always calls with level = _cmsGen->level() which is 1
      - ParNewGeneration::work calls with level = _gen->level(), where _gen is the young generation, so level is always 0 here
      - DefNewGeneration::collect calls with level = _level where _level is 0, since this is young generation

      The two callers apparently providing 0 as the level also always provide true as the second (younger_gens_as_roots) argument. Further argument simplifications would likely result from splitting.


        Issue Links



              Unassigned Unassigned
              jwilhelm Jesper Wilhelmsson
              0 Vote for this issue
              2 Start watching this issue