1. 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
  2. 18 5月, 2011 1 次提交
  3. 17 5月, 2011 1 次提交
  4. 03 5月, 2011 1 次提交
  5. 31 3月, 2011 1 次提交
  6. 19 3月, 2011 1 次提交
  7. 28 2月, 2011 1 次提交
  8. 09 2月, 2011 1 次提交
  9. 08 2月, 2011 1 次提交
  10. 28 1月, 2011 1 次提交
  11. 25 1月, 2011 1 次提交
  12. 12 1月, 2011 1 次提交
  13. 11 1月, 2011 1 次提交
  14. 07 1月, 2011 1 次提交
  15. 02 12月, 2010 1 次提交
  16. 01 12月, 2010 1 次提交
  17. 24 11月, 2010 1 次提交
  18. 23 10月, 2010 1 次提交
  19. 19 10月, 2010 1 次提交
  20. 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
  21. 01 10月, 2010 2 次提交
  22. 29 9月, 2010 1 次提交
  23. 22 9月, 2010 1 次提交
  24. 13 8月, 2010 1 次提交
  25. 11 8月, 2010 1 次提交
  26. 10 8月, 2010 1 次提交
  27. 03 8月, 2010 1 次提交
    • B
      6953477: Increase portability and flexibility of building Hotspot · 1d7def72
      bobv 提交于
      Summary: A collection of portability improvements including shared code support for PPC, ARM platforms, software floating point, cross compilation support and improvements in error crash detail.
      Reviewed-by: phh, never, coleenp, dholmes
      1d7def72
  28. 11 6月, 2010 1 次提交
  29. 05 6月, 2010 1 次提交
  30. 04 6月, 2010 1 次提交
  31. 28 5月, 2010 1 次提交
  32. 12 3月, 2010 1 次提交
  33. 03 3月, 2010 1 次提交
  34. 02 2月, 2010 1 次提交
  35. 14 1月, 2010 1 次提交
    • Y
      6896647: card marks can be deferred too long · 651edb8d
      ysr 提交于
      Summary: Deferred card marks are now flushed during the gc prologue. Parallel[Scavege,OldGC] and SerialGC no longer defer card marks generated by COMPILER2 as a result of ReduceInitialCardMarks. For these cases, introduced a diagnostic option to defer the card marks, only for the purposes of testing and diagnostics. CMS and G1 continue to defer card marks. Potential performance concern related to single-threaded flushing of deferred card marks in the gc prologue will be addressed in the future.
      Reviewed-by: never, johnc
      651edb8d
  36. 07 1月, 2010 1 次提交
  37. 05 1月, 2010 1 次提交
  38. 12 12月, 2009 1 次提交
  39. 26 11月, 2009 1 次提交