1. 19 6月, 2012 1 次提交
  2. 07 3月, 2012 1 次提交
  3. 12 4月, 2012 1 次提交
  4. 16 2月, 2012 1 次提交
  5. 02 2月, 2012 1 次提交
  6. 01 2月, 2012 1 次提交
  7. 12 1月, 2012 1 次提交
  8. 24 10月, 2011 1 次提交
  9. 14 10月, 2011 1 次提交
  10. 26 9月, 2011 1 次提交
  11. 23 9月, 2011 1 次提交
    • J
      6484982: G1: process references during evacuation pauses · 9c3adbcc
      johnc 提交于
      Summary: G1 now uses two reference processors - one is used by concurrent marking and the other is used by STW GCs (both full and incremental evacuation pauses). In an evacuation pause, the reference processor is embedded into the closures used to scan objects. Doing so causes causes reference objects to be 'discovered' by the reference processor. At the end of the evacuation pause, these discovered reference objects are processed - preserving (and copying) referent objects (and their reachable graphs) as appropriate.
      Reviewed-by: ysr, jwilhelm, brutisso, stefank, tonyp
      9c3adbcc
  12. 11 9月, 2011 1 次提交
  13. 06 9月, 2011 1 次提交
  14. 01 9月, 2011 1 次提交
  15. 10 8月, 2011 1 次提交
  16. 07 7月, 2011 1 次提交
  17. 14 6月, 2011 1 次提交
    • Y
      7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit · a4a62971
      ysr 提交于
      Summary: It turns out that there is no need to explicitly stop CMS since the JVM is taken down at a terminal safepoint during which CMS threads are (terminally) inactive. This  will need to be revised if and when we evolve in the future to a point where we allow JVM reincarnation in the same process, but those changes will be much more sweeping than just terminating CMS threads. The unused ::stop() methods will be removed in a separate CR. Also include in this CR is the fix for a small typo in the spelling of UseGCLogFileRotation in a message in arguments.cpp, brought to our attention by Rainer Jung and reviewed by minqi.
      Reviewed-by: johnc, jwilhelm
      a4a62971
  18. 18 5月, 2011 1 次提交
  19. 17 5月, 2011 1 次提交
  20. 03 5月, 2011 1 次提交
  21. 31 3月, 2011 1 次提交
  22. 19 3月, 2011 1 次提交
  23. 28 2月, 2011 1 次提交
  24. 09 2月, 2011 1 次提交
  25. 08 2月, 2011 1 次提交
  26. 28 1月, 2011 1 次提交
  27. 25 1月, 2011 1 次提交
  28. 12 1月, 2011 1 次提交
  29. 11 1月, 2011 1 次提交
  30. 07 1月, 2011 1 次提交
  31. 02 12月, 2010 1 次提交
  32. 01 12月, 2010 1 次提交
  33. 24 11月, 2010 1 次提交
  34. 23 10月, 2010 1 次提交
  35. 19 10月, 2010 1 次提交
  36. 02 10月, 2010 1 次提交
    • T
      6980838: G1: guarantee(false) failed: thread has an unexpected active value in its SATB queue · acd6a8e3
      tonyp 提交于
      Summary: Under certain circumstances a safepoint could happen between a JavaThread object being created and that object being added to the Java threads list. This could cause the active field of that thread's SATB queue to get out-of-sync with respect to the other Java threads. The solution is to activate the SATB queue, when necessary, before adding the thread to the Java threads list, not when the JavaThread object is created. The changeset also includes a small fix to rename the surrogate locker thread from "Surrogate Locker Thread (CMS)" to "Surrogate Locker Thread (Concurrent GC)" since it's also used in G1.
      Reviewed-by: iveresov, ysr, johnc, jcoomes
      acd6a8e3
  37. 01 10月, 2010 2 次提交
  38. 29 9月, 2010 1 次提交
  39. 22 9月, 2010 1 次提交