Openjdk hotspot build 14.0-b06 hard coded bug found.

[Tony Guan]

Hi there,

I think I've found a little bug in the parallel gc codes.  Will
somebody take a look at it?
Firstly, after a full gc, there maybe the need to adjust the boundary
between young and old generation.
and here in psMarkSweep.cpp, we
use:			heap->resize_old_gen(size_policy->calculated_old_free_size_in_bytes());

Then this methods will in turn call:
    gens()->adjust_boundary_for_old_gen_needs(desired_free_space);

in this function, we compare the desired_free_space with the current
free space, and then calls request_old_gen_expansion:
    if (old_gen()->free_in_bytes() < desired_free_space) {
      MutexLocker x(ExpandHeap_lock);
      request_old_gen_expansion(desired_free_space);
but in request_old_gen_expansion the desired_free_space is immediately
treated as expand_in_bytes. And in this implementation, the actual
change in bytes is computed like this:
 size_t change_in_bytes = MIN3(young_gen_available,
                                old_gen_available,
                                align_size_up_(expand_in_bytes, alignment));
and then:
 virtual_spaces()->adjust_boundary_up(change_in_bytes)

So in the end, we have old_gen()->free_in_bytes()+=desired_free_space
and the final "desired_free_space" is more than needed.

And after the boundary is moved up (too high), the
_old_gen->resize(desired_free_space)

will compute the new space size as:
 size_t new_size = used_in_bytes() + desired_free_space;

Thus it will shrink the old gen space smaller. So we have part the
space sacrificed by the young generation out of the old gen usage. And
the size of this wasted memory is (desired_free_space- prevoiusly free
space of old_gen).


Thanks!

Tony Guan