[PATCH] D39449: Rewrite FileOutputBuffer as two separate classes.

Rui Ueyama via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 31 11:13:51 PDT 2017


ruiu added inline comments.


================
Comment at: llvm/lib/Support/FileOutputBuffer.cpp:84-85
+    std::error_code EC;
+    MemoryBlock MB = Memory::allocateMappedMemory(
+        Size, nullptr, sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC);
+    if (EC)
----------------
zturner wrote:
> ruiu wrote:
> > zturner wrote:
> > > Why can't we just use `new` here?
> > I didn't design `Memory` class, but it looks like that class can be instantiated only via allocateMappedMemory.
> Right, but why do we even need to use the `Memory` class at all?  It seems like overkill.  The comments say:
> 
> ```
>     /// This method allocates a block of memory that is suitable for loading
>     /// dynamically generated code (e.g. JIT). 
> ```
> 
> Since we don't care about the protection (RWX) of the temporary storage, and only about the protection of the final file on disk, it seems like this is unnecessary.
> 
> Instead of storing `OwningMemoryBlock` as a member of the class, you could just store `std::vector<uint8_t>`.
> 
> There are fewer failure paths this way, as it's literally just one call to `new`, whereas `allocateMappedMemory` has several ways it can return errors.
How can you catch memory exhaustion error if you use `new`?


https://reviews.llvm.org/D39449





More information about the llvm-commits mailing list