Review request: Zero assembler port of HotSpot
gbenson at redhat.com
Fri Sep 18 03:25:37 PDT 2009
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?
More information about the hotspot-dev