RFR(S): 8138681: Runtime.getFreeMemory() reports wrong value after humongous allocation.

David Lindholm david.lindholm at oracle.com
Thu Nov 19 11:42:42 UTC 2015

Hi Thomas,

Thanks for looking at this!

On 2015-11-19 12:09, Thomas Schatzl wrote:
> Hi David,
> On Thu, 2015-11-19 at 11:08 +0100, David Lindholm wrote:
>> Hi,
>> Please review this patch that changes how the usage of humongous regions
>> are calculated. Since we (currently) cannot use the remainder of the
>> last humongous region, we say that the complete region is used for the
>> humongous object.
>> This is done by setting top=end and adding dummy/filler objects to the
>> end of the last region.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138681
>> Webrev: http://cr.openjdk.java.net/~david/JDK-8138681/webrev.00/
>> Testing: Passed JPRT, vm.gc testlist and the attached test from the bug.
>    two initial comments (I have not looked through the change completely
> in detail):
> - in g1CollecteHeap.cpp, line 343
>   342   size_t fill_size = word_size_sum - word_size;
>   343   if (fill_size > 0) {
> the condition is wrong. It should be >= min_fill_size().

Good catch, thank you! Fixed.

> - I would somewhat prefer if the BOT would not be updated as if the
> humongous object were a single object (I think). I won't object to that
> if others do not object either. I mean, I do not really see an issue
> with that for various reasons, but it would be nice if we tried to
> improve that. Maybe it is not worth the effort.

I don't really see the problem with that. Sure, I could walk the dummy 
objects after the call to fill_with_objects() and update the BOT, but 
again I don't really see the point.


> It's nice that this change actually removes some special handling in a
> few places.
> Thanks,
>    Thomas

More information about the hotspot-gc-dev mailing list