Just in case: it's early preview call---if you like the idea, I'd clean the
CL.
On 2010/04/09 13:48:51, antonm wrote:
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.
