[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Weak keyed tables with primitive keys
- From: Mark Hamburg <mark@...>
- Date: Wed, 21 Oct 2009 15:42:59 -0700
On Oct 21, 2009, at 1:30 PM, Roberto Ierusalimschy wrote:
The above seems like a memory leak, as 'cache[ aPath ] = aContent'
hold everything forever.
It is curious why nodoby is concerned with similar things happening
with numerical keys. If aPath is a number, you have exactly the same
situation. Should Lua wait until the number is collected to remove
entry from the table?
To start with files aren't generally identified by number (though I
guess one could get the inode number), but be that as it may...
What seems more troubling is not the fact that string keys aren't weak
(though that's at times awkward) as that string values aren't weak
(though the lack of weakness for string keys is a problem for weak
sets of strings even strings as values were weak).
In the file cache case, what really matters is that if the results of
the file read are still in memory then there's no point in reading
again. We can work around the issue with an intermediate table in the
cache which is mostly accurate if we don't hang onto the results of
file reads for very long. On the other hand, this means that any GC
protection logic -- i.e., logic to keep the read data from going away
too fast -- must now deal with the intermediate tables. We can't
simply access a value from the file cache and hand it to the GC
protection logic. Rather we need to hand an internal data structure
from the file cache to the GC protection logic.