[8u20] Request for approval for bulk integration of hs25.20-b02
goetz.lindenmaier at sap.com
Fri Jan 31 13:22:43 UTC 2014
>"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.
> 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