1. 31 7月, 2010 1 次提交
  2. 20 7月, 2010 1 次提交
  3. 17 7月, 2010 1 次提交
  4. 02 7月, 2010 1 次提交
  5. 29 6月, 2010 1 次提交
  6. 23 6月, 2010 1 次提交
  7. 28 5月, 2010 2 次提交
  8. 25 5月, 2010 1 次提交
  9. 19 5月, 2010 1 次提交
  10. 17 5月, 2010 1 次提交
  11. 15 5月, 2010 1 次提交
  12. 12 5月, 2010 1 次提交
  13. 11 5月, 2010 1 次提交
  14. 04 5月, 2010 2 次提交
  15. 23 4月, 2010 1 次提交
  16. 08 5月, 2010 1 次提交
    • T
      6949307: G1: raise a vm error, do not core dump, if target pause time and... · 7a0c8373
      tonyp 提交于
      6949307: G1: raise a vm error, do not core dump, if target pause time and target interval are inconsistent
      Summary: First, change the guarantee to raising a vm error. Second, set the interval dynamically, and based on the pause time target, if it is not set explicitly.
      Reviewed-by: ysr, johnc
      7a0c8373
  17. 23 4月, 2010 1 次提交
  18. 17 4月, 2010 1 次提交
  19. 16 4月, 2010 3 次提交
  20. 08 4月, 2010 1 次提交
    • J
      6940894: G1: assert(new_obj != 0 || ... "should be forwarded") for compaction tests · bc7497dc
      johnc 提交于
      Summary: Humongous regions may contain multiple objects as a result of being retained as to-space from a previous GC and then re-used as to-space after being tagged as humongous. These changes include a check that causes retained to-space regions that are now tagged as humongous to be disregarded and a new to-space region allocated.
      Reviewed-by: tonyp, iveresov
      bc7497dc
  21. 06 4月, 2010 2 次提交
    • T
      6909756: G1: guarantee(G1CollectedHeap::heap()->mark_in_progress(),"Precondition.") · 524b2dd2
      tonyp 提交于
      Summary: Make sure that two marking cycles do not overlap, i.e., a new one can only start after the concurrent marking thread finishes all its work. In the fix I piggy-back a couple of minor extra fixes: some general code reformatting for consistency (only around the code I modified), the removal of a field (G1CollectorPolicy::_should_initiate_conc_mark) which doesn't seem to be used at all (it's only set but never read), as well as moving the "is GC locker active" test earlier into the G1 pause / Full GC and using a more appropriate method for it.
      Reviewed-by: johnc, jmasa, jcoomes, ysr
      524b2dd2
    • T
      6940310: G1: MT-unsafe calls to CM::region_stack_push() / CM::region_stack_pop() · 1bf17034
      tonyp 提交于
      Summary: Calling the methods region_stack_push() and region_stack_pop() concurrent is not MT-safe. The assumption is that we will only call region_stack_push() during a GC pause and region_stack_pop() during marking. Unfortunately, we also call region_stack_push() during marking which seems to be introducing subtle marking failures. This change introduces lock-based methods for pushing / popping to be called during marking.
      Reviewed-by: iveresov, johnc
      1bf17034
  22. 03 4月, 2010 1 次提交
  23. 31 3月, 2010 1 次提交
  24. 14 4月, 2010 1 次提交
  25. 31 3月, 2010 1 次提交
    • T
      6937160: G1: should observe GCTimeRatio · ba4ccdf3
      tonyp 提交于
      Summary: Remove the G1GCPercent parameter, that specifies the desired GC overhead percentage in G1, and observe the GCTimeRatio parameter instead.
      Reviewed-by: jmasa, johnc
      ba4ccdf3
  26. 19 3月, 2010 2 次提交
    • J
      6935839: excessive marking stack growth during full gcs · 81554d51
      jcoomes 提交于
      Summary: process one item at a time from the objarray stack/queue
      Reviewed-by: apetrusenko, tonyp
      81554d51
    • T
      6935821: G1: threads created during marking do not active their SATB queues · 9677603a
      tonyp 提交于
      Summary: Newly-created threads always had the active field of their SATB queue initialized to false, even if they were created during marking. As a result, updates from threads created during a marking cycle were never enqueued and never processed. The fix includes remaining a method from active() to is_active() for readability and naming consistency.
      Reviewed-by: ysr, johnc
      9677603a
  27. 18 3月, 2010 1 次提交
  28. 12 3月, 2010 1 次提交
    • J
      6755988: G1: assert(new_obj != 0 || ... "should be forwarded") · 195509ea
      johnc 提交于
      Summary: A TLAB became large enough to be considered a humongous object allowing multiple objects to be allocated in a humongous region, which violates a basic assumption about humongous regions. The changes ensure that TLABs cannot be regarded as humongous.
      Reviewed-by: iveresov, tonyp
      195509ea
  29. 04 3月, 2010 2 次提交
  30. 25 2月, 2010 1 次提交
  31. 24 2月, 2010 3 次提交