Re: memory allocation policy
- From: Mike Pall <mike-1409@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 24 Sep 2014 12:07:08 +0200
Laurent Deniau wrote:
> - the gc collects (calls the finaliser) too lately as it is not
> aware that objects waiting for destruction sill consume a
> significant amount of memory.
That's certainly the case as it only sees tiny pointer objects.
Log the memory consumption over time and compare the actual need
vs. the use.
> - we fall back on the interpreter at some level
You can check with -jv, -jdump and the profiler in v2.1 (-jp=vl).
> - the gc uses a slow mechanism to invoke the finaliser
A call to a GC finalizer is not compiled. You can find out if this
is the problem by profiling with the GC running vs. stopped. You
probably need to shorten your test to avoid running out of memory.
> I suspect that this problem is not new and some solutions have
> been already found by others. It would be nice if someone could
> explain me why the delegation of memory management to C gives
> such bad results and how to solve the problem. Thanks.
It's not hard to do a pool allocator in Lua, using the FFI.
Allocate a big pool with mmap or malloc, then deal out chunks on
new and put them back on the free list in the finalizer. The
finalizer is a Lua function in this case, so it can be compiled.
But better check the new and free functions in isolation for any
inefficiencies by looking at the machine code with -jdump.
--Mike
Other related posts:
