1. 19 8月, 2014 1 次提交
  2. 25 6月, 2014 1 次提交
  3. 23 5月, 2014 1 次提交
    • D
      8037816: Fix for 8036122 breaks build with Xcode5/clang · ed4b64df
      drchase 提交于
      8043029: Change 8037816 breaks HS build with older GCC versions which don't support diagnostic pragmas
      8043164: Format warning in traceStream.hpp
      Summary: Backport of main fix + two corrections, enables clang compilation, turns on format attributes, corrects/mutes warnings
      Reviewed-by: kvn, coleenp, iveresov, twisti
      ed4b64df
  4. 28 11月, 2012 1 次提交
  5. 22 8月, 2012 1 次提交
    • J
      7192128: G1: Extend fix for 6948537 to G1's BOT · ddfab1b9
      johnc 提交于
      Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable.
      Reviewed-by: brutisso, jmasa
      ddfab1b9
  6. 29 6月, 2012 1 次提交
    • Z
      6995781: Native Memory Tracking (Phase 1) · bdfb3cf5
      zgu 提交于
      7151532: DCmd for hotspot native memory tracking
      Summary: Implementation of native memory tracking phase 1, which tracks VM native memory usage, and related DCmd
      Reviewed-by: acorn, coleenp, fparain
      bdfb3cf5
  7. 13 1月, 2011 1 次提交
    • T
      7007068: G1: refine the BOT during evac failure handling · d205bb81
      tonyp 提交于
      Summary: During evacuation failure handling we refine the BOT to reflect the location of all the objects in the regions we scan. The changeset includes some minor cleanup: a) non-product print_on() method on the G1 BOT class, b) added more complete BOT verification during heap / region verification, c) slight modification to the BOT set up for humongous regions to be more consistent with the BOT set up during evac failure handling, and d) removed a couple of unused methods.
      Reviewed-by: johnc, ysr
      d205bb81
  8. 24 11月, 2010 1 次提交
  9. 17 10月, 2010 1 次提交
    • T
      6991377: G1: race between concurrent refinement and humongous object allocation · a9a0cccb
      tonyp 提交于
      Summary: There is a race between the concurrent refinement threads and the humongous object allocation that can cause the concurrent refinement threads to corrupt the part of the BOT that it is being initialized by the humongous object allocation operation. The solution is to do the humongous object allocation in careful steps to ensure that the concurrent refinement threads always have a consistent view over the BOT, region contents, and top. The fix includes some very minor tidying up in sparsePRT.
      Reviewed-by: jcoomes, johnc, ysr
      a9a0cccb
  10. 28 5月, 2010 1 次提交
  11. 06 6月, 2008 1 次提交
  12. 01 12月, 2007 1 次提交