When running SPECjbb2013 there are multiple times when the eden usage ends up being higher than the eden size printed as part of PrintGCDetails

Example of output

------------
93.717: [GC pause (G1 Evacuation Pause) (young), 0.0770723 secs]
 ...
   [Eden: 1140.0M(504.0M)->0.0B(1904.0M) Survivors: 56.0M->72.0M Heap: 2533.8M(10.0G)->1451.1M(10.0G)]
------------

Here you can see that the usage of Eden is 1140M and the eden size is stated as 504M.

After each nursery collection the eden size is set as a target to reach, however there is no list of or pre-allocated eden regions. As memory allocation occurs the eden grabs free regions from the heap until a young collection is started and the process restarts.

What seems to happen here is that the young collection is not started as expected when the target length is reached, but much later and the reason for the print out looking strange is that the eden size is the target length and not number of allocated regions.

------------
void G1CollectorPolicy::record_heap_size_info_at_start(bool full) {
...
  _eden_used_bytes_before_gc = young_list->eden_used_bytes();
...
  _eden_capacity_bytes_before_gc =
          (_young_list_target_length * HeapRegion::GrainBytes) - _survivor_used_bytes_before_gc;
...
}

------------

void G1CollectorPolicy::print_detailed_heap_transition(bool full) {
  YoungList* young_list = _g1->young_list();
...
  gclog_or_tty->print(
          " [Eden: "EXT_SIZE_FORMAT"("EXT_SIZE_FORMAT")->"EXT_SIZE_FORMAT"("EXT_SIZE_FORMAT") "
          EXT_SIZE_PARAMS(_eden_used_bytes_before_gc),
          EXT_SIZE_PARAMS(_eden_capacity_bytes_before_gc),
...
}
------------

It is unclear why the young collection isn't started when the target is reached every time.

Two ideas that might be worth to check
   * GCLocker
   * Target is recalculated by concurrent threads and could be reduced below current usage