The high-level motivation is to remove the jump table entries on x64 for
"standard" deoptimizations, thus shrinking code size. In order to do this,
the
deopt entries need to be reachable through 32-bit relative jumps (that's the
problem that the jump table was trying to solve in the first place). In
order to
make the deopt entries reachable via the "short" 32-bit jumps from deopts,
they
need to be in the 2GB CodeRange address range and have a special RelocInfo
type,
since they require special handling by the GC.
Haitao has already changed x64 to do treat "entry point" code pointers
outside
the CodeRange object as EXTERNAL_REFERENCES and "entry point" references
inside
the CodeRange as RUNTIME_ENTRYs. I think this CL is just part of an effort
to
make other platforms consistent.
However, I am not 100% satisfied with this approach, since I don't see the
advantage of pushing the changes through to all platform. I think it might
be
more consistent to consider the entire address space on ARM and MIPS as the
"CodeRange", because it essentially is right now. This suggests leaving the
code
as-is, keeping deopt entries as RUNTIME_ENTRIES and instead implementing
platform-specific handling of RUNTIME_ENTRIES, which is already something
that
is done for CODE_TARGETs. Haitao is pursuing this in another CL, and I'd
prefer
to run with that first.
https://codereview.chromium.org/12213080/
--
--
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/groups/opt_out.
