[8u20] Request for approval for bulk integration of hs25.20-b02
goetz.lindenmaier at sap.com
Fri Jan 31 14:29:22 UTC 2014
> 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!
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
The webrev actually distinguishes between individual changesets. (rev
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?
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?
>> 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,
>> Thanks and best regards,
>> -----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:
>> 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
More information about the jdk8u-dev