JDK-8194877 : Clean up code in G1CollectedHeap::attempt_allocation_slow
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 11
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-01-10
  • Updated: 2019-02-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8137099 - G1 needs to "upgrade" GC within the safepoint if it can't allocate during that safepoint to avoid OoME
Description
During review of JDK-8137099 we found some code in G1CollectedHeap::attempt_allocation_slow() that could be cleaned up a little:

[...]
0  if (GCLocker::is_active_and_needs_gc() && g1_policy()->can_expand_young_list()) {
1    // No need for an ergo message here, can_expand_young_list() does this when it returns true
2    result = _allocator_attempt_allocation_force(word_size, context);
3    if (result != NULL) {
4      return result;
5    }
6  }

The issues are:
- The comment in line 1 is wrong, there is no ergo message anywhere.
- the result of attempt_allocation_force() must always be non-NULL as a successful can_expand_list() always indicates that another region can be allocated.

Clean this up.