IcedTea7 Forest Updated

Wed Feb 22 16:11:12 PST 2012

----- Original Message -----
> Hi
> Just a couple of comments ... inline below.
> On 22/02/12 03:52 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> On 22/02/12 10:12 AM, Andrew Hughes wrote:
> >>> I've bumped the forest to jdk7u4-b11 with hs23b14, with the hope
> >>> that people
> >>> can start testing earlier this time, before u4 is released.
> >>>
> >>> Changes to the IcedTea7 tree to use this will follow.
> >>
> >>
> >> Hi Andrew,
> >>
> >> Unless I miss-understand whats been done here, it means that the
> >> Zero
> >> resurrection is removed/ undone... it only worked with hs22 /
> >> early
> >> hs23 (b01/03?). [After that the  TARGET_ARCH_NYI_6939861 flag and
> >> code are completely removed.]
> >>
> >>
> >> Chris
> > No.  It was merged with the new HotSpot changes in u4.  Changes
> > like the
> > OBJCOPY change are definitely still there (I had to merge that
> > manually).
> > The NYI flag was removed in:
> >
> > changeset:   3231:15d394228cfa
> > user:        jrose
> > date:        Thu Jan 19 13:00:11 2012 -0800
> > summary:     7111138: delete the obsolete flag
> > -XX:+UseRicochetFrames

> This is the final acknowledgement of the removal of the non-Richochet
> frame
> support,  the TARGET_ARCH_NYI_6939861 enabled code is gone before
> this point.

Ah ok.  I just saw that one as being the change that altered the
methodHandles_zero.hpp file.

> 
> > I pre-approve
> > http://icedtea.classpath.org/hg/icedtea7-forest/hotspot/rev/433e4570d57c
> > going back to 2.1
> > if it hasn't already.  This branch uses hs22 and will continue to
> > do so, receiving
> > only security & approved backports as usual.

> Thanks I will do so.

> >
> > I don't think it helps anyone to stick with some old release while
> > OpenJDK
> > development continues at full steam... and we're only talking about
> > the 7
> > update stream here, not 8!  The longer we wait to pull in new
> > changes from
> > the 7u tree, the more change there will be, which means more work
> > for everyone.
> > It also makes it near impossible to upstream changes, as we're
> > working on something
> > different from what upstream is.

> Looking back I think I now see that you warned me but I didn't
> understand
> the warning...will try to pay a little more attention in the future.

Well, my impression was that you knew more about recent HotSpot changes
than I did and thus, that this was inevitably going to happen sooner or
later... :-)

I didn't spend a huge amount of time discussing this first for two
reasons:

1.  There's not really an alternative and we don't lose anything by
doing it.  Before, we had HEAD and 2.1 the same.  Now HEAD has moved
on, which I think is a reasonable situation for the main development
branch.  Not doing so now just makes things even more disruptive when
we do with more changes everywhere, not just in HotSpot, meaning more
of my time is spent doing the merge and it's harder to track down
what happened.  Most of all, it means we can't participate in jdk7u
development.

2.  When we did this for u2, I did it on a separate branch first.
It got pretty much no response, except from Damien who updated
the bootstrapping patches (thanks again for that -- it saved me
doing the work).  So this time I just went ahead and did the update
directly so people could get working on u4 ASAP.

> > Ideally, Zero et. al. should be working with the hsx trees that I
> > believe then feed
> > into 8 and 7u.  That's a steep hill to climb at this point, I know,
> > but it's where
> > we need to be.

> It's sad but there is no testing of Zero at all in pushes to the HSX
> trees,
> so almost anything can break Zero, then it will eventually end up in
> a
> 7uxx build.
> I suppose we could test the HSX Zero build daily... I try to do so
> weekly by hand
> but the timing can be crucial especially when code is changing
> rapidly and
> diagnosing the failures is hard and time consuming when you are
> familiar
> with the code
> being changed, let alone when the code is being re-designed and
> modified
> by another
> team without noticing any effects in the Zero code.
> 

Yeah I know.  I did quite a bit of work getting things going again
when HotSpot moved away from includeDB, and you'd find silly obvious
things that needed fixing.  As I say, it's where we need to aim to be
but it'll be hard to get there.  Equally, we need to think on this
for supporting the ARM port.

I guess what would be most helpful for me is just to know from you where we
are with this and the work that needs to be done.  This is the first
I've heard of any of this.

> Beyond that the HSX 23 JSR 292 design currently is Ricochet frames
> which depend
> on machine code stubs, so we have a fundamental  issue in Zero. A
> future
> has been
> suggested where it will move back into bytecode but that will
> probably
> be in JDK8.

Is it possible to just not have JSR292 support?  Or to come up with an
alternative design?

Has this been discussed on hotspot-dev?

> 
> Chris
> 
> 
> 

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07