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

[Jini George]

Thank you very much, Jim. Will do and submit a patch for review.

Thanks,
Jini.

On 12/5/2018 6:58 PM, Jim Laskey wrote:
> An oversight, please file a bug.
> 
> — Jim
> 
> 
>> On Dec 5, 2018, at 8:37 AM, Alan Bateman <Alan.Bateman at oracle.com 
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>> 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
>