JDK-8087339 : The code heap might use different alignment for committed size and reserved size
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-12
  • Updated: 2021-02-15
  • Resolved: 2017-11-27
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.
JDK 10
10 b36Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
The reserved gets aligned via the VirtualSpace and the committed size gets aligned with a page size from a explicit call to os::page_size_for_region. This is a probably fine in most cases but could cause problems in boundary conditions.
Comments
http://cr.openjdk.java.net/~thartmann/8087339/webrev.00/
22-11-2017

Deferring to JDK 10 because this is a possible problem that has not appeared yet.
25-05-2016

I recalled what the problem was when discussing JDK-8155098: The code cache memory is reserved in CodeCache::reserve_heap_memory(). We compute the page_size for the alignment like this: const size_t page_size = os::can_execute_large_page_memory() ? MIN2(os::page_size_for_region_aligned(InitialCodeCacheSize, 8), os::page_size_for_region_aligned(size, 8)) : os::vm_page_size(); I.e., we take the min of the page size for the reserved code cache size and the initial code cache size (which is usually very small). This probably prevents us from aligning the code cache to large pages. Re-opening this to be fixed in JDK 9.
26-04-2016

[~ehelin], I don't recall what the problem was. The committed size is aligned according to the region alignment in VirtualSpace::expand_by() which is called from VirtualSpace::initialize_with_granularity(). Where did you spot the inconsistency?
04-04-2016

ILW=Possible missalignment in code cache, never seen, none=MLH=P5
15-06-2015