1. 04 12月, 2009 2 次提交
    • T
      6880903: G1: G1 reports incorrect Runtime.maxMemory() · bc0d9e36
      tonyp 提交于
      Summary: G1 reports committed memory instead of reserved memory from the Runtime.maxMemory() method
      Reviewed-by: ysr, jmasa
      bc0d9e36
    • Y
      6906727: UseCompressedOops: some card-marking fixes related to object arrays · 1f7260b7
      ysr 提交于
      Summary: Introduced a new write_ref_array(HeapWords* start, size_t count) method that does the requisite MemRegion range calculation so (some of the) clients of the erstwhile write_ref_array(MemRegion mr) do not need to worry. This removed all external uses of array_size(), which was also simplified and made private. Asserts were added to catch other possible issues. Further, less essential, fixes stemming from this investigation are deferred to CR 6904516 (to follow shortly in hs17).
      Reviewed-by: kvn, coleenp, jmasa
      1f7260b7
  2. 25 11月, 2009 1 次提交
    • J
      6899058: G1: Internal error in ptrQueue.cpp:201 in nightly tests · 6269ed5f
      johnc 提交于
      Summary: Fixes a race on the dirty card queue completed buffer list between worker thread(s) performing a flush of a deferred store barrier (enqueueing a newly completed buffer) and worker thread(s) in the RSet updating code claiming completed buffers. Removed the routine that removes elements from the completed update buffer queue using a CAS.
      Reviewed-by: ysr, tonyp
      6269ed5f
  3. 21 11月, 2009 1 次提交
  4. 20 11月, 2009 2 次提交
    • Y
      6902303: G1: ScavengeALot should cause an incremental, rather than a full, collection · bef9ec13
      ysr 提交于
      Summary: ScavengeALot now causes an incremental (but possibly partially young, in the G1 sense) collection. Some such collections may be abandoned on account of MMU specs. Band-aided a native leak associated with abandoned pauses, as well as an MMU tracker overflow related to frequent scavenge events in the face of a large MMU denominator interval; the latter is protected by a product flag that defaults to false.
      Reviewed-by: tonyp
      bef9ec13
    • Y
      6902701: G1: protect debugging code related to 6898948 with a debug flag · df890d3a
      ysr 提交于
      Summary: Protected stats dump with a new develop flag; other than for the dump, reconciled product and non-product behaviour in face of the error.
      Reviewed-by: tonyp
      df890d3a
  5. 14 11月, 2009 1 次提交
  6. 11 11月, 2009 1 次提交
  7. 07 11月, 2009 1 次提交
  8. 04 11月, 2009 1 次提交
  9. 29 10月, 2009 1 次提交
    • Y
      6818264: Heap dumper unexpectedly adds .hprof suffix · 6c780766
      ysr 提交于
      Summary: Restore old behaviour wrt HeapDumpPath; first dump goes to <file>, <n>th dump goes to <file>.<n-1>, with default value of <file> the same as before.
      Reviewed-by: alanb, jcoomes, tonyp
      6c780766
  10. 27 10月, 2009 1 次提交
    • A
      6870843: G1: G1 GC memory leak · 3fddbba6
      apetrusenko 提交于
      Summary: The fix addresses two memory leaks in G1 code: (1) _evac_failure_scan_stack - a resource object allocated on the C heap was not freed; (2) RSHashTable were linked into deleted list which was only cleared at full GC.
      Reviewed-by: tonyp, iveresov
      3fddbba6
  11. 22 10月, 2009 2 次提交
  12. 21 10月, 2009 1 次提交
  13. 20 10月, 2009 1 次提交
  14. 18 10月, 2009 1 次提交
  15. 16 10月, 2009 1 次提交
    • Y
      6888898: CMS: ReduceInitialCardMarks unsafe in the presence of cms precleaning · 349bfec0
      ysr 提交于
      6889757: G1: enable card mark elision for initializing writes from compiled code (ReduceInitialCardMarks)
      Summary: Defer the (compiler-elided) card-mark upon a slow-path allocation until after the store  and before the next subsequent safepoint; G1 now answers yes to can_elide_tlab_write_barriers().
      Reviewed-by: jcoomes, kvn, never
      349bfec0
  16. 15 10月, 2009 1 次提交
  17. 14 10月, 2009 4 次提交
  18. 08 10月, 2009 3 次提交
  19. 07 10月, 2009 3 次提交
  20. 06 10月, 2009 1 次提交
  21. 03 10月, 2009 2 次提交
    • T
      6882730: G1: parallel heap verification messes up region dump · 7a16a15c
      tonyp 提交于
      Summary: It tidies up the G1 heap verification a bit. In particular, when the verification is done in parallel and there is a failure, this is propagated to the top level and the heap is dumped at the end, not by every thread that encounters a failure.
      Reviewed-by: johnc, jmasa
      7a16a15c
    • T
      6885041: G1: inconsistent thread dump · 510d088c
      tonyp 提交于
      Summary: When G1 is enabled, thread dumps are inconsistent as the info for some of the G1 threads is not formatted properly.
      Reviewed-by: ysr, johnc
      510d088c
  22. 01 10月, 2009 1 次提交
  23. 24 10月, 2009 1 次提交
  24. 26 9月, 2009 1 次提交
  25. 25 9月, 2009 1 次提交
  26. 24 9月, 2009 2 次提交
  27. 23 9月, 2009 2 次提交