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

[Lindenmaier, Goetz]

Hi,

> One observation from me is that jdk8u is a superset of jdk8 fixes. 
I know.  
> I'm sync'ing in jdk8 fixes weekly so you can forget about jdk8 if necessary.
No.  If we release jdk8 it should exactly contain the changes you released in
jdk8.  So we have to take the changes from there.

>Also, if you're not a fan of the bulk integration, note that the hsx 
>fixes gather individually at the hotspot team jdk8u integration forest : 
>http://hg.openjdk.java.net/jdk8u/hs-dev (before bulk integration to master)
Once we start working on jdk8u20, we want exactly the changes you put 
into 8u20, so we again must use that repository.  
Our process is semi-automated.  We don't want to pick changes from here and there.
We go release-by release, and only release what you did release.  So we can 
not take jdk8u.  I assume in jdk8u will show up changes that don't go to 
jdk8u20, before the last change that goes to jdk8u20.

Before, we could not use hsx, we always used hsx21, hsx22 etc, 
because only they would contain a stable release and nothing else
at the end.

Or will  jdk8u and jdk8u20 be identical up to the day you release 8u20?
If so, you should be able to just pull changes between the two repos.

Best regards,
  Goetz.





regards,
Sean.

On 31/01/2014 09:38, Lindenmaier, Goetz wrote:
> Hi Alejandro,
>
> we (SAP) would appreciate if you avoid bulk integrations as far as possible.
> 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.
>
> 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
>