1. 19 2月, 2010 1 次提交
  2. 18 2月, 2010 1 次提交
  3. 17 2月, 2010 2 次提交
  4. 13 2月, 2010 1 次提交
  5. 12 2月, 2010 1 次提交
    • I
      6923991: G1: improve scalability of RSet scanning · 88955d77
      iveresov 提交于
      Summary: Implemented block-based work stealing. Moved copying during the rset scanning phase to the main copying phase. Made the size of rset table depend on the region size.
      Reviewed-by: apetrusenko, tonyp
      88955d77
  6. 10 2月, 2010 2 次提交
  7. 09 2月, 2010 3 次提交
  8. 08 2月, 2010 1 次提交
  9. 06 2月, 2010 2 次提交
  10. 05 2月, 2010 1 次提交
  11. 04 2月, 2010 2 次提交
  12. 03 2月, 2010 1 次提交
  13. 02 2月, 2010 5 次提交
  14. 30 1月, 2010 4 次提交
  15. 29 1月, 2010 3 次提交
  16. 27 1月, 2010 2 次提交
  17. 26 1月, 2010 1 次提交
  18. 22 1月, 2010 1 次提交
  19. 21 1月, 2010 1 次提交
  20. 16 1月, 2010 2 次提交
  21. 14 1月, 2010 3 次提交
    • J
      6912065: final fields in objects need to support inlining optimizations for JSR 292 · 42263eca
      jrose 提交于
      Reviewed-by: twisti, kvn
      42263eca
    • J
      6915005: G1: Hang in PtrQueueSet::completed_buffers_list_length with gcl001 · b851645d
      johnc 提交于
      Summary: When enqueuing a completed PtrQueue buffer, cache a local pointer to the buffer and clear the field in the PtrQueue prior to unlocking the mutex referenced by the _lock field and pass the cached local value to the enqueuing routine. This will prevent the same completed buffer being enqueued multiple times, which causes the hang.
      Reviewed-by: ysr
      b851645d
    • 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