Use EXTERNAL_REFERENCE instead of RUNTIME_ENTRY for deoptimization entries for ARM and MIPS

Use EXTERNAL_REFERENCE instead of RUNTIME_ENTRY for deoptimization entries for ARM and MIPS

[haitao.feng, 2013-02-08 03:11:47]

From the source codes and discussion with danno, RUNTIME_ENTRY is a special
external reference. It does not move and is the target of relative
jump/branch/call instructions. Because the relative jump/branch/call
instructions might be moved by GC, RUNTIME_ENTRY needs to be relocated.

It seems that current ARM and MIPS does not use relative jump/branch/call
instructions when using RUNTIME_ENTRY (for deoptimization entries), we should be
able to replace RUNTIME_ENTRY with EXTERNAL_REFERENCE. In the future if ARM and
MIPS use CodeRange, we could use RUNTIME_ENTRY again as for X64
(https://codereview.chromium.org/11574027/).

Upstream MIPS could not be compiled, so I verified this patch set by using
https://github.com/paul99/v8m-rb for MIPS.

[Paul Lind, 2013-02-08 07:01:19]

This seems OK for mips, although its a bit late, and I don't quite yet grok the
motivation for the change. I'll study it a bit further tomorrow. Prelim testing
is fine, but some tests are still running, so I may have updated info in the
morning.

Thanks a lot Haitao for porting the mips change, and going to the extra effort
to pull from our external repo! As you can see, my colleague Akos has ported the
missing CL's, and they are now pending for review.

[danno, 2013-02-08 08:04:10]

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.

[haitao.feng, 2013-02-08 09:43:31]

Danno, thanks for the explanation. It is exactly the motivation behind this
patch.

I am trying to write a clean implementation to avoid platform #ifdef in
https://codereview.chromium.org/11574027/. Based on this replacement, we could
only introduce "target_runtime_entry" and RUNTIME_ENTRY is handled similarly
with CODE_TARGET in the CopyFrom.

[haitao.feng, 2013-02-27 02:55:35]

Agreed with Danno and I will close this CL.