Re: Avoiding FFI- allocations + using SSE-vectors

[Mike Pall <mikelu-1202@...>]

Ross Bencina wrote:
> I've no idea what
> it would take to add reference counted GC to LuaJIT (although I'd be
> very interested to hear what Mike thinks about adding this feature.)

Reference counting (RC) has plenty of practical problems. One key
aspect is that the impact is hard to measure, since the overhead
is spread out all over the code. Some issues, like excessive
number of writes, cache pollution, unbounded latency vs. delayed
free, etc. can be solved with more complex variants of RC.

However these asymptotically converge into something quite similar
to what the smart(er) generational GC algorithms do. I'd rather
improve the current GC than switch to RC.

The plan for LuaJIT 2.1 is to have a very fast bump allocator and
a generational and cache-optimized collector. That would alleviate
most of the pain of doing allocations (in case they can't be
eliminated).

> I'm not sure what benefit a circular buffer gives you over
> generational GC -- aside from the risk of overflowing the buffer and
> introducing hard to debug errors.

Well, it's a stopgap measure, for sure. But if you have a bounded
expression depth and are careful with copy vs. ref, this ain't
such a bad solution either.

[But _please_ don't use y = tab[idx % #tab]; idx = idx+1. Rather
use y = arr[idx]; idx=band(idx+1,31) or similar.]

One problem is that even the smartest algorithms can't avoid some
allocations, e.g. when you're passing a reference to a C function.
Unless you give it additional information that the reference isn't
stored elsewhere, the allocation won't be eliminated.

In C you'd allocate it on the stack. In Lua you'd have to make
sure the value holding it goes dead and the compiler notices that,
too (tricky). As I've previously said, adding special annotations
to temporary allocations isn't a viable solution.

--Mike