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

[Lindenmaier, Goetz]

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