Ah, you're right, although INTERNAL_REFERENCE is implemented in ia32, they
are
intended only for absolute addresses within the same code object, so the
existing logic would move deopt entries in the wrong direction during
relocation.
Then if you really want to shrink the jump table, I really think deopt
entries
need to be RUNTIME_ENTRIES, and as previous discussed all RUNTIME_ENTRIES
need
to be 32-bits with trampolines to call through to C++ code in the non-deopt
entry case. Alternatively, you could support RUNTIME_ENTRIES in two modes,
depending on the opcode before the RUNTIME_ENTRY in the instruction steam,
treating the 32-bit and 64-bit pointers differently in RelocInfo::apply and
RelocInfo::Visit/VisitRuntimeEntry. This is more plumbing work to put an
abstraction around whether the RUNTIME_ENTRY is 32 or 64 bits (although
RelocInfo already seems to support a call called "target_address_size", so
maybe
some of the abstraction is already there), but think that's probably a more
efficient solution in the long run.
https://codereview.chromium.org/11574027/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
