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

David Lindholm david.lindholm at oracle.com
Thu Nov 19 15:30:44 UTC 2015


Mikael,

Thanks for looking at this!

On 2015-11-19 15:01, Mikael Gerdin wrote:
> Hi David,
>
> On 2015-11-19 11:08, 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.
>
> It seems strange to me to set the block offset table covering the 
> filler object to point to the start of the humongous object.
> I would find it more natural to insert the filler object and update 
> the block offset table in the loop where the top pointer is set:
>
> for (uint i = first + 1; i < last - 1; ++i) {
>   hr = region_at(i);
>   hr->set_top(hr->end());
>   if (_hr_printer.is_active()) {
>     ...
>   }
> }
>
> // Fill out last region
> hr = region_at(last - 1);
> hr->set_top(obj_top);
> HeapWord* fill = hr->allocate(filler_obj_size); // allocate also calls 
> alloc_block on the BOT.
> fill_with_objects(fill);

As we discussed offline I think I must create the filler objects and 
update the BOT before the storestore, and after that update the 
top-pointers.

However, as we also discussed offline I now call alloc_block() 
separately for the filler object. Please see

http://cr.openjdk.java.net/~david/JDK-8138681/webrev.01/


Thanks,
David

> /Mikael
>
>
>
>>
>> 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.
>>
>>
>> Thanks,
>> David
>



More information about the hotspot-gc-dev mailing list