Why do we need a bunch of duplicate changes in jdk7u/hotspot ?

[David Holmes]

Hi Volker,

On 27/04/2012 11:15 PM, Volker Simonis wrote:
> Hi David,
>
> thank you very much for the detailed explanation and the links.
> I missed that discussion (there are just too many mailing lists to
> monitor) and now it's obviously too late to complain:)
>
> But as far as I understood, Eriks mail  "Community Input on Hotspot 22
> integration into 7u"
> (http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000161.html)
> was about problems integrating hs22 into 7u.
>
> Did these same problems also occur for hs23 as well? I assume yes and
> if so your explanation would sound perfectly clear to me.

I assume that the same "merge" based model has been followed since that 
point.

> On the other hand I saw no definitive answer to Edvard's mail "
> Proposal on how we should handle syncing between stabilisation forests
> and always open 7u"
> (http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000161.html).
>
> Does this mean that we will constantly see these kind of problems
> (i.e. duplicate changesets with the same bug ID or even worse
> duplicate changesets with different bug IDs) in the future?

It will occur as long as we are dealing with hsN-1 and hsN and we merge 
the way we are.

> Is there any "official" document available which explains the syncing
> between stabilisation forests and 7u?

I'm not aware of anything. I'm also not sure this is specifically an 
issue with stabilization forests - the 7u-dev forest will have the same 
issue.

David
-----

> Thank you and best regards,
> Volker
>
> On Fri, Apr 27, 2012 at 12:45 PM, David Holmes<david.holmes at oracle.com>  wrote:
>> Hi Volker,
>>
>>
>> On 27/04/2012 6:59 PM, Volker Simonis wrote:
>>>
>>> could anybody please explain why it was necessary to reintegrate a
>>> whole lot of changes into hs23 of jdk7u/hotspot which have been in the
>>> hotspot repository since hs22 anyway?
>>
>>
>> This was discussed last year (with thanks to John Rose for these
>> references):
>>
>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000161.html
>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-October/000582.html
>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-November/000748.html
>>
>> Basically what you are seeing are fixes that went into hs22 and hs23 after
>> hs23 forked. hs22 went into 7u2 which became the basis for 7u3 then 7u4.
>> Then hs23 had to be integrated into 7u4 and so you end up with different
>> changesets that duplicate the same actual changes.
>>
>> David
>> -----
>>
>>
>>> This all happened with the following bulk integrations:
>>>
>>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-April/002588.html
>>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-April/002651.html
>>>
>>> and it affects (among others):
>>>
>>> 7059019: G1: add G1 support to the SA
>>> 7092412: G1: Some roots not marked during an initial mark that gets an
>>> evacuation failure
>>> 7045232: G1: pool names are inconsistent with other collectors (don't
>>> have 'Space')
>>> 7068215: G1: Print reference processing time during remark
>>> 7091032: G1: assert failure when NewRatio is used
>>> 7092245: G1: Wrong format specifier in G1PrintRegionLivenessInfo header
>>> output
>>> 7092238: G1: Uninitialized field gc_efficiency in
>>> G1PrintRegionLivenessInfo output
>>> 6484982: G1: process references during evacuation pauses
>>> 7075646: G1: fix inconsistencies in the monitoring data
>>> 7086533: G1: assert(!_g1->is_obj_dead(obj)): We should not be
>>> preserving dead objs: g1CollectedHeap.cpp:3835
>>> 7097053: G1: assert(da ? referent->is_oop() :
>>> referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054
>>> 7097048: G1: extend the G1 SA changes to print per-heap space information
>>> 7092236: java/util/EnumSet/EnumSetBash.java fails
>>> 7092278: "jmap -finalizerinfo" throws
>>> "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137"
>>> 7096366: PPC: corruption of floating-point values with DeoptimizeALot
>>> 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp
>>>
>>> Looking for each of this changes will show you that they are present
>>> two times in the repository with exactly the same changesets. E.g.:
>>> http://hg.openjdk.java.net/jdk7u/jdk7u4/hotspot/log?rev=7059019
>>>
>>> Regards,
>>> Volker