Lasse, thanks a lot for comments and clarifications. May you have another look?
Major features: access to caches by indices; reworked search and eviction algorithm to implement LRU, hopefully this time for real. http://codereview.chromium.org/1563005/diff/12001/13008 File src/runtime.cc (right): http://codereview.chromium.org/1563005/diff/12001/13008#newcode10015 src/runtime.cc:10015: receiver, On 2010/04/09 07:18:25, Lasse Reichstein wrote:
That's ok for now. There doesn't seem to be any significant
regressions.
Ofcourse, that may just be because there are no non-pathological uses
of
String.search.
Ok, so let's postpone it for a next patch. http://codereview.chromium.org/1563005/diff/12001/13008#newcode10018 src/runtime.cc:10018: &pending_exception); On 2010/04/09 07:18:25, Lasse Reichstein wrote:
The reason I'm wary about this is that you are passing the address of
a handle
location, but handles can be shared, so if the value is modified by
code (apart
from GC, where it should be), it might affect other references to the
handle as
well. In this case, we know that the handle isn't shared (because we created
it from
an Object* just above), and it isn't used after this call, so even if
the value
is changed, it won't hurt anything. So I guess the comment I want here is that the key handle isn't shared
and isn't
used later.
Thanks a lot for explanations. Put into a separate block and comment added. http://codereview.chromium.org/1563005/diff/12001/13008#newcode10071 src/runtime.cc:10071: int target_index = (finger_index > kEntriesIndex) ? finger_index - 2 On 2010/04/09 07:18:25, Lasse Reichstein wrote:
I want LRU order too, but I don't think the current code does that for
the
entries added before the cache fills up.
The current code fills up the array in increasing order, but evicts in decreasing. I.e., if there are four positions, they are filled in the
order 0,
1, 2, 3, and then when it's full, the first to be evicted/reused is 2,
and then
continuing with 1, 0, 3, 2.... (at which point it is doing LRU order). The LRU element at the time the cache fills up would be the one after
the finger
(wrapping to 0).
I'm not sure what you mean by iterating backwards, but if you keep the
current
filling strategy and evict the post-finger entry each time, you will
keep
cycling in the same order for both partial and full caches.
Let me try to make code speak for itself---it'd be a good readability check :) http://codereview.chromium.org/1563005/show -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev To unsubscribe, reply using "remove me" as the subject.
