JDK-8215026 : Incorrect amount of memory unmapped with ImageFileReader::close()
  • Type: Bug
  • Component: tools
  • Sub-Component: jlink
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-12-07
  • Updated: 2019-11-25
  • Resolved: 2018-12-10
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 11 JDK 12
11.0.4Fixed 12 b24Fixed
Related Reports
Relates :  
Description
When the "modules" file is opened in ImageFileReader::open(), and the contents are mmap()-ed, the size to be mmap()-ed is derived from map_size().

399     // Memory map image (minimally the index.)
400     _index_data = (u1*)osSupport::map_memory(_fd, _name, 0, (size_t)map_size());

Which could be _file_size or _index_size, and for 64 bit processes, it would be _file_size. (about 140 MB)

488     // Retrieve the size of the mapped image.
489     inline u8 map_size() const {
490         return (u8)(memory_map_image ? _file_size : _index_size);
491     }

But when the contents are unmapped in ImageFileReader::close(), the amount of memory unmapped is only _index_size (which is considerably lesser than _file_size).

427 // Close image file.
428 void ImageFileReader::close() {
429     // Deallocate the index.
430     if (_index_data) {
431         osSupport::unmap_memory((char*)_index_data, _index_size);
432         _index_data = NULL;
433     }

The amount of memory unmapped should also be map_size().  

Mail thread here: 

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-December/014043.html
Comments
Fix Request for 11u: I want to backport changes in below: - JDK-8200613 - JDK-8215342 - JDK-8219414 - JDK-8219574 - JDK-8215026 They are very helpful for crash analysis. We can apply them straightly to 11u, but they need to apply them in same time. Risk is low because these changes affects only to coredump on Linux. They are covered with serviceability/sa tests.
13-05-2019