[8u20] Request for approval for bulk integration of hs25.20-b02

[Alejandro E Murillo]

as indicated by Rob and David, It's not a single bulk push, it's several 
changesets pushed
simultaneously, it's just a snapshot of the hotspot development repo 
than then is taken
through PIT testing

Thanks
Alejandro


On 1/31/2014 7:29 AM, Lindenmaier, Goetz wrote:
>> multiple changesets as far as mercurial is concerned.
> Yes!! That's what I want. In the target repo.
>
> So I misread the webrev?  Sorry for that and all the confusion I caused!
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: jdk8u-dev-bounces at openjdk.java.net [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf Of Rob McKenna
> Sent: Freitag, 31. Januar 2014 15:06
> To: jdk8u-dev at openjdk.java.net
> Subject: Re: [8u20] Request for approval for bulk integration of hs25.20-b02
>
> Hi Goetz,
>
> The webrev actually distinguishes between individual changesets. (rev
> 5801 etc)
>
> This means that there will be a single webrev and a single push, but
> multiple changesets as far as mercurial is concerned.
>
> Does this address your concerns?
>
>       -Rob
>
> On 31/01/14 13:22, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>>> "bulk integration" - meaning a collective request for approval followed
>>> by a push of all pending changesets - is the normal modus operandi for
>>> hotspot integrations.
>> What do you mean by "all pending changesets"?  This is one webrev with
>> one patch consisting of 10 changes made individually all merged together.
>> That's what's not good.
>> Or is this webrev only for review?
>> http://cr.openjdk.java.net/~amurillo/8u20/hs25.20-b02-jdk8u20-b01.webrev/
>>
>>> I'm unclear what you are looking for instead: N approval emails followed
>>> by N separate pushes ?? What practical difference does that make?
>> Sure, one mail is fine.  But not merging different changes.
>>
>>> At this stage all pushes are to jdk8u-dev. The 8u20 moniker is only used
>>> as that is the proposed next release of 8u. jdk8u-dev and 8u20 are
>>> synonymous up to the point where 8u20 repos have to fork due to rampdown
>>> to the 8u20 release.
>> Yes.  But during rampdown you add new changes fixing bugs, and 8u20 can differ
>> from 8u, because there show up new changes not targeted for 8u20. So we have to
>> take 8u20 to get a repo with a stable, final VM.
>>
>>>> For our internal VM (not the ppc port) we consume jdk8, then jdk8u20 and only
>>>> much later jdk9.  Thus we have to sort out the changes that appear several times,
>>>> but fix the differences between them.  Bulk integrations complicate this a lot.
>>> I don't follow. From what you just wrote I don't expect you to even look
>>> at 8u until 8u20 is finalized. ??
>> Ideally, we never look at 8u.  After 8u20 we will release 8u40.
>>
>> Best regards,
>>    Goetz.
>>
>>
>>
>>
>>> Thanks and best regards,
>>>      Goetz.
>>>
>>> -----Original Message-----
>>> From: jdk8u-dev-bounces at openjdk.java.net [mailto:jdk8u-dev-bounces at openjdk.java.net] On Behalf Of Alejandro E Murillo
>>> Sent: Freitag, 31. Januar 2014 01:30
>>> To: jdk8u-dev at openjdk.java.net
>>> Subject: [8u20] Request for approval for bulk integration of hs25.20-b02
>>>
>>> Requesting approval to integrate hs25.20-b02 into jdk8u20-b01.
>>>
>>> A webrev is available at:
>>>
>>> http://cr.openjdk.java.net/~amurillo/8u20/hs25.20-b02-jdk8u20-b01.webrev/
>>>
>>> Pre-integration testing is in progress; the integration will proceed
>>> only after SQE has analyzed the results and approved.
>>>
>>> The fixes in the proposed integration are below.  All have undergone
>>> nightly testing and are already in a jdk9 repository.
>>>
>>> 8027364: PSScavenge accounts too large code section to StringTable unlink
>>> 8027454: Do not traverse string table during G1 remark when treating them as strong roots during initial mark
>>> 8027455: Improve symbol table scan times during gc pauses
>>> 8027476: Improve performance of Stringtable unlink
>>> 8027746: Remove do_gen_barrier template parameter in G1ParCopyClosure
>>> 8028553: The JVM should not throw VerifyError when 'overriding' a static final method in a superclass.
>>> 8030027: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Linux-amd64: SIGSEGV in JavaThread::last_java_vframe(RegisterMap*)+0xfa
>>> 8030955: assert(_prologue != NULL) failed: prologue pointer must be initialized
>>> 8031045: Access checks should precede additional per-instruction checks
>>> 8032014: new hotspot build - hs25.20-b02
>>>

-- 
Alejandro