Review request: Zero assembler port of HotSpot

[Gary Benson]

Hi Tom,

I've been working on a new webrev for Zero.  I'm mostly there,
but I'd like to check on a couple of points you originally raised.

Tom Rodriguez wrote:
> I guess I would expect the build directories to look like
> linux_i486_zero instead of linux_zero_core which is what I
> think you'd currently get.

Fixing this is tricky.  There is no variable for this directory,
it's always referenced as $(OSNAME)_$(BUILDARCH)_whatever, and
in addition to specifiying the build directory, BUILDARCH is
used in conditionals in various makefiles to add extra compiler
flags, etc.  If I set BUILDARCH to "i486", for example, then I
get a load of extra stuff that isn't wanted.

Removing the CORE_BUILD stuff has changed the build directory
to linux_zero_zero (which will be linux_zero_shark when Shark
is enabled).  Is this acceptable?

> Shouldn't is_deoptimizer_frame be is_deoptimized_frame?

HotSpot's deoptimizer walks the stack in two places, both of
which are a C++ function called from the compiled code, so the
stack looks like this:

  (top)  Frame of C++ function
         Frame of compiled method
         ...

When walking the stack, the C++ functions skip over the first
frame to find the frame of the compiled method.  Zero and Shark
maintain a Java stack that is separate from the ABI stack, so
the top frame on the stack will be the frame of the compiled
method.  To give the C++ code a frame to skip, Shark pushes an
empty frame onto the stack.  That frame is what I've called a
deoptimizer frame.  Is that ok?

Cheers,
Gary

-- 
http://gbenson.net/