Review request: Zero assembler port of HotSpot

[Gary Benson]

Tom Rodriguez wrote:
> On Sep 18, 2009, at 3:25 AM, Gary Benson wrote:
> > 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.

I'll make a new webrev so you can work on the partially right one.

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

I was mistaken about it being a C++ frame (it's been a while since I
wrote this code).  The two places that walk the stack during a deopt
(Deoptimization::uncommon_trap_inner and Deoptimization::unpack_frames)
both use use JavaThread::last_frame().  The frame it's skipping is the
deopt stub's frame.

> 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);

Yes.  Maybe it would be better to rename DEOPTIMIZER_FRAME as
something like EMPTY_FRAME or DUMMY_FRAME?

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

There's nowhere else in Zero or Shark that creates dummy frames like
this.

Cheers,
Gary

-- 
http://gbenson.net/