Re: Memory Allocator Issues

  • From: Peter Cawley <corsix@xxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Wed, 19 Apr 2017 23:44:52 +0100

2.1-master has interpreter plus JIT for GC64 on x64 (earlier versions
of 2.1 were interpreter only on x64)

On Wed, Apr 19, 2017 at 11:42 PM, Caswal Parker
<caswal@xxxxxxxxxxxxxxxxxxxx> wrote:

Thanks Peter,

I did see mention of that in the 2.1 changes list. But the change list made
it look like this only works in interpreted mode?

Are there any other concerns with regards to performance I should know about
for GC64 in LuaJIT 2.1?

Cheers

On 20 April 2017 at 10:35, Peter Cawley <corsix@xxxxxxxxxx> wrote:

If you're willing to use LuaJIT 2.1-master instead of 2.0.4, you could
turn GC64 mode (c.f.
https://github.com/LuaJIT/LuaJIT/issues/259#issuecomment-268515498),
which would result in LuaJIT using 47 bits of address space rather
than 31, thereby solving your issue.

On Wed, Apr 19, 2017 at 11:31 PM, Caswal Parker
<caswal@xxxxxxxxxxxxxxxxxxxx> wrote:
I am using LuaJIT 2.0.4 embedded into an Unreal Engine 4 project. With
an
x64 executable.

On Windows 7 machines, I am seeing extreme instability, running in
interpreter mode I get various "out of memory errors.".

As the project uses multiple GB of ram, it appears that on Windows 7 UE4
has
acquired almost all the virtual address space in the lower 2GB of
address
space. Although I have not mapped any memory I assume that with Windows
10
we don't see this behaviour as the virtual address space is allocated
more
spread out, but I would rather put a system in place to guarantee this.

Looking at lj_alloc.c, I can see the low-level Windows API calls to
guarantee memory allocations in the lower 2GB of address space on Win64
systems.

The way around this issue would be to allocate a memory pool early in
initialization to guarantee memory in the first 2GB of address space.
Then
write a custom allocator to use this pool.

Has anyone done anything like this and would be willing to share, or
give me
some tips?

I've never dealt with a dlmalloc myself before, could I get away with
creating a simple memory pool that serves as replacement to CALL_MMAP,
DIRECT_MMAP and CALL_MUNMAP dealing and tracking DEFAULT_GRANULARITY
sized
chunks?

Any insight or advice greatly appreciated.

Cheers Caswal

--

---------------------------------------------------------------------------------

Caswal Parker
Co-Owner/Lead Programmer - Camshaft Software
Skype name: caswal
http://camshaftsoftware.com




--
---------------------------------------------------------------------------------

Caswal Parker
Co-Owner/Lead Programmer - Camshaft Software
Skype name: caswal
http://camshaftsoftware.com

Other related posts: