On 2014/10/14 06:56:27, Sven Panne wrote:
Could you please explain how this is supposed to work? As it is, I don't
understand it. Previously things were very simple: For all classes with
IDs,
base_id() tells you where the range of num_ids() start, and all of the
logic
was
local. This should not change even if we do this in a separate pass.
After this patch, the situation is exactly the same: base_id() tells you
where
the ids for a given class start, except that there is no num_ids() function.
The difference is that instead of adding up id counts for each class node
in a
type hierarchy (i.e. num_ids() for each type) to get the total number of
nodes
to reserve, this patch reserves ids using a similar mechanism as the one
that
objects.h uses to reserve slots in HeapObjects: kBailoutIdCount is the
cumulative number of ids to reserve, and every subclass adds on their slots
to
the parent.
https://codereview.chromium.org/636403003/diff/1/src/ast.h
File src/ast.h (right):
https://codereview.chromium.org/636403003/diff/1/src/ast.h#newcode411
src/ast.h:411: int leaf_base_id() const { return base_id() + 2; }
I don't understand what leaf_base_id() should do. Why do we need both
base_id()
and leaf_base_id()?
leaf_base_id() is defined by non-final types with bailout ids. It is the
base_id that direct subclasses should use.
And what is the "+ 2"? Is it actually "+ kBailoutIdCount"?
No. kBailoutIdCount is cumulative, like JSObject::kSize.
https://codereview.chromium.org/636403003/
--
--
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.
