Clarification needed for the amount of memory unmapped during imagefile closure.

[Alan Bateman]

On 05/12/2018 12:26, Jini George wrote:
> Hello!
>
> I needed a clarification regarding the amount of memory unmapped 
> during imagefile closure in 
> src/java.base/share/native/libjimage/imageFile.cpp.
>
> I noticed that 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     }
>
> Wanted to check if this is an oversight, or if there is a reason 
> behind this and I am missing something. Shouldn't the amount of memory 
> unmapped be map_size() too ?
It doesn't look right but needs closer examination. However, I'm curious 
how you are running into it as it will be completely unmapped when the 
VM terminates. Is this a tool or test that runs "in process"?

-Alan