On 2015/06/08 11:17:14, jochen wrote:
On 2015/06/08 at 11:15:18, ishell wrote:
> On 2015/06/08 11:04:59, jochen wrote:
> > replaced all the #ifdefs
> >
> >
https://codereview.chromium.org/1135353003/diff/120001/src/objects-inl.h
> > File src/objects-inl.h (right):
> >
> >
https://codereview.chromium.org/1135353003/diff/120001/src/objects-inl.h#newcode1553
> > src/objects-inl.h:1553: // TODO(jochen): Why do we claim that Code
and Map
> > contain only raw values?
> > On 2015/06/08 at 10:45:12, Igor Sheludko wrote:
> > > I guess because we never called MayContainRawValues() method for
Code
and
Map
> > object before, but now we do during the slots filtering. So probably
it
makes
> > sense to return kTaggedValues for Code and Map here.
> > >
> > > I'm not sure which way is the best: to reorder instance types or to
add
more
> > conditions here.
> >
> > I'd rather keep this patch as refactoring only, we can still do that
in a
> > follow-up.
> Ok, fine.
>
> > At least Code should be kMixedValues, no? It contains all the
assembly...
> In this sense Map is also a kMixedValues thing - it contains sizes
field and
bit fields.
> BTW, LayoutDescriptor machinery does not support Maps and Code cases.
bit fields and stuff are fine as long as they look like Smis (i.e. bit 0
is
unused)
I don't think it's guaranteed. Actually GC knows about these raw fields and
skips them manually (see Map::kPointerFieldsBeginOffset). Probably the same
could be said about Code handling. GC never looks into the assembly
directly -
only through relocation info or through typed slot buffer entries.
https://codereview.chromium.org/1135353003/
--
--
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.
