<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - SectionMemoryManager assumes allocateMappedMemory to return a size that is a multiple of page size, but it can return much larger memory blocks."
href="https://bugs.llvm.org/show_bug.cgi?id=41690">41690</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>SectionMemoryManager assumes allocateMappedMemory to return a size that is a multiple of page size, but it can return much larger memory blocks.
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>release blocker
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>OrcJIT
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>contact@machiel.info
</td>
</tr>
<tr>
<th>CC</th>
<td>1101.debian@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Recently, the behaviour of allocateMappedMemory in Memory.h was changed to
return the requested memory size in the returned MemoryBlock instead of the
size that was actually allocated. SectionMemoryManager was updated to assume
that allocateMappedMemory returns a memory block with a size that is a multiple
of the page size. This is a bad assumption because on windows
allocateMappedMemory returns sizes with a granularity of 64kb (16 pages).
This is currently causing huge memory consumption, as in 100s of MBs of wasted
space, and out-of-memory crashes in my use case (using the ORC JIT on Windows
in a 32-bit application).
Also, when protectMappedMemory in Memory.h is called on Windows, it will use
the size stored in the MemoryBlock, which now is the requested size, and not
the actual allocated size. This may cause problems if the extra available space
is actually used for executable code because the memory beyond the initially
requested size might not be given executable permissions. This is because the
allocation granularity is 16 pages and the memory protection granularity is 1
page on Windows. Therefore it is not enough to update SectionMemoryManager to
assume multiples of 64kb on Windows. It's probably better for a MemoryBlock to
expose both the requested size and the allocated size and for
protectMappedMemory to use the allocated size.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>