LRU cache for ~=

[Leandro Lucarella]

Andrei Alexandrescu, el 19 de octubre a las 13:51 me escribiste:
> I just wrote this to Sean and Walter and subsequently discussed it
> with Walter. Walter thinks this should work. Does anyone have the
> time and inclination to test this out? It would involve hacking into
> druntime's implementation of ~= (I'm not sure what the function name
> is). I'd really appreciate this; I'm overloaded as it is.
> 
> ==================
> 
> In wake of the recent demise of T[new], I was thinking of finding
> ways of making ~= efficient for T[].
> 
> Currently ~= is slow because accessing GC.sizeOf(void*) acquires a
> global lock and generally must figure out a lot of things about the
> pointer to make a decision.
> 
> Also, ~= is dangerous because it allows slices to stomp over other slices.
> 
> I was thinking of solving these issues by keeping an LRU (Least
> Recently Used) cache inside the implementation of ~=. The LRU would
> only have a few entries (4-8) and would store the parameters of the
> last ~= calls, and their cached capacities.
> 
> So whenever code calls arr ~= b, the LRU is searched first. If the
> system finds "arr" (both bounds) in the LRU, that means the cached
> capacity is correct and can solve the matter without an actual trip
> to the GC at all! Otherwise, do the deed and cache the new slice and
> the new capacity.
> 
> This also solves the lack of safety: if you request a growth on an
> array you just grew, it's impossible  to have a valid slice beyond
> that array.
> 
> This LRU would allow us to keep the slice API as it currently is,
> and also at excellent efficiency.
> 
> What do you think?

I think this is moving in the wrong direction. It's a patch, not
a solution. And this makes dynamic arrays more coupled with the way the GC
works. I think the GC shouldn't even provide a sizeOf(void*), we should
move in that direction, removing restrictions to the GC instead of
enforcing the current ones; at lest if the goal is to eventually have
a better GC (a copying GC doesn't even have to store the size of the
cell, for example).

I hope you eventually realize that you are complicating things much more
than necessary.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
ACCIDENTE FATAL EN FLORES, MUEREN DOS PERSONAS Y UN BOLIVIANO
	-- Crónica TV