Review request: Zero assembler port of HotSpot

[Tom Rodriguez]

On Sep 18, 2009, at 3:25 AM, Gary Benson wrote:

> 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?

I'm going to look into making it work the way I want.  The logic is  
mainly driven through buildtree.make and I recently was experimenting  
with driving that differently so I think I can see how to do it.  I'll  
take a stab and get back to you.  If I can't then linux_zero_zero will  
have to do.

>
>> 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
>         ...

If I understand you correctly, it's really this case:

c++ (fetch_unroll_info)
deopt blob
compiled frame

> 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?

So it's just a dummy frame to make the idiom below work?

     frame stub_frame = thread->last_frame();
     frame caller_frame = stub_frame.sender(&reg_map);

Do you insert dummy stub frames to deal with other places that use  
that idiom or are you not using entry points that have that pattern?

tom

>
> Cheers,
> Gary
>
> -- 
> http://gbenson.net/