Request for code review - 8130265: gctests/LargeObjects/large001 fails with OutOfMemoryError: Java heap space
Alexander Harlap
alexander.harlap at oracle.com
Fri Aug 21 15:44:38 UTC 2015
On 8/21/2015 8:18 AM, Jesper Wilhelmsson wrote:
> Hi Alex,
>
> Alexander Harlap skrev den 20/8/15 21:41:
>> Kim and Thomas,
>>
>> Here is new version with your suggestions in:
>>
>> http://cr.openjdk.java.net/~aharlap/8130265/webrev.03/
>> <http://cr.openjdk.java.net/%7Eaharlap/8130265/webrev.03/>
>> Alex
>>
>
> A few comments on this latest version.
>
> * Why do you assert_at_safepoint and set succeeded to true in your
> helper? The original code did not do this at these places. I think you
> can remove these lines.
>
> 1736 assert_at_safepoint(true /* should_be_vm_thread */);
> 1737
> 1738 *succeeded = true;
>
Even method called satisfy_failed_allocation_helper , there is no way to
make sure that it is called /only /from satisfy_failed_allocation.
satisfy_failed_allocation_helper is a separate method and those lines
are needed.
So I would like to keep
1736 assert_at_safepoint(true /* should_be_vm_thread */);
1737
1738 *succeeded = true;
>
> * Please align the arguments in
>
> 1732 G1CollectedHeap::satisfy_failed_allocation_helper(size_t word_size,
> 1733 AllocationContext_t context,
> 1734 bool clear_all_soft_refs,
> 1735 bool* succeeded) {
>
> and
>
> 1748 HeapWord* result = attempt_allocation_at_safepoint(word_size,
> 1749 context,
> 1750 true /*
> expect_null_mutator_alloc_region */);
>
> and also in the header file.
>
Sure.
>
> * Your last version did:
>
> attempt_allocation_at_safepoint(word_size, context, false);
> expand_and_allocate(word_size, context);
> do_collection(false, false, word_size);
> attempt_allocation_at_safepoint(word_size, context, true);
> expand_and_allocate(word_size, context);
> do_collection(false, true, word_size);
> attempt_allocation_at_safepoint(word_size, context, true);
> assert(!collector_policy()->should_clear_all_soft_refs());
> expand_and_allocate(word_size, context);
>
> You have chosen to break this into:
>
> attempt_allocation_at_safepoint(word_size, context, false);
> expand_and_allocate(word_size, context);
>
> satisfy_failed_allocation_helper(word_size, context, false, succeeded);
> do_collection(false, false, word_size);
> attempt_allocation_at_safepoint(word_size, context, true);
> expand_and_allocate(word_size, context);
>
> satisfy_failed_allocation_helper(word_size, context, true, succeeded);
> do_collection(false, true, word_size);
> attempt_allocation_at_safepoint(word_size, context, true);
> expand_and_allocate(word_size, context);
>
> assert(!collector_policy()->should_clear_all_soft_refs());
>
> This is not entirely identical, depending on how important the assert
> is that could be an issue since the assert is now skipped in some
> cases where it was previously used.
>
> My suggestion would be to break the code up like this:
>
> satisfy_failed_allocation_helper(word_size, context, do_gc,
> clear_softrefs)
> attempt_allocation_at_safepoint(word_size, context, false);
> expand_and_allocate(word_size, context);
> do_collection(false, false, word_size);
>
> satisfy_failed_allocation_helper(word_size, context, do_gc,
> clear_softrefs)
> attempt_allocation_at_safepoint(word_size, context, true);
> expand_and_allocate(word_size, context);
> do_collection(false, true, word_size);
>
> satisfy_failed_allocation_helper(word_size, context, do_gc,
> clear_softrefs)
> attempt_allocation_at_safepoint(word_size, context, true);
> if (!do_gc)
> assert(!collector_policy()->should_clear_all_soft_refs());
> expand_and_allocate(word_size, context);
>
> This would make the code in satisfy_failed_allocation() a lot more clean.
>
In webrev.03 I decided to put same way as it was in the original code
(before any of my changes),
at the very end of method just when we already exhausted all
possibilities and about to return NULL.
/attempt_allocation_at_safepoint(word_size, context, false); //
//expand_and_allocate(word_size, context); //
//do_collection(false, false, word_size); //
//attempt_allocation_at_safepoint(word_size, context, true); //
////do_collection(false, true, word_size); //
//attempt_allocation_at_safepoint(word_size, context, true); //
//assert(!collector_policy()->should_clear_all_soft_refs()); ///
// What else? We might try synchronous finalization later. If the
total 1799 // space available is large enough for the allocation, then a
more
// complete compaction phase than we've tried so far might be
// appropriate.
assert(*succeeded, "sanity");
return NULL; 1804
}
webrev.03 has this assert at same position, and I prefer it this way.
>
> * Unless I'm missing some subtle detail here, the usage of the
> variable 'succeeded' is unnecessary as 'result' will always contain
> the same information. I don't think we should pass on 'succeeded' to
> the helper, but simply set it afterwards before we return from
> satisfy_failed_allocation().
>
No, helper may return NULL in two differnt cases:
1. Full GC failed, *succeeded = false, no attempts to allocate was made
2. Full GC succeeded, *succeeded = true, all attempts to allocate failed
So we need to pass 'succeeded' to the helper.
> Thanks,
> /Jesper
>
>
>> On 8/20/2015 11:01 AM, Thomas Schatzl wrote:
>>> Hi Alex,
>>>
>>> On Wed, 2015-08-19 at 18:43 -0400, Kim Barrett wrote:
>>>> On Aug 19, 2015, at 5:02 PM, Alexander Harlap
>>>> <alexander.harlap at oracle.com>
>>>> wrote:
>>>>> I agree.
>>>>>
>>>>> Here is new revision:
>>>>>
>>>>> http://cr.openjdk.java.net/~aharlap/8130265/webrev.02/
>>>>> <http://cr.openjdk.java.net/%7Eaharlap/8130265/webrev.02/>
>>> would it be possible to fix the code duplication between lines
>>> 1759-1784 and 1785 and 1812? The code seems to be completely the same
>>> except the different flag value passed to the Full GC call and the
>>> assert about that should_clear_all_soft_refs().
>>>
>>> Otherwise it looks good.
>>>
>>> Thanks,
>>> Thomas
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150821/6d5b829d/attachment.htm>
More information about the hotspot-gc-dev
mailing list