Foreign calls + Compiled stubs

[Doug Simon]

Hi,

This is an update on the changes I've pushed over the last 2 weeks.

As described in the javadoc for ForeignCallDescriptor, a foreign call differs from a normal compiled Java call in at least one of these aspects:
- The call is to C/C++/assembler code.
- The call uses different conventions for passing parameters or returning values.
- The callee has different register saving semantics. For example, the callee may save all
  registers (apart from some specified temporaries) in which case the register allocator doesn't
  not need to spill all live registers around the call site.
- The call does not derive from an INVOKE* bytecode.

Slow path support routines are also called by foreign calls. These stubs that may handle "medium path" logic directly (e.g., NewInstanceStub implements TLAB refill logic, only calling out to a C++ function if that fails) or simply call out to a runtime function (written in C/C++ or manually assembled). For the latter, stub generation is largely automated through use of the ForeignCallStub.

Linking foreign calls is a matter of creating a HotSpotForeignCallLinkage object for each ForeignCallDescriptor. It's probably best to just see how this is done in [AMD64]HotSpotRuntime.registerReplacements().

One enhancement we are considering, is to modify HotSpot such that it can handle calls to normal Java code from non-invoke bytecodes. This would allow one to write certain support routines in Java (such as the routines for creating ArrayIndexOutOfBoundsExceptions and NullPointerExceptions). It would also allow for pretty powerful instrumentation routines to be written in Java where all register and stack values are made available to the support routine (for example).

-Doug