Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8016395 | 8 | Thomas Schatzl | P4 | Resolved | Fixed | b94 |
JDK-8033508 | 7u80 | Thomas Schatzl | P4 | Resolved | Fixed | b01 |
JDK-8034527 | 7u65 | Thomas Schatzl | P4 | Resolved | Fixed | b01 |
JDK-8028186 | 7u60 | Thomas Schatzl | P4 | Closed | Fixed | b05 |
Here's how one set of stats looks like:
Concurrent RS processed -1761455529 cards
Of 9224262 completed buffers:
9224262 (100.0%) by conc RS threads.
0 ( 0.0%) by mutator threads.
Conc RS threads times(s)
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Total heap region rem set sizes = 1120947K. Max = 4047K.
Static structures = 600K, free_lists = 5312K.
717820015 occupied cards represented.
Max size region = 378:(O)[0x00000004fa000000,0x00000004fb000000,0x00000004fb000000], size = 4048K, occupied = 37303K.
Did 209966 coarsenings.
There are multiple issues as listed:
1) -ve number for cards
2) Conc RS threads times are always 0.00
3) In-spite of specifying a period for stats (in this case -XX:G1SummarizeRSetStatsPeriod=1), the data seems to be cumulative.
Also, it seems that cards processed by mutator threads are always 0 (0.0%).
For #2, I understand that it is OS related, but, I'd appreciate any information, doesn't have to be exact (since per thread times are listed, so helps with performance analysis to see how many refinement threads were used during the specified period)
For #3, I guess that the stats period was probably introduced so as not to pollute with excess data, but I take that to mean that the stats per period would be printed and not cummulative data.
Concurrent RS processed -1761455529 cards
Of 9224262 completed buffers:
9224262 (100.0%) by conc RS threads.
0 ( 0.0%) by mutator threads.
Conc RS threads times(s)
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Total heap region rem set sizes = 1120947K. Max = 4047K.
Static structures = 600K, free_lists = 5312K.
717820015 occupied cards represented.
Max size region = 378:(O)[0x00000004fa000000,0x00000004fb000000,0x00000004fb000000], size = 4048K, occupied = 37303K.
Did 209966 coarsenings.
There are multiple issues as listed:
1) -ve number for cards
2) Conc RS threads times are always 0.00
3) In-spite of specifying a period for stats (in this case -XX:G1SummarizeRSetStatsPeriod=1), the data seems to be cumulative.
Also, it seems that cards processed by mutator threads are always 0 (0.0%).
For #2, I understand that it is OS related, but, I'd appreciate any information, doesn't have to be exact (since per thread times are listed, so helps with performance analysis to see how many refinement threads were used during the specified period)
For #3, I guess that the stats period was probably introduced so as not to pollute with excess data, but I take that to mean that the stats per period would be printed and not cummulative data.
- backported by
-
JDK-8016395 G1: G1SummarizeRSetStats output on Linux needs improvement
-
- Resolved
-
-
JDK-8033508 G1: G1SummarizeRSetStats output on Linux needs improvement
-
- Resolved
-
-
JDK-8034527 G1: G1SummarizeRSetStats output on Linux needs improvement
-
- Resolved
-
-
JDK-8028186 G1: G1SummarizeRSetStats output on Linux needs improvement
-
- Closed
-
- relates to
-
JDK-8014078 G1: improve remembered set summary information by providing per region type information
-
- Resolved
-
-
JDK-8040804 G1: Concurrent mark stuck in loop calling os::elapsedVTime()
-
- Closed
-
(1 relates to)