IcedTea7 Forest Updated

[Chris Phillips]

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.

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

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.

Chris