Review request: Zero assembler port of HotSpot
gbenson at redhat.com
Tue Sep 22 01:38:26 PDT 2009
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(®_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
More information about the hotspot-dev