https://codereview.chromium.org/1219063017/diff/140001/src/compiler/coalesced-live-ranges.h
File src/compiler/coalesced-live-ranges.h (right):
https://codereview.chromium.org/1219063017/diff/140001/src/compiler/coalesced-live-ranges.h#newcode38
src/compiler/coalesced-live-ranges.h:38: void VisitConflicts(const
LiveRange* range, ConstLiveRangePtrToBool visitor) {
On 2015/07/14 05:13:04, Benedikt Meurer wrote:
Higher order functions which iterate over a data structure, and allow
callbacks
to mutate the underlying data structure, are usually a bad idea, esp.
in C++
(with STL). IMHO this is worse compared to the conflict_iterator.
What happened to the idea of simple loops? I thought we agreed on that
as a
starting point.
I called this out in the code review description: the starting point
suffered from code duplication and increased concept coupling. Both
complicate (and increase cost of) maintenance and testing.
The starting point wasn't really simple loops either: both
GetMaximumConflictingWeight and EvictAndRescheduleConflicts had to
carefully traverse the set of allocated ranges, and in a very similar
way. The difference between the 2 was subtle and unnecessary (eviction
had to skip over successive intervals of same range, finding max weight
could do without that, but didn't need to). When looking into unit
testing, the code duplication became clear.
I'm assuming your concern with potentially mutating visitors is about
mutation invalidating the underlying iterator? I believe the
implementation ensures safe mutation, unless I'm missing something?
https://codereview.chromium.org/1219063017/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
