From sybersnake at gmail.com  Mon Aug  1 00:23:13 2016
From: sybersnake at gmail.com (Jon V.)
Date: Sun, 31 Jul 2016 20:23:13 -0400
Subject: NIO IOUtils Direct vs Heap
In-Reply-To: <579E90C5.50201@redhat.com>
References: <CALR2BPYxUTQP6TOcC+82UVg7wN2gi0jVjJL7XY5-Ba91K0M5=g@mail.gmail.com>
	<579E90C5.50201@redhat.com>
Message-ID: <CALR2BPZeo=uWhqzRqFh_SHK38Y9ZS26ALG-jcfX5meqvdZboWg@mail.gmail.com>

Andrew,

Thanks for the reply.

So it basically comes down to the need to keep the threads at safe points
as often as possible?  Don?t JNI calls already prevent GC due to references
as arguments?

On Sun, Jul 31, 2016 at 7:59 PM, Andrew Haley <aph at redhat.com> wrote:

> Hi,
>
> On 31/07/16 12:25, Jon V. wrote:
>
> > As I?m sure we are all aware that all HeapBuffers must be copied to
> > DirectBuffers in order to be written to NIO.  IOUtils provides the
> > necessary automation for writing to the FD and working with the
> BufferCache.
> >
> > My question is this: Since we know that byte[] can be passed to JNI
> > and safely copied to native memory. (exactly how the heap is copied
> > to the native) Why can?t byte[] be written directly to the FD and
> > bypass all the nastiness of copying to native memory.
>
> You could use write() directly on the byte array.  But write() is a
> blocking system call, so it could block for a very long time.  During
> that time the byte array would have to be pinned in memory; it could
> not be moved until write() completed.  You'd have a byte array stuck
> in the middle of the heap, preventing compaction.  Eventually the
> system would run out of memory.
>
> Andrew.
>

From aph at redhat.com  Mon Aug  1 00:47:53 2016
From: aph at redhat.com (Andrew Haley)
Date: Mon, 1 Aug 2016 01:47:53 +0100
Subject: NIO IOUtils Direct vs Heap
In-Reply-To: <CALR2BPZeo=uWhqzRqFh_SHK38Y9ZS26ALG-jcfX5meqvdZboWg@mail.gmail.com>
References: <CALR2BPYxUTQP6TOcC+82UVg7wN2gi0jVjJL7XY5-Ba91K0M5=g@mail.gmail.com>
	<579E90C5.50201@redhat.com>
	<CALR2BPZeo=uWhqzRqFh_SHK38Y9ZS26ALG-jcfX5meqvdZboWg@mail.gmail.com>
Message-ID: <579E9C39.1080205@redhat.com>

On 01/08/16 01:23, Jon V. wrote:

> So it basically comes down to the need to keep the threads at safe
> points as often as possible?  Don?t JNI calls already prevent GC due
> to references as arguments?

No.  JNI calls don't prevent GC.  When you access the elements of a
byte array in JNI you use GetByteArrayElements, and that copies the
data to native memory.  You could use GetPrimitiveArrayCritical which
may not do such copying and may block the GC, but in that case you
must not make any blocking system call.  If you do, you are on the
fast road to deadlock.  There's no getting away from it: if you want
to call write(), your data must be in native memory.

Andrew.

From sybersnake at gmail.com  Mon Aug  1 04:24:45 2016
From: sybersnake at gmail.com (Jon V.)
Date: Mon, 1 Aug 2016 00:24:45 -0400
Subject: Proposal for Direct-X-Buffer change to improve allocation of zero
	capacity buffers
Message-ID: <CALR2BPZDCF54+Rmsmq4xAuaMy5DffZLwPsWOBW0dCN18gODrkw@mail.gmail.com>

The Direct Buffer does not optimize the allocation of zero capacity
buffers.  I am proposing a simple if( cap != 0 )  condition that will
bypass most of the setup process.

Here is the current constructor:

    Direct$Type$Buffer$RW$(int cap) {                   // package-private
#if[rw]
        super(-1, 0, cap, cap);
        boolean pa = VM.isDirectMemoryPageAligned();
        int ps = Bits.pageSize();
        long size = Math.max(1L, (long)cap + (pa ? ps : 0));
        Bits.reserveMemory(size, cap);

        long base = 0;
        try {
            base = unsafe.allocateMemory(size);
        } catch (OutOfMemoryError x) {
            Bits.unreserveMemory(size, cap);
            throw x;
        }
        unsafe.setMemory(base, size, (byte) 0);
        if (pa && (base % ps != 0)) {
            // Round up to page boundary
            address = base + ps - (base & (ps - 1));
        } else {
            address = base;
        }
        cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
        att = null;
#else[rw]
        super(cap);
#end[rw]
    }

From erik.joelsson at oracle.com  Mon Aug  1 11:34:34 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 1 Aug 2016 13:34:34 +0200
Subject: PING: [8u112] Request for review & approval for CR8151841: Build
	needs additional flags to compile with GCC 6
In-Reply-To: <788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com>
References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com>
	<577F4C58.6060101@oracle.com>
	<1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com>
	<788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com>
Message-ID: <75eba245-b501-6567-445c-836fa7fc3885@oracle.com>

Looks good now, thanks!

Sorry for not answering earlier. I just got back from vacation.

/Erik

On 2016-07-15 17:22, Andrew Hughes wrote:
> Ping?
>
> ----- Original Message -----
>> ----- Original Message -----
>>> Hello,
>>>
>>> It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always returning
>>> yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and
>>> C++ checks.
>>>
>> Ugh, merged a block in the wrong place by the looks of it.
>>
>> Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/
>>
>> configure:29739: checking if the C++ compiler supports "-std=gnu++98 "
>> configure:29755: /usr/bin/g++ -c  -std=gnu++98   conftest.cpp >&5
>> configure:29755: $? = 0
>> configure:29769: result: yes
>> configure:29815: checking if the C compiler supports
>> "-fno-delete-null-pointer-checks -Werror"
>> configure:29832: /usr/bin/gcc -c  -fno-delete-null-pointer-checks -Werror
>> conftest.c >&5
>> configure:29832: $? = 0
>> configure:29846: result: yes
>> configure:29855: checking if the C++ compiler supports
>> "-fno-delete-null-pointer-checks -Werror"
>> configure:29871: /usr/bin/g++ -c  -fno-delete-null-pointer-checks -Werror
>> conftest.cpp >&5
>> configure:29871: $? = 0
>> configure:29885: result: yes
>> configure:29894: checking if both compilers support
>> "-fno-delete-null-pointer-checks -Werror"
>> configure:29899: result: yes
>> configure:29911: checking if the C compiler supports "-fno-lifetime-dse
>> -Werror"
>> configure:29927: /usr/bin/gcc -c  -fno-lifetime-dse -Werror  conftest.c >&5
>> configure:29927: $? = 0
>> configure:29941: result: yes
>> configure:29950: checking if the C++ compiler supports "-fno-lifetime-dse
>> -Werror"
>> configure:29966: /usr/bin/g++ -c  -fno-lifetime-dse -Werror  conftest.cpp >&5
>> configure:29966: $? = 0
>> configure:29980: result: yes
>> configure:29989: checking if both compilers support "-fno-lifetime-dse
>> -Werror"
>> configure:29994: result: yes
>>
>>
>>> /Erik
>>>
>>> On 2016-07-07 22:21, Andrew Hughes wrote:
>>>> Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151841
>>>>
>>>> This is a backport of the original fix to support building OpenJDK
>>>> with GCC 6. It was necessary to cherry-pick parts of a number of
>>>> earlier fixes to make this work with the build system in 8:
>>>>
>>>> 8149647: Incremental enhancements from build-infra
>>>> 8032045: Enable compiler and linker safety switches for debug builds
>>>>
>>>> and so I'm requesting a review of the 8 version of the patch here as well
>>>> as approval for 8u.
>>>>
>>>> In brief, the patch makes OpenJDK build with GCC 6 by explicitly
>>>> specifying
>>>> the C++ standard to use (-std=gnu++98) and disabling two optimisations
>>>> with
>>>> -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further
>>>> information
>>>> on the changes is available in the GCC 6 release notes [0]. GCC 6 uses
>>>> a newer C++ standard, C++14, with which the OpenJDK codebase is not yet
>>>> compliant. The simplest way to fix this, especially for existing
>>>> releases,
>>>> is to explicitly request the previous default, gnu++98. The deletion
>>>> of null pointer checks and more aggressive lifetime dead store
>>>> elimination
>>>> in 6 lead to a crashing virtual machine being built, so we disable them
>>>> if GCC >= 6 is used.
>>>>
>>>> To make the original patch work with 8u, a number of changes from other
>>>> fixes had to also be brought over:
>>>>
>>>> * We need to check we are using GCC 6 or above, so we need to bring
>>>> over the TOOLCHAIN_CHECK_COMPILER_VERSION and
>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647.
>>>> TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional
>>>> numbered rather than named argument macro so we don't need to backport
>>>> BASIC_DEFUN_NAMED.
>>>> * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245
>>>> as we need to apply the -std option only to the C++ compiler, not the
>>>> C compiler. If passed to the C compiler, it will produce a warning,
>>>> and this is converted to an error at one point in the build
>>>> (a -Werror in libsctp).
>>>>
>>>> Generally, we've kept things in toolchain.m4 (8034788 introduced
>>>> flags.m4,
>>>> separating out some code, and so many of these changes are in that file
>>>> in 9) and avoid named argument macros. Otherwise, it's largely the
>>>> same as the 9 version. We have adopted the longer name for
>>>> the -fno-delete-null-pointer-checks flag variable as suggested in the
>>>> review of the update to this patch for the new HotSpot build [1].
>>>>
>>>> [0] https://gcc.gnu.org/gcc-6/porting_to.html
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html
>>>
>> --
>> Andrew :)
>>
>> Senior Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>
>>
>>


From sean.coffey at oracle.com  Tue Aug  2 07:58:25 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 2 Aug 2016 08:58:25 +0100
Subject: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <CA+3eh11HpG3FjaebVOu9P5XG7nZyCE5ZNLRRTWjr6dom6cW6_w@mail.gmail.com>
References: <CA+3eh11nxD1Dn7Bo=WHwnstFUG4=OM3Yuj7hf-St9=QDKbTNhw@mail.gmail.com>
	<CA+3eh11HpG3FjaebVOu9P5XG7nZyCE5ZNLRRTWjr6dom6cW6_w@mail.gmail.com>
Message-ID: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com>

Volker,

Have the jdk8u hotspot edits been reviewed ? Looks like they should be.

Can you add a suitable noreg label to the master bug report also.

Regards,
Sean.

On 29/07/2016 19:58, Volker Simonis wrote:
> Ping!
>
> Can I please have an approval for backporting this change to 8u-dev?
>
> Thanks,
> Volker
>
>
> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> could you please approve the backport of the following, mostly ppc64
>> change to jdk8u-dev:
>>
>> 8152172: PPC64: Support AES intrinsics
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>
>> As you can see, the change consists of two parts - the main one in the
>> hotpsot repo and a small part in the jdk repo.
>>
>> The jdk part applied cleanly to jdk8u (with the usual directory shuffling).
>>
>> The hotspot part required a small tweak, but only in the ppc-only
>> part. This is because the feature detection for the AES instructions
>> was already active in jdk9 when the original change was made but is
>> not available in jdk8u until now. You can find the additional changes
>> at the end of this mail for your convenience.
>>
>> The required shared changes cleanly apply to jdk8u.
>>
>> As Vladimir pointed out in a previous thread, shared Hotspot changes
>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
>> that and synchronously push both parts.
>>
>> @Hiroshii: could you please verify that you are fine with the change?
>> I've done some tests on Power8LE but just want to be sure this
>> downport satisfies your needs as well.
>>
>> Thank you and best regards,
>> Volker
>>
>> =====================
>>
>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700
>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200
>> @@ -452,6 +476,7 @@
>>     a->popcntw(R7, R5);                          // code[7] -> popcntw
>>     a->fcfids(F3, F4);                           // code[8] -> fcfids
>>     a->vand(VR0, VR0, VR0);                      // code[9] -> vand
>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] -> vcipher
>>     a->blr();
>>
>>     // Emit function to set one cache line to zero. Emit function
>> descriptor and get pointer to it.
>> @@ -495,6 +520,7 @@
>>     if (code[feature_cntr++]) features |= popcntw_m;
>>     if (code[feature_cntr++]) features |= fcfids_m;
>>     if (code[feature_cntr++]) features |= vand_m;
>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>
>>     // Print the detection code.
>>     if (PrintAssembly) {
>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700
>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200
>> @@ -42,6 +42,7 @@
>>       fcfids,
>>       vand,
>>       dcba,
>> +    vcipher,
>>       num_features // last entry to count features
>>     };
>>     enum Feature_Flag_Set {
>> @@ -56,6 +57,7 @@
>>       fcfids_m              = (1 << fcfids ),
>>       vand_m                = (1 << vand   ),
>>       dcba_m                = (1 << dcba   ),
>> +    vcipher_m             = (1 << vcipher),
>>       all_features_m        = -1
>>     };
>>     static int  _features;
>> @@ -83,6 +85,7 @@
>>     static bool has_fcfids()  { return (_features & fcfids_m) != 0; }
>>     static bool has_vand()    { return (_features & vand_m) != 0; }
>>     static bool has_dcba()    { return (_features & dcba_m) != 0; }
>> +  static bool has_vcipher() { return (_features & vcipher_m) != 0; }
>>
>>     static const char* cpu_features() { return _features_str; }


From sean.coffey at oracle.com  Tue Aug  2 10:11:10 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 2 Aug 2016 11:11:10 +0100
Subject: PING: [8u112] Request for review & approval for CR8151841: Build
	needs additional flags to compile with GCC 6
In-Reply-To: <75eba245-b501-6567-445c-836fa7fc3885@oracle.com>
References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com>
	<577F4C58.6060101@oracle.com>
	<1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com>
	<788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com>
	<75eba245-b501-6567-445c-836fa7fc3885@oracle.com>
Message-ID: <c0c6400b-0043-e014-5f8c-292e40bb3abf@oracle.com>

I'm seeing this patch fail across all platforms on internal builds. 
Please hold off any push for now. Maybe other config changes are needed 
on our build systems.

e.g.

> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC                                    \
>                      -m64 -G -KPIC     \
> 	           -I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc                                        \
> 	           -I../generated                                       \
> 	           -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include                          \
> 	           -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris    \
> 	                                     \
> 	           /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp                                        \
> 	           sadis.o                                          \
> 	           -M /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile -mt -xnolib -norunpath                                         \
> 	           -o libsaproc.so                                                \
> 	           -ldl -ldemangle -lthread -lc
> ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such file or directory
> ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or directory
> ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory
> ld: fatal: file processing errors. No output written to libgenerateJvmOffsets.so
> gmake[6]: *** [libgenerateJvmOffsets.so] Error 1
> gmake[6]: *** Waiting for unfinished jobs....
> gmake[6]: Leaving directory `/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product'
> gmake[5]: *** [the_vm] Error 2

Regards,
Sean.

On 01/08/2016 12:34, Erik Joelsson wrote:
> Looks good now, thanks!
>
> Sorry for not answering earlier. I just got back from vacation.
>
> /Erik
>
> On 2016-07-15 17:22, Andrew Hughes wrote:
>> Ping?
>>
>> ----- Original Message -----
>>> ----- Original Message -----
>>>> Hello,
>>>>
>>>> It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always 
>>>> returning
>>>> yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and
>>>> C++ checks.
>>>>
>>> Ugh, merged a block in the wrong place by the looks of it.
>>>
>>> Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/
>>>
>>> configure:29739: checking if the C++ compiler supports "-std=gnu++98 "
>>> configure:29755: /usr/bin/g++ -c  -std=gnu++98   conftest.cpp >&5
>>> configure:29755: $? = 0
>>> configure:29769: result: yes
>>> configure:29815: checking if the C compiler supports
>>> "-fno-delete-null-pointer-checks -Werror"
>>> configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks 
>>> -Werror
>>> conftest.c >&5
>>> configure:29832: $? = 0
>>> configure:29846: result: yes
>>> configure:29855: checking if the C++ compiler supports
>>> "-fno-delete-null-pointer-checks -Werror"
>>> configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks 
>>> -Werror
>>> conftest.cpp >&5
>>> configure:29871: $? = 0
>>> configure:29885: result: yes
>>> configure:29894: checking if both compilers support
>>> "-fno-delete-null-pointer-checks -Werror"
>>> configure:29899: result: yes
>>> configure:29911: checking if the C compiler supports "-fno-lifetime-dse
>>> -Werror"
>>> configure:29927: /usr/bin/gcc -c  -fno-lifetime-dse -Werror 
>>> conftest.c >&5
>>> configure:29927: $? = 0
>>> configure:29941: result: yes
>>> configure:29950: checking if the C++ compiler supports 
>>> "-fno-lifetime-dse
>>> -Werror"
>>> configure:29966: /usr/bin/g++ -c  -fno-lifetime-dse -Werror 
>>> conftest.cpp >&5
>>> configure:29966: $? = 0
>>> configure:29980: result: yes
>>> configure:29989: checking if both compilers support "-fno-lifetime-dse
>>> -Werror"
>>> configure:29994: result: yes
>>>
>>>
>>>> /Erik
>>>>
>>>> On 2016-07-07 22:21, Andrew Hughes wrote:
>>>>> Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151841
>>>>>
>>>>> This is a backport of the original fix to support building OpenJDK
>>>>> with GCC 6. It was necessary to cherry-pick parts of a number of
>>>>> earlier fixes to make this work with the build system in 8:
>>>>>
>>>>> 8149647: Incremental enhancements from build-infra
>>>>> 8032045: Enable compiler and linker safety switches for debug builds
>>>>>
>>>>> and so I'm requesting a review of the 8 version of the patch here 
>>>>> as well
>>>>> as approval for 8u.
>>>>>
>>>>> In brief, the patch makes OpenJDK build with GCC 6 by explicitly
>>>>> specifying
>>>>> the C++ standard to use (-std=gnu++98) and disabling two 
>>>>> optimisations
>>>>> with
>>>>> -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further
>>>>> information
>>>>> on the changes is available in the GCC 6 release notes [0]. GCC 6 
>>>>> uses
>>>>> a newer C++ standard, C++14, with which the OpenJDK codebase is 
>>>>> not yet
>>>>> compliant. The simplest way to fix this, especially for existing
>>>>> releases,
>>>>> is to explicitly request the previous default, gnu++98. The deletion
>>>>> of null pointer checks and more aggressive lifetime dead store
>>>>> elimination
>>>>> in 6 lead to a crashing virtual machine being built, so we disable 
>>>>> them
>>>>> if GCC >= 6 is used.
>>>>>
>>>>> To make the original patch work with 8u, a number of changes from 
>>>>> other
>>>>> fixes had to also be brought over:
>>>>>
>>>>> * We need to check we are using GCC 6 or above, so we need to bring
>>>>> over the TOOLCHAIN_CHECK_COMPILER_VERSION and
>>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647.
>>>>> TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional
>>>>> numbered rather than named argument macro so we don't need to 
>>>>> backport
>>>>> BASIC_DEFUN_NAMED.
>>>>> * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245
>>>>> as we need to apply the -std option only to the C++ compiler, not the
>>>>> C compiler. If passed to the C compiler, it will produce a warning,
>>>>> and this is converted to an error at one point in the build
>>>>> (a -Werror in libsctp).
>>>>>
>>>>> Generally, we've kept things in toolchain.m4 (8034788 introduced
>>>>> flags.m4,
>>>>> separating out some code, and so many of these changes are in that 
>>>>> file
>>>>> in 9) and avoid named argument macros. Otherwise, it's largely the
>>>>> same as the 9 version. We have adopted the longer name for
>>>>> the -fno-delete-null-pointer-checks flag variable as suggested in the
>>>>> review of the update to this patch for the new HotSpot build [1].
>>>>>
>>>>> [0] https://gcc.gnu.org/gcc-6/porting_to.html
>>>>> [1]
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html 
>>>>>
>>>>
>>> -- 
>>> Andrew :)
>>>
>>> Senior Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>>
>>> PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
>>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>>
>>>
>>>
>


From sean.coffey at oracle.com  Tue Aug  2 11:21:18 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 2 Aug 2016 12:21:18 +0100
Subject: PING: [8u112] Request for review & approval for CR8151841: Build
	needs additional flags to compile with GCC 6
In-Reply-To: <c0c6400b-0043-e014-5f8c-292e40bb3abf@oracle.com>
References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com>
	<577F4C58.6060101@oracle.com>
	<1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com>
	<788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com>
	<75eba245-b501-6567-445c-836fa7fc3885@oracle.com>
	<c0c6400b-0043-e014-5f8c-292e40bb3abf@oracle.com>
Message-ID: <2204d04d-4e7d-6d47-dc6b-398bac5506b1@oracle.com>

Andrew,

there are some non-OpenJDK related changes that I need to make at time 
of this push. Is it OK if I push this patch to jdk8u-dev for you ?

Approved for jdk8u-dev.

Regards,
Sean.

On 02/08/2016 11:11, Se?n Coffey wrote:
>
> I'm seeing this patch fail across all platforms on internal builds. 
> Please hold off any push for now. Maybe other config changes are 
> needed on our build systems.
>
> e.g.
>
>> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC                                    \
>>                      -m64 -G -KPIC     \
>> 	           -I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc                                        \
>> 	           -I../generated                                       \
>> 	           -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include                          \
>> 	           -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris    \
>> 	                                     \
>> 	           /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp                                        \
>> 	           sadis.o                                          \
>> 	           -M /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile -mt -xnolib -norunpath                                         \
>> 	           -o libsaproc.so                                                \
>> 	           -ldl -ldemangle -lthread -lc
>> ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such file or directory
>> ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or directory
>> ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory
>> ld: fatal: file processing errors. No output written to libgenerateJvmOffsets.so
>> gmake[6]: *** [libgenerateJvmOffsets.so] Error 1
>> gmake[6]: *** Waiting for unfinished jobs....
>> gmake[6]: Leaving directory `/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product'
>> gmake[5]: *** [the_vm] Error 2
>
> Regards,
> Sean.
> On 01/08/2016 12:34, Erik Joelsson wrote:
>> Looks good now, thanks!
>>
>> Sorry for not answering earlier. I just got back from vacation.
>>
>> /Erik
>>
>> On 2016-07-15 17:22, Andrew Hughes wrote:
>>> Ping?
>>>
>>> ----- Original Message -----
>>>> ----- Original Message -----
>>>>> Hello,
>>>>>
>>>>> It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always 
>>>>> returning
>>>>> yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C 
>>>>> and
>>>>> C++ checks.
>>>>>
>>>> Ugh, merged a block in the wrong place by the looks of it.
>>>>
>>>> Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/
>>>>
>>>> configure:29739: checking if the C++ compiler supports "-std=gnu++98 "
>>>> configure:29755: /usr/bin/g++ -c  -std=gnu++98 conftest.cpp >&5
>>>> configure:29755: $? = 0
>>>> configure:29769: result: yes
>>>> configure:29815: checking if the C compiler supports
>>>> "-fno-delete-null-pointer-checks -Werror"
>>>> configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks 
>>>> -Werror
>>>> conftest.c >&5
>>>> configure:29832: $? = 0
>>>> configure:29846: result: yes
>>>> configure:29855: checking if the C++ compiler supports
>>>> "-fno-delete-null-pointer-checks -Werror"
>>>> configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks 
>>>> -Werror
>>>> conftest.cpp >&5
>>>> configure:29871: $? = 0
>>>> configure:29885: result: yes
>>>> configure:29894: checking if both compilers support
>>>> "-fno-delete-null-pointer-checks -Werror"
>>>> configure:29899: result: yes
>>>> configure:29911: checking if the C compiler supports 
>>>> "-fno-lifetime-dse
>>>> -Werror"
>>>> configure:29927: /usr/bin/gcc -c  -fno-lifetime-dse -Werror 
>>>> conftest.c >&5
>>>> configure:29927: $? = 0
>>>> configure:29941: result: yes
>>>> configure:29950: checking if the C++ compiler supports 
>>>> "-fno-lifetime-dse
>>>> -Werror"
>>>> configure:29966: /usr/bin/g++ -c  -fno-lifetime-dse -Werror 
>>>> conftest.cpp >&5
>>>> configure:29966: $? = 0
>>>> configure:29980: result: yes
>>>> configure:29989: checking if both compilers support "-fno-lifetime-dse
>>>> -Werror"
>>>> configure:29994: result: yes
>>>>
>>>>
>>>>> /Erik
>>>>>
>>>>> On 2016-07-07 22:21, Andrew Hughes wrote:
>>>>>> Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151841
>>>>>>
>>>>>> This is a backport of the original fix to support building OpenJDK
>>>>>> with GCC 6. It was necessary to cherry-pick parts of a number of
>>>>>> earlier fixes to make this work with the build system in 8:
>>>>>>
>>>>>> 8149647: Incremental enhancements from build-infra
>>>>>> 8032045: Enable compiler and linker safety switches for debug builds
>>>>>>
>>>>>> and so I'm requesting a review of the 8 version of the patch here 
>>>>>> as well
>>>>>> as approval for 8u.
>>>>>>
>>>>>> In brief, the patch makes OpenJDK build with GCC 6 by explicitly
>>>>>> specifying
>>>>>> the C++ standard to use (-std=gnu++98) and disabling two 
>>>>>> optimisations
>>>>>> with
>>>>>> -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further
>>>>>> information
>>>>>> on the changes is available in the GCC 6 release notes [0]. GCC 6 
>>>>>> uses
>>>>>> a newer C++ standard, C++14, with which the OpenJDK codebase is 
>>>>>> not yet
>>>>>> compliant. The simplest way to fix this, especially for existing
>>>>>> releases,
>>>>>> is to explicitly request the previous default, gnu++98. The deletion
>>>>>> of null pointer checks and more aggressive lifetime dead store
>>>>>> elimination
>>>>>> in 6 lead to a crashing virtual machine being built, so we 
>>>>>> disable them
>>>>>> if GCC >= 6 is used.
>>>>>>
>>>>>> To make the original patch work with 8u, a number of changes from 
>>>>>> other
>>>>>> fixes had to also be brought over:
>>>>>>
>>>>>> * We need to check we are using GCC 6 or above, so we need to bring
>>>>>> over the TOOLCHAIN_CHECK_COMPILER_VERSION and
>>>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647.
>>>>>> TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional
>>>>>> numbered rather than named argument macro so we don't need to 
>>>>>> backport
>>>>>> BASIC_DEFUN_NAMED.
>>>>>> * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 
>>>>>> 8030245
>>>>>> as we need to apply the -std option only to the C++ compiler, not 
>>>>>> the
>>>>>> C compiler. If passed to the C compiler, it will produce a warning,
>>>>>> and this is converted to an error at one point in the build
>>>>>> (a -Werror in libsctp).
>>>>>>
>>>>>> Generally, we've kept things in toolchain.m4 (8034788 introduced
>>>>>> flags.m4,
>>>>>> separating out some code, and so many of these changes are in 
>>>>>> that file
>>>>>> in 9) and avoid named argument macros. Otherwise, it's largely the
>>>>>> same as the 9 version. We have adopted the longer name for
>>>>>> the -fno-delete-null-pointer-checks flag variable as suggested in 
>>>>>> the
>>>>>> review of the update to this patch for the new HotSpot build [1].
>>>>>>
>>>>>> [0] https://gcc.gnu.org/gcc-6/porting_to.html
>>>>>> [1]
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html 
>>>>>>
>>>>>
>>>> -- 
>>>> Andrew :)
>>>>
>>>> Senior Free Java Software Engineer
>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>
>>>> PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
>>>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>>>
>>>>
>>>>
>>
>


From volker.simonis at gmail.com  Tue Aug  2 19:47:45 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 2 Aug 2016 21:47:45 +0200
Subject: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com>
References: <CA+3eh11nxD1Dn7Bo=WHwnstFUG4=OM3Yuj7hf-St9=QDKbTNhw@mail.gmail.com>
	<CA+3eh11HpG3FjaebVOu9P5XG7nZyCE5ZNLRRTWjr6dom6cW6_w@mail.gmail.com>
	<5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com>
Message-ID: <CA+3eh10uxCFpJ_j4A4EdG1hbHYP5MT3mf+gQwPd2VUDvpxFMVA@mail.gmail.com>

Hi Sean,

thanks a lot for your reply.

You're right - I'm still waiting for a review of the hotspot part. Any
volunteers :)

Regarding the noreg label: I used 'noreg-other' because there already
exist AES tests (they have never been part of this original change).
Is that the right label? There are simply too many different noreg
labels without documentation so if I selected the wrong one, please
advice which one to choose.

Thanks,
Volker


On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> Volker,
>
> Have the jdk8u hotspot edits been reviewed ? Looks like they should be.
>
> Can you add a suitable noreg label to the master bug report also.
>
> Regards,
> Sean.
>
>
> On 29/07/2016 19:58, Volker Simonis wrote:
>>
>> Ping!
>>
>> Can I please have an approval for backporting this change to 8u-dev?
>>
>> Thanks,
>> Volker
>>
>>
>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> could you please approve the backport of the following, mostly ppc64
>>> change to jdk8u-dev:
>>>
>>> 8152172: PPC64: Support AES intrinsics
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>> Review:
>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>>
>>> As you can see, the change consists of two parts - the main one in the
>>> hotpsot repo and a small part in the jdk repo.
>>>
>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>> shuffling).
>>>
>>> The hotspot part required a small tweak, but only in the ppc-only
>>> part. This is because the feature detection for the AES instructions
>>> was already active in jdk9 when the original change was made but is
>>> not available in jdk8u until now. You can find the additional changes
>>> at the end of this mail for your convenience.
>>>
>>> The required shared changes cleanly apply to jdk8u.
>>>
>>> As Vladimir pointed out in a previous thread, shared Hotspot changes
>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
>>> that and synchronously push both parts.
>>>
>>> @Hiroshii: could you please verify that you are fine with the change?
>>> I've done some tests on Power8LE but just want to be sure this
>>> downport satisfies your needs as well.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> =====================
>>>
>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700
>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200
>>> @@ -452,6 +476,7 @@
>>>     a->popcntw(R7, R5);                          // code[7] -> popcntw
>>>     a->fcfids(F3, F4);                           // code[8] -> fcfids
>>>     a->vand(VR0, VR0, VR0);                      // code[9] -> vand
>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] -> vcipher
>>>     a->blr();
>>>
>>>     // Emit function to set one cache line to zero. Emit function
>>> descriptor and get pointer to it.
>>> @@ -495,6 +520,7 @@
>>>     if (code[feature_cntr++]) features |= popcntw_m;
>>>     if (code[feature_cntr++]) features |= fcfids_m;
>>>     if (code[feature_cntr++]) features |= vand_m;
>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>
>>>     // Print the detection code.
>>>     if (PrintAssembly) {
>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700
>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200
>>> @@ -42,6 +42,7 @@
>>>       fcfids,
>>>       vand,
>>>       dcba,
>>> +    vcipher,
>>>       num_features // last entry to count features
>>>     };
>>>     enum Feature_Flag_Set {
>>> @@ -56,6 +57,7 @@
>>>       fcfids_m              = (1 << fcfids ),
>>>       vand_m                = (1 << vand   ),
>>>       dcba_m                = (1 << dcba   ),
>>> +    vcipher_m             = (1 << vcipher),
>>>       all_features_m        = -1
>>>     };
>>>     static int  _features;
>>> @@ -83,6 +85,7 @@
>>>     static bool has_fcfids()  { return (_features & fcfids_m) != 0; }
>>>     static bool has_vand()    { return (_features & vand_m) != 0; }
>>>     static bool has_dcba()    { return (_features & dcba_m) != 0; }
>>> +  static bool has_vcipher() { return (_features & vcipher_m) != 0; }
>>>
>>>     static const char* cpu_features() { return _features_str; }
>
>

From sean.coffey at oracle.com  Wed Aug  3 11:32:01 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 3 Aug 2016 12:32:01 +0100
Subject: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <CA+3eh10uxCFpJ_j4A4EdG1hbHYP5MT3mf+gQwPd2VUDvpxFMVA@mail.gmail.com>
References: <CA+3eh11nxD1Dn7Bo=WHwnstFUG4=OM3Yuj7hf-St9=QDKbTNhw@mail.gmail.com>
	<CA+3eh11HpG3FjaebVOu9P5XG7nZyCE5ZNLRRTWjr6dom6cW6_w@mail.gmail.com>
	<5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com>
	<CA+3eh10uxCFpJ_j4A4EdG1hbHYP5MT3mf+gQwPd2VUDvpxFMVA@mail.gmail.com>
Message-ID: <57A1D631.10500@oracle.com>

On 02/08/16 20:47, Volker Simonis wrote:
> Hi Sean,
>
> thanks a lot for your reply.
>
> You're right - I'm still waiting for a review of the hotspot part. Any
> volunteers :)
OK - would be good to get a hotspot reviewer to look at those first.
>
> Regarding the noreg label: I used 'noreg-other' because there already
> exist AES tests (they have never been part of this original change).
> Is that the right label? There are simply too many different noreg
> labels without documentation so if I selected the wrong one, please
> advice which one to choose.
noreg labels are documented at : 
http://openjdk.java.net/guide/changePlanning.html#noreg
noreg-other seems fine. You might want to add a short comment to bug 
outlining your comment on existing AES tests.

regards,
Sean.
>
> Thanks,
> Volker
>
>
> On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>> Volker,
>>
>> Have the jdk8u hotspot edits been reviewed ? Looks like they should be.
>>
>> Can you add a suitable noreg label to the master bug report also.
>>
>> Regards,
>> Sean.
>>
>>
>> On 29/07/2016 19:58, Volker Simonis wrote:
>>> Ping!
>>>
>>> Can I please have an approval for backporting this change to 8u-dev?
>>>
>>> Thanks,
>>> Volker
>>>
>>>
>>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> could you please approve the backport of the following, mostly ppc64
>>>> change to jdk8u-dev:
>>>>
>>>> 8152172: PPC64: Support AES intrinsics
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>>> Review:
>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>>>
>>>> As you can see, the change consists of two parts - the main one in the
>>>> hotpsot repo and a small part in the jdk repo.
>>>>
>>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>>> shuffling).
>>>>
>>>> The hotspot part required a small tweak, but only in the ppc-only
>>>> part. This is because the feature detection for the AES instructions
>>>> was already active in jdk9 when the original change was made but is
>>>> not available in jdk8u until now. You can find the additional changes
>>>> at the end of this mail for your convenience.
>>>>
>>>> The required shared changes cleanly apply to jdk8u.
>>>>
>>>> As Vladimir pointed out in a previous thread, shared Hotspot changes
>>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
>>>> that and synchronously push both parts.
>>>>
>>>> @Hiroshii: could you please verify that you are fine with the change?
>>>> I've done some tests on Power8LE but just want to be sure this
>>>> downport satisfies your needs as well.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>> =====================
>>>>
>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700
>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200
>>>> @@ -452,6 +476,7 @@
>>>>      a->popcntw(R7, R5);                          // code[7] -> popcntw
>>>>      a->fcfids(F3, F4);                           // code[8] -> fcfids
>>>>      a->vand(VR0, VR0, VR0);                      // code[9] -> vand
>>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] -> vcipher
>>>>      a->blr();
>>>>
>>>>      // Emit function to set one cache line to zero. Emit function
>>>> descriptor and get pointer to it.
>>>> @@ -495,6 +520,7 @@
>>>>      if (code[feature_cntr++]) features |= popcntw_m;
>>>>      if (code[feature_cntr++]) features |= fcfids_m;
>>>>      if (code[feature_cntr++]) features |= vand_m;
>>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>>
>>>>      // Print the detection code.
>>>>      if (PrintAssembly) {
>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700
>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200
>>>> @@ -42,6 +42,7 @@
>>>>        fcfids,
>>>>        vand,
>>>>        dcba,
>>>> +    vcipher,
>>>>        num_features // last entry to count features
>>>>      };
>>>>      enum Feature_Flag_Set {
>>>> @@ -56,6 +57,7 @@
>>>>        fcfids_m              = (1 << fcfids ),
>>>>        vand_m                = (1 << vand   ),
>>>>        dcba_m                = (1 << dcba   ),
>>>> +    vcipher_m             = (1 << vcipher),
>>>>        all_features_m        = -1
>>>>      };
>>>>      static int  _features;
>>>> @@ -83,6 +85,7 @@
>>>>      static bool has_fcfids()  { return (_features & fcfids_m) != 0; }
>>>>      static bool has_vand()    { return (_features & vand_m) != 0; }
>>>>      static bool has_dcba()    { return (_features & dcba_m) != 0; }
>>>> +  static bool has_vcipher() { return (_features & vcipher_m) != 0; }
>>>>
>>>>      static const char* cpu_features() { return _features_str; }
>>


From rob.mckenna at oracle.com  Wed Aug  3 13:20:25 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 3 Aug 2016 14:20:25 +0100
Subject: Proposal for Direct-X-Buffer change to improve allocation of
	zero capacity buffers
In-Reply-To: <CALR2BPZDCF54+Rmsmq4xAuaMy5DffZLwPsWOBW0dCN18gODrkw@mail.gmail.com>
References: <CALR2BPZDCF54+Rmsmq4xAuaMy5DffZLwPsWOBW0dCN18gODrkw@mail.gmail.com>
Message-ID: <20160803132025.GA3414@vimes>

Hi Jon,

I think nio-dev at openjdk.java.net would be a more appropriate venue for this discussion.

	-Rob

On 01/08/16 12:24, Jon V. wrote:
> The Direct Buffer does not optimize the allocation of zero capacity
> buffers.  I am proposing a simple if( cap != 0 )  condition that will
> bypass most of the setup process.
> 
> Here is the current constructor:
> 
>     Direct$Type$Buffer$RW$(int cap) {                   // package-private
> #if[rw]
>         super(-1, 0, cap, cap);
>         boolean pa = VM.isDirectMemoryPageAligned();
>         int ps = Bits.pageSize();
>         long size = Math.max(1L, (long)cap + (pa ? ps : 0));
>         Bits.reserveMemory(size, cap);
> 
>         long base = 0;
>         try {
>             base = unsafe.allocateMemory(size);
>         } catch (OutOfMemoryError x) {
>             Bits.unreserveMemory(size, cap);
>             throw x;
>         }
>         unsafe.setMemory(base, size, (byte) 0);
>         if (pa && (base % ps != 0)) {
>             // Round up to page boundary
>             address = base + ps - (base & (ps - 1));
>         } else {
>             address = base;
>         }
>         cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
>         att = null;
> #else[rw]
>         super(cap);
> #end[rw]
>     }

From svetlana.nikandrova at oracle.com  Wed Aug  3 16:37:13 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Wed, 03 Aug 2016 19:37:13 +0300
Subject: [8u-dev] Request for Approval 8035158: Remove dependency on
	sun.misc.RegexpPool and friends
Message-ID: <57A21DB9.8040403@oracle.com>

Hello,

please approve the direct backport to jdk 8. Applied cleanly.
Motivation:
While dependency refactoring a number of issues applicable to jdk 8 were 
fixed (please see review for further details).

JBS:
https://bugs.openjdk.java.net/browse/JDK-8035158
Review:
http://mail.openjdk.java.net/pipermail/net-dev/2014-March/008332.html
JDK 9 changeset:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade

JPRT tested.

Thank you,
Svetlana

From shafi.s.ahmad at oracle.com  Thu Aug  4 06:25:13 2016
From: shafi.s.ahmad at oracle.com (Shafi Ahmad)
Date: Wed, 3 Aug 2016 23:25:13 -0700 (PDT)
Subject: [8u] RFA for JDK-8161144: Fix for JDK-8147451 failed: Crash in
	Method::checked_resolve_jmethod_id(_jmethodID*)
Message-ID: <2def9514-e001-4cb7-9cd2-fac7807e9860@default>

Hi,

Please approve the code change for bug '' JDK-8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) " to jdk8u-dev

Jdk8 Bug: https://bugs.openjdk.java.net/browse/JDK-8161144
Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-August/020530.html
Webrev link: http://cr.openjdk.java.net/~shshahma/8161144/webrev.02/

Regards,
Shafi

From david.buck at oracle.com  Thu Aug  4 06:42:03 2016
From: david.buck at oracle.com (david buck)
Date: Thu, 4 Aug 2016 15:42:03 +0900
Subject: [8u] RFA for JDK-8161144: Fix for JDK-8147451 failed: Crash in
	Method::checked_resolve_jmethod_id(_jmethodID*)
In-Reply-To: <2def9514-e001-4cb7-9cd2-fac7807e9860@default>
References: <2def9514-e001-4cb7-9cd2-fac7807e9860@default>
Message-ID: <671211c7-736e-1e73-cdfc-75651c93b407@oracle.com>

approved for push to 8u-dev

Cheers,
-Buck

On 2016/08/04 15:25, Shafi Ahmad wrote:
> Hi,
>
> Please approve the code change for bug '' JDK-8161144: Fix for JDK-8147451 failed: Crash in Method::checked_resolve_jmethod_id(_jmethodID*) " to jdk8u-dev
>
> Jdk8 Bug: https://bugs.openjdk.java.net/browse/JDK-8161144
> Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-August/020530.html
> Webrev link: http://cr.openjdk.java.net/~shshahma/8161144/webrev.02/
>
> Regards,
> Shafi
>

From christoph.langer at sap.com  Thu Aug  4 08:49:35 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 4 Aug 2016 08:49:35 +0000
Subject: [8u-dev] Request for approval: 8158023: SocketExceptions contain too
	little information sometimes
Message-ID: <a070fdf1fae14ec0a3d195317199d6ff@DEWDFE13DE11.global.corp.sap>

Hi,



can I get approval for backporting the following fix:



Original Bug: https://bugs.openjdk.java.net/browse/JDK-8158023

Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b88eb2f451d

Jdk9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041677.html



I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev. This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.8udev/



Thanks a lot and Best regards,

Christoph







From sean.coffey at oracle.com  Thu Aug  4 10:27:58 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 4 Aug 2016 11:27:58 +0100
Subject: [8u-dev] Request for approval: 8158023: SocketExceptions contain
	too little information sometimes
In-Reply-To: <a070fdf1fae14ec0a3d195317199d6ff@DEWDFE13DE11.global.corp.sap>
References: <a070fdf1fae14ec0a3d195317199d6ff@DEWDFE13DE11.global.corp.sap>
Message-ID: <6fd4732a-e0c0-382e-6d84-d41528d0079b@oracle.com>

Looks fine. Approved for jdk8u-dev. Please add a suitable noreg label to 
the master bug record :

http://openjdk.java.net/guide/changePlanning.html#noreg

Regards,
Sean.

On 04/08/2016 09:49, Langer, Christoph wrote:
> Hi,
>
>
>
> can I get approval for backporting the following fix:
>
>
>
> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8158023
>
> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b88eb2f451d
>
> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041677.html
>
>
>
> I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev. This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.8udev/
>
>
>
> Thanks a lot and Best regards,
>
> Christoph
>
>
>
>
>
>


From manuelag2004 at yahoo.co.uk  Fri Aug  5 12:41:15 2016
From: manuelag2004 at yahoo.co.uk (Manuela Grindei)
Date: Fri, 5 Aug 2016 12:41:15 +0000 (UTC)
Subject: 8154066:  Exclude test
	java/util/logging/TestLogConfigurationDeadLockWithConf.java from
	execution on compact profiles 1 and 2
References: <126184592.17233260.1470400875923.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <126184592.17233260.1470400875923.JavaMail.yahoo@mail.yahoo.com>

Hi everyone,
I'm a new OpenJDK contributor, ready for my first task.? 
I would like to fix JDK-8154066 and I think it can be done by a small change in the list of tests under needs_compact3 from TEST.groups. I intend to create a patch with the fix, please let me know if you have any objections.
Best wishes,
Manuela Grindei

From sean.coffey at oracle.com  Fri Aug  5 14:41:34 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 5 Aug 2016 15:41:34 +0100
Subject: 8154066: Exclude test
	java/util/logging/TestLogConfigurationDeadLockWithConf.java from
	execution on compact profiles 1 and 2
In-Reply-To: <126184592.17233260.1470400875923.JavaMail.yahoo@mail.yahoo.com>
References: <126184592.17233260.1470400875923.JavaMail.yahoo.ref@mail.yahoo.com>
	<126184592.17233260.1470400875923.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <57A4A59E.1060001@oracle.com>

Hi Manuela,

Welcome to OpenJDK. I don't foresee any issues with you taking ownership 
of that test bug. Please ensure you can reproduce the issue before 
tackling it. I can assign it to myself while you create the patch.

More help on how to contribute to OpenJDK is available from : 
http://openjdk.java.net/contribute/

Regards,
Sean.

On 05/08/16 13:41, Manuela Grindei wrote:
> Hi everyone,
> I'm a new OpenJDK contributor, ready for my first task.
> I would like to fix JDK-8154066 and I think it can be done by a small change in the list of tests under needs_compact3 from TEST.groups. I intend to create a patch with the fix, please let me know if you have any objections.
> Best wishes,
> Manuela Grindei


From gnu.andrew at redhat.com  Fri Aug  5 15:12:22 2016
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 5 Aug 2016 11:12:22 -0400 (EDT)
Subject: PING: [8u112] Request for review & approval for CR8151841:
	Build needs additional flags to compile with GCC 6
In-Reply-To: <c0c6400b-0043-e014-5f8c-292e40bb3abf@oracle.com>
References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com>
	<577F4C58.6060101@oracle.com>
	<1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com>
	<788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com>
	<75eba245-b501-6567-445c-836fa7fc3885@oracle.com>
	<c0c6400b-0043-e014-5f8c-292e40bb3abf@oracle.com>
Message-ID: <247448866.1378063.1470409942851.JavaMail.zimbra@redhat.com>



----- Original Message -----
> I'm seeing this patch fail across all platforms on internal builds.
> Please hold off any push for now. Maybe other config changes are needed
> on our build systems.
> 
> e.g.
> 
> > /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC
> > \
> >                      -m64 -G -KPIC     \
> > 	           -I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc
> > 	           \
> > 	           -I../generated                                       \
> > 	           -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include
> > 	           \
> > 	           -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris
> > 	           \
> > 	                                     \
> > 	           /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp
> > 	           \
> > 	           sadis.o                                          \
> > 	           -M
> > 	           /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile
> > 	           -mt -xnolib -norunpath
> > 	           \
> > 	           -o libsaproc.so
> > 	           \
> > 	           -ldl -ldemangle -lthread -lc
> > ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such
> > file or directory
> > ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or
> > directory
> > ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory
> > ld: fatal: file processing errors. No output written to
> > libgenerateJvmOffsets.so
> > gmake[6]: *** [libgenerateJvmOffsets.so] Error 1
> > gmake[6]: *** Waiting for unfinished jobs....
> > gmake[6]: Leaving directory
> > `/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product'
> > gmake[5]: *** [the_vm] Error 2
> 

It needs to be pushed by someone at Oracle anyway, so your internal
configure can be updated.

I think that might be the problem here. @CXXSTD_CXXFLAG@ and friends
should be substituted by configure with either the flag or the empty
string, so something is going wrong earlier with the configure stage.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222



From sergei.kovalev at oracle.com  Fri Aug  5 15:19:25 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Fri, 5 Aug 2016 18:19:25 +0300
Subject: 8154066: Exclude test
	java/util/logging/TestLogConfigurationDeadLockWithConf.java from
	execution on compact profiles 1 and 2
In-Reply-To: <126184592.17233260.1470400875923.JavaMail.yahoo@mail.yahoo.com>
References: <126184592.17233260.1470400875923.JavaMail.yahoo.ref@mail.yahoo.com>
	<126184592.17233260.1470400875923.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <282877b5-3526-d2d5-5606-0563c061adde@oracle.com>

Welcome Manuela,

The group you mentioned is legacy from JDK8. For JDK9 you'd better use 
other approach. Issues like "unable run on compact profile" for JDK9 
should be fixed by adding "@requires module" tag in case there is no way 
to re-write the test without missed classes.


05.08.16 15:41, Manuela Grindei wrote:
> Hi everyone,
> I'm a new OpenJDK contributor, ready for my first task.
> I would like to fix JDK-8154066 and I think it can be done by a small change in the list of tests under needs_compact3 from TEST.groups. I intend to create a patch with the fix, please let me know if you have any objections.
> Best wishes,
> Manuela Grindei

-- 
With best regards,
Sergei


From vadim.pakhnushev at oracle.com  Mon Aug  8 12:07:31 2016
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Mon, 8 Aug 2016 15:07:31 +0300
Subject: [8u122] Request for approval for 8149714, 8161733, 8161742, 8161761
Message-ID: <57ceeaf4-2f84-ae05-d552-502f05a47b54@oracle.com>

Hello,

Please approve these 4 clean backports.
Reviews for these fixes were done internally.

8149714: [parfait] char array lengths don't match in awt_Font.cpp:1701
https://bugs.openjdk.java.net/browse/JDK-8149714
http://hg.openjdk.java.net/jdk9/client/jdk/rev/dfec431427f9

8161733: [parfait] Memory leak in imageioJPEG.c:2803
https://bugs.openjdk.java.net/browse/JDK-8161733
http://hg.openjdk.java.net/jdk9/client/jdk/rev/f7cb006b293a

8161742: [parfait] Uninitialised memory in isXTestAvailable of 
awt_Robot.c:65
https://bugs.openjdk.java.net/browse/JDK-8161742
http://hg.openjdk.java.net/jdk9/client/jdk/rev/ee42ccb4ab68

8161761: [parfait] 2 JNI exception pending defect groups in 
GraphicsPrimitiveMgr.c
https://bugs.openjdk.java.net/browse/JDK-8161761
http://hg.openjdk.java.net/jdk9/client/jdk/rev/42f457587791

Thanks,
Vadim

From volker.simonis at gmail.com  Mon Aug  8 13:43:08 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 8 Aug 2016 15:43:08 +0200
Subject: Ping: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
Message-ID: <CA+3eh10Fhjt=ZOx31E_-yfwtj124sXFV31je5hSG5cA-Hx19Ew@mail.gmail.com>

Ping...

Can I please get a review for this downport. The shared changes all
cleanly apply to jdk8, only the ppc64 part required a small tweak (see
intial mail).

Thanks,
Volker

On Wed, Aug 3, 2016 at 1:32 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> On 02/08/16 20:47, Volker Simonis wrote:
>>
>> Hi Sean,
>>
>> thanks a lot for your reply.
>>
>> You're right - I'm still waiting for a review of the hotspot part. Any
>> volunteers :)
>
> OK - would be good to get a hotspot reviewer to look at those first.
>>
>>
>> Regarding the noreg label: I used 'noreg-other' because there already
>> exist AES tests (they have never been part of this original change).
>> Is that the right label? There are simply too many different noreg
>> labels without documentation so if I selected the wrong one, please
>> advice which one to choose.
>
> noreg labels are documented at :
> http://openjdk.java.net/guide/changePlanning.html#noreg
> noreg-other seems fine. You might want to add a short comment to bug
> outlining your comment on existing AES tests.
>
> regards,
> Sean.
>
>>
>> Thanks,
>> Volker
>>
>>
>> On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey <sean.coffey at oracle.com>
>> wrote:
>>>
>>> Volker,
>>>
>>> Have the jdk8u hotspot edits been reviewed ? Looks like they should be.
>>>
>>> Can you add a suitable noreg label to the master bug report also.
>>>
>>> Regards,
>>> Sean.
>>>
>>>
>>> On 29/07/2016 19:58, Volker Simonis wrote:
>>>>
>>>> Ping!
>>>>
>>>> Can I please have an approval for backporting this change to 8u-dev?
>>>>
>>>> Thanks,
>>>> Volker
>>>>
>>>>
>>>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>>>> <volker.simonis at gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> could you please approve the backport of the following, mostly ppc64
>>>>> change to jdk8u-dev:
>>>>>
>>>>> 8152172: PPC64: Support AES intrinsics
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>>>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>>>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>>>> Review:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>>>>
>>>>> As you can see, the change consists of two parts - the main one in the
>>>>> hotpsot repo and a small part in the jdk repo.
>>>>>
>>>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>>>> shuffling).
>>>>>
>>>>> The hotspot part required a small tweak, but only in the ppc-only
>>>>> part. This is because the feature detection for the AES instructions
>>>>> was already active in jdk9 when the original change was made but is
>>>>> not available in jdk8u until now. You can find the additional changes
>>>>> at the end of this mail for your convenience.
>>>>>
>>>>> The required shared changes cleanly apply to jdk8u.
>>>>>
>>>>> As Vladimir pointed out in a previous thread, shared Hotspot changes
>>>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
>>>>> that and synchronously push both parts.
>>>>>
>>>>> @Hiroshii: could you please verify that you are fine with the change?
>>>>> I've done some tests on Power8LE but just want to be sure this
>>>>> downport satisfies your needs as well.
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>> =====================
>>>>>
>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700
>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200
>>>>> @@ -452,6 +476,7 @@
>>>>>      a->popcntw(R7, R5);                          // code[7] -> popcntw
>>>>>      a->fcfids(F3, F4);                           // code[8] -> fcfids
>>>>>      a->vand(VR0, VR0, VR0);                      // code[9] -> vand
>>>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] -> vcipher
>>>>>      a->blr();
>>>>>
>>>>>      // Emit function to set one cache line to zero. Emit function
>>>>> descriptor and get pointer to it.
>>>>> @@ -495,6 +520,7 @@
>>>>>      if (code[feature_cntr++]) features |= popcntw_m;
>>>>>      if (code[feature_cntr++]) features |= fcfids_m;
>>>>>      if (code[feature_cntr++]) features |= vand_m;
>>>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>>>
>>>>>      // Print the detection code.
>>>>>      if (PrintAssembly) {
>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700
>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200
>>>>> @@ -42,6 +42,7 @@
>>>>>        fcfids,
>>>>>        vand,
>>>>>        dcba,
>>>>> +    vcipher,
>>>>>        num_features // last entry to count features
>>>>>      };
>>>>>      enum Feature_Flag_Set {
>>>>> @@ -56,6 +57,7 @@
>>>>>        fcfids_m              = (1 << fcfids ),
>>>>>        vand_m                = (1 << vand   ),
>>>>>        dcba_m                = (1 << dcba   ),
>>>>> +    vcipher_m             = (1 << vcipher),
>>>>>        all_features_m        = -1
>>>>>      };
>>>>>      static int  _features;
>>>>> @@ -83,6 +85,7 @@
>>>>>      static bool has_fcfids()  { return (_features & fcfids_m) != 0; }
>>>>>      static bool has_vand()    { return (_features & vand_m) != 0; }
>>>>>      static bool has_dcba()    { return (_features & dcba_m) != 0; }
>>>>> +  static bool has_vcipher() { return (_features & vcipher_m) != 0; }
>>>>>
>>>>>      static const char* cpu_features() { return _features_str; }
>>>
>>>
>

From rob.mckenna at oracle.com  Mon Aug  8 13:57:12 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 8 Aug 2016 14:57:12 +0100
Subject: [8u122] Request for approval for 8149714, 8161733, 8161742,
	8161761
In-Reply-To: <57ceeaf4-2f84-ae05-d552-502f05a47b54@oracle.com>
References: <57ceeaf4-2f84-ae05-d552-502f05a47b54@oracle.com>
Message-ID: <20160808135712.GA3708@vimes>

Approved - please add an appropriate noreg label to each.

	-Rob

On 08/08/16 03:07, Vadim Pakhnushev wrote:
> Hello,
> 
> Please approve these 4 clean backports.
> Reviews for these fixes were done internally.
> 
> 8149714: [parfait] char array lengths don't match in awt_Font.cpp:1701
> https://bugs.openjdk.java.net/browse/JDK-8149714
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/dfec431427f9
> 
> 8161733: [parfait] Memory leak in imageioJPEG.c:2803
> https://bugs.openjdk.java.net/browse/JDK-8161733
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/f7cb006b293a
> 
> 8161742: [parfait] Uninitialised memory in isXTestAvailable of
> awt_Robot.c:65
> https://bugs.openjdk.java.net/browse/JDK-8161742
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ee42ccb4ab68
> 
> 8161761: [parfait] 2 JNI exception pending defect groups in
> GraphicsPrimitiveMgr.c
> https://bugs.openjdk.java.net/browse/JDK-8161761
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/42f457587791
> 
> Thanks,
> Vadim

From rob.mckenna at oracle.com  Mon Aug  8 15:46:57 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 8 Aug 2016 16:46:57 +0100
Subject: [8u-dev] Request for Approval 8035158: Remove dependency on
	sun.misc.RegexpPool and friends
In-Reply-To: <57A21DB9.8040403@oracle.com>
References: <57A21DB9.8040403@oracle.com>
Message-ID: <20160808154657.GC3708@vimes>

Approved

	-Rob

On 03/08/16 07:37, Svetlana Nikandrova wrote:
> Hello,
> 
> please approve the direct backport to jdk 8. Applied cleanly.
> Motivation:
> While dependency refactoring a number of issues applicable to jdk 8 were
> fixed (please see review for further details).
> 
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8035158
> Review:
> http://mail.openjdk.java.net/pipermail/net-dev/2014-March/008332.html
> JDK 9 changeset:
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50a749f2cade
> 
> JPRT tested.
> 
> Thank you,
> Svetlana

From zoltan.majo at oracle.com  Tue Aug  9 09:03:31 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Tue, 9 Aug 2016 11:03:31 +0200
Subject: Ping: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <CA+3eh10Fhjt=ZOx31E_-yfwtj124sXFV31je5hSG5cA-Hx19Ew@mail.gmail.com>
References: <CA+3eh10Fhjt=ZOx31E_-yfwtj124sXFV31je5hSG5cA-Hx19Ew@mail.gmail.com>
Message-ID: <3129351f-9ba0-7c60-77fd-291479ca80fd@oracle.com>

Hi Volker,


On 08/08/2016 03:43 PM, Volker Simonis wrote:
> Ping...
>
> Can I please get a review for this downport. The shared changes all
> cleanly apply to jdk8, only the ppc64 part required a small tweak (see
> intial mail).

you changes look good for me. I can sponsor the changes, if you want.

Thank you and best regards,


Zoltan

>
> Thanks,
> Volker
>
> On Wed, Aug 3, 2016 at 1:32 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>> On 02/08/16 20:47, Volker Simonis wrote:
>>> Hi Sean,
>>>
>>> thanks a lot for your reply.
>>>
>>> You're right - I'm still waiting for a review of the hotspot part. Any
>>> volunteers :)
>> OK - would be good to get a hotspot reviewer to look at those first.
>>>
>>> Regarding the noreg label: I used 'noreg-other' because there already
>>> exist AES tests (they have never been part of this original change).
>>> Is that the right label? There are simply too many different noreg
>>> labels without documentation so if I selected the wrong one, please
>>> advice which one to choose.
>> noreg labels are documented at :
>> http://openjdk.java.net/guide/changePlanning.html#noreg
>> noreg-other seems fine. You might want to add a short comment to bug
>> outlining your comment on existing AES tests.
>>
>> regards,
>> Sean.
>>
>>> Thanks,
>>> Volker
>>>
>>>
>>> On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey <sean.coffey at oracle.com>
>>> wrote:
>>>> Volker,
>>>>
>>>> Have the jdk8u hotspot edits been reviewed ? Looks like they should be.
>>>>
>>>> Can you add a suitable noreg label to the master bug report also.
>>>>
>>>> Regards,
>>>> Sean.
>>>>
>>>>
>>>> On 29/07/2016 19:58, Volker Simonis wrote:
>>>>> Ping!
>>>>>
>>>>> Can I please have an approval for backporting this change to 8u-dev?
>>>>>
>>>>> Thanks,
>>>>> Volker
>>>>>
>>>>>
>>>>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>>>>> <volker.simonis at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> could you please approve the backport of the following, mostly ppc64
>>>>>> change to jdk8u-dev:
>>>>>>
>>>>>> 8152172: PPC64: Support AES intrinsics
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>>>>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>>>>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>>>>> Review:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>>>>>
>>>>>> As you can see, the change consists of two parts - the main one in the
>>>>>> hotpsot repo and a small part in the jdk repo.
>>>>>>
>>>>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>>>>> shuffling).
>>>>>>
>>>>>> The hotspot part required a small tweak, but only in the ppc-only
>>>>>> part. This is because the feature detection for the AES instructions
>>>>>> was already active in jdk9 when the original change was made but is
>>>>>> not available in jdk8u until now. You can find the additional changes
>>>>>> at the end of this mail for your convenience.
>>>>>>
>>>>>> The required shared changes cleanly apply to jdk8u.
>>>>>>
>>>>>> As Vladimir pointed out in a previous thread, shared Hotspot changes
>>>>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
>>>>>> that and synchronously push both parts.
>>>>>>
>>>>>> @Hiroshii: could you please verify that you are fine with the change?
>>>>>> I've done some tests on Power8LE but just want to be sure this
>>>>>> downport satisfies your needs as well.
>>>>>>
>>>>>> Thank you and best regards,
>>>>>> Volker
>>>>>>
>>>>>> =====================
>>>>>>
>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700
>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200
>>>>>> @@ -452,6 +476,7 @@
>>>>>>       a->popcntw(R7, R5);                          // code[7] -> popcntw
>>>>>>       a->fcfids(F3, F4);                           // code[8] -> fcfids
>>>>>>       a->vand(VR0, VR0, VR0);                      // code[9] -> vand
>>>>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] -> vcipher
>>>>>>       a->blr();
>>>>>>
>>>>>>       // Emit function to set one cache line to zero. Emit function
>>>>>> descriptor and get pointer to it.
>>>>>> @@ -495,6 +520,7 @@
>>>>>>       if (code[feature_cntr++]) features |= popcntw_m;
>>>>>>       if (code[feature_cntr++]) features |= fcfids_m;
>>>>>>       if (code[feature_cntr++]) features |= vand_m;
>>>>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>>>>
>>>>>>       // Print the detection code.
>>>>>>       if (PrintAssembly) {
>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700
>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200
>>>>>> @@ -42,6 +42,7 @@
>>>>>>         fcfids,
>>>>>>         vand,
>>>>>>         dcba,
>>>>>> +    vcipher,
>>>>>>         num_features // last entry to count features
>>>>>>       };
>>>>>>       enum Feature_Flag_Set {
>>>>>> @@ -56,6 +57,7 @@
>>>>>>         fcfids_m              = (1 << fcfids ),
>>>>>>         vand_m                = (1 << vand   ),
>>>>>>         dcba_m                = (1 << dcba   ),
>>>>>> +    vcipher_m             = (1 << vcipher),
>>>>>>         all_features_m        = -1
>>>>>>       };
>>>>>>       static int  _features;
>>>>>> @@ -83,6 +85,7 @@
>>>>>>       static bool has_fcfids()  { return (_features & fcfids_m) != 0; }
>>>>>>       static bool has_vand()    { return (_features & vand_m) != 0; }
>>>>>>       static bool has_dcba()    { return (_features & dcba_m) != 0; }
>>>>>> +  static bool has_vcipher() { return (_features & vcipher_m) != 0; }
>>>>>>
>>>>>>       static const char* cpu_features() { return _features_str; }
>>>>


From volker.simonis at gmail.com  Tue Aug  9 15:48:52 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 9 Aug 2016 17:48:52 +0200
Subject: Ping: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <3129351f-9ba0-7c60-77fd-291479ca80fd@oracle.com>
References: <CA+3eh10Fhjt=ZOx31E_-yfwtj124sXFV31je5hSG5cA-Hx19Ew@mail.gmail.com>
	<3129351f-9ba0-7c60-77fd-291479ca80fd@oracle.com>
Message-ID: <CA+3eh11d8YYhbq9yN77XWbA-=yky=zvmMS2kaL2jL2bbrkCLVw@mail.gmail.com>

On Tue, Aug 9, 2016 at 11:03 AM, Zolt?n Maj? <zoltan.majo at oracle.com> wrote:
> Hi Volker,
>
>
> On 08/08/2016 03:43 PM, Volker Simonis wrote:
>>
>> Ping...
>>
>> Can I please get a review for this downport. The shared changes all
>> cleanly apply to jdk8, only the ppc64 part required a small tweak (see
>> intial mail).
>
>
> you changes look good for me. I can sponsor the changes, if you want.
>

Hi Zoltan,

thanks a lot. That would be really great!
I'm just waiting for the final confirmation from Hiroshi. One he gives
his OK, it would be really nice if you could sponsor the change.

Thanks again,
Volker

> Thank you and best regards,
>
>
> Zoltan
>
>
>>
>> Thanks,
>> Volker
>>
>> On Wed, Aug 3, 2016 at 1:32 PM, Se?n Coffey <sean.coffey at oracle.com>
>> wrote:
>>>
>>> On 02/08/16 20:47, Volker Simonis wrote:
>>>>
>>>> Hi Sean,
>>>>
>>>> thanks a lot for your reply.
>>>>
>>>> You're right - I'm still waiting for a review of the hotspot part. Any
>>>> volunteers :)
>>>
>>> OK - would be good to get a hotspot reviewer to look at those first.
>>>>
>>>>
>>>> Regarding the noreg label: I used 'noreg-other' because there already
>>>> exist AES tests (they have never been part of this original change).
>>>> Is that the right label? There are simply too many different noreg
>>>> labels without documentation so if I selected the wrong one, please
>>>> advice which one to choose.
>>>
>>> noreg labels are documented at :
>>> http://openjdk.java.net/guide/changePlanning.html#noreg
>>> noreg-other seems fine. You might want to add a short comment to bug
>>> outlining your comment on existing AES tests.
>>>
>>> regards,
>>> Sean.
>>>
>>>> Thanks,
>>>> Volker
>>>>
>>>>
>>>> On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey <sean.coffey at oracle.com>
>>>> wrote:
>>>>>
>>>>> Volker,
>>>>>
>>>>> Have the jdk8u hotspot edits been reviewed ? Looks like they should be.
>>>>>
>>>>> Can you add a suitable noreg label to the master bug report also.
>>>>>
>>>>> Regards,
>>>>> Sean.
>>>>>
>>>>>
>>>>> On 29/07/2016 19:58, Volker Simonis wrote:
>>>>>>
>>>>>> Ping!
>>>>>>
>>>>>> Can I please have an approval for backporting this change to 8u-dev?
>>>>>>
>>>>>> Thanks,
>>>>>> Volker
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>>>>>> <volker.simonis at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> could you please approve the backport of the following, mostly ppc64
>>>>>>> change to jdk8u-dev:
>>>>>>>
>>>>>>> 8152172: PPC64: Support AES intrinsics
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>>>>>> Webrev
>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>>>>>> Review:
>>>>>>>
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>>>>>>
>>>>>>> As you can see, the change consists of two parts - the main one in
>>>>>>> the
>>>>>>> hotpsot repo and a small part in the jdk repo.
>>>>>>>
>>>>>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>>>>>> shuffling).
>>>>>>>
>>>>>>> The hotspot part required a small tweak, but only in the ppc-only
>>>>>>> part. This is because the feature detection for the AES instructions
>>>>>>> was already active in jdk9 when the original change was made but is
>>>>>>> not available in jdk8u until now. You can find the additional changes
>>>>>>> at the end of this mail for your convenience.
>>>>>>>
>>>>>>> The required shared changes cleanly apply to jdk8u.
>>>>>>>
>>>>>>> As Vladimir pointed out in a previous thread, shared Hotspot changes
>>>>>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
>>>>>>> that and synchronously push both parts.
>>>>>>>
>>>>>>> @Hiroshii: could you please verify that you are fine with the change?
>>>>>>> I've done some tests on Power8LE but just want to be sure this
>>>>>>> downport satisfies your needs as well.
>>>>>>>
>>>>>>> Thank you and best regards,
>>>>>>> Volker
>>>>>>>
>>>>>>> =====================
>>>>>>>
>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016
>>>>>>> -0700
>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016
>>>>>>> +0200
>>>>>>> @@ -452,6 +476,7 @@
>>>>>>>       a->popcntw(R7, R5);                          // code[7] ->
>>>>>>> popcntw
>>>>>>>       a->fcfids(F3, F4);                           // code[8] ->
>>>>>>> fcfids
>>>>>>>       a->vand(VR0, VR0, VR0);                      // code[9] -> vand
>>>>>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] ->
>>>>>>> vcipher
>>>>>>>       a->blr();
>>>>>>>
>>>>>>>       // Emit function to set one cache line to zero. Emit function
>>>>>>> descriptor and get pointer to it.
>>>>>>> @@ -495,6 +520,7 @@
>>>>>>>       if (code[feature_cntr++]) features |= popcntw_m;
>>>>>>>       if (code[feature_cntr++]) features |= fcfids_m;
>>>>>>>       if (code[feature_cntr++]) features |= vand_m;
>>>>>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>>>>>
>>>>>>>       // Print the detection code.
>>>>>>>       if (PrintAssembly) {
>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016
>>>>>>> -0700
>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016
>>>>>>> +0200
>>>>>>> @@ -42,6 +42,7 @@
>>>>>>>         fcfids,
>>>>>>>         vand,
>>>>>>>         dcba,
>>>>>>> +    vcipher,
>>>>>>>         num_features // last entry to count features
>>>>>>>       };
>>>>>>>       enum Feature_Flag_Set {
>>>>>>> @@ -56,6 +57,7 @@
>>>>>>>         fcfids_m              = (1 << fcfids ),
>>>>>>>         vand_m                = (1 << vand   ),
>>>>>>>         dcba_m                = (1 << dcba   ),
>>>>>>> +    vcipher_m             = (1 << vcipher),
>>>>>>>         all_features_m        = -1
>>>>>>>       };
>>>>>>>       static int  _features;
>>>>>>> @@ -83,6 +85,7 @@
>>>>>>>       static bool has_fcfids()  { return (_features & fcfids_m) != 0;
>>>>>>> }
>>>>>>>       static bool has_vand()    { return (_features & vand_m) != 0; }
>>>>>>>       static bool has_dcba()    { return (_features & dcba_m) != 0; }
>>>>>>> +  static bool has_vcipher() { return (_features & vcipher_m) != 0; }
>>>>>>>
>>>>>>>       static const char* cpu_features() { return _features_str; }
>>>>>
>>>>>
>

From robin.stevens at scz.be  Tue Aug  9 21:22:42 2016
From: robin.stevens at scz.be (Robin Stevens)
Date: Tue, 9 Aug 2016 23:22:42 +0200
Subject: [8u-dev] Request for Approval: Review Request: 8161664: Memory leak
	in com.apple.laf.AquaProgressBarUI: removed progress bar still
	referenced
Message-ID: <CAN4rkZnic_VC6qphCsjyLMZg+6vpqRVCbFQ9Vk94beU+3Men-Q@mail.gmail.com>

Please approve the backport of 8161664 to 8u-dev.

Bug: https://bugs.openjdk.java.net/browse/JDK-8161664
Webrev: http://cr.openjdk.java.net/~rstevens/8161664/webrev.02/
Review thread:
http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006360.html and
http://mail.openjdk.java.net/pipermail/swing-dev/2016-August/006448.html

Changes apply cleanly to jdk8u-dev after path reshuffling.
The only thing that needs to change is to remove the

@key headful

tag in the test, as that seems unknown on JDK8.

Thanks,

Robin

From rob.mckenna at oracle.com  Tue Aug  9 23:06:11 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 10 Aug 2016 00:06:11 +0100
Subject: [8u-dev] Request for Approval: Review Request: 8161664: Memory
	leak in com.apple.laf.AquaProgressBarUI: removed progress bar still
	referenced
In-Reply-To: <CAN4rkZnic_VC6qphCsjyLMZg+6vpqRVCbFQ9Vk94beU+3Men-Q@mail.gmail.com>
References: <CAN4rkZnic_VC6qphCsjyLMZg+6vpqRVCbFQ9Vk94beU+3Men-Q@mail.gmail.com>
Message-ID: <20160809230611.GC7212@vimes>

Approved

	-Rob

On 09/08/16 11:22, Robin Stevens wrote:
> Please approve the backport of 8161664 to 8u-dev.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8161664
> Webrev: http://cr.openjdk.java.net/~rstevens/8161664/webrev.02/
> Review thread:
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-July/006360.html and
> http://mail.openjdk.java.net/pipermail/swing-dev/2016-August/006448.html
> 
> Changes apply cleanly to jdk8u-dev after path reshuffling.
> The only thing that needs to change is to remove the
> 
> @key headful
> 
> tag in the test, as that seems unknown on JDK8.
> 
> Thanks,
> 
> Robin

From volker.simonis at gmail.com  Wed Aug 10 07:40:43 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 10 Aug 2016 09:40:43 +0200
Subject: Ping: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <OFADDBC69E.1BEA57DF-ON4925800B.001C812D-4925800B.001CAAE2@notes.na.collabserv.com>
References: <CA+3eh10Fhjt=ZOx31E_-yfwtj124sXFV31je5hSG5cA-Hx19Ew@mail.gmail.com>
	<3129351f-9ba0-7c60-77fd-291479ca80fd@oracle.com>
	<CA+3eh11d8YYhbq9yN77XWbA-=yky=zvmMS2kaL2jL2bbrkCLVw@mail.gmail.com>
	<OFADDBC69E.1BEA57DF-ON4925800B.001C812D-4925800B.001CAAE2@notes.na.collabserv.com>
Message-ID: <CA+3eh129-ahLyJdKNO88_VwpYL4F11CyV=NTHp4e-jPZ0SNiLQ@mail.gmail.com>

Hi Hiroshi,

thanks a lot for checking!

@Zoltan: so we're ready to go :)

Thanks,
Volker


On Wed, Aug 10, 2016 at 7:13 AM, Hiroshi H Horii <HORII at jp.ibm.com> wrote:
> Hi Volker,
>
> I confirmed this AES Intrinsics improve SPECjbb2013 scores (MAXjOPs) 7-8%.
> Thank you for your great work.
>
> Regards,
> Hiroshi
> -----------------------
> Hiroshi Horii, Ph.D.
> IBM Research - Tokyo
>
>
>
>
> From:        Volker Simonis <volker.simonis at gmail.com>
> To:        Zolt?n Maj? <zoltan.majo at oracle.com>, Hiroshi H
> Horii/Japan/IBM at IBMJP
> Cc:        Se?n Coffey <sean.coffey at oracle.com>,
> "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>, HotSpot Open
> Source Developers <hotspot-dev at openjdk.java.net>
> Date:        08/10/2016 00:49
> Subject:        Re: Ping: [8u] request for approval: "8152172: PPC64:
> Support AES intrinsics"
> ________________________________
>
>
>
> On Tue, Aug 9, 2016 at 11:03 AM, Zolt?n Maj? <zoltan.majo at oracle.com> wrote:
>> Hi Volker,
>>
>>
>> On 08/08/2016 03:43 PM, Volker Simonis wrote:
>>>
>>> Ping...
>>>
>>> Can I please get a review for this downport. The shared changes all
>>> cleanly apply to jdk8, only the ppc64 part required a small tweak (see
>>> intial mail).
>>
>>
>> you changes look good for me. I can sponsor the changes, if you want.
>>
>
> Hi Zoltan,
>
> thanks a lot. That would be really great!
> I'm just waiting for the final confirmation from Hiroshi. One he gives
> his OK, it would be really nice if you could sponsor the change.
>
> Thanks again,
> Volker
>
>> Thank you and best regards,
>>
>>
>> Zoltan
>>
>>
>>>
>>> Thanks,
>>> Volker
>>>
>>> On Wed, Aug 3, 2016 at 1:32 PM, Se?n Coffey <sean.coffey at oracle.com>
>>> wrote:
>>>>
>>>> On 02/08/16 20:47, Volker Simonis wrote:
>>>>>
>>>>> Hi Sean,
>>>>>
>>>>> thanks a lot for your reply.
>>>>>
>>>>> You're right - I'm still waiting for a review of the hotspot part. Any
>>>>> volunteers :)
>>>>
>>>> OK - would be good to get a hotspot reviewer to look at those first.
>>>>>
>>>>>
>>>>> Regarding the noreg label: I used 'noreg-other' because there already
>>>>> exist AES tests (they have never been part of this original change).
>>>>> Is that the right label? There are simply too many different noreg
>>>>> labels without documentation so if I selected the wrong one, please
>>>>> advice which one to choose.
>>>>
>>>> noreg labels are documented at :
>>>> http://openjdk.java.net/guide/changePlanning.html#noreg
>>>> noreg-other seems fine. You might want to add a short comment to bug
>>>> outlining your comment on existing AES tests.
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>>> Thanks,
>>>>> Volker
>>>>>
>>>>>
>>>>> On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey <sean.coffey at oracle.com>
>>>>> wrote:
>>>>>>
>>>>>> Volker,
>>>>>>
>>>>>> Have the jdk8u hotspot edits been reviewed ? Looks like they should
>>>>>> be.
>>>>>>
>>>>>> Can you add a suitable noreg label to the master bug report also.
>>>>>>
>>>>>> Regards,
>>>>>> Sean.
>>>>>>
>>>>>>
>>>>>> On 29/07/2016 19:58, Volker Simonis wrote:
>>>>>>>
>>>>>>> Ping!
>>>>>>>
>>>>>>> Can I please have an approval for backporting this change to 8u-dev?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Volker
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>>>>>>> <volker.simonis at gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> could you please approve the backport of the following, mostly ppc64
>>>>>>>> change to jdk8u-dev:
>>>>>>>>
>>>>>>>> 8152172: PPC64: Support AES intrinsics
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>>>>>>> Webrev
>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>>>>>>> Review:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
>>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>>>>>>>
>>>>>>>> As you can see, the change consists of two parts - the main one in
>>>>>>>> the
>>>>>>>> hotpsot repo and a small part in the jdk repo.
>>>>>>>>
>>>>>>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>>>>>>> shuffling).
>>>>>>>>
>>>>>>>> The hotspot part required a small tweak, but only in the ppc-only
>>>>>>>> part. This is because the feature detection for the AES instructions
>>>>>>>> was already active in jdk9 when the original change was made but is
>>>>>>>> not available in jdk8u until now. You can find the additional
>>>>>>>> changes
>>>>>>>> at the end of this mail for your convenience.
>>>>>>>>
>>>>>>>> The required shared changes cleanly apply to jdk8u.
>>>>>>>>
>>>>>>>> As Vladimir pointed out in a previous thread, shared Hotspot changes
>>>>>>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
>>>>>>>> that and synchronously push both parts.
>>>>>>>>
>>>>>>>> @Hiroshii: could you please verify that you are fine with the
>>>>>>>> change?
>>>>>>>> I've done some tests on Power8LE but just want to be sure this
>>>>>>>> downport satisfies your needs as well.
>>>>>>>>
>>>>>>>> Thank you and best regards,
>>>>>>>> Volker
>>>>>>>>
>>>>>>>> =====================
>>>>>>>>
>>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016
>>>>>>>> -0700
>>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016
>>>>>>>> +0200
>>>>>>>> @@ -452,6 +476,7 @@
>>>>>>>>       a->popcntw(R7, R5);                          // code[7] ->
>>>>>>>> popcntw
>>>>>>>>       a->fcfids(F3, F4);                           // code[8] ->
>>>>>>>> fcfids
>>>>>>>>       a->vand(VR0, VR0, VR0);                      // code[9] ->
>>>>>>>> vand
>>>>>>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] ->
>>>>>>>> vcipher
>>>>>>>>       a->blr();
>>>>>>>>
>>>>>>>>       // Emit function to set one cache line to zero. Emit function
>>>>>>>> descriptor and get pointer to it.
>>>>>>>> @@ -495,6 +520,7 @@
>>>>>>>>       if (code[feature_cntr++]) features |= popcntw_m;
>>>>>>>>       if (code[feature_cntr++]) features |= fcfids_m;
>>>>>>>>       if (code[feature_cntr++]) features |= vand_m;
>>>>>>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>>>>>>
>>>>>>>>       // Print the detection code.
>>>>>>>>       if (PrintAssembly) {
>>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016
>>>>>>>> -0700
>>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016
>>>>>>>> +0200
>>>>>>>> @@ -42,6 +42,7 @@
>>>>>>>>         fcfids,
>>>>>>>>         vand,
>>>>>>>>         dcba,
>>>>>>>> +    vcipher,
>>>>>>>>         num_features // last entry to count features
>>>>>>>>       };
>>>>>>>>       enum Feature_Flag_Set {
>>>>>>>> @@ -56,6 +57,7 @@
>>>>>>>>         fcfids_m              = (1 << fcfids ),
>>>>>>>>         vand_m                = (1 << vand   ),
>>>>>>>>         dcba_m                = (1 << dcba   ),
>>>>>>>> +    vcipher_m             = (1 << vcipher),
>>>>>>>>         all_features_m        = -1
>>>>>>>>       };
>>>>>>>>       static int  _features;
>>>>>>>> @@ -83,6 +85,7 @@
>>>>>>>>       static bool has_fcfids()  { return (_features & fcfids_m) !=
>>>>>>>> 0;
>>>>>>>> }
>>>>>>>>       static bool has_vand()    { return (_features & vand_m) != 0;
>>>>>>>> }
>>>>>>>>       static bool has_dcba()    { return (_features & dcba_m) != 0;
>>>>>>>> }
>>>>>>>> +  static bool has_vcipher() { return (_features & vcipher_m) != 0;
>>>>>>>> }
>>>>>>>>
>>>>>>>>       static const char* cpu_features() { return _features_str; }
>>>>>>
>>>>>>
>>
>
>
>
>

From sean.coffey at oracle.com  Wed Aug 10 08:19:07 2016
From: sean.coffey at oracle.com (Sean Coffey)
Date: Wed, 10 Aug 2016 09:19:07 +0100
Subject: Ping: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <CA+3eh129-ahLyJdKNO88_VwpYL4F11CyV=NTHp4e-jPZ0SNiLQ@mail.gmail.com>
References: <CA+3eh10Fhjt=ZOx31E_-yfwtj124sXFV31je5hSG5cA-Hx19Ew@mail.gmail.com>
	<3129351f-9ba0-7c60-77fd-291479ca80fd@oracle.com>
	<CA+3eh11d8YYhbq9yN77XWbA-=yky=zvmMS2kaL2jL2bbrkCLVw@mail.gmail.com>
	<OFADDBC69E.1BEA57DF-ON4925800B.001C812D-4925800B.001CAAE2@notes.na.collabserv.com>
	<CA+3eh129-ahLyJdKNO88_VwpYL4F11CyV=NTHp4e-jPZ0SNiLQ@mail.gmail.com>
Message-ID: <e0c6c255-f4ad-7875-e1c5-634261cdd914@oracle.com>

Thanks all. Approved for jdk8u-dev.

regards,
Sean.


On 10/08/2016 08:40, Volker Simonis wrote:
> Hi Hiroshi,
>
> thanks a lot for checking!
>
> @Zoltan: so we're ready to go :)
>
> Thanks,
> Volker
>
>
> On Wed, Aug 10, 2016 at 7:13 AM, Hiroshi H Horii <HORII at jp.ibm.com> wrote:
>> Hi Volker,
>>
>> I confirmed this AES Intrinsics improve SPECjbb2013 scores (MAXjOPs) 7-8%.
>> Thank you for your great work.
>>
>> Regards,
>> Hiroshi
>> -----------------------
>> Hiroshi Horii, Ph.D.
>> IBM Research - Tokyo
>>
>>
>>
>>
>> From:        Volker Simonis <volker.simonis at gmail.com>
>> To:        Zolt?n Maj? <zoltan.majo at oracle.com>, Hiroshi H
>> Horii/Japan/IBM at IBMJP
>> Cc:        Se?n Coffey <sean.coffey at oracle.com>,
>> "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>, HotSpot Open
>> Source Developers <hotspot-dev at openjdk.java.net>
>> Date:        08/10/2016 00:49
>> Subject:        Re: Ping: [8u] request for approval: "8152172: PPC64:
>> Support AES intrinsics"
>> ________________________________
>>
>>
>>
>> On Tue, Aug 9, 2016 at 11:03 AM, Zolt?n Maj? <zoltan.majo at oracle.com> wrote:
>>> Hi Volker,
>>>
>>>
>>> On 08/08/2016 03:43 PM, Volker Simonis wrote:
>>>> Ping...
>>>>
>>>> Can I please get a review for this downport. The shared changes all
>>>> cleanly apply to jdk8, only the ppc64 part required a small tweak (see
>>>> intial mail).
>>>
>>> you changes look good for me. I can sponsor the changes, if you want.
>>>
>> Hi Zoltan,
>>
>> thanks a lot. That would be really great!
>> I'm just waiting for the final confirmation from Hiroshi. One he gives
>> his OK, it would be really nice if you could sponsor the change.
>>
>> Thanks again,
>> Volker
>>
>>> Thank you and best regards,
>>>
>>>
>>> Zoltan
>>>
>>>
>>>> Thanks,
>>>> Volker
>>>>
>>>> On Wed, Aug 3, 2016 at 1:32 PM, Se?n Coffey <sean.coffey at oracle.com>
>>>> wrote:
>>>>> On 02/08/16 20:47, Volker Simonis wrote:
>>>>>> Hi Sean,
>>>>>>
>>>>>> thanks a lot for your reply.
>>>>>>
>>>>>> You're right - I'm still waiting for a review of the hotspot part. Any
>>>>>> volunteers :)
>>>>> OK - would be good to get a hotspot reviewer to look at those first.
>>>>>>
>>>>>> Regarding the noreg label: I used 'noreg-other' because there already
>>>>>> exist AES tests (they have never been part of this original change).
>>>>>> Is that the right label? There are simply too many different noreg
>>>>>> labels without documentation so if I selected the wrong one, please
>>>>>> advice which one to choose.
>>>>> noreg labels are documented at :
>>>>> http://openjdk.java.net/guide/changePlanning.html#noreg
>>>>> noreg-other seems fine. You might want to add a short comment to bug
>>>>> outlining your comment on existing AES tests.
>>>>>
>>>>> regards,
>>>>> Sean.
>>>>>
>>>>>> Thanks,
>>>>>> Volker
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey <sean.coffey at oracle.com>
>>>>>> wrote:
>>>>>>> Volker,
>>>>>>>
>>>>>>> Have the jdk8u hotspot edits been reviewed ? Looks like they should
>>>>>>> be.
>>>>>>>
>>>>>>> Can you add a suitable noreg label to the master bug report also.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Sean.
>>>>>>>
>>>>>>>
>>>>>>> On 29/07/2016 19:58, Volker Simonis wrote:
>>>>>>>> Ping!
>>>>>>>>
>>>>>>>> Can I please have an approval for backporting this change to 8u-dev?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Volker
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>>>>>>>> <volker.simonis at gmail.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> could you please approve the backport of the following, mostly ppc64
>>>>>>>>> change to jdk8u-dev:
>>>>>>>>>
>>>>>>>>> 8152172: PPC64: Support AES intrinsics
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>>>>>>>> Webrev
>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>>>>>>>> Review:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032
>>>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>>>>>>>>
>>>>>>>>> As you can see, the change consists of two parts - the main one in
>>>>>>>>> the
>>>>>>>>> hotpsot repo and a small part in the jdk repo.
>>>>>>>>>
>>>>>>>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>>>>>>>> shuffling).
>>>>>>>>>
>>>>>>>>> The hotspot part required a small tweak, but only in the ppc-only
>>>>>>>>> part. This is because the feature detection for the AES instructions
>>>>>>>>> was already active in jdk9 when the original change was made but is
>>>>>>>>> not available in jdk8u until now. You can find the additional
>>>>>>>>> changes
>>>>>>>>> at the end of this mail for your convenience.
>>>>>>>>>
>>>>>>>>> The required shared changes cleanly apply to jdk8u.
>>>>>>>>>
>>>>>>>>> As Vladimir pointed out in a previous thread, shared Hotspot changes
>>>>>>>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do
>>>>>>>>> that and synchronously push both parts.
>>>>>>>>>
>>>>>>>>> @Hiroshii: could you please verify that you are fine with the
>>>>>>>>> change?
>>>>>>>>> I've done some tests on Power8LE but just want to be sure this
>>>>>>>>> downport satisfies your needs as well.
>>>>>>>>>
>>>>>>>>> Thank you and best regards,
>>>>>>>>> Volker
>>>>>>>>>
>>>>>>>>> =====================
>>>>>>>>>
>>>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016
>>>>>>>>> -0700
>>>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016
>>>>>>>>> +0200
>>>>>>>>> @@ -452,6 +476,7 @@
>>>>>>>>>        a->popcntw(R7, R5);                          // code[7] ->
>>>>>>>>> popcntw
>>>>>>>>>        a->fcfids(F3, F4);                           // code[8] ->
>>>>>>>>> fcfids
>>>>>>>>>        a->vand(VR0, VR0, VR0);                      // code[9] ->
>>>>>>>>> vand
>>>>>>>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] ->
>>>>>>>>> vcipher
>>>>>>>>>        a->blr();
>>>>>>>>>
>>>>>>>>>        // Emit function to set one cache line to zero. Emit function
>>>>>>>>> descriptor and get pointer to it.
>>>>>>>>> @@ -495,6 +520,7 @@
>>>>>>>>>        if (code[feature_cntr++]) features |= popcntw_m;
>>>>>>>>>        if (code[feature_cntr++]) features |= fcfids_m;
>>>>>>>>>        if (code[feature_cntr++]) features |= vand_m;
>>>>>>>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>>>>>>>
>>>>>>>>>        // Print the detection code.
>>>>>>>>>        if (PrintAssembly) {
>>>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016
>>>>>>>>> -0700
>>>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016
>>>>>>>>> +0200
>>>>>>>>> @@ -42,6 +42,7 @@
>>>>>>>>>          fcfids,
>>>>>>>>>          vand,
>>>>>>>>>          dcba,
>>>>>>>>> +    vcipher,
>>>>>>>>>          num_features // last entry to count features
>>>>>>>>>        };
>>>>>>>>>        enum Feature_Flag_Set {
>>>>>>>>> @@ -56,6 +57,7 @@
>>>>>>>>>          fcfids_m              = (1 << fcfids ),
>>>>>>>>>          vand_m                = (1 << vand   ),
>>>>>>>>>          dcba_m                = (1 << dcba   ),
>>>>>>>>> +    vcipher_m             = (1 << vcipher),
>>>>>>>>>          all_features_m        = -1
>>>>>>>>>        };
>>>>>>>>>        static int  _features;
>>>>>>>>> @@ -83,6 +85,7 @@
>>>>>>>>>        static bool has_fcfids()  { return (_features & fcfids_m) !=
>>>>>>>>> 0;
>>>>>>>>> }
>>>>>>>>>        static bool has_vand()    { return (_features & vand_m) != 0;
>>>>>>>>> }
>>>>>>>>>        static bool has_dcba()    { return (_features & dcba_m) != 0;
>>>>>>>>> }
>>>>>>>>> +  static bool has_vcipher() { return (_features & vcipher_m) != 0;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>        static const char* cpu_features() { return _features_str; }
>>>>>>>
>>
>>
>>


From zoltan.majo at oracle.com  Wed Aug 10 13:09:30 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Wed, 10 Aug 2016 15:09:30 +0200
Subject: Ping: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <e0c6c255-f4ad-7875-e1c5-634261cdd914@oracle.com>
References: <CA+3eh10Fhjt=ZOx31E_-yfwtj124sXFV31je5hSG5cA-Hx19Ew@mail.gmail.com>
	<3129351f-9ba0-7c60-77fd-291479ca80fd@oracle.com>
	<CA+3eh11d8YYhbq9yN77XWbA-=yky=zvmMS2kaL2jL2bbrkCLVw@mail.gmail.com>
	<OFADDBC69E.1BEA57DF-ON4925800B.001C812D-4925800B.001CAAE2@notes.na.collabserv.com>
	<CA+3eh129-ahLyJdKNO88_VwpYL4F11CyV=NTHp4e-jPZ0SNiLQ@mail.gmail.com>
	<e0c6c255-f4ad-7875-e1c5-634261cdd914@oracle.com>
Message-ID: <40a8e89f-8ea1-c19c-0a12-7a7590607ead@oracle.com>

Hi,


On 08/10/2016 10:19 AM, Sean Coffey wrote:
> Thanks all. Approved for jdk8u-dev.
>
> regards,
> Sean.
>
>
> On 10/08/2016 08:40, Volker Simonis wrote:
>> Hi Hiroshi,
>>
>> thanks a lot for checking!
>>
>> @Zoltan: so we're ready to go :)

thank you, I started the push job.

Best regards,


Zoltan

>>
>> Thanks,
>> Volker
>>
>>
>> On Wed, Aug 10, 2016 at 7:13 AM, Hiroshi H Horii <HORII at jp.ibm.com> 
>> wrote:
>>> Hi Volker,
>>>
>>> I confirmed this AES Intrinsics improve SPECjbb2013 scores (MAXjOPs) 
>>> 7-8%.
>>> Thank you for your great work.
>>>
>>> Regards,
>>> Hiroshi
>>> -----------------------
>>> Hiroshi Horii, Ph.D.
>>> IBM Research - Tokyo
>>>
>>>
>>>
>>>
>>> From:        Volker Simonis <volker.simonis at gmail.com>
>>> To:        Zolt?n Maj? <zoltan.majo at oracle.com>, Hiroshi H
>>> Horii/Japan/IBM at IBMJP
>>> Cc:        Se?n Coffey <sean.coffey at oracle.com>,
>>> "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>, HotSpot Open
>>> Source Developers <hotspot-dev at openjdk.java.net>
>>> Date:        08/10/2016 00:49
>>> Subject:        Re: Ping: [8u] request for approval: "8152172: PPC64:
>>> Support AES intrinsics"
>>> ________________________________
>>>
>>>
>>>
>>> On Tue, Aug 9, 2016 at 11:03 AM, Zolt?n Maj? 
>>> <zoltan.majo at oracle.com> wrote:
>>>> Hi Volker,
>>>>
>>>>
>>>> On 08/08/2016 03:43 PM, Volker Simonis wrote:
>>>>> Ping...
>>>>>
>>>>> Can I please get a review for this downport. The shared changes all
>>>>> cleanly apply to jdk8, only the ppc64 part required a small tweak 
>>>>> (see
>>>>> intial mail).
>>>>
>>>> you changes look good for me. I can sponsor the changes, if you want.
>>>>
>>> Hi Zoltan,
>>>
>>> thanks a lot. That would be really great!
>>> I'm just waiting for the final confirmation from Hiroshi. One he gives
>>> his OK, it would be really nice if you could sponsor the change.
>>>
>>> Thanks again,
>>> Volker
>>>
>>>> Thank you and best regards,
>>>>
>>>>
>>>> Zoltan
>>>>
>>>>
>>>>> Thanks,
>>>>> Volker
>>>>>
>>>>> On Wed, Aug 3, 2016 at 1:32 PM, Se?n Coffey <sean.coffey at oracle.com>
>>>>> wrote:
>>>>>> On 02/08/16 20:47, Volker Simonis wrote:
>>>>>>> Hi Sean,
>>>>>>>
>>>>>>> thanks a lot for your reply.
>>>>>>>
>>>>>>> You're right - I'm still waiting for a review of the hotspot 
>>>>>>> part. Any
>>>>>>> volunteers :)
>>>>>> OK - would be good to get a hotspot reviewer to look at those first.
>>>>>>>
>>>>>>> Regarding the noreg label: I used 'noreg-other' because there 
>>>>>>> already
>>>>>>> exist AES tests (they have never been part of this original 
>>>>>>> change).
>>>>>>> Is that the right label? There are simply too many different noreg
>>>>>>> labels without documentation so if I selected the wrong one, please
>>>>>>> advice which one to choose.
>>>>>> noreg labels are documented at :
>>>>>> http://openjdk.java.net/guide/changePlanning.html#noreg
>>>>>> noreg-other seems fine. You might want to add a short comment to bug
>>>>>> outlining your comment on existing AES tests.
>>>>>>
>>>>>> regards,
>>>>>> Sean.
>>>>>>
>>>>>>> Thanks,
>>>>>>> Volker
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey 
>>>>>>> <sean.coffey at oracle.com>
>>>>>>> wrote:
>>>>>>>> Volker,
>>>>>>>>
>>>>>>>> Have the jdk8u hotspot edits been reviewed ? Looks like they 
>>>>>>>> should
>>>>>>>> be.
>>>>>>>>
>>>>>>>> Can you add a suitable noreg label to the master bug report also.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Sean.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29/07/2016 19:58, Volker Simonis wrote:
>>>>>>>>> Ping!
>>>>>>>>>
>>>>>>>>> Can I please have an approval for backporting this change to 
>>>>>>>>> 8u-dev?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Volker
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>>>>>>>>> <volker.simonis at gmail.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> could you please approve the backport of the following, 
>>>>>>>>>> mostly ppc64
>>>>>>>>>> change to jdk8u-dev:
>>>>>>>>>>
>>>>>>>>>> 8152172: PPC64: Support AES intrinsics
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>>>>>>>>> Webrev
>>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>>>>>>>>> Review:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 
>>>>>>>>>>
>>>>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>>>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As you can see, the change consists of two parts - the main 
>>>>>>>>>> one in
>>>>>>>>>> the
>>>>>>>>>> hotpsot repo and a small part in the jdk repo.
>>>>>>>>>>
>>>>>>>>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>>>>>>>>> shuffling).
>>>>>>>>>>
>>>>>>>>>> The hotspot part required a small tweak, but only in the 
>>>>>>>>>> ppc-only
>>>>>>>>>> part. This is because the feature detection for the AES 
>>>>>>>>>> instructions
>>>>>>>>>> was already active in jdk9 when the original change was made 
>>>>>>>>>> but is
>>>>>>>>>> not available in jdk8u until now. You can find the additional
>>>>>>>>>> changes
>>>>>>>>>> at the end of this mail for your convenience.
>>>>>>>>>>
>>>>>>>>>> The required shared changes cleanly apply to jdk8u.
>>>>>>>>>>
>>>>>>>>>> As Vladimir pointed out in a previous thread, shared Hotspot 
>>>>>>>>>> changes
>>>>>>>>>> have to go through JPRT even in jdk8u-dev. So I need a 
>>>>>>>>>> sponsor to do
>>>>>>>>>> that and synchronously push both parts.
>>>>>>>>>>
>>>>>>>>>> @Hiroshii: could you please verify that you are fine with the
>>>>>>>>>> change?
>>>>>>>>>> I've done some tests on Power8LE but just want to be sure this
>>>>>>>>>> downport satisfies your needs as well.
>>>>>>>>>>
>>>>>>>>>> Thank you and best regards,
>>>>>>>>>> Volker
>>>>>>>>>>
>>>>>>>>>> =====================
>>>>>>>>>>
>>>>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>>>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016
>>>>>>>>>> -0700
>>>>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016
>>>>>>>>>> +0200
>>>>>>>>>> @@ -452,6 +476,7 @@
>>>>>>>>>>        a->popcntw(R7, R5);                          // 
>>>>>>>>>> code[7] ->
>>>>>>>>>> popcntw
>>>>>>>>>>        a->fcfids(F3, F4);                           // 
>>>>>>>>>> code[8] ->
>>>>>>>>>> fcfids
>>>>>>>>>>        a->vand(VR0, VR0, VR0);                      // 
>>>>>>>>>> code[9] ->
>>>>>>>>>> vand
>>>>>>>>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] ->
>>>>>>>>>> vcipher
>>>>>>>>>>        a->blr();
>>>>>>>>>>
>>>>>>>>>>        // Emit function to set one cache line to zero. Emit 
>>>>>>>>>> function
>>>>>>>>>> descriptor and get pointer to it.
>>>>>>>>>> @@ -495,6 +520,7 @@
>>>>>>>>>>        if (code[feature_cntr++]) features |= popcntw_m;
>>>>>>>>>>        if (code[feature_cntr++]) features |= fcfids_m;
>>>>>>>>>>        if (code[feature_cntr++]) features |= vand_m;
>>>>>>>>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>>>>>>>>
>>>>>>>>>>        // Print the detection code.
>>>>>>>>>>        if (PrintAssembly) {
>>>>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>>>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016
>>>>>>>>>> -0700
>>>>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016
>>>>>>>>>> +0200
>>>>>>>>>> @@ -42,6 +42,7 @@
>>>>>>>>>>          fcfids,
>>>>>>>>>>          vand,
>>>>>>>>>>          dcba,
>>>>>>>>>> +    vcipher,
>>>>>>>>>>          num_features // last entry to count features
>>>>>>>>>>        };
>>>>>>>>>>        enum Feature_Flag_Set {
>>>>>>>>>> @@ -56,6 +57,7 @@
>>>>>>>>>>          fcfids_m              = (1 << fcfids ),
>>>>>>>>>>          vand_m                = (1 << vand   ),
>>>>>>>>>>          dcba_m                = (1 << dcba   ),
>>>>>>>>>> +    vcipher_m             = (1 << vcipher),
>>>>>>>>>>          all_features_m        = -1
>>>>>>>>>>        };
>>>>>>>>>>        static int  _features;
>>>>>>>>>> @@ -83,6 +85,7 @@
>>>>>>>>>>        static bool has_fcfids()  { return (_features & 
>>>>>>>>>> fcfids_m) !=
>>>>>>>>>> 0;
>>>>>>>>>> }
>>>>>>>>>>        static bool has_vand()    { return (_features & 
>>>>>>>>>> vand_m) != 0;
>>>>>>>>>> }
>>>>>>>>>>        static bool has_dcba()    { return (_features & 
>>>>>>>>>> dcba_m) != 0;
>>>>>>>>>> }
>>>>>>>>>> +  static bool has_vcipher() { return (_features & vcipher_m) 
>>>>>>>>>> != 0;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>        static const char* cpu_features() { return 
>>>>>>>>>> _features_str; }
>>>>>>>>
>>>
>>>
>>>
>


From svetlana.nikandrova at oracle.com  Wed Aug 10 13:18:42 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Wed, 10 Aug 2016 16:18:42 +0300
Subject: [8u-dev] Request for Approval 8162876: [TEST_BUG]
	sun/net/www/protocol/http/HttpInputStream.java fails intermittently
Message-ID: <57AB29B2.9080701@oracle.com>

Hello,

please approve this test fix backport. Applied cleanly.

JBS:
https://bugs.openjdk.java.net/browse/JDK-8162876
Review:
http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010138.html
JDK 9 changeset:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/28022a67ecca
  
JPRT tested.
  
Thank you,
Svetlana




From david.buck at oracle.com  Wed Aug 10 13:24:44 2016
From: david.buck at oracle.com (david buck)
Date: Wed, 10 Aug 2016 22:24:44 +0900
Subject: [8u-dev] Request for Approval 8162876: [TEST_BUG]
	sun/net/www/protocol/http/HttpInputStream.java fails intermittently
In-Reply-To: <57AB29B2.9080701@oracle.com>
References: <57AB29B2.9080701@oracle.com>
Message-ID: <21ff0d96-b26a-3ebd-56ae-d6bf3da29601@oracle.com>

approved for backport to 8u-dev

Cheers,
-Buck

On 2016/08/10 22:18, Svetlana Nikandrova wrote:
> Hello,
>
> please approve this test fix backport. Applied cleanly.
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8162876
> Review:
> http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010138.html
> JDK 9 changeset:
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/28022a67ecca
>
> JPRT tested.
>
> Thank you,
> Svetlana
>
>
>

From sean.coffey at oracle.com  Wed Aug 10 14:35:30 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 10 Aug 2016 15:35:30 +0100
Subject: [8u-dev] Request for approval : 8147772, 8163104
Message-ID: <57AB3BB2.5070704@oracle.com>

Looking to port both of these fixes from JDK 9 :

JDK-8147772 Update KerberosTicket to describe behavior if it has been 
destroyed and fix NullPointerExceptions
JDK-8163104 Unexpected NPE still possible on some Kerberos ticket calls

webrev : 
http://cr.openjdk.java.net/~coffeys/webrev.8147772.8163104.jdk8u/webrev/
JDK 8u code review : 
http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014563.html

https://bugs.openjdk.java.net/browse/JDK-8147772
https://bugs.openjdk.java.net/browse/JDK-8163104

-- 
Regards,
Sean.


From rob.mckenna at oracle.com  Wed Aug 10 14:47:39 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 10 Aug 2016 15:47:39 +0100
Subject: [8u-dev] Request for approval : 8147772, 8163104
In-Reply-To: <57AB3BB2.5070704@oracle.com>
References: <57AB3BB2.5070704@oracle.com>
Message-ID: <20160810144739.GA8064@vimes>

Approved

	-Rob

On 10/08/16 03:35, Se?n Coffey wrote:
> Looking to port both of these fixes from JDK 9 :
> 
> JDK-8147772 Update KerberosTicket to describe behavior if it has been
> destroyed and fix NullPointerExceptions
> JDK-8163104 Unexpected NPE still possible on some Kerberos ticket calls
> 
> webrev :
> http://cr.openjdk.java.net/~coffeys/webrev.8147772.8163104.jdk8u/webrev/
> JDK 8u code review :
> http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014563.html
> 
> https://bugs.openjdk.java.net/browse/JDK-8147772
> https://bugs.openjdk.java.net/browse/JDK-8163104
> 
> -- 
> Regards,
> Sean.
> 

From HORII at jp.ibm.com  Wed Aug 10 05:13:07 2016
From: HORII at jp.ibm.com (Hiroshi H Horii)
Date: Wed, 10 Aug 2016 14:13:07 +0900
Subject: Ping: [8u] request for approval: "8152172: PPC64: Support AES
	intrinsics"
In-Reply-To: <CA+3eh11d8YYhbq9yN77XWbA-=yky=zvmMS2kaL2jL2bbrkCLVw@mail.gmail.com>
References: <CA+3eh10Fhjt=ZOx31E_-yfwtj124sXFV31je5hSG5cA-Hx19Ew@mail.gmail.com>
	<3129351f-9ba0-7c60-77fd-291479ca80fd@oracle.com>
	<CA+3eh11d8YYhbq9yN77XWbA-=yky=zvmMS2kaL2jL2bbrkCLVw@mail.gmail.com>
Message-ID: <OFADDBC69E.1BEA57DF-ON4925800B.001C812D-4925800B.001CAAE2@notes.na.collabserv.com>

Hi Volker,

I confirmed this AES Intrinsics improve SPECjbb2013 scores (MAXjOPs) 7-8%. 

Thank you for your great work.

Regards,
Hiroshi
-----------------------
Hiroshi Horii, Ph.D.
IBM Research - Tokyo




From:   Volker Simonis <volker.simonis at gmail.com>
To:     Zolt?n Maj? <zoltan.majo at oracle.com>, Hiroshi H 
Horii/Japan/IBM at IBMJP
Cc:     Se?n Coffey <sean.coffey at oracle.com>, "jdk8u-dev at openjdk.java.net" 
<jdk8u-dev at openjdk.java.net>, HotSpot Open Source Developers 
<hotspot-dev at openjdk.java.net>
Date:   08/10/2016 00:49
Subject:        Re: Ping: [8u] request for approval: "8152172: PPC64: 
Support AES intrinsics"



On Tue, Aug 9, 2016 at 11:03 AM, Zolt?n Maj? <zoltan.majo at oracle.com> 
wrote:
> Hi Volker,
>
>
> On 08/08/2016 03:43 PM, Volker Simonis wrote:
>>
>> Ping...
>>
>> Can I please get a review for this downport. The shared changes all
>> cleanly apply to jdk8, only the ppc64 part required a small tweak (see
>> intial mail).
>
>
> you changes look good for me. I can sponsor the changes, if you want.
>

Hi Zoltan,

thanks a lot. That would be really great!
I'm just waiting for the final confirmation from Hiroshi. One he gives
his OK, it would be really nice if you could sponsor the change.

Thanks again,
Volker

> Thank you and best regards,
>
>
> Zoltan
>
>
>>
>> Thanks,
>> Volker
>>
>> On Wed, Aug 3, 2016 at 1:32 PM, Se?n Coffey <sean.coffey at oracle.com>
>> wrote:
>>>
>>> On 02/08/16 20:47, Volker Simonis wrote:
>>>>
>>>> Hi Sean,
>>>>
>>>> thanks a lot for your reply.
>>>>
>>>> You're right - I'm still waiting for a review of the hotspot part. 
Any
>>>> volunteers :)
>>>
>>> OK - would be good to get a hotspot reviewer to look at those first.
>>>>
>>>>
>>>> Regarding the noreg label: I used 'noreg-other' because there already
>>>> exist AES tests (they have never been part of this original change).
>>>> Is that the right label? There are simply too many different noreg
>>>> labels without documentation so if I selected the wrong one, please
>>>> advice which one to choose.
>>>
>>> noreg labels are documented at :
>>> http://openjdk.java.net/guide/changePlanning.html#noreg
>>> noreg-other seems fine. You might want to add a short comment to bug
>>> outlining your comment on existing AES tests.
>>>
>>> regards,
>>> Sean.
>>>
>>>> Thanks,
>>>> Volker
>>>>
>>>>
>>>> On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey <sean.coffey at oracle.com>
>>>> wrote:
>>>>>
>>>>> Volker,
>>>>>
>>>>> Have the jdk8u hotspot edits been reviewed ? Looks like they should 
be.
>>>>>
>>>>> Can you add a suitable noreg label to the master bug report also.
>>>>>
>>>>> Regards,
>>>>> Sean.
>>>>>
>>>>>
>>>>> On 29/07/2016 19:58, Volker Simonis wrote:
>>>>>>
>>>>>> Ping!
>>>>>>
>>>>>> Can I please have an approval for backporting this change to 
8u-dev?
>>>>>>
>>>>>> Thanks,
>>>>>> Volker
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis
>>>>>> <volker.simonis at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> could you please approve the backport of the following, mostly 
ppc64
>>>>>>> change to jdk8u-dev:
>>>>>>>
>>>>>>> 8152172: PPC64: Support AES intrinsics
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/
>>>>>>> Webrev
>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/
>>>>>>> Review:
>>>>>>>
>>>>>>>
>>>>>>> 
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032

>>>>>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b
>>>>>>> URL:
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f
>>>>>>>
>>>>>>> As you can see, the change consists of two parts - the main one in
>>>>>>> the
>>>>>>> hotpsot repo and a small part in the jdk repo.
>>>>>>>
>>>>>>> The jdk part applied cleanly to jdk8u (with the usual directory
>>>>>>> shuffling).
>>>>>>>
>>>>>>> The hotspot part required a small tweak, but only in the ppc-only
>>>>>>> part. This is because the feature detection for the AES 
instructions
>>>>>>> was already active in jdk9 when the original change was made but 
is
>>>>>>> not available in jdk8u until now. You can find the additional 
changes
>>>>>>> at the end of this mail for your convenience.
>>>>>>>
>>>>>>> The required shared changes cleanly apply to jdk8u.
>>>>>>>
>>>>>>> As Vladimir pointed out in a previous thread, shared Hotspot 
changes
>>>>>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to 
do
>>>>>>> that and synchronously push both parts.
>>>>>>>
>>>>>>> @Hiroshii: could you please verify that you are fine with the 
change?
>>>>>>> I've done some tests on Power8LE but just want to be sure this
>>>>>>> downport satisfies your needs as well.
>>>>>>>
>>>>>>> Thank you and best regards,
>>>>>>> Volker
>>>>>>>
>>>>>>> =====================
>>>>>>>
>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp
>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016
>>>>>>> -0700
>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016
>>>>>>> +0200
>>>>>>> @@ -452,6 +476,7 @@
>>>>>>>       a->popcntw(R7, R5);                          // code[7] ->
>>>>>>> popcntw
>>>>>>>       a->fcfids(F3, F4);                           // code[8] ->
>>>>>>> fcfids
>>>>>>>       a->vand(VR0, VR0, VR0);                      // code[9] -> 
vand
>>>>>>> +  a->vcipher(VR0, VR1, VR2);                   // code[10] ->
>>>>>>> vcipher
>>>>>>>       a->blr();
>>>>>>>
>>>>>>>       // Emit function to set one cache line to zero. Emit 
function
>>>>>>> descriptor and get pointer to it.
>>>>>>> @@ -495,6 +520,7 @@
>>>>>>>       if (code[feature_cntr++]) features |= popcntw_m;
>>>>>>>       if (code[feature_cntr++]) features |= fcfids_m;
>>>>>>>       if (code[feature_cntr++]) features |= vand_m;
>>>>>>> +  if (code[feature_cntr++]) features |= vcipher_m;
>>>>>>>
>>>>>>>       // Print the detection code.
>>>>>>>       if (PrintAssembly) {
>>>>>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp
>>>>>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016
>>>>>>> -0700
>>>>>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016
>>>>>>> +0200
>>>>>>> @@ -42,6 +42,7 @@
>>>>>>>         fcfids,
>>>>>>>         vand,
>>>>>>>         dcba,
>>>>>>> +    vcipher,
>>>>>>>         num_features // last entry to count features
>>>>>>>       };
>>>>>>>       enum Feature_Flag_Set {
>>>>>>> @@ -56,6 +57,7 @@
>>>>>>>         fcfids_m              = (1 << fcfids ),
>>>>>>>         vand_m                = (1 << vand   ),
>>>>>>>         dcba_m                = (1 << dcba   ),
>>>>>>> +    vcipher_m             = (1 << vcipher),
>>>>>>>         all_features_m        = -1
>>>>>>>       };
>>>>>>>       static int  _features;
>>>>>>> @@ -83,6 +85,7 @@
>>>>>>>       static bool has_fcfids()  { return (_features & fcfids_m) != 
0;
>>>>>>> }
>>>>>>>       static bool has_vand()    { return (_features & vand_m) != 
0; }
>>>>>>>       static bool has_dcba()    { return (_features & dcba_m) != 
0; }
>>>>>>> +  static bool has_vcipher() { return (_features & vcipher_m) != 
0; }
>>>>>>>
>>>>>>>       static const char* cpu_features() { return _features_str; }
>>>>>
>>>>>
>






From alexander.zvegintsev at oracle.com  Thu Aug 11 00:09:30 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 11 Aug 2016 03:09:30 +0300
Subject: [8u-dev] Request for approval: 8155690: Update libPNG library to the
	latest up-to-date
Message-ID: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>

Hello,

Please approve the backport, applied cleanly.

http://mail.openjdk.java.net/pipermail/awt-dev/2016-July/011718.html

https://bugs.openjdk.java.net/browse/JDK-8155690

http://hg.openjdk.java.net/jdk9/client/jdk/rev/ba155d4962c2


-- 
--
Thanks,
Alexander.


From david.buck at oracle.com  Thu Aug 11 04:15:13 2016
From: david.buck at oracle.com (david buck)
Date: Thu, 11 Aug 2016 13:15:13 +0900
Subject: [8u-dev] Request for approval: 8155690: Update libPNG library to
	the latest up-to-date
In-Reply-To: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
Message-ID: <a45d9a4b-9c03-d933-8851-fc82416dd5b6@oracle.com>

approved for push to 8u-dev after the appropriate noreg label has been 
added to the parent bug report in JBS.

[ noreg bug labels ]
http://openjdk.java.net/guide/changePlanning.html#noreg

Cheers,
-Buck

On 2016/08/11 9:09, Alexander Zvegintsev wrote:
> Hello,
>
> Please approve the backport, applied cleanly.
>
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-July/011718.html
>
> https://bugs.openjdk.java.net/browse/JDK-8155690
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ba155d4962c2
>
>

From rob.mckenna at oracle.com  Thu Aug 11 14:11:14 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 11 Aug 2016 15:11:14 +0100
Subject: [8u Communication] JDK 8u122 timeline
Message-ID: <20160811141114.GA4805@vimes>

Hi folks,

I've published a proposal for the key milestone dates relating to the 8u122 release:

http://openjdk.java.net/projects/jdk8u/releases/8u122.html

July 2016       8u-dev forest begins collecting 8u122 fixes (completed)
October 2016    RampDown 2
Jan 2017        GA

Note that these timelines are preliminary only and are subject to change. Please refer to the JDK 8 milestones definition page [1] for a summary of what each milestone consists of. Please submit feedback by Wednesday the 17th of August 2016.

Thanks,

       -Rob

From ivan.gerasimov at oracle.com  Thu Aug 11 14:31:49 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 11 Aug 2016 17:31:49 +0300
Subject: [8u-dev] Request for approval to backport: Integer overflow in
	StringBufferInputStream.read() and CharArrayReader.read/skip()
Message-ID: <e2a21159-6b9e-41f8-0002-a5cdad8e1e5f@oracle.com>

Hello!

I'd like to backport this fix to jdk8u-dev.

The unshuffled patch applies cleanly.

Bug: https://bugs.openjdk.java.net/browse/JDK-8163518
Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b3a8f572544
Jdk9 review: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042887.html 


Would you please approve?

With kind regards,
Ivan


From vicente.romero at oracle.com  Thu Aug 11 14:40:39 2016
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 11 Aug 2016 10:40:39 -0400
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
Message-ID: <d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>

Please review the following backport to 8udev. The jtreg test is 
different from the jdk9 version.

jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
backport: https://bugs.openjdk.java.net/browse/JDK-8163866
open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
jdk9 patch: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624

Thanks,
Vicente

From rob.mckenna at oracle.com  Thu Aug 11 15:43:00 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 11 Aug 2016 16:43:00 +0100
Subject: [8u-dev] Request for approval to backport: Integer overflow in
	StringBufferInputStream.read() and CharArrayReader.read/skip()
In-Reply-To: <e2a21159-6b9e-41f8-0002-a5cdad8e1e5f@oracle.com>
References: <e2a21159-6b9e-41f8-0002-a5cdad8e1e5f@oracle.com>
Message-ID: <20160811154300.GB4805@vimes>

Approved

	-Rob

On 11/08/16 05:31, Ivan Gerasimov wrote:
> Hello!
> 
> I'd like to backport this fix to jdk8u-dev.
> 
> The unshuffled patch applies cleanly.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163518
> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b3a8f572544
> Jdk9 review:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042887.html
> 
> 
> Would you please approve?
> 
> With kind regards,
> Ivan
> 

From ivan.gerasimov at oracle.com  Thu Aug 11 20:53:41 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 11 Aug 2016 23:53:41 +0300
Subject: [8u-dev] Request for approval to backport: 8163877: Tests added in
	JDK-8163518 fail on some platforms
In-Reply-To: <20160811154300.GB4805@vimes>
References: <e2a21159-6b9e-41f8-0002-a5cdad8e1e5f@oracle.com>
	<20160811154300.GB4805@vimes>
Message-ID: <e788571a-4189-de42-1b9d-fb1227bac688@oracle.com>

That was a bit too early to backport.

The tests was reported to fail in some environments.

Would you please approve the followup test fix, which prevents the tests 
from running with 32-bit JVM?

An alternative would be to @ignore these tests in jdk8u and below and 
leave them enabled only in jdk9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8163877
Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/997eb92cd683
Jdk9 review: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042897.html 


With kind regards,

Ivan

On 11.08.2016 18:43, Rob McKenna wrote:
> Approved
>
> 	-Rob
>
> On 11/08/16 05:31, Ivan Gerasimov wrote:
>> Hello!
>>
>> I'd like to backport this fix to jdk8u-dev.
>>
>> The unshuffled patch applies cleanly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163518
>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b3a8f572544
>> Jdk9 review:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042887.html
>>
>>
>> Would you please approve?
>>
>> With kind regards,
>> Ivan
>>


From rob.mckenna at oracle.com  Thu Aug 11 22:20:19 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 11 Aug 2016 23:20:19 +0100
Subject: [8u-dev] Request for approval to backport: 8163877: Tests added
	in JDK-8163518 fail on some platforms
In-Reply-To: <e788571a-4189-de42-1b9d-fb1227bac688@oracle.com>
References: <e2a21159-6b9e-41f8-0002-a5cdad8e1e5f@oracle.com>
	<20160811154300.GB4805@vimes>
	<e788571a-4189-de42-1b9d-fb1227bac688@oracle.com>
Message-ID: <20160811222019.GD4805@vimes>

Gah, 32 bit vm on a 64 bit os. That's caught me out before.

Approved,

	-Rob

On 11/08/16 11:53, Ivan Gerasimov wrote:
> That was a bit too early to backport.
> 
> The tests was reported to fail in some environments.
> 
> Would you please approve the followup test fix, which prevents the tests
> from running with 32-bit JVM?
> 
> An alternative would be to @ignore these tests in jdk8u and below and leave
> them enabled only in jdk9.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163877
> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/997eb92cd683
> Jdk9 review:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042897.html
> 
> 
> With kind regards,
> 
> Ivan
> 
> On 11.08.2016 18:43, Rob McKenna wrote:
> >Approved
> >
> >	-Rob
> >
> >On 11/08/16 05:31, Ivan Gerasimov wrote:
> >>Hello!
> >>
> >>I'd like to backport this fix to jdk8u-dev.
> >>
> >>The unshuffled patch applies cleanly.
> >>
> >>Bug: https://bugs.openjdk.java.net/browse/JDK-8163518
> >>Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4b3a8f572544
> >>Jdk9 review:
> >>http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042887.html
> >>
> >>
> >>Would you please approve?
> >>
> >>With kind regards,
> >>Ivan
> >>
> 

From mikhail.cherkasov at oracle.com  Fri Aug 12 16:00:00 2016
From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov)
Date: Fri, 12 Aug 2016 19:00:00 +0300
Subject: [8u-dev] Request for Approval: Review Request: 8160696,
	IllegalArgumentException: adding a component to a container on a
	different GraphicsDevice
Message-ID: <a8f1a565-7418-125c-bfb9-55789412d54f@oracle.com>

Hello,

Could you please approve a direct backport from jdk9 to 8:

jbs: https://bugs.openjdk.java.net/browse/JDK-8160696
changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/d5dc0c4fb473
review: 
http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011749.html
webrev: http://cr.openjdk.java.net/~mcherkas/8160696/8/webrev/

Thanks,
Mikhail.

From mikhail.cherkasov at oracle.com  Fri Aug 12 16:27:45 2016
From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov)
Date: Fri, 12 Aug 2016 19:27:45 +0300
Subject: [8u-dev] Request for Approval: 8160696 IllegalArgumentException:
	adding a component to a container on a different GraphicsDevice
In-Reply-To: <a8f1a565-7418-125c-bfb9-55789412d54f@oracle.com>
References: <a8f1a565-7418-125c-bfb9-55789412d54f@oracle.com>
Message-ID: <1af2e03f-8544-bd58-1877-2fabc65f953b@oracle.com>

sorry,  I sent it with wrong title, now I'm re-sending it with correct one.


On 12.08.2016 19:00, Mikhail Cherkasov wrote:
> Hello,
>
> Could you please approve a direct backport from jdk9 to 8:
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8160696
> changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/d5dc0c4fb473
> review: 
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011749.html
> webrev: http://cr.openjdk.java.net/~mcherkas/8160696/8/webrev/
>
> Thanks,
> Mikhail.


From rob.mckenna at oracle.com  Fri Aug 12 17:58:17 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 12 Aug 2016 18:58:17 +0100
Subject: [8u-dev] Request for Approval: 8160696 IllegalArgumentException:
	adding a component to a container on a different GraphicsDevice
In-Reply-To: <1af2e03f-8544-bd58-1877-2fabc65f953b@oracle.com>
References: <a8f1a565-7418-125c-bfb9-55789412d54f@oracle.com>
	<1af2e03f-8544-bd58-1877-2fabc65f953b@oracle.com>
Message-ID: <20160812175817.GB6338@vimes>

Approved

	-Rob

On 12/08/16 07:27, Mikhail Cherkasov wrote:
> sorry,  I sent it with wrong title, now I'm re-sending it with correct one.
> 
> 
> On 12.08.2016 19:00, Mikhail Cherkasov wrote:
> >Hello,
> >
> >Could you please approve a direct backport from jdk9 to 8:
> >
> >jbs: https://bugs.openjdk.java.net/browse/JDK-8160696
> >changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/d5dc0c4fb473
> >review:
> >http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011749.html
> >webrev: http://cr.openjdk.java.net/~mcherkas/8160696/8/webrev/
> >
> >Thanks,
> >Mikhail.
> 

From maurizio.cimadamore at oracle.com  Mon Aug 15 16:16:42 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 15 Aug 2016 17:16:42 +0100
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
	<d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
Message-ID: <c08a400c-3394-fa96-f759-04c5bf3055f8@oracle.com>

The tests seem to belong to the wrong folder? I.e. they should be in a 
folder whose name matches the package name?

Maurizio


On 11/08/16 15:40, Vicente-Arturo Romero-Zaldivar wrote:
> Please review the following backport to 8udev. The jtreg test is 
> different from the jdk9 version.
>
> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
> backport: https://bugs.openjdk.java.net/browse/JDK-8163866
> open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
> jdk9 patch: 
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624
>
> Thanks,
> Vicente


From vicente.romero at oracle.com  Mon Aug 15 16:31:47 2016
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 15 Aug 2016 12:31:47 -0400
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <c08a400c-3394-fa96-f759-04c5bf3055f8@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
	<d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
	<c08a400c-3394-fa96-f759-04c5bf3055f8@oracle.com>
Message-ID: <7d099f1f-d097-20d5-75a0-48cb4cd6134c@oracle.com>

On 08/15/2016 12:16 PM, Maurizio Cimadamore wrote:
> The tests seem to belong to the wrong folder? I.e. they should be in a 
> folder whose name matches the package name?

You can do it for clarity but it's not strictly necessary. Javac will 
generate the right class file structure

>
> Maurizio

Vicente

>
>
> On 11/08/16 15:40, Vicente-Arturo Romero-Zaldivar wrote:
>> Please review the following backport to 8udev. The jtreg test is 
>> different from the jdk9 version.
>>
>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
>> backport: https://bugs.openjdk.java.net/browse/JDK-8163866
>> open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
>> jdk9 patch: 
>> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624
>>
>> Thanks,
>> Vicente
>


From maurizio.cimadamore at oracle.com  Mon Aug 15 23:17:58 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 Aug 2016 00:17:58 +0100
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <7d099f1f-d097-20d5-75a0-48cb4cd6134c@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
	<d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
	<c08a400c-3394-fa96-f759-04c5bf3055f8@oracle.com>
	<7d099f1f-d097-20d5-75a0-48cb4cd6134c@oracle.com>
Message-ID: <7ce1cfe1-917c-3d35-f859-75d612b6bcef@oracle.com>



On 15/08/16 17:31, Vicente-Arturo Romero-Zaldivar wrote:
> On 08/15/2016 12:16 PM, Maurizio Cimadamore wrote:
>> The tests seem to belong to the wrong folder? I.e. they should be in 
>> a folder whose name matches the package name?
>
> You can do it for clarity but it's not strictly necessary. Javac will 
> generate the right class file structure
I tried to replicate that structure in a local folder and I got this:

$ javac LetExpressionsAreUnnecessarilyGeneratedTest.java
$ javac Sub.java
Sub.java:3: error: package base does not exist
    import base.LetExpressionsAreUnnecessarilyGeneratedTest;
               ^
Sub.java:5: error: cannot find symbol
    public class Sub extends LetExpressionsAreUnnecessarilyGeneratedTest {
                             ^
   symbol: class LetExpressionsAreUnnecessarilyGeneratedTest
Sub.java:10: error: not an enclosing class: Sub
                    Sub.super.i += 10;
                       ^
3 errors

What am I missing?

Maurizio
>
>>
>> Maurizio
>
> Vicente
>
>>
>>
>> On 11/08/16 15:40, Vicente-Arturo Romero-Zaldivar wrote:
>>> Please review the following backport to 8udev. The jtreg test is 
>>> different from the jdk9 version.
>>>
>>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
>>> backport: https://bugs.openjdk.java.net/browse/JDK-8163866
>>> open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
>>> jdk9 patch: 
>>> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624
>>>
>>> Thanks,
>>> Vicente
>>
>


From maurizio.cimadamore at oracle.com  Mon Aug 15 23:25:46 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 Aug 2016 00:25:46 +0100
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <7ce1cfe1-917c-3d35-f859-75d612b6bcef@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
	<d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
	<c08a400c-3394-fa96-f759-04c5bf3055f8@oracle.com>
	<7d099f1f-d097-20d5-75a0-48cb4cd6134c@oracle.com>
	<7ce1cfe1-917c-3d35-f859-75d612b6bcef@oracle.com>
Message-ID: <fcec8eb0-d1c4-c63c-9753-a97de7138862@oracle.com>

Ah ok - the right directory structure is only created if -d is specified 
(which is used by jtreg) - which is normal javac behavior (which I keep 
forgetting about :-)).

Maurizio


On 16/08/16 00:17, Maurizio Cimadamore wrote:
>
>
> On 15/08/16 17:31, Vicente-Arturo Romero-Zaldivar wrote:
>> On 08/15/2016 12:16 PM, Maurizio Cimadamore wrote:
>>> The tests seem to belong to the wrong folder? I.e. they should be in 
>>> a folder whose name matches the package name?
>>
>> You can do it for clarity but it's not strictly necessary. Javac will 
>> generate the right class file structure
> I tried to replicate that structure in a local folder and I got this:
>
> $ javac LetExpressionsAreUnnecessarilyGeneratedTest.java
> $ javac Sub.java
> Sub.java:3: error: package base does not exist
>    import base.LetExpressionsAreUnnecessarilyGeneratedTest;
>               ^
> Sub.java:5: error: cannot find symbol
>    public class Sub extends LetExpressionsAreUnnecessarilyGeneratedTest {
>                             ^
>   symbol: class LetExpressionsAreUnnecessarilyGeneratedTest
> Sub.java:10: error: not an enclosing class: Sub
>                    Sub.super.i += 10;
>                       ^
> 3 errors
>
> What am I missing?
>
> Maurizio
>>
>>>
>>> Maurizio
>>
>> Vicente
>>
>>>
>>>
>>> On 11/08/16 15:40, Vicente-Arturo Romero-Zaldivar wrote:
>>>> Please review the following backport to 8udev. The jtreg test is 
>>>> different from the jdk9 version.
>>>>
>>>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
>>>> backport: https://bugs.openjdk.java.net/browse/JDK-8163866
>>>> open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
>>>> jdk9 patch: 
>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624
>>>>
>>>> Thanks,
>>>> Vicente
>>>
>>
>


From maurizio.cimadamore at oracle.com  Mon Aug 15 23:26:11 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 Aug 2016 00:26:11 +0100
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
	<d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
Message-ID: <7a9c56df-5355-4748-cdb5-2016aa86d85f@oracle.com>

Looks ok

Maurizio


On 11/08/16 15:40, Vicente-Arturo Romero-Zaldivar wrote:
> Please review the following backport to 8udev. The jtreg test is 
> different from the jdk9 version.
>
> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
> backport: https://bugs.openjdk.java.net/browse/JDK-8163866
> open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
> jdk9 patch: 
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624
>
> Thanks,
> Vicente


From vicente.romero at oracle.com  Tue Aug 16 02:35:09 2016
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 15 Aug 2016 22:35:09 -0400
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <fcec8eb0-d1c4-c63c-9753-a97de7138862@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
	<d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
	<c08a400c-3394-fa96-f759-04c5bf3055f8@oracle.com>
	<7d099f1f-d097-20d5-75a0-48cb4cd6134c@oracle.com>
	<7ce1cfe1-917c-3d35-f859-75d612b6bcef@oracle.com>
	<fcec8eb0-d1c4-c63c-9753-a97de7138862@oracle.com>
Message-ID: <d82103df-3f58-ed48-6a7b-9d9684a97c6d@oracle.com>

On 08/15/2016 07:25 PM, Maurizio Cimadamore wrote:
> Ah ok - the right directory structure is only created if -d is 
> specified (which is used by jtreg) - which is normal javac behavior 
> (which I keep forgetting about :-)).

yep that's correct

>
> Maurizio

Vicente

>
>
> On 16/08/16 00:17, Maurizio Cimadamore wrote:
>>
>>
>> On 15/08/16 17:31, Vicente-Arturo Romero-Zaldivar wrote:
>>> On 08/15/2016 12:16 PM, Maurizio Cimadamore wrote:
>>>> The tests seem to belong to the wrong folder? I.e. they should be 
>>>> in a folder whose name matches the package name?
>>>
>>> You can do it for clarity but it's not strictly necessary. Javac 
>>> will generate the right class file structure
>> I tried to replicate that structure in a local folder and I got this:
>>
>> $ javac LetExpressionsAreUnnecessarilyGeneratedTest.java
>> $ javac Sub.java
>> Sub.java:3: error: package base does not exist
>>    import base.LetExpressionsAreUnnecessarilyGeneratedTest;
>>               ^
>> Sub.java:5: error: cannot find symbol
>>    public class Sub extends 
>> LetExpressionsAreUnnecessarilyGeneratedTest {
>>                             ^
>>   symbol: class LetExpressionsAreUnnecessarilyGeneratedTest
>> Sub.java:10: error: not an enclosing class: Sub
>>                    Sub.super.i += 10;
>>                       ^
>> 3 errors
>>
>> What am I missing?
>>
>> Maurizio
>>>
>>>>
>>>> Maurizio
>>>
>>> Vicente
>>>
>>>>
>>>>
>>>> On 11/08/16 15:40, Vicente-Arturo Romero-Zaldivar wrote:
>>>>> Please review the following backport to 8udev. The jtreg test is 
>>>>> different from the jdk9 version.
>>>>>
>>>>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
>>>>> backport: https://bugs.openjdk.java.net/browse/JDK-8163866
>>>>> open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
>>>>> jdk9 patch: 
>>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624
>>>>>
>>>>> Thanks,
>>>>> Vicente
>>>>
>>>
>>
>


From vicente.romero at oracle.com  Tue Aug 16 02:35:31 2016
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 15 Aug 2016 22:35:31 -0400
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <7a9c56df-5355-4748-cdb5-2016aa86d85f@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
	<d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
	<7a9c56df-5355-4748-cdb5-2016aa86d85f@oracle.com>
Message-ID: <92b1dfd7-04d1-93a9-c16b-aecd6eb0826d@oracle.com>

On 08/15/2016 07:26 PM, Maurizio Cimadamore wrote:
> Looks ok

Thanks,
>
> Maurizio

Vicente

>
>
> On 11/08/16 15:40, Vicente-Arturo Romero-Zaldivar wrote:
>> Please review the following backport to 8udev. The jtreg test is 
>> different from the jdk9 version.
>>
>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
>> backport: https://bugs.openjdk.java.net/browse/JDK-8163866
>> open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
>> jdk9 patch: 
>> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624
>>
>> Thanks,
>> Vicente
>


From shafi.s.ahmad at oracle.com  Tue Aug 16 04:28:08 2016
From: shafi.s.ahmad at oracle.com (Shafi Ahmad)
Date: Mon, 15 Aug 2016 21:28:08 -0700 (PDT)
Subject: [8u] RFA for JDK-8162419:
	closed/com/oracle/jfr/runtime/TestVMInfoEvent.sh failing after
	JDK-8155968
Message-ID: <18a0a10e-2bb5-4724-8dca-3b8101a47723@default>

Hi,

Please approve the code change for bug '' JDK-8162419: closed/com/oracle/jfr/runtime/TestVMInfoEvent.sh failing after JDK-8155968" to jdk8u-dev

Jdk8 Bug: https://bugs.openjdk.java.net/browse/JDK-8162419
Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-August/020604.html
Webrev link: http://cr.openjdk.java.net/~shshahma/8162419/webrev.01/

Regards,
Shafi

From david.buck at oracle.com  Tue Aug 16 04:59:20 2016
From: david.buck at oracle.com (david buck)
Date: Tue, 16 Aug 2016 13:59:20 +0900
Subject: [8u] RFA for JDK-8162419:
	closed/com/oracle/jfr/runtime/TestVMInfoEvent.sh failing after
	JDK-8155968
In-Reply-To: <18a0a10e-2bb5-4724-8dca-3b8101a47723@default>
References: <18a0a10e-2bb5-4724-8dca-3b8101a47723@default>
Message-ID: <ca37b3f9-5726-bf44-bcc2-f7c08d11f531@oracle.com>

approved for push to 8u-dev

Cheers,
-Buck

On 2016/08/16 13:28, Shafi Ahmad wrote:
> Hi,
>
> Please approve the code change for bug '' JDK-8162419: closed/com/oracle/jfr/runtime/TestVMInfoEvent.sh failing after JDK-8155968" to jdk8u-dev
>
> Jdk8 Bug: https://bugs.openjdk.java.net/browse/JDK-8162419
> Review link: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-August/020604.html
> Webrev link: http://cr.openjdk.java.net/~shshahma/8162419/webrev.01/
>
> Regards,
> Shafi
>

From david.buck at oracle.com  Tue Aug 16 05:02:27 2016
From: david.buck at oracle.com (david buck)
Date: Tue, 16 Aug 2016 14:02:27 +0900
Subject: [8u-dev] Request for review: 8160156: javac is generating let
	expressions unnecessarily
In-Reply-To: <92b1dfd7-04d1-93a9-c16b-aecd6eb0826d@oracle.com>
References: <29b9d643-4711-8ad9-b7b0-fafb892f54be@oracle.com>
	<d82b16f2-7dd5-7b3e-a306-cda14ff0fba8@oracle.com>
	<7a9c56df-5355-4748-cdb5-2016aa86d85f@oracle.com>
	<92b1dfd7-04d1-93a9-c16b-aecd6eb0826d@oracle.com>
Message-ID: <f99871b2-560d-af88-620a-004621cf7a60@oracle.com>

approved for push to 8u-dev

Cheers,
-Buck

On 2016/08/16 11:35, Vicente-Arturo Romero-Zaldivar wrote:
> On 08/15/2016 07:26 PM, Maurizio Cimadamore wrote:
>> Looks ok
>
> Thanks,
>>
>> Maurizio
>
> Vicente
>
>>
>>
>> On 11/08/16 15:40, Vicente-Arturo Romero-Zaldivar wrote:
>>> Please review the following backport to 8udev. The jtreg test is
>>> different from the jdk9 version.
>>>
>>> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8160156
>>> backport: https://bugs.openjdk.java.net/browse/JDK-8163866
>>> open webrev: http://cr.openjdk.java.net/~vromero/8160156/webrev.00/
>>> jdk9 patch:
>>> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/88cc9b782624
>>>
>>> Thanks,
>>> Vicente
>>
>

From dmitry.markov at oracle.com  Tue Aug 16 08:53:26 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Tue, 16 Aug 2016 11:53:26 +0300
Subject: [8u-dev] Request for approval 8163583: [macosx] Press "To Back" button
	on the Dialog,the Dialog moves behind the Frame
Message-ID: <57B2D486.8060405@oracle.com>

Hello,

Could you approve the back-port of the fix for 8163583 to jdk8u-dev, 
please? The jdk9 patch applies cleanly except the changes in the 
regression tests, since the tests are absent in jdk8u-dev repository.

The bug:
https://bugs.openjdk.java.net/browse/JDK-8163583
The webrev:
http://cr.openjdk.java.net/~dmarkov/8163583/jdk8u/webrev.00/
The review thread:
http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011776.html
The jdk9 changeset:
http://hg.openjdk.java.net/jdk9/client/jdk/rev/8e78c621a64d

Thanks,
Dmitry

From christoph.langer at sap.com  Tue Aug 16 10:09:26 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 16 Aug 2016 10:09:26 +0000
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes and
	improvements for network interface listing
Message-ID: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>

Hi,



can I get approval for backporting the following fix:



Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174

Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12

Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-dev/2016-July/010100.html



I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev. This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/



I ran builds on all Linux platforms and verified the results.



Thanks a lot and best regards,

Christoph


From svetlana.nikandrova at oracle.com  Tue Aug 16 12:15:22 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Tue, 16 Aug 2016 15:15:22 +0300
Subject: [8u-dev] Request for Approval 8145732: Duplicate entry in
	http.nonProxyHosts will ignore subsequent entries - test update
Message-ID: <57B303DA.8050602@oracle.com>

Hello,

please approve the direct backport of test update. Applied cleanly.

JBS: https://bugs.openjdk.java.net/browse/JDK-8145732
JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/011f83649452
JDK 9 review thread: 
http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010143.html

Thank you,
Svetlana

From hannes.wallnoefer at oracle.com  Tue Aug 16 13:39:31 2016
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 16 Aug 2016 15:39:31 +0200
Subject: [8u-dev] Request for Approval: 8163945: Honor Number type hint in
	toPrimitive on Numbers
Message-ID: <a161d938-4ae5-7365-d1fa-6672e5a5de79@oracle.com>

Please approve backport of 8163945 to 8u-dev.

Bug: https://bugs.openjdk.java.net/browse/JDK-8163945
Webrev: http://cr.openjdk.java.net/~hannesw/8163945/webrev/
Review thread: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-August/006440.html

Changes apply cleanly to jdk8u-dev after path reshuffling.

Thanks,
Hannes


From james.laskey at oracle.com  Tue Aug 16 13:40:18 2016
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 16 Aug 2016 10:40:18 -0300
Subject: [8u-dev] Request for Approval: 8163945: Honor Number type hint in
	toPrimitive on Numbers
In-Reply-To: <a161d938-4ae5-7365-d1fa-6672e5a5de79@oracle.com>
References: <a161d938-4ae5-7365-d1fa-6672e5a5de79@oracle.com>
Message-ID: <268CA386-1AB4-445B-AC88-1499C7AFC298@oracle.com>

+1

> On Aug 16, 2016, at 10:39 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please approve backport of 8163945 to 8u-dev.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163945
> Webrev: http://cr.openjdk.java.net/~hannesw/8163945/webrev/
> Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-August/006440.html
> 
> Changes apply cleanly to jdk8u-dev after path reshuffling.
> 
> Thanks,
> Hannes
> 


From rob.mckenna at oracle.com  Tue Aug 16 14:41:26 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 Aug 2016 15:41:26 +0100
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
Message-ID: <20160816144126.GB4783@vimes>

Hi Christoph,

If the patch has changed from 9 you will need a separate review.

	-Rob

On 16/08/16 10:09, Langer, Christoph wrote:
> Hi,
> 
> 
> 
> can I get approval for backporting the following fix:
> 
> 
> 
> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
> 
> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
> 
> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-dev/2016-July/010100.html
> 
> 
> 
> I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev. This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
> 
> 
> 
> I ran builds on all Linux platforms and verified the results.
> 
> 
> 
> Thanks a lot and best regards,
> 
> Christoph
> 

From rob.mckenna at oracle.com  Tue Aug 16 14:43:37 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 Aug 2016 15:43:37 +0100
Subject: [8u-dev] Request for approval 8163583: [macosx] Press "To Back"
	button on the Dialog,the Dialog moves behind the Frame
In-Reply-To: <57B2D486.8060405@oracle.com>
References: <57B2D486.8060405@oracle.com>
Message-ID: <20160816144337.GC4783@vimes>

Approved

	-Rob

On 16/08/16 11:53, dmitry markov wrote:
> Hello,
> 
> Could you approve the back-port of the fix for 8163583 to jdk8u-dev, please?
> The jdk9 patch applies cleanly except the changes in the regression tests,
> since the tests are absent in jdk8u-dev repository.
> 
> The bug:
> https://bugs.openjdk.java.net/browse/JDK-8163583
> The webrev:
> http://cr.openjdk.java.net/~dmarkov/8163583/jdk8u/webrev.00/
> The review thread:
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011776.html
> The jdk9 changeset:
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8e78c621a64d
> 
> Thanks,
> Dmitry

From rob.mckenna at oracle.com  Tue Aug 16 14:45:05 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 Aug 2016 15:45:05 +0100
Subject: [8u-dev] Request for Approval 8145732: Duplicate entry in
	http.nonProxyHosts will ignore subsequent entries - test update
In-Reply-To: <57B303DA.8050602@oracle.com>
References: <57B303DA.8050602@oracle.com>
Message-ID: <20160816144505.GD4783@vimes>

Approved

	-Rob

On 16/08/16 03:15, Svetlana Nikandrova wrote:
> Hello,
> 
> please approve the direct backport of test update. Applied cleanly.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8145732
> JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/011f83649452
> JDK 9 review thread:
> http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010143.html
> 
> Thank you,
> Svetlana

From rob.mckenna at oracle.com  Tue Aug 16 14:45:49 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 Aug 2016 15:45:49 +0100
Subject: [8u-dev] Request for Approval: 8163945: Honor Number type hint
	in toPrimitive on Numbers
In-Reply-To: <a161d938-4ae5-7365-d1fa-6672e5a5de79@oracle.com>
References: <a161d938-4ae5-7365-d1fa-6672e5a5de79@oracle.com>
Message-ID: <20160816144549.GE4783@vimes>

Approved

	-Rob

On 16/08/16 03:39, Hannes Wallnoefer wrote:
> Please approve backport of 8163945 to 8u-dev.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163945
> Webrev: http://cr.openjdk.java.net/~hannesw/8163945/webrev/
> Review thread:
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-August/006440.html
> 
> Changes apply cleanly to jdk8u-dev after path reshuffling.
> 
> Thanks,
> Hannes
> 

From mikhail.cherkasov at oracle.com  Tue Aug 16 17:04:01 2016
From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov)
Date: Tue, 16 Aug 2016 20:04:01 +0300
Subject: [8u-dev] Request for Review and Approval for 8164119
	MoveToOtherScreenTest fails due wrong key attribute
Message-ID: <301a1cc1-b341-3737-b1ff-a57707567150@oracle.com>

Hi all,

I haven't removed the "@key headful" that isn't included into TEST.ROOT 
in jdk8, as result test fails with an error:

bugdb: https://bugs.openjdk.java.net/browse/JDK-8164119
webrev: 
http://cr.openjdk.java.net/~mcherkas/8164119/webrev/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.udiff.html

Thanks,
Mikhail.

From alexander.zvegintsev at oracle.com  Tue Aug 16 19:18:29 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 16 Aug 2016 22:18:29 +0300
Subject: [8u-dev] Request for approval: 8155691: Update GIFlib library to the
	latest up-to-date
Message-ID: <80ab1358-349f-c672-83d8-b8f67283fde1@oracle.com>

Hello,

Please approve the backport, applied cleanly.

http://mail.openjdk.java.net/pipermail/awt-dev/2016-July/011719.html

https://bugs.openjdk.java.net/browse/JDK-8155691

http://hg.openjdk.java.net/jdk9/client/jdk/rev/c07be59d7160


-- 
--
Thanks,
Alexander.


From david.buck at oracle.com  Wed Aug 17 08:03:27 2016
From: david.buck at oracle.com (david buck)
Date: Wed, 17 Aug 2016 17:03:27 +0900
Subject: [8u-dev] Request for approval: 8155691: Update GIFlib library to
	the latest up-to-date
In-Reply-To: <80ab1358-349f-c672-83d8-b8f67283fde1@oracle.com>
References: <80ab1358-349f-c672-83d8-b8f67283fde1@oracle.com>
Message-ID: <7f10fed1-2fe1-a66b-658f-12dd2d57f6c3@oracle.com>

approved for backport to 8u-dev

Cheers,
-Buck

On 2016/08/17 4:18, Alexander Zvegintsev wrote:
> Hello,
>
> Please approve the backport, applied cleanly.
>
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-July/011719.html
>
> https://bugs.openjdk.java.net/browse/JDK-8155691
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c07be59d7160
>
>

From rwestrel at redhat.com  Wed Aug 17 15:00:18 2016
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 17 Aug 2016 17:00:18 +0200
Subject: [8u] request for approval: "8162384: Performance regression:
	bimorphic inlining may be bypassed by type speculation"
Message-ID: <dk64m6jwid9.fsf@rwestrel.remote.csb>


Hi,

I'd like to backport 8162384 to 8u as it's an issue reported by one of
our (Red Hat) customers. The patch applies cleanly. It was pushed to
jdk9 3 weeks ago and hasn't caused any follow up bugs that I know of.

https://bugs.openjdk.java.net/browse/JDK-8162384
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e9f9f6ffc351

8u webrev:

http://cr.openjdk.java.net/~roland/8162384.8u/webrev.00/

Roland.

From rwestrel at redhat.com  Wed Aug 17 16:54:52 2016
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 17 Aug 2016 18:54:52 +0200
Subject: [8u] request for approval: "8162384: Performance regression:
	bimorphic inlining may be bypassed by type speculation"
Message-ID: <dk637m3bajn.fsf@rwestrel.remote.csb>


(resending as I wasn't on jdk8u-dev when I sent this before)

Hi,

I'd like to backport 8162384 to 8u as it's an issue reported by one of
our (Red Hat) customers. The patch applies cleanly. It was pushed to
jdk9 3 weeks ago and hasn't caused any follow up bugs that I know of.

https://bugs.openjdk.java.net/browse/JDK-8162384
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e9f9f6ffc351

8u webrev:

http://cr.openjdk.java.net/~roland/8162384.8u/webrev.00/

Roland.

From vladimir.kozlov at oracle.com  Wed Aug 17 18:46:33 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Aug 2016 11:46:33 -0700
Subject: [8u] request for approval: "8162384: Performance regression:
	bimorphic inlining may be bypassed by type speculation"
In-Reply-To: <dk637m3bajn.fsf@rwestrel.remote.csb>
References: <dk637m3bajn.fsf@rwestrel.remote.csb>
Message-ID: <57B4B109.1040808@oracle.com>

Looks good. You would be asked for the test. Please, provide keyword and reason for no test.

Thanks,
Vladimir

On 8/17/16 9:54 AM, Roland Westrelin wrote:
>
> (resending as I wasn't on jdk8u-dev when I sent this before)
>
> Hi,
>
> I'd like to backport 8162384 to 8u as it's an issue reported by one of
> our (Red Hat) customers. The patch applies cleanly. It was pushed to
> jdk9 3 weeks ago and hasn't caused any follow up bugs that I know of.
>
> https://bugs.openjdk.java.net/browse/JDK-8162384
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e9f9f6ffc351
>
> 8u webrev:
>
> http://cr.openjdk.java.net/~roland/8162384.8u/webrev.00/
>
> Roland.
>

From adisheshsm at gmail.com  Thu Aug 18 05:10:13 2016
From: adisheshsm at gmail.com (Adishesh M)
Date: Thu, 18 Aug 2016 10:40:13 +0530
Subject: Regarding life cycle of openJDK 8u
Message-ID: <CA+f1OFpYG4aFc2pLkHDj504=4DjvWd3YvCnbDDdyRWcAVOO9tw@mail.gmail.com>

Hi,

Currently I am  using 8u92 openJDK version.

when will support for this version ends.
In general how the support for older version of openJDK 8 updates are
handled. whenever new 8u update is available support for older 8u release
ends?


if this is already documented, please redirect me to it.


thanks and regards,
Adishesh

From ramanand.patil at oracle.com  Thu Aug 18 05:34:35 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Wed, 17 Aug 2016 22:34:35 -0700 (PDT)
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
Message-ID: <e197c9b4-c813-4780-a5ef-de867d24171d@default>

Hi,

Please review and approve the backport of 8144566 to 8u-dev.

Bug: https://bugs.openjdk.java.net/browse/JDK-8144566

JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3

JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013171.html

JDK8u-dev Webrev: http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/

Changes apply semi-cleanly to jdk8u-dev after path reshuffling. Below are few reasons for manual edits in the jdk8u-dev patch:

1. JDK9 class name for "JavaNetAccess" is changed to " JavaNetInetAddressAccess".
2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
3. test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.


Regards,
Ramanand.

From david.buck at oracle.com  Thu Aug 18 06:03:36 2016
From: david.buck at oracle.com (David Buck)
Date: Thu, 18 Aug 2016 15:03:36 +0900
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
In-Reply-To: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
References: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
Message-ID: <9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>

Hi Ramanand!

As there are (minor) changes between the two change sets, you will need to get a code review of the backported changes. I have included the security-dev alias in the CC list.

Cheers,
-Buck

> On Aug 18, 2016, at 14:34, Ramanand Patil <ramanand.patil at oracle.com> wrote:
> 
> Hi,
> 
> Please review and approve the backport of 8144566 to 8u-dev.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144566
> 
> JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3
> 
> JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013171.html
> 
> JDK8u-dev Webrev: http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/
> 
> Changes apply semi-cleanly to jdk8u-dev after path reshuffling. Below are few reasons for manual edits in the jdk8u-dev patch:
> 
> 1. JDK9 class name for "JavaNetAccess" is changed to " JavaNetInetAddressAccess".
> 2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
> 3. test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
> 
> 
> Regards,
> Ramanand.


From mallikarjuna.avaluri at oracle.com  Thu Aug 18 06:07:10 2016
From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri)
Date: Thu, 18 Aug 2016 11:37:10 +0530
Subject: Request for approval: JDK-8160913: [TEST_BUG]
	javax/management/security/SecurityTest.java fails due to missing
	keyStore file
Message-ID: <dc1df699-bb81-87f0-40c7-3addd424ad5e@oracle.com>

Hi all,

Please Approve the fix for following issue.

JDK-8160913: [TEST_BUG] javax/management/security/SecurityTest.java 
fails due to missing keyStore file
https://bugs.openjdk.java.net/browse/JDK-8160913

Fix:  Following files keystoreAgent, keystoreClient, truststoreAgent and 
truststoreClient were created under jdk/test/javax/management/ folder,
while test expects them under jdk/test/javax/management/security/ path. 
Moved the files to correct folder.

Webrev: 
http://cr.openjdk.java.net/~bgopularam/mavaluri/rev/8160913/webrev.00/ 
<http://cr.openjdk.java.net/%7Ebgopularam/mavaluri/rev/8160913/webrev.00/>


Thanks,
Mallikarjuna Avaluri


From sean.coffey at oracle.com  Thu Aug 18 07:51:58 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 18 Aug 2016 08:51:58 +0100
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
In-Reply-To: <9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>
References: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
	<9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>
Message-ID: <e28d8b3a-0c0b-8b26-4031-7085424f6809@oracle.com>

Changes look good Ramanand. Reviewed.

Regards,
Sean.

On 18/08/2016 07:03, David Buck wrote:
> Hi Ramanand!
>
> As there are (minor) changes between the two change sets, you will need to get a code review of the backported changes. I have included the security-dev alias in the CC list.
>
> Cheers,
> -Buck
>
>> On Aug 18, 2016, at 14:34, Ramanand Patil <ramanand.patil at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review and approve the backport of 8144566 to 8u-dev.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144566
>>
>> JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3
>>
>> JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013171.html
>>
>> JDK8u-dev Webrev: http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/
>>
>> Changes apply semi-cleanly to jdk8u-dev after path reshuffling. Below are few reasons for manual edits in the jdk8u-dev patch:
>>
>> 1. JDK9 class name for "JavaNetAccess" is changed to " JavaNetInetAddressAccess".
>> 2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
>> 3. test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
>>
>>
>> Regards,
>> Ramanand.


From david.buck at oracle.com  Thu Aug 18 07:55:31 2016
From: david.buck at oracle.com (david buck)
Date: Thu, 18 Aug 2016 16:55:31 +0900
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
In-Reply-To: <e28d8b3a-0c0b-8b26-4031-7085424f6809@oracle.com>
References: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
	<9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>
	<e28d8b3a-0c0b-8b26-4031-7085424f6809@oracle.com>
Message-ID: <fb44f429-fc6a-e68c-7f13-e473d641a078@oracle.com>

approved for push to 8u-dev

Cheers,
-Buck

On 2016/08/18 16:51, Se?n Coffey wrote:
> Changes look good Ramanand. Reviewed.
>
> Regards,
> Sean.
>
> On 18/08/2016 07:03, David Buck wrote:
>> Hi Ramanand!
>>
>> As there are (minor) changes between the two change sets, you will
>> need to get a code review of the backported changes. I have included
>> the security-dev alias in the CC list.
>>
>> Cheers,
>> -Buck
>>
>>> On Aug 18, 2016, at 14:34, Ramanand Patil <ramanand.patil at oracle.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please review and approve the backport of 8144566 to 8u-dev.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144566
>>>
>>> JDK9 Changeset:
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3
>>>
>>> JDK9 Review Thread:
>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013171.html
>>>
>>>
>>> JDK8u-dev Webrev: http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/
>>>
>>> Changes apply semi-cleanly to jdk8u-dev after path reshuffling. Below
>>> are few reasons for manual edits in the jdk8u-dev patch:
>>>
>>> 1. JDK9 class name for "JavaNetAccess" is changed to "
>>> JavaNetInetAddressAccess".
>>> 2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java
>>> pathToStores(keystore path) doesn't exist in JDK8u, hence changed the
>>> variable to point to available path.
>>> 3.
>>> test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java
>>> pathToStores(keystore path) doesn't exist in JDK8u, hence changed the
>>> variable to point to available path.
>>>
>>>
>>> Regards,
>>> Ramanand.
>

From ramanand.patil at oracle.com  Thu Aug 18 07:57:01 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Thu, 18 Aug 2016 00:57:01 -0700 (PDT)
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
In-Reply-To: <fb44f429-fc6a-e68c-7f13-e473d641a078@oracle.com>
References: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
	<9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>
	<e28d8b3a-0c0b-8b26-4031-7085424f6809@oracle.com>
	<fb44f429-fc6a-e68c-7f13-e473d641a078@oracle.com>
Message-ID: <3191d787-dc45-4584-b99d-b717afdfa96c@default>

Thank you Sean and David.

Regards,
Ramanand.

-----Original Message-----
From: david buck 
Sent: Thursday, August 18, 2016 1:26 PM
To: Se?n Coffey; Ramanand Patil
Cc: jdk8u-dev; security-dev at openjdk.java.net
Subject: Re: [8u-dev] Request for Approval: Backport of 8144566: Custom HostnameVerifier disables SNI extension

approved for push to 8u-dev

Cheers,
-Buck

On 2016/08/18 16:51, Se?n Coffey wrote:
> Changes look good Ramanand. Reviewed.
>
> Regards,
> Sean.
>
> On 18/08/2016 07:03, David Buck wrote:
>> Hi Ramanand!
>>
>> As there are (minor) changes between the two change sets, you will 
>> need to get a code review of the backported changes. I have included 
>> the security-dev alias in the CC list.
>>
>> Cheers,
>> -Buck
>>
>>> On Aug 18, 2016, at 14:34, Ramanand Patil 
>>> <ramanand.patil at oracle.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please review and approve the backport of 8144566 to 8u-dev.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144566
>>>
>>> JDK9 Changeset:
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3
>>>
>>> JDK9 Review Thread:
>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-December/01
>>> 3171.html
>>>
>>>
>>> JDK8u-dev Webrev: 
>>> http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/
>>>
>>> Changes apply semi-cleanly to jdk8u-dev after path reshuffling. 
>>> Below are few reasons for manual edits in the jdk8u-dev patch:
>>>
>>> 1. JDK9 class name for "JavaNetAccess" is changed to "
>>> JavaNetInetAddressAccess".
>>> 2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java
>>> pathToStores(keystore path) doesn't exist in JDK8u, hence changed 
>>> the variable to point to available path.
>>> 3.
>>> test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java
>>> pathToStores(keystore path) doesn't exist in JDK8u, hence changed 
>>> the variable to point to available path.
>>>
>>>
>>> Regards,
>>> Ramanand.
>

From sean.coffey at oracle.com  Thu Aug 18 12:42:32 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 18 Aug 2016 13:42:32 +0100
Subject: [8u-dev] Request for Review and Approval for 8164119
	MoveToOtherScreenTest fails due wrong key attribute
In-Reply-To: <301a1cc1-b341-3737-b1ff-a57707567150@oracle.com>
References: <301a1cc1-b341-3737-b1ff-a57707567150@oracle.com>
Message-ID: <d11d62e6-5435-7a60-10a2-5f5b40a22aef@oracle.com>

Looks fine. I would prefer if you dropped the 8164119 reference from the 
@bug tag. Generally, that's used for product bug IDs AFAIK. noreg-self 
could be added to bug report as an alternative. Please add 9-na label to 
bug report also.

Approved.

Regards,
Sean.

On 16/08/2016 18:04, Mikhail Cherkasov wrote:
> Hi all,
>
> I haven't removed the "@key headful" that isn't included into 
> TEST.ROOT in jdk8, as result test fails with an error:
>
> bugdb: https://bugs.openjdk.java.net/browse/JDK-8164119
> webrev: 
> http://cr.openjdk.java.net/~mcherkas/8164119/webrev/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.udiff.html
>
> Thanks,
> Mikhail.


From mikhail.cherkasov at oracle.com  Thu Aug 18 13:05:36 2016
From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov)
Date: Thu, 18 Aug 2016 16:05:36 +0300
Subject: [8u-dev] Request for Review and Approval for 8164119
	MoveToOtherScreenTest fails due wrong key attribute
In-Reply-To: <d11d62e6-5435-7a60-10a2-5f5b40a22aef@oracle.com>
References: <301a1cc1-b341-3737-b1ff-a57707567150@oracle.com>
	<d11d62e6-5435-7a60-10a2-5f5b40a22aef@oracle.com>
Message-ID: <a331b9ac-9248-feb3-cd04-5eccb11294dd@oracle.com>

Ok, thank you, I'll remove 8164119.


On 18.08.2016 15:42, Se?n Coffey wrote:
> Looks fine. I would prefer if you dropped the 8164119 reference from 
> the @bug tag. Generally, that's used for product bug IDs AFAIK. 
> noreg-self could be added to bug report as an alternative. Please add 
> 9-na label to bug report also.
>
> Approved.
>
> Regards,
> Sean.
>
> On 16/08/2016 18:04, Mikhail Cherkasov wrote:
>> Hi all,
>>
>> I haven't removed the "@key headful" that isn't included into 
>> TEST.ROOT in jdk8, as result test fails with an error:
>>
>> bugdb: https://bugs.openjdk.java.net/browse/JDK-8164119
>> webrev: 
>> http://cr.openjdk.java.net/~mcherkas/8164119/webrev/test/java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java.udiff.html
>>
>> Thanks,
>> Mikhail.
>


From rwestrel at redhat.com  Thu Aug 18 14:56:56 2016
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 18 Aug 2016 16:56:56 +0200
Subject: [8u] request for approval: "8162384: Performance regression:
	bimorphic inlining may be bypassed by type speculation"
In-Reply-To: <57B4B109.1040808@oracle.com>
References: <dk637m3bajn.fsf@rwestrel.remote.csb> <57B4B109.1040808@oracle.com>
Message-ID: <dk6twei9lc7.fsf@rwestrel.remote.csb>


> Looks good. You would be asked for the test. Please, provide keyword
> and reason for no test.

Thanks for looking at this, Vladimir. I added a keyword/reason for no
regression test.

Do I need further approval beyond your ok? Do I need a sponsor or can I
push it directly?

Roland.

From vladimir.kozlov at oracle.com  Thu Aug 18 15:04:16 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Aug 2016 08:04:16 -0700
Subject: [8u] request for approval: "8162384: Performance regression:
	bimorphic inlining may be bypassed by type speculation"
In-Reply-To: <dk6twei9lc7.fsf@rwestrel.remote.csb>
References: <dk637m3bajn.fsf@rwestrel.remote.csb>
	<57B4B109.1040808@oracle.com> <dk6twei9lc7.fsf@rwestrel.remote.csb>
Message-ID: <57B5CE70.9040400@oracle.com>

You need approval from jdk 8u gatekeeper, Rob McKenna or Se?n Coffey.

Vladimir

On 8/18/16 7:56 AM, Roland Westrelin wrote:
>
>> Looks good. You would be asked for the test. Please, provide keyword
>> and reason for no test.
>
> Thanks for looking at this, Vladimir. I added a keyword/reason for no
> regression test.
>
> Do I need further approval beyond your ok? Do I need a sponsor or can I
> push it directly?
>
> Roland.
>

From sean.coffey at oracle.com  Thu Aug 18 15:17:43 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 18 Aug 2016 16:17:43 +0100
Subject: [8u] request for approval: "8162384: Performance regression:
	bimorphic inlining may be bypassed by type speculation"
In-Reply-To: <57B5CE70.9040400@oracle.com>
References: <dk637m3bajn.fsf@rwestrel.remote.csb>
	<57B4B109.1040808@oracle.com> <dk6twei9lc7.fsf@rwestrel.remote.csb>
	<57B5CE70.9040400@oracle.com>
Message-ID: <dd8a7ec0-e6dc-514e-7088-47f8fa103059@oracle.com>

Approved for jdk8u-dev.

Regards,
Sean.

On 18/08/2016 16:04, Vladimir Kozlov wrote:
> You need approval from jdk 8u gatekeeper, Rob McKenna or Se?n Coffey.
>
> Vladimir
>
> On 8/18/16 7:56 AM, Roland Westrelin wrote:
>>
>>> Looks good. You would be asked for the test. Please, provide keyword
>>> and reason for no test.
>>
>> Thanks for looking at this, Vladimir. I added a keyword/reason for no
>> regression test.
>>
>> Do I need further approval beyond your ok? Do I need a sponsor or can I
>> push it directly?
>>
>> Roland.
>>


From vladimir.kozlov at oracle.com  Thu Aug 18 15:27:06 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Aug 2016 08:27:06 -0700
Subject: [8u] request for approval: "8162384: Performance regression:
	bimorphic inlining may be bypassed by type speculation"
In-Reply-To: <dd8a7ec0-e6dc-514e-7088-47f8fa103059@oracle.com>
References: <dk637m3bajn.fsf@rwestrel.remote.csb>
	<57B4B109.1040808@oracle.com> <dk6twei9lc7.fsf@rwestrel.remote.csb>
	<57B5CE70.9040400@oracle.com>
	<dd8a7ec0-e6dc-514e-7088-47f8fa103059@oracle.com>
Message-ID: <57B5D3CA.10902@oracle.com>

Thank you, Sean.

I will sponsor push.

Vladimir

On 8/18/16 8:17 AM, Se?n Coffey wrote:
> Approved for jdk8u-dev.
>
> Regards,
> Sean.
>
> On 18/08/2016 16:04, Vladimir Kozlov wrote:
>> You need approval from jdk 8u gatekeeper, Rob McKenna or Se?n Coffey.
>>
>> Vladimir
>>
>> On 8/18/16 7:56 AM, Roland Westrelin wrote:
>>>
>>>> Looks good. You would be asked for the test. Please, provide keyword
>>>> and reason for no test.
>>>
>>> Thanks for looking at this, Vladimir. I added a keyword/reason for no
>>> regression test.
>>>
>>> Do I need further approval beyond your ok? Do I need a sponsor or can I
>>> push it directly?
>>>
>>> Roland.
>>>
>

From rwestrel at redhat.com  Thu Aug 18 15:27:24 2016
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 18 Aug 2016 17:27:24 +0200
Subject: [8u] request for approval: "8162384: Performance regression:
	bimorphic inlining may be bypassed by type speculation"
In-Reply-To: <57B5D3CA.10902@oracle.com>
References: <dk637m3bajn.fsf@rwestrel.remote.csb>
	<57B4B109.1040808@oracle.com> <dk6twei9lc7.fsf@rwestrel.remote.csb>
	<57B5CE70.9040400@oracle.com>
	<dd8a7ec0-e6dc-514e-7088-47f8fa103059@oracle.com>
	<57B5D3CA.10902@oracle.com>
Message-ID: <fe1f566a-53a3-62d1-a6d8-28c8d4c779be@redhat.com>

Thanks Sean & Vladimir!

Roland.

On 08/18/2016 05:27 PM, Vladimir Kozlov wrote:
> Thank you, Sean.
> 
> I will sponsor push.
> 
> Vladimir
> 
> On 8/18/16 8:17 AM, Se?n Coffey wrote:
>> Approved for jdk8u-dev.
>>
>> Regards,
>> Sean.
>>
>> On 18/08/2016 16:04, Vladimir Kozlov wrote:
>>> You need approval from jdk 8u gatekeeper, Rob McKenna or Se?n Coffey.
>>>
>>> Vladimir
>>>
>>> On 8/18/16 7:56 AM, Roland Westrelin wrote:
>>>>
>>>>> Looks good. You would be asked for the test. Please, provide keyword
>>>>> and reason for no test.
>>>>
>>>> Thanks for looking at this, Vladimir. I added a keyword/reason for no
>>>> regression test.
>>>>
>>>> Do I need further approval beyond your ok? Do I need a sponsor or can I
>>>> push it directly?
>>>>
>>>> Roland.
>>>>
>>

From chris.hegarty at oracle.com  Thu Aug 18 15:49:22 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 18 Aug 2016 16:49:22 +0100
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <20160816144126.GB4783@vimes>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
Message-ID: <19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>

On 16 Aug 2016, at 15:41, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> Hi Christoph,
> 
> If the patch has changed from 9 you will need a separate review.
> 
> 	-Rob
> 
> On 16/08/16 10:09, Langer, Christoph wrote:
>> Hi,
>> 
>> can I get approval for backporting the following fix:
>> 
>> 
>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
>> 
>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
>> 
>> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-dev/2016-July/010100.html
>> 
>> 
>> I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev. This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/

Wow, there are quite a lot of changes in this. I do remember reviewing this for 9 ( it
took a long time ).  I do have a concern that this change may cause some subtle
behavioural differences, since the underlying systems calls may be different. This
may be acceptable for a major release, but not so for an update release.

Is there a strong need for this to be backported?

-Chris.

From chris.hegarty at oracle.com  Thu Aug 18 15:49:22 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 18 Aug 2016 16:49:22 +0100
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <20160816144126.GB4783@vimes>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
Message-ID: <CC05624B-E0BA-4700-9EEF-E0C565B51BA2@oracle.com>

On 16 Aug 2016, at 15:41, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> Hi Christoph,
> 
> If the patch has changed from 9 you will need a separate review.
> 
> 	-Rob
> 
> On 16/08/16 10:09, Langer, Christoph wrote:
>> Hi,
>> 
>> can I get approval for backporting the following fix:
>> 
>> 
>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
>> 
>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
>> 
>> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-dev/2016-July/010100.html
>> 
>> 
>> I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev. This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/

Wow, there are quite a lot of changes in this. I do remember reviewing this for 9 ( it
took a long time ).  I do have a concern that this change may cause some subtle
behavioural differences, since the underlying systems calls may be different. This
may be acceptable for a major release, but not so for an update release.

Is there a strong need for this to be backported?

-Chris.

From sean.coffey at oracle.com  Fri Aug 19 06:46:14 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 19 Aug 2016 07:46:14 +0100
Subject: [jdk8u-dev] Request for approval : 8162916:Test
	sun/security/krb5/auto/UnboundSSL.java fails
Message-ID: <4fb7bfcf-141d-0b09-a76f-326a8c3517d5@oracle.com>

Looking to push this simple testcase fix to jdk8u-dev.

bug report : https://bugs.openjdk.java.net/browse/JDK-8162916
review thread : 
http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014634.html


-- 
Regards,
Sean.


From david.buck at oracle.com  Fri Aug 19 07:00:50 2016
From: david.buck at oracle.com (David Buck)
Date: Fri, 19 Aug 2016 16:00:50 +0900
Subject: [jdk8u-dev] Request for approval : 8162916:Test
	sun/security/krb5/auto/UnboundSSL.java fails
In-Reply-To: <4fb7bfcf-141d-0b09-a76f-326a8c3517d5@oracle.com>
References: <4fb7bfcf-141d-0b09-a76f-326a8c3517d5@oracle.com>
Message-ID: <71AB5545-373B-4BDF-96EF-9B27F611060F@oracle.com>

approved

Cheers,
-Buck

> On Aug 19, 2016, at 15:46, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Looking to push this simple testcase fix to jdk8u-dev.
> 
> bug report : https://bugs.openjdk.java.net/browse/JDK-8162916
> review thread : http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014634.html
> 
> 
> -- 
> Regards,
> Sean.
> 


From sean.coffey at oracle.com  Fri Aug 19 08:43:53 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 19 Aug 2016 09:43:53 +0100
Subject: PING: [8u112] Request for review & approval for CR8151841: Build
	needs additional flags to compile with GCC 6
In-Reply-To: <247448866.1378063.1470409942851.JavaMail.zimbra@redhat.com>
References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com>
	<577F4C58.6060101@oracle.com>
	<1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com>
	<788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com>
	<75eba245-b501-6567-445c-836fa7fc3885@oracle.com>
	<c0c6400b-0043-e014-5f8c-292e40bb3abf@oracle.com>
	<247448866.1378063.1470409942851.JavaMail.zimbra@redhat.com>
Message-ID: <c1c06463-6ac6-187d-de32-af43c5c5e4de@oracle.com>

Haven't forgotten about this one. Hope to get to it today.

Regards,
Sean.

On 05/08/2016 16:12, Andrew Hughes wrote:
>
> ----- Original Message -----
>> I'm seeing this patch fail across all platforms on internal builds.
>> Please hold off any push for now. Maybe other config changes are needed
>> on our build systems.
>>
>> e.g.
>>
>>> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC
>>> \
>>>                       -m64 -G -KPIC     \
>>> 	           -I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc
>>> 	           \
>>> 	           -I../generated                                       \
>>> 	           -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include
>>> 	           \
>>> 	           -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris
>>> 	           \
>>> 	                                     \
>>> 	           /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp
>>> 	           \
>>> 	           sadis.o                                          \
>>> 	           -M
>>> 	           /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile
>>> 	           -mt -xnolib -norunpath
>>> 	           \
>>> 	           -o libsaproc.so
>>> 	           \
>>> 	           -ldl -ldemangle -lthread -lc
>>> ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such
>>> file or directory
>>> ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or
>>> directory
>>> ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory
>>> ld: fatal: file processing errors. No output written to
>>> libgenerateJvmOffsets.so
>>> gmake[6]: *** [libgenerateJvmOffsets.so] Error 1
>>> gmake[6]: *** Waiting for unfinished jobs....
>>> gmake[6]: Leaving directory
>>> `/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product'
>>> gmake[5]: *** [the_vm] Error 2
> It needs to be pushed by someone at Oracle anyway, so your internal
> configure can be updated.
>
> I think that might be the problem here. @CXXSTD_CXXFLAG@ and friends
> should be substituted by configure with either the flag or the empty
> string, so something is going wrong earlier with the configure stage.


From mikhail.cherkasov at oracle.com  Fri Aug 19 16:06:18 2016
From: mikhail.cherkasov at oracle.com (Mikhail Cherkasov)
Date: Fri, 19 Aug 2016 19:06:18 +0300
Subject: [8u-dev] Request for Approval: 8040322 TextArea.replaceRange() and
	insert() are broken with setText(null)
Message-ID: <9f572abb-3077-e807-9bd7-a6df6ae8546c@oracle.com>

Hi all,

Could you please approve a direct backport from jdk9 to 8:
jbs: https://bugs.openjdk.java.net/browse/JDK-8040322
jdk8 webrev: http://cr.openjdk.java.net/~mcherkas/8040322/webrev/
jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/1ca9365c8173
review: 
http://mail.openjdk.java.net/pipermail/awt-dev/2015-September/010081.html

Thanks,
Mikhail.


From rob.mckenna at oracle.com  Fri Aug 19 16:16:15 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 19 Aug 2016 17:16:15 +0100
Subject: [8u-dev] Request for Approval: 8040322 TextArea.replaceRange()
	and insert() are broken with setText(null)
In-Reply-To: <9f572abb-3077-e807-9bd7-a6df6ae8546c@oracle.com>
References: <9f572abb-3077-e807-9bd7-a6df6ae8546c@oracle.com>
Message-ID: <20160819161615.GA5790@vimes>

Approved

	-Rob

On 19/08/16 07:06, Mikhail Cherkasov wrote:
> Hi all,
> 
> Could you please approve a direct backport from jdk9 to 8:
> jbs: https://bugs.openjdk.java.net/browse/JDK-8040322
> jdk8 webrev: http://cr.openjdk.java.net/~mcherkas/8040322/webrev/
> jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/1ca9365c8173
> review:
> http://mail.openjdk.java.net/pipermail/awt-dev/2015-September/010081.html
> 
> Thanks,
> Mikhail.
> 

From dalibor.topic at oracle.com  Sat Aug 20 10:11:28 2016
From: dalibor.topic at oracle.com (dalibor topic)
Date: Sat, 20 Aug 2016 12:11:28 +0200
Subject: Regarding life cycle of openJDK 8u
In-Reply-To: <CA+f1OFpYG4aFc2pLkHDj504=4DjvWd3YvCnbDDdyRWcAVOO9tw@mail.gmail.com>
References: <CA+f1OFpYG4aFc2pLkHDj504=4DjvWd3YvCnbDDdyRWcAVOO9tw@mail.gmail.com>
Message-ID: <d703942d-701d-e152-0a4c-71e3277e6c77@oracle.com>



On 18.08.2016 07:10, Adishesh M wrote:
> Hi,
>
> Currently I am  using 8u92 openJDK version.
>
> when will support for this version ends.
> In general how the support for older version of openJDK 8 updates are
> handled. whenever new 8u update is available support for older 8u release
> ends?

Hi Adishesh,

as an open source Project focused on source code only, we don't provide 
any specific kind of support for any specific OpenJDK JDK 8 Updates 
source code release.

If you're using your own builds builds, that means that your support for 
a specific release ends when you end supporting it for yourself.

If you are using third party provided builds, that means support for a 
specific release ends when they stop supporting it to you. For details, 
please inquire with the corresponding third party.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From mallikarjuna.avaluri at oracle.com  Mon Aug 22 04:21:07 2016
From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri)
Date: Mon, 22 Aug 2016 09:51:07 +0530
Subject: Request for approval: JDK-8160913: [TEST_BUG]
	javax/management/security/SecurityTest.java fails due to missing
	keyStore file
In-Reply-To: <dc1df699-bb81-87f0-40c7-3addd424ad5e@oracle.com>
References: <dc1df699-bb81-87f0-40c7-3addd424ad5e@oracle.com>
Message-ID: <ed9ccf5a-d31b-5ec2-dcd6-d6e94558db71@oracle.com>

Hi,

Reminder,  please help me with this Approval.


Regards,

Mallikarjuna Avaluri


On 8/18/2016 11:37 AM, Mallikarjuna Avaluri wrote:
>
> Hi all,
>
> Please Approve the fix for following issue.
>
> JDK-8160913: [TEST_BUG] javax/management/security/SecurityTest.java 
> fails due to missing keyStore file
> https://bugs.openjdk.java.net/browse/JDK-8160913
>
> Fix:  Following files keystoreAgent, keystoreClient, truststoreAgent 
> and truststoreClient were created under jdk/test/javax/management/ 
> folder,
> while test expects them under jdk/test/javax/management/security/ 
> path. Moved the files to correct folder.
>
> Webrev: 
> http://cr.openjdk.java.net/~bgopularam/mavaluri/rev/8160913/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ebgopularam/mavaluri/rev/8160913/webrev.00/>
>
>
> Thanks,
> Mallikarjuna Avaluri
>


From david.buck at oracle.com  Mon Aug 22 04:33:59 2016
From: david.buck at oracle.com (david buck)
Date: Mon, 22 Aug 2016 13:33:59 +0900
Subject: Request for approval: JDK-8160913: [TEST_BUG]
	javax/management/security/SecurityTest.java fails due to missing
	keyStore file
In-Reply-To: <ed9ccf5a-d31b-5ec2-dcd6-d6e94558db71@oracle.com>
References: <dc1df699-bb81-87f0-40c7-3addd424ad5e@oracle.com>
	<ed9ccf5a-d31b-5ec2-dcd6-d6e94558db71@oracle.com>
Message-ID: <d1329c8b-7ec9-b6ff-1622-7504c38d2b4a@oracle.com>

Hi Mallikarjuna!

This is not strictly a request for approval, but a request for review. 
You may have better luck getting a code reviewer to notice by changing 
the message's subject field to reflect that. You may also want to try 
CCing the appropriate development team's alias as well. Once the change 
is reviewed, you can consider this particular fix approved for push to 
8u-dev. If the code review takes place on a different alias, please be 
sure to update this thread with a link to the review before pushing.

Cheers,
-Buck

On 2016/08/22 13:21, Mallikarjuna Avaluri wrote:
> Hi,
>
> Reminder,  please help me with this Approval.
>
>
> Regards,
>
> Mallikarjuna Avaluri

From christoph.langer at sap.com  Mon Aug 22 10:00:11 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Aug 2016 10:00:11 +0000
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
Message-ID: <f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>

Hi Chris,

I understand your concerns regarding too much change here which could result in subtle differences that might not be wanted for a released version.

The main motivation for me to integrate the change into JDK 8 is mergeability. In our SAP JVM 8 we had the need to do several fixes for problems on various of our supported platforms. And with the current coding layout it is very hard to do fixes, especially for AIX/Linux as all the #ifdefs make it a mess. So we already stepped to a version of code that merely matches the JDK9 version.

But I agree that with my proposal (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/) I'm probably touching unnecessary places and make a review really hard.

What about this proposal for downporting the fix to Bug 8158519:
http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/

Here I really only split the enumIPv*Interfaces methods to a clean structure and then make the necessary changes to eliminate getBroadcast() and getSubnet() functions in order to determine that information correctly in place before calling addif.

Could you give a review for that?

Thanks a lot
Christoph



> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Donnerstag, 18. August 2016 17:49
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna <rob.mckenna at oracle.com>
> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface - fixes
> and improvements for network interface listing
> 
> On 16 Aug 2016, at 15:41, Rob McKenna <rob.mckenna at oracle.com> wrote:
> >
> > Hi Christoph,
> >
> > If the patch has changed from 9 you will need a separate review.
> >
> > 	-Rob
> >
> > On 16/08/16 10:09, Langer, Christoph wrote:
> >> Hi,
> >>
> >> can I get approval for backporting the following fix:
> >>
> >>
> >> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
> >>
> >> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
> >>
> >> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-dev/2016-
> July/010100.html
> >>
> >>
> >> I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev.
> This is the new webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
> 
> Wow, there are quite a lot of changes in this. I do remember reviewing this for
> 9 ( it
> took a long time ).  I do have a concern that this change may cause some subtle
> behavioural differences, since the underlying systems calls may be different.
> This
> may be acceptable for a major release, but not so for an update release.
> 
> Is there a strong need for this to be backported?
> 
> -Chris.

From aleksej.efimov at oracle.com  Mon Aug 22 13:37:40 2016
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 22 Aug 2016 16:37:40 +0300
Subject: [8u-dev] Request for approval: 8146961: Fix PermGen memory leaks
	caused by static final Exceptions
Message-ID: <11b29ad0-5f77-69c1-1490-d536a910b40d@oracle.com>

Hello,

Please, approve the backport of JDK-8146961 to JDK8u-dev. The changes 
are almost identical except the removal of unused 'abort' field from 
DOMSerializerImpl class: this field was already removed in JDK9 by 
JDK-8035437  [1] changes.

Build with these changes was tested with JPRT and JCK tests: no failures

JBS:
https://bugs.openjdk.java.net/browse/JDK-8146961

JDK9 Changeset:
http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/4271b37ff91f

JDK9 Review Thread:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042928.html

Webrev with JDK8 changes:
http://cr.openjdk.java.net/~aefimov/8146961/8/00/

With Best Regards,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8035437


From chris.hegarty at oracle.com  Mon Aug 22 14:04:17 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 22 Aug 2016 15:04:17 +0100
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
	<f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
Message-ID: <ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>

Hi Christoph,

On 22/08/16 11:00, Langer, Christoph wrote:
> Hi Chris,
>
> I understand your concerns regarding too much change here which could result in subtle differences that might not be wanted for a released version.
>
> The main motivation for me to integrate the change into JDK 8 is mergeability. In our SAP JVM 8 we had the need to do several fixes for problems on various of our supported platforms. And with the current coding layout it is very hard to do fixes, especially for AIX/Linux as all the #ifdefs make it a mess. So we already stepped to a version of code that merely matches the JDK9 version.

I understand, and can sympathize with this.

> But I agree that with my proposal (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/) I'm probably touching unnecessary places and make a review really hard.

Well after further thought, if we are going to make changes here,
then maybe there is an argument for keeping the code consistent
with 9, at least we end up with a single body of code.

8160174 has been in JDK 9 for almost a month, and there have been
no reported issues.

Is it the case that with your previous proposal that the 8u version
of the file is identical to that of the 9 version?

-Chris.

> What about this proposal for downporting the fix to Bug 8158519:
> http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/
>
> Here I really only split the enumIPv*Interfaces methods to a clean structure and then make the necessary changes to eliminate getBroadcast() and getSubnet() functions in order to determine that information correctly in place before calling addif.
>
> Could you give a review for that?
>
> Thanks a lot
> Christoph
>
>
>
>> -----Original Message-----
>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>> Sent: Donnerstag, 18. August 2016 17:49
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna <rob.mckenna at oracle.com>
>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface - fixes
>> and improvements for network interface listing
>>
>> On 16 Aug 2016, at 15:41, Rob McKenna <rob.mckenna at oracle.com> wrote:
>>>
>>> Hi Christoph,
>>>
>>> If the patch has changed from 9 you will need a separate review.
>>>
>>> 	-Rob
>>>
>>> On 16/08/16 10:09, Langer, Christoph wrote:
>>>> Hi,
>>>>
>>>> can I get approval for backporting the following fix:
>>>>
>>>>
>>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
>>>>
>>>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
>>>>
>>>> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-dev/2016-
>> July/010100.html
>>>>
>>>>
>>>> I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev.
>> This is the new webrev:
>> http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
>>
>> Wow, there are quite a lot of changes in this. I do remember reviewing this for
>> 9 ( it
>> took a long time ).  I do have a concern that this change may cause some subtle
>> behavioural differences, since the underlying systems calls may be different.
>> This
>> may be acceptable for a major release, but not so for an update release.
>>
>> Is there a strong need for this to be backported?
>>
>> -Chris.

From christoph.langer at sap.com  Mon Aug 22 14:38:24 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Aug 2016 14:38:24 +0000
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
	<f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
	<ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>
Message-ID: <f9b6aa2b4cb54981a266be0ff01d8752@DEWDFE13DE11.global.corp.sap>

Hi Chris,

yes, the change for 8160174 would make the code mostly identical to the current JDK9 version, except for some calls to NET_ or JNU_ macros/functions wich are either not available in 8 or I didn't dare to touch.

Best
Christoph

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Montag, 22. August 2016 16:04
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna <rob.mckenna at oracle.com>
> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface - fixes
> and improvements for network interface listing
> 
> Hi Christoph,
> 
> On 22/08/16 11:00, Langer, Christoph wrote:
> > Hi Chris,
> >
> > I understand your concerns regarding too much change here which could
> result in subtle differences that might not be wanted for a released version.
> >
> > The main motivation for me to integrate the change into JDK 8 is
> mergeability. In our SAP JVM 8 we had the need to do several fixes for
> problems on various of our supported platforms. And with the current coding
> layout it is very hard to do fixes, especially for AIX/Linux as all the #ifdefs make
> it a mess. So we already stepped to a version of code that merely matches the
> JDK9 version.
> 
> I understand, and can sympathize with this.
> 
> > But I agree that with my proposal
> (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/) I'm probably
> touching unnecessary places and make a review really hard.
> 
> Well after further thought, if we are going to make changes here,
> then maybe there is an argument for keeping the code consistent
> with 9, at least we end up with a single body of code.
> 
> 8160174 has been in JDK 9 for almost a month, and there have been
> no reported issues.
> 
> Is it the case that with your previous proposal that the 8u version
> of the file is identical to that of the 9 version?
> 
> -Chris.
> 
> > What about this proposal for downporting the fix to Bug 8158519:
> > http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/
> >
> > Here I really only split the enumIPv*Interfaces methods to a clean structure
> and then make the necessary changes to eliminate getBroadcast() and
> getSubnet() functions in order to determine that information correctly in place
> before calling addif.
> >
> > Could you give a review for that?
> >
> > Thanks a lot
> > Christoph
> >
> >
> >
> >> -----Original Message-----
> >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >> Sent: Donnerstag, 18. August 2016 17:49
> >> To: Langer, Christoph <christoph.langer at sap.com>
> >> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna <rob.mckenna at oracle.com>
> >> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface -
> fixes
> >> and improvements for network interface listing
> >>
> >> On 16 Aug 2016, at 15:41, Rob McKenna <rob.mckenna at oracle.com>
> wrote:
> >>>
> >>> Hi Christoph,
> >>>
> >>> If the patch has changed from 9 you will need a separate review.
> >>>
> >>> 	-Rob
> >>>
> >>> On 16/08/16 10:09, Langer, Christoph wrote:
> >>>> Hi,
> >>>>
> >>>> can I get approval for backporting the following fix:
> >>>>
> >>>>
> >>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
> >>>>
> >>>> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
> >>>>
> >>>> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-dev/2016-
> >> July/010100.html
> >>>>
> >>>>
> >>>> I had to modify the jdk9 patch after unshuffling to get it to apply to 8udev.
> >> This is the new webrev:
> >> http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
> >>
> >> Wow, there are quite a lot of changes in this. I do remember reviewing this
> for
> >> 9 ( it
> >> took a long time ).  I do have a concern that this change may cause some
> subtle
> >> behavioural differences, since the underlying systems calls may be different.
> >> This
> >> may be acceptable for a major release, but not so for an update release.
> >>
> >> Is there a strong need for this to be backported?
> >>
> >> -Chris.

From sean.coffey at oracle.com  Mon Aug 22 15:19:07 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 22 Aug 2016 16:19:07 +0100
Subject: [8u-dev] Request for approval: 8146961: Fix PermGen memory leaks
	caused by static final Exceptions
In-Reply-To: <11b29ad0-5f77-69c1-1490-d536a910b40d@oracle.com>
References: <11b29ad0-5f77-69c1-1490-d536a910b40d@oracle.com>
Message-ID: <57BB17EB.5000304@oracle.com>

Changes look good Aleksej.

Approved for jdk8u-dev forest.

Regards,
Sean.

On 22/08/16 14:37, Aleks Efimov wrote:
> Hello,
>
> Please, approve the backport of JDK-8146961 to JDK8u-dev. The changes 
> are almost identical except the removal of unused 'abort' field from 
> DOMSerializerImpl class: this field was already removed in JDK9 by 
> JDK-8035437  [1] changes.
>
> Build with these changes was tested with JPRT and JCK tests: no failures
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8146961
>
> JDK9 Changeset:
> http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/4271b37ff91f
>
> JDK9 Review Thread:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042928.html 
>
>
> Webrev with JDK8 changes:
> http://cr.openjdk.java.net/~aefimov/8146961/8/00/
>
> With Best Regards,
> Aleksej
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8035437
>


From sean.coffey at oracle.com  Mon Aug 22 15:25:11 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 22 Aug 2016 16:25:11 +0100
Subject: [jdk8u-dev] Request for approval : 8162362: Introduce system property
	to control enabled ciphersuites
Message-ID: <57BB1957.7010106@oracle.com>

Looking to port this back to jdk8u-dev.

JBS : https://bugs.openjdk.java.net/browse/JDK-8162362
review thread : 
http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014689.html

-- 
Regards,
Sean.


From rob.mckenna at oracle.com  Mon Aug 22 15:40:27 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 22 Aug 2016 16:40:27 +0100
Subject: [jdk8u-dev] Request for approval : 8162362: Introduce system
	property to control enabled ciphersuites
In-Reply-To: <57BB1957.7010106@oracle.com>
References: <57BB1957.7010106@oracle.com>
Message-ID: <20160822154027.GC5163@vimes>

Approved

	-Rob

On 22/08/16 04:25, Se?n Coffey wrote:
> Looking to port this back to jdk8u-dev.
> 
> JBS : https://bugs.openjdk.java.net/browse/JDK-8162362
> review thread :
> http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014689.html
> 
> -- 
> Regards,
> Sean.
> 

From mallikarjuna.avaluri at oracle.com  Tue Aug 23 03:09:11 2016
From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri)
Date: Tue, 23 Aug 2016 08:39:11 +0530
Subject: Request for approval: JDK-8160913: [TEST_BUG]
	javax/management/security/SecurityTest.java fails due to missing
	keyStore file
In-Reply-To: <d1329c8b-7ec9-b6ff-1622-7504c38d2b4a@oracle.com>
References: <dc1df699-bb81-87f0-40c7-3addd424ad5e@oracle.com>
	<ed9ccf5a-d31b-5ec2-dcd6-d6e94558db71@oracle.com>
	<d1329c8b-7ec9-b6ff-1622-7504c38d2b4a@oracle.com>
Message-ID: <7926c129-c770-2829-e9dd-095d663041df@oracle.com>

Hi,

Code review has happened in different thread, please find the link below 
for the same.

Review link : 
http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020165.html


Regards,

Mallikarjuna Avaluri


On 8/22/2016 10:03 AM, david buck wrote:
> Hi Mallikarjuna!
>
> This is not strictly a request for approval, but a request for review. 
> You may have better luck getting a code reviewer to notice by changing 
> the message's subject field to reflect that. You may also want to try 
> CCing the appropriate development team's alias as well. Once the 
> change is reviewed, you can consider this particular fix approved for 
> push to 8u-dev. If the code review takes place on a different alias, 
> please be sure to update this thread with a link to the review before 
> pushing.
>
> Cheers,
> -Buck
>
> On 2016/08/22 13:21, Mallikarjuna Avaluri wrote:
>> Hi,
>>
>> Reminder,  please help me with this Approval.
>>
>>
>> Regards,
>>
>> Mallikarjuna Avaluri


From sean.coffey at oracle.com  Tue Aug 23 10:57:24 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 23 Aug 2016 11:57:24 +0100
Subject: [8u communication] New changes for JDK 8 Update enhancement requests
Message-ID: <4efc8b83-56a8-67e9-69d8-b4a1854d16e1@oracle.com>

As the JDK 9 GA date continues to grow closer[1], more efforts will go
into stabilizing the JDK 9 release. The latest feature release line serves
as a delivery mechanism for new enhancements that enter the JDK.

With that in mind, I'd like to propose a change to how enhancements
are ported to JDK 8 Updates.

Enhancements normally bring more code change and testing requirements
with them. With most efforts being focused on JDK 9, I'd like to
suggest that we recapitulate any enhancements being proposed for the
JDK 8 Updates Project. The proposed change just involves giving the
Project maintainers early notification of any proposed enhancement
work being planned for the Project. The maintainers can assess each
request and help make a decision on its suitability.

In particular here are the proposed changes for the JDK 8 Updates 
processes:

====
In Ground Rules: [2]

  In Rule 3:

    Changes submitted for a JDK 8 Update forest MUST go through code
    review, and MUST be approved by the maintainer for that forest.
    The maintainer of a forest MAY delegate that authority, allowing for
    approvals to happen in a more finely granular fashion - per
    repository, for example.

Add:

    If the change is an enhancement, then a separate enhancement backport
    request MUST be approved by the maintainer for that forest prior to
    the change being submitted for code review and final maintainer
    approval.

with "Enhancement backport request" linking to a new

   Enhancement Backport Approval Template:

    Use this template for requesting a backport of an enhancement to any
    8u release. Note that "critical fix approval" also needs to be
    requested for any fixes targeted to an RDP2 release. Enhancement
    backport approval requests for JDK 8 update releases MUST be sent to
    the jdk8u-dev at openjdk.java.net mailing list prior to requesting code
    review, and SHOULD follow this template:

   Subject: [8u$N] Request for enhancement backport approval for CR $NR 
- $Synopsis

   With the body containing:

   * either a link to the publicly visible enhancement issue on the 
bugs.java.com
   site (or its equivalent), or a description of the change in case that 
there is no publicly
   visible enhancement issue to link to

   * a rationale for why the enhancement should be backported,
   including the benefit and risks involved, what testing has been done, 
and what the results were.

====

Please submit comments on this proposal before 31st August 2016.

regards,
Sean.

[1] http://openjdk.java.net/projects/jdk9/
[2] http://openjdk.java.net/projects/jdk8u/groundrules.html


From ivan.gerasimov at oracle.com  Tue Aug 23 16:53:49 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 23 Aug 2016 19:53:49 +0300
Subject: [8u-dev] Request for approval to backport: 8164366:
	ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input
Message-ID: <20a43a35-79ce-0611-5c15-5a3d857a4a22@oracle.com>

Hello!

I'd like to backport this fix to jdk8u.  Unshuffled patch applies cleanly.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164366
Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8e5362b5a18d
Jdk9 review: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/043074.html

With kind regards,
Ivan



From david.buck at oracle.com  Tue Aug 23 17:41:46 2016
From: david.buck at oracle.com (david buck)
Date: Wed, 24 Aug 2016 02:41:46 +0900
Subject: [8u-dev] Request for approval to backport: 8164366:
	ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input
In-Reply-To: <20a43a35-79ce-0611-5c15-5a3d857a4a22@oracle.com>
References: <20a43a35-79ce-0611-5c15-5a3d857a4a22@oracle.com>
Message-ID: <858fa8db-0d12-57a1-93dc-e95f205cf96b@oracle.com>

approved for backport to 8u-dev

Cheers,
-Buck

On 2016/08/24 1:53, Ivan Gerasimov wrote:
> Hello!
>
> I'd like to backport this fix to jdk8u.  Unshuffled patch applies cleanly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164366
> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8e5362b5a18d
> Jdk9 review:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/043074.html
>
>
> With kind regards,
> Ivan
>
>

From christoph.langer at sap.com  Wed Aug 24 10:51:58 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 24 Aug 2016 10:51:58 +0000
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <1924989a-1ccc-8bc4-b6cf-8ece75abffaa@oracle.com>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
	<f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
	<ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>
	<3f8c3680087d412c8e590ace6f7285de@DEWDFE13DE11.global.corp.sap>
	<1924989a-1ccc-8bc4-b6cf-8ece75abffaa@oracle.com>
Message-ID: <9aa68d6b38394b39961416b21eb5fe29@DEWDFE13DE11.global.corp.sap>

Hi,

forwarding Chris' review for the downported change.

Can I please get the approval now?

Thanks
Christoph

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Mittwoch, 24. August 2016 12:04
> To: Langer, Christoph <christoph.langer at sap.com>
> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface - fixes
> and improvements for network interface listing
> 
> On 24/08/16 10:23, Langer, Christoph wrote:
> > Hi Chris,
> >
> > so, does it mean you'll give a review for the backport change now?
> 
> Yes. Consider it reviewed.
> 
> -Chris.
> 
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: Langer, Christoph
> >> Sent: Montag, 22. August 2016 16:38
> >> To: 'Chris Hegarty' <chris.hegarty at oracle.com>
> >> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna <rob.mckenna at oracle.com>
> >> Subject: RE: Request for approval: 8160174: java.net.NetworkInterface -
> fixes
> >> and improvements for network interface listing
> >>
> >> Hi Chris,
> >>
> >> yes, the change for 8160174 would make the code mostly identical to the
> >> current JDK9 version, except for some calls to NET_ or JNU_
> macros/functions
> >> wich are either not available in 8 or I didn't dare to touch.
> >>
> >> Best
> >> Christoph
> >>
> >>> -----Original Message-----
> >>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >>> Sent: Montag, 22. August 2016 16:04
> >>> To: Langer, Christoph <christoph.langer at sap.com>
> >>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
> <rob.mckenna at oracle.com>
> >>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface -
> fixes
> >>> and improvements for network interface listing
> >>>
> >>> Hi Christoph,
> >>>
> >>> On 22/08/16 11:00, Langer, Christoph wrote:
> >>>> Hi Chris,
> >>>>
> >>>> I understand your concerns regarding too much change here which could
> >>> result in subtle differences that might not be wanted for a released
> version.
> >>>>
> >>>> The main motivation for me to integrate the change into JDK 8 is
> >>> mergeability. In our SAP JVM 8 we had the need to do several fixes for
> >>> problems on various of our supported platforms. And with the current
> coding
> >>> layout it is very hard to do fixes, especially for AIX/Linux as all the #ifdefs
> >> make
> >>> it a mess. So we already stepped to a version of code that merely matches
> >> the
> >>> JDK9 version.
> >>>
> >>> I understand, and can sympathize with this.
> >>>
> >>>> But I agree that with my proposal
> >>> (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/) I'm
> probably
> >>> touching unnecessary places and make a review really hard.
> >>>
> >>> Well after further thought, if we are going to make changes here,
> >>> then maybe there is an argument for keeping the code consistent
> >>> with 9, at least we end up with a single body of code.
> >>>
> >>> 8160174 has been in JDK 9 for almost a month, and there have been
> >>> no reported issues.
> >>>
> >>> Is it the case that with your previous proposal that the 8u version
> >>> of the file is identical to that of the 9 version?
> >>>
> >>> -Chris.
> >>>
> >>>> What about this proposal for downporting the fix to Bug 8158519:
> >>>> http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/
> >>>>
> >>>> Here I really only split the enumIPv*Interfaces methods to a clean
> structure
> >>> and then make the necessary changes to eliminate getBroadcast() and
> >>> getSubnet() functions in order to determine that information correctly in
> >> place
> >>> before calling addif.
> >>>>
> >>>> Could you give a review for that?
> >>>>
> >>>> Thanks a lot
> >>>> Christoph
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >>>>> Sent: Donnerstag, 18. August 2016 17:49
> >>>>> To: Langer, Christoph <christoph.langer at sap.com>
> >>>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
> >> <rob.mckenna at oracle.com>
> >>>>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface -
> >>> fixes
> >>>>> and improvements for network interface listing
> >>>>>
> >>>>> On 16 Aug 2016, at 15:41, Rob McKenna <rob.mckenna at oracle.com>
> >>> wrote:
> >>>>>>
> >>>>>> Hi Christoph,
> >>>>>>
> >>>>>> If the patch has changed from 9 you will need a separate review.
> >>>>>>
> >>>>>> 	-Rob
> >>>>>>
> >>>>>> On 16/08/16 10:09, Langer, Christoph wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> can I get approval for backporting the following fix:
> >>>>>>>
> >>>>>>>
> >>>>>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
> >>>>>>>
> >>>>>>> Jdk9 change:
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
> >>>>>>>
> >>>>>>> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-
> >> dev/2016-
> >>>>> July/010100.html
> >>>>>>>
> >>>>>>>
> >>>>>>> I had to modify the jdk9 patch after unshuffling to get it to apply to
> >> 8udev.
> >>>>> This is the new webrev:
> >>>>> http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
> >>>>>
> >>>>> Wow, there are quite a lot of changes in this. I do remember reviewing
> >> this
> >>> for
> >>>>> 9 ( it
> >>>>> took a long time ).  I do have a concern that this change may cause some
> >>> subtle
> >>>>> behavioural differences, since the underlying systems calls may be
> >> different.
> >>>>> This
> >>>>> may be acceptable for a major release, but not so for an update release.
> >>>>>
> >>>>> Is there a strong need for this to be backported?
> >>>>>
> >>>>> -Chris.

From sean.coffey at oracle.com  Thu Aug 25 17:10:13 2016
From: sean.coffey at oracle.com (Sean Coffey)
Date: Thu, 25 Aug 2016 18:10:13 +0100
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <9aa68d6b38394b39961416b21eb5fe29@DEWDFE13DE11.global.corp.sap>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
	<f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
	<ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>
	<3f8c3680087d412c8e590ace6f7285de@DEWDFE13DE11.global.corp.sap>
	<1924989a-1ccc-8bc4-b6cf-8ece75abffaa@oracle.com>
	<9aa68d6b38394b39961416b21eb5fe29@DEWDFE13DE11.global.corp.sap>
Message-ID: <d2cbadb9-09e6-a687-0a2c-422d9f76b439@oracle.com>

Approved for jdk8u-dev. David Buck ran your patch through our build & 
test system (JPRT). No issues spotted.

regards
Sean.


On 24/08/2016 11:51, Langer, Christoph wrote:
> Hi,
>
> forwarding Chris' review for the downported change.
>
> Can I please get the approval now?
>
> Thanks
> Christoph
>
>> -----Original Message-----
>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>> Sent: Mittwoch, 24. August 2016 12:04
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface - fixes
>> and improvements for network interface listing
>>
>> On 24/08/16 10:23, Langer, Christoph wrote:
>>> Hi Chris,
>>>
>>> so, does it mean you'll give a review for the backport change now?
>> Yes. Consider it reviewed.
>>
>> -Chris.
>>
>>> Best regards
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: Langer, Christoph
>>>> Sent: Montag, 22. August 2016 16:38
>>>> To: 'Chris Hegarty' <chris.hegarty at oracle.com>
>>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna <rob.mckenna at oracle.com>
>>>> Subject: RE: Request for approval: 8160174: java.net.NetworkInterface -
>> fixes
>>>> and improvements for network interface listing
>>>>
>>>> Hi Chris,
>>>>
>>>> yes, the change for 8160174 would make the code mostly identical to the
>>>> current JDK9 version, except for some calls to NET_ or JNU_
>> macros/functions
>>>> wich are either not available in 8 or I didn't dare to touch.
>>>>
>>>> Best
>>>> Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>>>>> Sent: Montag, 22. August 2016 16:04
>>>>> To: Langer, Christoph <christoph.langer at sap.com>
>>>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
>> <rob.mckenna at oracle.com>
>>>>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface -
>> fixes
>>>>> and improvements for network interface listing
>>>>>
>>>>> Hi Christoph,
>>>>>
>>>>> On 22/08/16 11:00, Langer, Christoph wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> I understand your concerns regarding too much change here which could
>>>>> result in subtle differences that might not be wanted for a released
>> version.
>>>>>> The main motivation for me to integrate the change into JDK 8 is
>>>>> mergeability. In our SAP JVM 8 we had the need to do several fixes for
>>>>> problems on various of our supported platforms. And with the current
>> coding
>>>>> layout it is very hard to do fixes, especially for AIX/Linux as all the #ifdefs
>>>> make
>>>>> it a mess. So we already stepped to a version of code that merely matches
>>>> the
>>>>> JDK9 version.
>>>>>
>>>>> I understand, and can sympathize with this.
>>>>>
>>>>>> But I agree that with my proposal
>>>>> (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/) I'm
>> probably
>>>>> touching unnecessary places and make a review really hard.
>>>>>
>>>>> Well after further thought, if we are going to make changes here,
>>>>> then maybe there is an argument for keeping the code consistent
>>>>> with 9, at least we end up with a single body of code.
>>>>>
>>>>> 8160174 has been in JDK 9 for almost a month, and there have been
>>>>> no reported issues.
>>>>>
>>>>> Is it the case that with your previous proposal that the 8u version
>>>>> of the file is identical to that of the 9 version?
>>>>>
>>>>> -Chris.
>>>>>
>>>>>> What about this proposal for downporting the fix to Bug 8158519:
>>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/
>>>>>>
>>>>>> Here I really only split the enumIPv*Interfaces methods to a clean
>> structure
>>>>> and then make the necessary changes to eliminate getBroadcast() and
>>>>> getSubnet() functions in order to determine that information correctly in
>>>> place
>>>>> before calling addif.
>>>>>> Could you give a review for that?
>>>>>>
>>>>>> Thanks a lot
>>>>>> Christoph
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>>>>>>> Sent: Donnerstag, 18. August 2016 17:49
>>>>>>> To: Langer, Christoph <christoph.langer at sap.com>
>>>>>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
>>>> <rob.mckenna at oracle.com>
>>>>>>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface -
>>>>> fixes
>>>>>>> and improvements for network interface listing
>>>>>>>
>>>>>>> On 16 Aug 2016, at 15:41, Rob McKenna <rob.mckenna at oracle.com>
>>>>> wrote:
>>>>>>>> Hi Christoph,
>>>>>>>>
>>>>>>>> If the patch has changed from 9 you will need a separate review.
>>>>>>>>
>>>>>>>> 	-Rob
>>>>>>>>
>>>>>>>> On 16/08/16 10:09, Langer, Christoph wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> can I get approval for backporting the following fix:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
>>>>>>>>>
>>>>>>>>> Jdk9 change:
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
>>>>>>>>> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-
>>>> dev/2016-
>>>>>>> July/010100.html
>>>>>>>>>
>>>>>>>>> I had to modify the jdk9 patch after unshuffling to get it to apply to
>>>> 8udev.
>>>>>>> This is the new webrev:
>>>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
>>>>>>>
>>>>>>> Wow, there are quite a lot of changes in this. I do remember reviewing
>>>> this
>>>>> for
>>>>>>> 9 ( it
>>>>>>> took a long time ).  I do have a concern that this change may cause some
>>>>> subtle
>>>>>>> behavioural differences, since the underlying systems calls may be
>>>> different.
>>>>>>> This
>>>>>>> may be acceptable for a major release, but not so for an update release.
>>>>>>>
>>>>>>> Is there a strong need for this to be backported?
>>>>>>>
>>>>>>> -Chris.


From christoph.langer at sap.com  Fri Aug 26 06:24:25 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 26 Aug 2016 06:24:25 +0000
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <d2cbadb9-09e6-a687-0a2c-422d9f76b439@oracle.com>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
	<f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
	<ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>
	<3f8c3680087d412c8e590ace6f7285de@DEWDFE13DE11.global.corp.sap>
	<1924989a-1ccc-8bc4-b6cf-8ece75abffaa@oracle.com>
	<9aa68d6b38394b39961416b21eb5fe29@DEWDFE13DE11.global.corp.sap>
	<d2cbadb9-09e6-a687-0a2c-422d9f76b439@oracle.com>
Message-ID: <93a479b95c7749a28b6122b89c06307e@DEWDFE13DE11.global.corp.sap>

Thanks Sean and David.

Can either of you push it for me as I'm no jdk8 committer?

Best regards
Christoph

> -----Original Message-----
> From: Sean Coffey [mailto:sean.coffey at oracle.com]
> Sent: Donnerstag, 25. August 2016 19:10
> To: Langer, Christoph <christoph.langer at sap.com>; jdk8u-
> dev at openjdk.java.net
> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface - fixes
> and improvements for network interface listing
> 
> Approved for jdk8u-dev. David Buck ran your patch through our build &
> test system (JPRT). No issues spotted.
> 
> regards
> Sean.
> 
> 
> On 24/08/2016 11:51, Langer, Christoph wrote:
> > Hi,
> >
> > forwarding Chris' review for the downported change.
> >
> > Can I please get the approval now?
> >
> > Thanks
> > Christoph
> >
> >> -----Original Message-----
> >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >> Sent: Mittwoch, 24. August 2016 12:04
> >> To: Langer, Christoph <christoph.langer at sap.com>
> >> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface -
> fixes
> >> and improvements for network interface listing
> >>
> >> On 24/08/16 10:23, Langer, Christoph wrote:
> >>> Hi Chris,
> >>>
> >>> so, does it mean you'll give a review for the backport change now?
> >> Yes. Consider it reviewed.
> >>
> >> -Chris.
> >>
> >>> Best regards
> >>> Christoph
> >>>
> >>>> -----Original Message-----
> >>>> From: Langer, Christoph
> >>>> Sent: Montag, 22. August 2016 16:38
> >>>> To: 'Chris Hegarty' <chris.hegarty at oracle.com>
> >>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
> <rob.mckenna at oracle.com>
> >>>> Subject: RE: Request for approval: 8160174: java.net.NetworkInterface -
> >> fixes
> >>>> and improvements for network interface listing
> >>>>
> >>>> Hi Chris,
> >>>>
> >>>> yes, the change for 8160174 would make the code mostly identical to the
> >>>> current JDK9 version, except for some calls to NET_ or JNU_
> >> macros/functions
> >>>> wich are either not available in 8 or I didn't dare to touch.
> >>>>
> >>>> Best
> >>>> Christoph
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >>>>> Sent: Montag, 22. August 2016 16:04
> >>>>> To: Langer, Christoph <christoph.langer at sap.com>
> >>>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
> >> <rob.mckenna at oracle.com>
> >>>>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface -
> >> fixes
> >>>>> and improvements for network interface listing
> >>>>>
> >>>>> Hi Christoph,
> >>>>>
> >>>>> On 22/08/16 11:00, Langer, Christoph wrote:
> >>>>>> Hi Chris,
> >>>>>>
> >>>>>> I understand your concerns regarding too much change here which
> could
> >>>>> result in subtle differences that might not be wanted for a released
> >> version.
> >>>>>> The main motivation for me to integrate the change into JDK 8 is
> >>>>> mergeability. In our SAP JVM 8 we had the need to do several fixes for
> >>>>> problems on various of our supported platforms. And with the current
> >> coding
> >>>>> layout it is very hard to do fixes, especially for AIX/Linux as all the #ifdefs
> >>>> make
> >>>>> it a mess. So we already stepped to a version of code that merely
> matches
> >>>> the
> >>>>> JDK9 version.
> >>>>>
> >>>>> I understand, and can sympathize with this.
> >>>>>
> >>>>>> But I agree that with my proposal
> >>>>> (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/) I'm
> >> probably
> >>>>> touching unnecessary places and make a review really hard.
> >>>>>
> >>>>> Well after further thought, if we are going to make changes here,
> >>>>> then maybe there is an argument for keeping the code consistent
> >>>>> with 9, at least we end up with a single body of code.
> >>>>>
> >>>>> 8160174 has been in JDK 9 for almost a month, and there have been
> >>>>> no reported issues.
> >>>>>
> >>>>> Is it the case that with your previous proposal that the 8u version
> >>>>> of the file is identical to that of the 9 version?
> >>>>>
> >>>>> -Chris.
> >>>>>
> >>>>>> What about this proposal for downporting the fix to Bug 8158519:
> >>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/
> >>>>>>
> >>>>>> Here I really only split the enumIPv*Interfaces methods to a clean
> >> structure
> >>>>> and then make the necessary changes to eliminate getBroadcast() and
> >>>>> getSubnet() functions in order to determine that information correctly in
> >>>> place
> >>>>> before calling addif.
> >>>>>> Could you give a review for that?
> >>>>>>
> >>>>>> Thanks a lot
> >>>>>> Christoph
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >>>>>>> Sent: Donnerstag, 18. August 2016 17:49
> >>>>>>> To: Langer, Christoph <christoph.langer at sap.com>
> >>>>>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
> >>>> <rob.mckenna at oracle.com>
> >>>>>>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface
> -
> >>>>> fixes
> >>>>>>> and improvements for network interface listing
> >>>>>>>
> >>>>>>> On 16 Aug 2016, at 15:41, Rob McKenna <rob.mckenna at oracle.com>
> >>>>> wrote:
> >>>>>>>> Hi Christoph,
> >>>>>>>>
> >>>>>>>> If the patch has changed from 9 you will need a separate review.
> >>>>>>>>
> >>>>>>>> 	-Rob
> >>>>>>>>
> >>>>>>>> On 16/08/16 10:09, Langer, Christoph wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> can I get approval for backporting the following fix:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8160174
> >>>>>>>>>
> >>>>>>>>> Jdk9 change:
> >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
> >>>>>>>>> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/net-
> >>>> dev/2016-
> >>>>>>> July/010100.html
> >>>>>>>>>
> >>>>>>>>> I had to modify the jdk9 patch after unshuffling to get it to apply to
> >>>> 8udev.
> >>>>>>> This is the new webrev:
> >>>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
> >>>>>>>
> >>>>>>> Wow, there are quite a lot of changes in this. I do remember
> reviewing
> >>>> this
> >>>>> for
> >>>>>>> 9 ( it
> >>>>>>> took a long time ).  I do have a concern that this change may cause
> some
> >>>>> subtle
> >>>>>>> behavioural differences, since the underlying systems calls may be
> >>>> different.
> >>>>>>> This
> >>>>>>> may be acceptable for a major release, but not so for an update
> release.
> >>>>>>>
> >>>>>>> Is there a strong need for this to be backported?
> >>>>>>>
> >>>>>>> -Chris.


From sean.coffey at oracle.com  Fri Aug 26 07:53:42 2016
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Fri, 26 Aug 2016 08:53:42 +0100
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <93a479b95c7749a28b6122b89c06307e@DEWDFE13DE11.global.corp.sap>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
	<f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
	<ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>
	<3f8c3680087d412c8e590ace6f7285de@DEWDFE13DE11.global.corp.sap>
	<1924989a-1ccc-8bc4-b6cf-8ece75abffaa@oracle.com>
	<9aa68d6b38394b39961416b21eb5fe29@DEWDFE13DE11.global.corp.sap>
	<d2cbadb9-09e6-a687-0a2c-422d9f76b439@oracle.com>
	<93a479b95c7749a28b6122b89c06307e@DEWDFE13DE11.global.corp.sap>
Message-ID: <4DA2EA6F-C124-4F6F-BD60-3D06168AE74E@oracle.com>

Sure, we can push this change.

Regards,
Sean.

On 26 August 2016 07:24:25 GMT+01:00, "Langer, Christoph" <christoph.langer at sap.com> wrote:
>Thanks Sean and David.
>
>Can either of you push it for me as I'm no jdk8 committer?
>
>Best regards
>Christoph
>
>> -----Original Message-----
>> From: Sean Coffey [mailto:sean.coffey at oracle.com]
>> Sent: Donnerstag, 25. August 2016 19:10
>> To: Langer, Christoph <christoph.langer at sap.com>; jdk8u-
>> dev at openjdk.java.net
>> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface
>- fixes
>> and improvements for network interface listing
>> 
>> Approved for jdk8u-dev. David Buck ran your patch through our build &
>> test system (JPRT). No issues spotted.
>> 
>> regards
>> Sean.
>> 
>> 
>> On 24/08/2016 11:51, Langer, Christoph wrote:
>> > Hi,
>> >
>> > forwarding Chris' review for the downported change.
>> >
>> > Can I please get the approval now?
>> >
>> > Thanks
>> > Christoph
>> >
>> >> -----Original Message-----
>> >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>> >> Sent: Mittwoch, 24. August 2016 12:04
>> >> To: Langer, Christoph <christoph.langer at sap.com>
>> >> Subject: Re: Request for approval: 8160174:
>java.net.NetworkInterface -
>> fixes
>> >> and improvements for network interface listing
>> >>
>> >> On 24/08/16 10:23, Langer, Christoph wrote:
>> >>> Hi Chris,
>> >>>
>> >>> so, does it mean you'll give a review for the backport change
>now?
>> >> Yes. Consider it reviewed.
>> >>
>> >> -Chris.
>> >>
>> >>> Best regards
>> >>> Christoph
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Langer, Christoph
>> >>>> Sent: Montag, 22. August 2016 16:38
>> >>>> To: 'Chris Hegarty' <chris.hegarty at oracle.com>
>> >>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
>> <rob.mckenna at oracle.com>
>> >>>> Subject: RE: Request for approval: 8160174:
>java.net.NetworkInterface -
>> >> fixes
>> >>>> and improvements for network interface listing
>> >>>>
>> >>>> Hi Chris,
>> >>>>
>> >>>> yes, the change for 8160174 would make the code mostly identical
>to the
>> >>>> current JDK9 version, except for some calls to NET_ or JNU_
>> >> macros/functions
>> >>>> wich are either not available in 8 or I didn't dare to touch.
>> >>>>
>> >>>> Best
>> >>>> Christoph
>> >>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>> >>>>> Sent: Montag, 22. August 2016 16:04
>> >>>>> To: Langer, Christoph <christoph.langer at sap.com>
>> >>>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
>> >> <rob.mckenna at oracle.com>
>> >>>>> Subject: Re: Request for approval: 8160174:
>java.net.NetworkInterface -
>> >> fixes
>> >>>>> and improvements for network interface listing
>> >>>>>
>> >>>>> Hi Christoph,
>> >>>>>
>> >>>>> On 22/08/16 11:00, Langer, Christoph wrote:
>> >>>>>> Hi Chris,
>> >>>>>>
>> >>>>>> I understand your concerns regarding too much change here
>which
>> could
>> >>>>> result in subtle differences that might not be wanted for a
>released
>> >> version.
>> >>>>>> The main motivation for me to integrate the change into JDK 8
>is
>> >>>>> mergeability. In our SAP JVM 8 we had the need to do several
>fixes for
>> >>>>> problems on various of our supported platforms. And with the
>current
>> >> coding
>> >>>>> layout it is very hard to do fixes, especially for AIX/Linux as
>all the #ifdefs
>> >>>> make
>> >>>>> it a mess. So we already stepped to a version of code that
>merely
>> matches
>> >>>> the
>> >>>>> JDK9 version.
>> >>>>>
>> >>>>> I understand, and can sympathize with this.
>> >>>>>
>> >>>>>> But I agree that with my proposal
>> >>>>> (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/)
>I'm
>> >> probably
>> >>>>> touching unnecessary places and make a review really hard.
>> >>>>>
>> >>>>> Well after further thought, if we are going to make changes
>here,
>> >>>>> then maybe there is an argument for keeping the code consistent
>> >>>>> with 9, at least we end up with a single body of code.
>> >>>>>
>> >>>>> 8160174 has been in JDK 9 for almost a month, and there have
>been
>> >>>>> no reported issues.
>> >>>>>
>> >>>>> Is it the case that with your previous proposal that the 8u
>version
>> >>>>> of the file is identical to that of the 9 version?
>> >>>>>
>> >>>>> -Chris.
>> >>>>>
>> >>>>>> What about this proposal for downporting the fix to Bug
>8158519:
>> >>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/
>> >>>>>>
>> >>>>>> Here I really only split the enumIPv*Interfaces methods to a
>clean
>> >> structure
>> >>>>> and then make the necessary changes to eliminate getBroadcast()
>and
>> >>>>> getSubnet() functions in order to determine that information
>correctly in
>> >>>> place
>> >>>>> before calling addif.
>> >>>>>> Could you give a review for that?
>> >>>>>>
>> >>>>>> Thanks a lot
>> >>>>>> Christoph
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>> >>>>>>> Sent: Donnerstag, 18. August 2016 17:49
>> >>>>>>> To: Langer, Christoph <christoph.langer at sap.com>
>> >>>>>>> Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
>> >>>> <rob.mckenna at oracle.com>
>> >>>>>>> Subject: Re: Request for approval: 8160174:
>java.net.NetworkInterface
>> -
>> >>>>> fixes
>> >>>>>>> and improvements for network interface listing
>> >>>>>>>
>> >>>>>>> On 16 Aug 2016, at 15:41, Rob McKenna
><rob.mckenna at oracle.com>
>> >>>>> wrote:
>> >>>>>>>> Hi Christoph,
>> >>>>>>>>
>> >>>>>>>> If the patch has changed from 9 you will need a separate
>review.
>> >>>>>>>>
>> >>>>>>>> 	-Rob
>> >>>>>>>>
>> >>>>>>>> On 16/08/16 10:09, Langer, Christoph wrote:
>> >>>>>>>>> Hi,
>> >>>>>>>>>
>> >>>>>>>>> can I get approval for backporting the following fix:
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Original Bug:
>https://bugs.openjdk.java.net/browse/JDK-8160174
>> >>>>>>>>>
>> >>>>>>>>> Jdk9 change:
>> >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
>> >>>>>>>>> Jdk9 review thread:
>http://mail.openjdk.java.net/pipermail/net-
>> >>>> dev/2016-
>> >>>>>>> July/010100.html
>> >>>>>>>>>
>> >>>>>>>>> I had to modify the jdk9 patch after unshuffling to get it
>to apply to
>> >>>> 8udev.
>> >>>>>>> This is the new webrev:
>> >>>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
>> >>>>>>>
>> >>>>>>> Wow, there are quite a lot of changes in this. I do remember
>> reviewing
>> >>>> this
>> >>>>> for
>> >>>>>>> 9 ( it
>> >>>>>>> took a long time ).  I do have a concern that this change may
>cause
>> some
>> >>>>> subtle
>> >>>>>>> behavioural differences, since the underlying systems calls
>may be
>> >>>> different.
>> >>>>>>> This
>> >>>>>>> may be acceptable for a major release, but not so for an
>update
>> release.
>> >>>>>>>
>> >>>>>>> Is there a strong need for this to be backported?
>> >>>>>>>
>> >>>>>>> -Chris.

--
Regards,
Sean.
 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From david.buck at oracle.com  Fri Aug 26 11:35:51 2016
From: david.buck at oracle.com (david buck)
Date: Fri, 26 Aug 2016 20:35:51 +0900
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <4DA2EA6F-C124-4F6F-BD60-3D06168AE74E@oracle.com>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
	<f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
	<ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>
	<3f8c3680087d412c8e590ace6f7285de@DEWDFE13DE11.global.corp.sap>
	<1924989a-1ccc-8bc4-b6cf-8ece75abffaa@oracle.com>
	<9aa68d6b38394b39961416b21eb5fe29@DEWDFE13DE11.global.corp.sap>
	<d2cbadb9-09e6-a687-0a2c-422d9f76b439@oracle.com>
	<93a479b95c7749a28b6122b89c06307e@DEWDFE13DE11.global.corp.sap>
	<4DA2EA6F-C124-4F6F-BD60-3D06168AE74E@oracle.com>
Message-ID: <e460bf1f-70a0-09bb-7e4d-73ecb1be73c3@oracle.com>

done

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3dc438e0c8e1

Cheers,
-Buck

On 2016/08/26 16:53, Se?n Coffey wrote:
> Sure, we can push this change.
>
> Regards,
> Sean.
>
> On 26 August 2016 07:24:25 GMT+01:00, "Langer, Christoph"
> <christoph.langer at sap.com> wrote:
>
>     Thanks Sean and David.
>
>     Can either of you push it for me as I'm no jdk8 committer?
>
>     Best regards
>     Christoph
>
>         -----Original Message-----
>         From: Sean Coffey [mailto:sean.coffey at oracle.com]
>         Sent: Donnerstag, 25. August 2016 19:10
>         To: Langer, Christoph <christoph.langer at sap.com>; jdk8u-
>         dev at openjdk.java.net
>         Subject: Re: Request for approval: 8160174: java.net
>         <http://java.net>.NetworkInterface - fixes
>         and improvements for network interface listing
>
>         Approved for jdk8u-dev. David Buck ran your patch through our
>         build &
>         test system (JPRT). No issues spotted.
>
>         regards
>         Sean.
>
>
>         On 24/08/2016 11:51, Langer, Christoph wrote:
>
>             Hi,
>
>             forwarding Chris' review for the downported change.
>
>             Can I please get the approval now?
>
>             Thanks
>             Christoph
>
>                 -----Original Message-----
>                 From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
>                 Sent: Mittwoch, 24. August 2016 12:04
>                 To: Langer, Christoph <christoph.langer at sap.com>
>                 Subject: Re: Request for approval: 8160174: java.net
>                 <http://java.net>.NetworkInterface -
>
>         fixes
>
>                 and improvements for network interface listing
>
>                 On 24/08/16 10:23, Langer, Christoph wrote:
>
>                     Hi Chris,
>
>                     so, does it mean you'll give a review for the
>                     backport change now?
>
>                 Yes. Consider it reviewed.
>
>                 -Chris.
>
>                     Best regards
>                     Christoph
>
>                         -----Original Message-----
>                         From: Langer, Christoph
>                         Sent: Montag, 22. August 2016 16:38
>                         To: 'Chris Hegarty' <chris.hegarty at oracle.com>
>                         Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
>
>         <rob.mckenna at oracle.com>
>
>                         Subject: RE: Request for approval: 8160174:
>                         java.net <http://java.net>.NetworkInterface -
>
>                 fixes
>
>                         and improvements for network interface listing
>
>                         Hi Chris,
>
>                         yes, the change for 8160174 would make the code
>                         mostly identical to the
>                         current JDK9 version, except for some calls to
>                         NET_ or JNU_
>
>                 macros/functions
>
>                         wich are either not available in 8 or I didn't
>                         dare to touch.
>
>                         Best
>                         Christoph
>
>                             -----Original Message-----
>                             From: Chris Hegarty
>                             [mailto:chris.hegarty at oracle.com]
>                             Sent: Montag, 22. August 2016 16:04
>                             To: Langer, Christoph <christoph.langer at sap.com>
>                             Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
>
>                 <rob.mckenna at oracle.com>
>
>                             Subject: Re: Request for approval: 8160174:
>                             java.net <http://java.net>.NetworkInterface -
>
>                 fixes
>
>                             and improvements for network interface listing
>
>                             Hi Christoph,
>
>                             On 22/08/16 11:00, Langer, Christoph wrote:
>
>                                 Hi Chris,
>
>                                 I understand your concerns regarding too
>                                 much change here which
>
>         could
>
>                             result in subtle differences that might not
>                             be wanted for a released
>
>                 version.
>
>                                 The main motivation for me to integrate
>                                 the change into JDK 8 is
>
>                             mergeability. In our SAP JVM 8 we had the
>                             need to do several fixes for
>                             problems on various of our supported
>                             platforms. And with the current
>
>                 coding
>
>                             layout it is very hard to do fixes,
>                             especially for AIX/Linux as all the #ifdefs
>
>                         make
>
>                             it a mess. So we already stepped to a
>                             version of code that merely
>
>         matches
>
>                         the
>
>                             JDK9 version.
>
>                             I understand, and can sympathize with this.
>
>                                 But I agree that with my proposal
>
>                             (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/)
>                             I'm
>
>                 probably
>
>                             touching unnecessary places and make a
>                             review really hard.
>
>                             Well after further thought, if we are going
>                             to make changes here,
>                             then maybe there is an argument for keeping
>                             the code consistent
>                             with 9, at least we end up with a single
>                             body of code.
>
>                             8160174 has been in JDK 9 for almost a
>                             month, and there have been
>                             no reported issues.
>
>                             Is it the case that with your previous
>                             proposal that the 8u version
>                             of the file is identical to that of the 9
>                             version?
>
>                             -Chris.
>
>                                 What about this proposal for downporting
>                                 the fix to Bug 8158519:
>                                 http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/
>
>                                 Here I really only split the
>                                 enumIPv*Interfaces methods to a clean
>
>                 structure
>
>                             and then make the necessary changes to
>                             eliminate getBroadcast() and
>                             getSubnet() functions in order to determine
>                             that information correctly in
>
>                         place
>
>                             before calling addif.
>
>                                 Could you give a review for that?
>
>                                 Thanks a lot
>                                 Christoph
>
>
>
>                                     -----Original Message-----
>                                     From: Chris Hegarty
>                                     [mailto:chris.hegarty at oracle.com]
>                                     Sent: Donnerstag, 18. August 2016 17:49
>                                     To: Langer, Christoph
>                                     <christoph.langer at sap.com>
>                                     Cc: jdk8u-dev at openjdk.java.net; Rob
>                                     McKenna
>
>                         <rob.mckenna at oracle.com>
>
>                                     Subject: Re: Request for approval:
>                                     8160174: java.net
>                                     <http://java.net>.NetworkInterface
>
>         -
>
>                             fixes
>
>                                     and improvements for network
>                                     interface listing
>
>                                     On 16 Aug 2016, at 15:41, Rob
>                                     McKenna <rob.mckenna at oracle.com>
>
>                             wrote:
>
>                                         Hi Christoph,
>
>                                         If the patch has changed from 9
>                                         you will need a separate review.
>
>                                         -Rob
>
>                                         On 16/08/16 10:09, Langer,
>                                         Christoph wrote:
>
>                                             Hi,
>
>                                             can I get approval for
>                                             backporting the following fix:
>
>
>                                             Original Bug:
>                                             https://bugs.openjdk.java.net/browse/JDK-8160174
>
>                                             Jdk9 change:
>
>                 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
>
>                                             Jdk9 review thread:
>                                             http://mail.openjdk.java.net/pipermail/net-
>
>                         dev/2016-
>
>                                     July/010100.html
>
>
>                                             I had to modify the jdk9
>                                             patch after unshuffling to
>                                             get it to apply to
>
>                         8udev.
>
>                                     This is the new webrev:
>                                     http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
>
>                                     Wow, there are quite a lot of
>                                     changes in this. I do remember
>
>         reviewing
>
>                         this
>
>                             for
>
>                                     9 ( it
>                                     took a long time ). I do have a
>                                     concern that this change may cause
>
>         some
>
>                             subtle
>
>                                     behavioural differences, since the
>                                     underlying systems calls may be
>
>                         different.
>
>                                     This
>                                     may be acceptable for a major
>                                     release, but not so for an update
>
>         release.
>
>
>                                     Is there a strong need for this to
>                                     be backported?
>
>                                     -Chris.
>
>
>
> --
> Regards,
> Sean.
>
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

From christoph.langer at sap.com  Fri Aug 26 11:58:46 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 26 Aug 2016 11:58:46 +0000
Subject: Request for approval: 8160174: java.net.NetworkInterface - fixes
	and improvements for network interface listing
In-Reply-To: <e460bf1f-70a0-09bb-7e4d-73ecb1be73c3@oracle.com>
References: <67f367a01e554bda8ce68966fc71224b@DEWDFE13DE11.global.corp.sap>
	<20160816144126.GB4783@vimes>
	<19C3B85B-1F31-4EEF-9820-FE290335F6ED@oracle.com>
	<f161f1382b664a9eb221a93da5af282d@DEWDFE13DE11.global.corp.sap>
	<ca02d641-96e7-923d-b1c9-bbe6760bf396@oracle.com>
	<3f8c3680087d412c8e590ace6f7285de@DEWDFE13DE11.global.corp.sap>
	<1924989a-1ccc-8bc4-b6cf-8ece75abffaa@oracle.com>
	<9aa68d6b38394b39961416b21eb5fe29@DEWDFE13DE11.global.corp.sap>
	<d2cbadb9-09e6-a687-0a2c-422d9f76b439@oracle.com>
	<93a479b95c7749a28b6122b89c06307e@DEWDFE13DE11.global.corp.sap>
	<4DA2EA6F-C124-4F6F-BD60-3D06168AE74E@oracle.com>
	<e460bf1f-70a0-09bb-7e4d-73ecb1be73c3@oracle.com>
Message-ID: <5e3dfa48a79e425e90a73a6bb5e67345@DEWDFE13DE11.global.corp.sap>

Thanks a lot.

> -----Original Message-----
> From: david buck [mailto:david.buck at oracle.com]
> Sent: Freitag, 26. August 2016 13:36
> To: Se?n Coffey <sean.coffey at oracle.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Cc: jdk8u-dev at openjdk.java.net
> Subject: Re: Request for approval: 8160174: java.net.NetworkInterface - fixes
> and improvements for network interface listing
> 
> done
> 
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3dc438e0c8e1
> 
> Cheers,
> -Buck
> 
> On 2016/08/26 16:53, Se?n Coffey wrote:
> > Sure, we can push this change.
> >
> > Regards,
> > Sean.
> >
> > On 26 August 2016 07:24:25 GMT+01:00, "Langer, Christoph"
> > <christoph.langer at sap.com> wrote:
> >
> >     Thanks Sean and David.
> >
> >     Can either of you push it for me as I'm no jdk8 committer?
> >
> >     Best regards
> >     Christoph
> >
> >         -----Original Message-----
> >         From: Sean Coffey [mailto:sean.coffey at oracle.com]
> >         Sent: Donnerstag, 25. August 2016 19:10
> >         To: Langer, Christoph <christoph.langer at sap.com>; jdk8u-
> >         dev at openjdk.java.net
> >         Subject: Re: Request for approval: 8160174: java.net
> >         <http://java.net>.NetworkInterface - fixes
> >         and improvements for network interface listing
> >
> >         Approved for jdk8u-dev. David Buck ran your patch through our
> >         build &
> >         test system (JPRT). No issues spotted.
> >
> >         regards
> >         Sean.
> >
> >
> >         On 24/08/2016 11:51, Langer, Christoph wrote:
> >
> >             Hi,
> >
> >             forwarding Chris' review for the downported change.
> >
> >             Can I please get the approval now?
> >
> >             Thanks
> >             Christoph
> >
> >                 -----Original Message-----
> >                 From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> >                 Sent: Mittwoch, 24. August 2016 12:04
> >                 To: Langer, Christoph <christoph.langer at sap.com>
> >                 Subject: Re: Request for approval: 8160174: java.net
> >                 <http://java.net>.NetworkInterface -
> >
> >         fixes
> >
> >                 and improvements for network interface listing
> >
> >                 On 24/08/16 10:23, Langer, Christoph wrote:
> >
> >                     Hi Chris,
> >
> >                     so, does it mean you'll give a review for the
> >                     backport change now?
> >
> >                 Yes. Consider it reviewed.
> >
> >                 -Chris.
> >
> >                     Best regards
> >                     Christoph
> >
> >                         -----Original Message-----
> >                         From: Langer, Christoph
> >                         Sent: Montag, 22. August 2016 16:38
> >                         To: 'Chris Hegarty' <chris.hegarty at oracle.com>
> >                         Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
> >
> >         <rob.mckenna at oracle.com>
> >
> >                         Subject: RE: Request for approval: 8160174:
> >                         java.net <http://java.net>.NetworkInterface -
> >
> >                 fixes
> >
> >                         and improvements for network interface listing
> >
> >                         Hi Chris,
> >
> >                         yes, the change for 8160174 would make the code
> >                         mostly identical to the
> >                         current JDK9 version, except for some calls to
> >                         NET_ or JNU_
> >
> >                 macros/functions
> >
> >                         wich are either not available in 8 or I didn't
> >                         dare to touch.
> >
> >                         Best
> >                         Christoph
> >
> >                             -----Original Message-----
> >                             From: Chris Hegarty
> >                             [mailto:chris.hegarty at oracle.com]
> >                             Sent: Montag, 22. August 2016 16:04
> >                             To: Langer, Christoph <christoph.langer at sap.com>
> >                             Cc: jdk8u-dev at openjdk.java.net; Rob McKenna
> >
> >                 <rob.mckenna at oracle.com>
> >
> >                             Subject: Re: Request for approval: 8160174:
> >                             java.net <http://java.net>.NetworkInterface -
> >
> >                 fixes
> >
> >                             and improvements for network interface listing
> >
> >                             Hi Christoph,
> >
> >                             On 22/08/16 11:00, Langer, Christoph wrote:
> >
> >                                 Hi Chris,
> >
> >                                 I understand your concerns regarding too
> >                                 much change here which
> >
> >         could
> >
> >                             result in subtle differences that might not
> >                             be wanted for a released
> >
> >                 version.
> >
> >                                 The main motivation for me to integrate
> >                                 the change into JDK 8 is
> >
> >                             mergeability. In our SAP JVM 8 we had the
> >                             need to do several fixes for
> >                             problems on various of our supported
> >                             platforms. And with the current
> >
> >                 coding
> >
> >                             layout it is very hard to do fixes,
> >                             especially for AIX/Linux as all the #ifdefs
> >
> >                         make
> >
> >                             it a mess. So we already stepped to a
> >                             version of code that merely
> >
> >         matches
> >
> >                         the
> >
> >                             JDK9 version.
> >
> >                             I understand, and can sympathize with this.
> >
> >                                 But I agree that with my proposal
> >
> >
> (http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/)
> >                             I'm
> >
> >                 probably
> >
> >                             touching unnecessary places and make a
> >                             review really hard.
> >
> >                             Well after further thought, if we are going
> >                             to make changes here,
> >                             then maybe there is an argument for keeping
> >                             the code consistent
> >                             with 9, at least we end up with a single
> >                             body of code.
> >
> >                             8160174 has been in JDK 9 for almost a
> >                             month, and there have been
> >                             no reported issues.
> >
> >                             Is it the case that with your previous
> >                             proposal that the 8u version
> >                             of the file is identical to that of the 9
> >                             version?
> >
> >                             -Chris.
> >
> >                                 What about this proposal for downporting
> >                                 the fix to Bug 8158519:
> >
> http://cr.openjdk.java.net/~clanger/webrevs/8158519.8udev/
> >
> >                                 Here I really only split the
> >                                 enumIPv*Interfaces methods to a clean
> >
> >                 structure
> >
> >                             and then make the necessary changes to
> >                             eliminate getBroadcast() and
> >                             getSubnet() functions in order to determine
> >                             that information correctly in
> >
> >                         place
> >
> >                             before calling addif.
> >
> >                                 Could you give a review for that?
> >
> >                                 Thanks a lot
> >                                 Christoph
> >
> >
> >
> >                                     -----Original Message-----
> >                                     From: Chris Hegarty
> >                                     [mailto:chris.hegarty at oracle.com]
> >                                     Sent: Donnerstag, 18. August 2016 17:49
> >                                     To: Langer, Christoph
> >                                     <christoph.langer at sap.com>
> >                                     Cc: jdk8u-dev at openjdk.java.net; Rob
> >                                     McKenna
> >
> >                         <rob.mckenna at oracle.com>
> >
> >                                     Subject: Re: Request for approval:
> >                                     8160174: java.net
> >                                     <http://java.net>.NetworkInterface
> >
> >         -
> >
> >                             fixes
> >
> >                                     and improvements for network
> >                                     interface listing
> >
> >                                     On 16 Aug 2016, at 15:41, Rob
> >                                     McKenna <rob.mckenna at oracle.com>
> >
> >                             wrote:
> >
> >                                         Hi Christoph,
> >
> >                                         If the patch has changed from 9
> >                                         you will need a separate review.
> >
> >                                         -Rob
> >
> >                                         On 16/08/16 10:09, Langer,
> >                                         Christoph wrote:
> >
> >                                             Hi,
> >
> >                                             can I get approval for
> >                                             backporting the following fix:
> >
> >
> >                                             Original Bug:
> >                                             https://bugs.openjdk.java.net/browse/JDK-
> 8160174
> >
> >                                             Jdk9 change:
> >
> >                 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a8db670c7d12
> >
> >                                             Jdk9 review thread:
> >                                             http://mail.openjdk.java.net/pipermail/net-
> >
> >                         dev/2016-
> >
> >                                     July/010100.html
> >
> >
> >                                             I had to modify the jdk9
> >                                             patch after unshuffling to
> >                                             get it to apply to
> >
> >                         8udev.
> >
> >                                     This is the new webrev:
> >
> http://cr.openjdk.java.net/~clanger/webrevs/8160174.8udev/
> >
> >                                     Wow, there are quite a lot of
> >                                     changes in this. I do remember
> >
> >         reviewing
> >
> >                         this
> >
> >                             for
> >
> >                                     9 ( it
> >                                     took a long time ). I do have a
> >                                     concern that this change may cause
> >
> >         some
> >
> >                             subtle
> >
> >                                     behavioural differences, since the
> >                                     underlying systems calls may be
> >
> >                         different.
> >
> >                                     This
> >                                     may be acceptable for a major
> >                                     release, but not so for an update
> >
> >         release.
> >
> >
> >                                     Is there a strong need for this to
> >                                     be backported?
> >
> >                                     -Chris.
> >
> >
> >
> > --
> > Regards,
> > Sean.
> >
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.

From mallikarjuna.avaluri at oracle.com  Mon Aug 29 02:31:46 2016
From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri)
Date: Mon, 29 Aug 2016 08:01:46 +0530
Subject: Request for approval: JDK-8160913: [TEST_BUG]
	javax/management/security/SecurityTest.java fails due to missing
	keyStore file
In-Reply-To: <ed9ccf5a-d31b-5ec2-dcd6-d6e94558db71@oracle.com>
References: <dc1df699-bb81-87f0-40c7-3addd424ad5e@oracle.com>
	<ed9ccf5a-d31b-5ec2-dcd6-d6e94558db71@oracle.com>
Message-ID: <1f5cc76d-e382-23e9-2434-991cfa4e9b5d@oracle.com>

Hi,

Code review has happened in different thread, please find the link below 
for the same.

Review link 
:http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020165.html 


Please help me with this Approval.


Regards,

Mallikarjuna Avaluri


On 8/22/2016 9:51 AM, Mallikarjuna Avaluri wrote:
>
> Hi,
>
> Reminder,  please help me with this Approval.
>
>
> Regards,
>
> Mallikarjuna Avaluri
>
>
> On 8/18/2016 11:37 AM, Mallikarjuna Avaluri wrote:
>>
>> Hi all,
>>
>> Please Approve the fix for following issue.
>>
>> JDK-8160913: [TEST_BUG] javax/management/security/SecurityTest.java 
>> fails due to missing keyStore file
>> https://bugs.openjdk.java.net/browse/JDK-8160913
>>
>> Fix:  Following files keystoreAgent, keystoreClient, truststoreAgent 
>> and truststoreClient were created under jdk/test/javax/management/ 
>> folder,
>> while test expects them under jdk/test/javax/management/security/ 
>> path. Moved the files to correct folder.
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~bgopularam/mavaluri/rev/8160913/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Ebgopularam/mavaluri/rev/8160913/webrev.00/>
>>
>>
>> Thanks,
>> Mallikarjuna Avaluri
>>
>


From david.buck at oracle.com  Mon Aug 29 02:48:57 2016
From: david.buck at oracle.com (david buck)
Date: Mon, 29 Aug 2016 11:48:57 +0900
Subject: Request for approval: JDK-8160913: [TEST_BUG]
	javax/management/security/SecurityTest.java fails due to missing
	keyStore file
In-Reply-To: <1f5cc76d-e382-23e9-2434-991cfa4e9b5d@oracle.com>
References: <dc1df699-bb81-87f0-40c7-3addd424ad5e@oracle.com>
	<ed9ccf5a-d31b-5ec2-dcd6-d6e94558db71@oracle.com>
	<1f5cc76d-e382-23e9-2434-991cfa4e9b5d@oracle.com>
Message-ID: <3fa2a8bc-cdce-d9ea-5c57-6aea08ed6c40@oracle.com>

approved for push into 8u-dev

Cheers,
-Buck

On 2016/08/29 11:31, Mallikarjuna Avaluri wrote:
> Hi,
>
> Code review has happened in different thread, please find the link below
> for the same.
>
> Review link
> :http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020165.html
>
>
> Please help me with this Approval.
>
>
> Regards,
>
> Mallikarjuna Avaluri
>
>
> On 8/22/2016 9:51 AM, Mallikarjuna Avaluri wrote:
>>
>> Hi,
>>
>> Reminder,  please help me with this Approval.
>>
>>
>> Regards,
>>
>> Mallikarjuna Avaluri
>>
>>
>> On 8/18/2016 11:37 AM, Mallikarjuna Avaluri wrote:
>>>
>>> Hi all,
>>>
>>> Please Approve the fix for following issue.
>>>
>>> JDK-8160913: [TEST_BUG] javax/management/security/SecurityTest.java
>>> fails due to missing keyStore file
>>> https://bugs.openjdk.java.net/browse/JDK-8160913
>>>
>>> Fix:  Following files keystoreAgent, keystoreClient, truststoreAgent
>>> and truststoreClient were created under jdk/test/javax/management/
>>> folder,
>>> while test expects them under jdk/test/javax/management/security/
>>> path. Moved the files to correct folder.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~bgopularam/mavaluri/rev/8160913/webrev.00/ <http://cr.openjdk.java.net/%7Ebgopularam/mavaluri/rev/8160913/webrev.00/>
>>>
>>>
>>>
>>> Thanks,
>>> Mallikarjuna Avaluri
>>>
>>
>

From li.jiang at oracle.com  Mon Aug 29 17:24:11 2016
From: li.jiang at oracle.com (Leo Jiang)
Date: Tue, 30 Aug 2016 01:24:11 +0800
Subject: [jdk8u-dev] Request for Review: 8129533: ISO 4217 amendment 160
Message-ID: <abd68005-4bf0-e8a4-dfc7-dbe0571486f6@oracle.com>

Hi,

Request a review for JDK8 as well as approval.

Webrev: http://cr.openjdk.java.net/~ljiang/8129533/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8129533

This is a backport of the original fix to support ISO 4127 amendment #160.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8129361

I had tried the unshuffle_patch tool but failed as the paths of CurrencyData.properties and CurrencyNames.properties are 
not managed by the tool. I had to modify the patch and edit manually to apply to 8u repo.

I had run the builds on all platforms and test with jprt.

Thanks,
Leo

From naoto.sato at oracle.com  Mon Aug 29 20:13:10 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 29 Aug 2016 13:13:10 -0700
Subject: [jdk8u-dev] Request for Review: 8129533: ISO 4217 amendment 160
In-Reply-To: <abd68005-4bf0-e8a4-dfc7-dbe0571486f6@oracle.com>
References: <abd68005-4bf0-e8a4-dfc7-dbe0571486f6@oracle.com>
Message-ID: <14fcdadc-6415-24c0-bd75-e6733db455e1@oracle.com>

Hi Leo,

The change looks good to me. Also I approve to backport this to 
jdk8u-dev. Please note that you need to use the *original* bug id for 
both the review and the changeset comment.

Naoto

On 8/29/16 10:24 AM, Leo Jiang wrote:
> Hi,
>
> Request a review for JDK8 as well as approval.
>
> Webrev: http://cr.openjdk.java.net/~ljiang/8129533/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8129533
>
> This is a backport of the original fix to support ISO 4127 amendment #160.
>
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8129361
>
> I had tried the unshuffle_patch tool but failed as the paths of
> CurrencyData.properties and CurrencyNames.properties are not managed by
> the tool. I had to modify the patch and edit manually to apply to 8u repo.
>
> I had run the builds on all platforms and test with jprt.
>
> Thanks,
> Leo

From ivan.gerasimov at oracle.com  Tue Aug 30 12:57:30 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 30 Aug 2016 15:57:30 +0300
Subject: [8u-dev] Request for approval to backport: 6474807: (smartcardio)
	CardTerminal.connect() throws CardException instead of
	CardNotPresentException
Message-ID: <a40cb1a2-d63c-45ac-5db1-4fff108c1fac@oracle.com>

Hello!

May I please have an approval to backport this fix of a conformance 
issue to jdk8u?

The unshuffled fix applies cleanly.

Bug: https://bugs.openjdk.java.net/browse/JDK-6474807
Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/556549260289
Jdk9 review: 
http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014768.html

With kind regards,
Ivan


From rob.mckenna at oracle.com  Tue Aug 30 14:00:29 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 30 Aug 2016 15:00:29 +0100
Subject: [8u-dev] Request for approval to backport: 6474807:
	(smartcardio) CardTerminal.connect() throws CardException instead of
	CardNotPresentException
In-Reply-To: <a40cb1a2-d63c-45ac-5db1-4fff108c1fac@oracle.com>
References: <a40cb1a2-d63c-45ac-5db1-4fff108c1fac@oracle.com>
Message-ID: <20160830140029.GA5186@tecra>

Approved

	-Rob

On 30/08/16 03:57, Ivan Gerasimov wrote:
> Hello!
> 
> May I please have an approval to backport this fix of a conformance issue to
> jdk8u?
> 
> The unshuffled fix applies cleanly.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-6474807
> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/556549260289
> Jdk9 review:
> http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014768.html
> 
> With kind regards,
> Ivan
> 

From svetlana.nikandrova at oracle.com  Wed Aug 31 09:45:35 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Wed, 31 Aug 2016 12:45:35 +0300
Subject: [8u-dev] Request for Approval 8164533:
	sun/security/ssl/SSLSocketImpl/CloseSocket.java
	failed with "Error while cleaning up threads after test"
Message-ID: <57C6A73F.3060605@oracle.com>

Hello,

please approve this test backport. Applied cleanly after path 
reshuffling. JPRT tested.

JBS: https://bugs.openjdk.java.net/browse/JDK-8164533
JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c5a832e62e0f
JDK 9 review thread: 
http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014751.html

Thank you,
Svetlana

From svetlana.nikandrova at oracle.com  Wed Aug 31 09:50:07 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Wed, 31 Aug 2016 12:50:07 +0300
Subject: [8u-dev] Request for Approval 8146602:
	jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java
	test fails with NullPointerException
Message-ID: <57C6A84F.2050901@oracle.com>

Hello,

please approve this test fix backport. Applied cleanly.

JBS: https://bugs.openjdk.java.net/browse/JDK-8146602 
<https://bugs.openjdk.java.net/browse/JDK-8164533>
JDK 9 changeset: hg.openjdk.java.net/jdk9/dev/jdk/rev/6f5da13861db 
<http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c5a832e62e0f>
JDK 9 review thread: 
http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010138.html 
<http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014751.html>

Thank you,
Svetlana

From david.buck at oracle.com  Wed Aug 31 09:50:43 2016
From: david.buck at oracle.com (david buck)
Date: Wed, 31 Aug 2016 18:50:43 +0900
Subject: [8u-dev] Request for Approval 8164533:
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <57C6A73F.3060605@oracle.com>
References: <57C6A73F.3060605@oracle.com>
Message-ID: <63e8c01d-2b05-2b7e-fce1-3e32b5a8257c@oracle.com>

Hi Svetlana!

Please add the appropriate noreg label to the bug report:

[ noreg bug labels ]
http://openjdk.java.net/guide/changePlanning.html#noreg

Once you have added the noreg label, please consider this approved for 
backport to 8u-dev.

Cheers,
-Buck

On 2016/08/31 18:45, Svetlana Nikandrova wrote:
> Hello,
>
> please approve this test backport. Applied cleanly after path
> reshuffling. JPRT tested.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8164533
> JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c5a832e62e0f
> JDK 9 review thread:
> http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014751.html
>
> Thank you,
> Svetlana

From shafi.s.ahmad at oracle.com  Wed Aug 31 10:45:56 2016
From: shafi.s.ahmad at oracle.com (Shafi Ahmad)
Date: Wed, 31 Aug 2016 03:45:56 -0700 (PDT)
Subject: [8u] RFA for JDK-8152438: Threads may do significant work out of the
	non-shared overflow buffer
Message-ID: <0e518206-e1ff-4659-9222-fd3903061ac8@default>

Hi,

Please approve this backport (patch doesn't apply cleanly) to 8u-dev.

Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8152438
Webrev: http://cr.openjdk.java.net/~shshahma/8152438/webrev.00/
Jdk8 review link: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024397.html
Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-May/018147.html

Regards,
Shafi

From svetlana.nikandrova at oracle.com  Wed Aug 31 10:50:19 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Wed, 31 Aug 2016 13:50:19 +0300
Subject: [8u-dev] Request for Approval 8146602:
	jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java
	test fails with NullPointerException
Message-ID: <57C6B66B.1000802@oracle.com>

(corrected link, please ignore my previous mail with this subj)

Hello,

please approve this test fix backport. Applied cleanly.

JBS: https://bugs.openjdk.java.net/browse/JDK-8146602 
<https://bugs.openjdk.java.net/browse/JDK-8164533>
JDK 9 changeset: hg.openjdk.java.net/jdk9/dev/jdk/rev/6f5da13861db 
<http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c5a832e62e0f>
JDK 9 review thread: 
http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010148.html 
<http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014751.html>

Thank you,
Svetlana

From svetlana.nikandrova at oracle.com  Wed Aug 31 11:32:43 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Wed, 31 Aug 2016 14:32:43 +0300
Subject: [8u-dev] Request for Approval 8146602:
	jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java
	test fails with NullPointerException
In-Reply-To: <57C6B66B.1000802@oracle.com>
References: <57C6B66B.1000802@oracle.com>
Message-ID: <57C6C05B.10803@oracle.com>

Oh, I did it again.

Ok, *this* is corrected links set:
JBS: https://bugs.openjdk.java.net/browse/JDK-8146602
JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6f5da13861db
JDK 9 review thread: 
http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010148.html

Thanks and sorry for all this spam,
Svetlana

On 31.08.2016 13:50, Svetlana Nikandrova wrote:
> (corrected link, please ignore my previous mail with this subj)
>
> Hello,
>
> please approve this test fix backport. Applied cleanly.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8146602 
> <https://bugs.openjdk.java.net/browse/JDK-8164533>
> JDK 9 changeset: hg.openjdk.java.net/jdk9/dev/jdk/rev/6f5da13861db 
> <http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c5a832e62e0f>
> JDK 9 review thread: 
> http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010148.html 
> <http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014751.html> 
>
>
> Thank you,
> Svetlana


From ivan.gerasimov at oracle.com  Wed Aug 31 11:48:57 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 31 Aug 2016 14:48:57 +0300
Subject: [8u-dev] Request for approval to backport: 8163896: Finalizing one
	key of a KeyPair invalidates the other key
Message-ID: <b28d44f3-cb97-68f7-3a05-4eee2be5cd77@oracle.com>

Hello!

I'd like to backport this bug fix to jdk8u.
The unshuffled patch applies cleanly.

Bug Id: https://bugs.openjdk.java.net/browse/JDK-8163896
Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7ed792ba0b17
Jdk9 review: 
http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014601.html

Would you please approve?

With kind regards,
Ivan


From david.buck at oracle.com  Wed Aug 31 11:53:09 2016
From: david.buck at oracle.com (david buck)
Date: Wed, 31 Aug 2016 20:53:09 +0900
Subject: [8u-dev] Request for approval to backport: 8163896: Finalizing
	one key of a KeyPair invalidates the other key
In-Reply-To: <b28d44f3-cb97-68f7-3a05-4eee2be5cd77@oracle.com>
References: <b28d44f3-cb97-68f7-3a05-4eee2be5cd77@oracle.com>
Message-ID: <0edd81db-d693-94ce-b8b7-a34955862c0a@oracle.com>

approved for backport to 8u-dev

Cheers,
-Buck

On 2016/08/31 20:48, Ivan Gerasimov wrote:
> Hello!
>
> I'd like to backport this bug fix to jdk8u.
> The unshuffled patch applies cleanly.
>
> Bug Id: https://bugs.openjdk.java.net/browse/JDK-8163896
> Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7ed792ba0b17
> Jdk9 review:
> http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014601.html
>
> Would you please approve?
>
> With kind regards,
> Ivan
>

From david.buck at oracle.com  Wed Aug 31 11:55:56 2016
From: david.buck at oracle.com (david buck)
Date: Wed, 31 Aug 2016 20:55:56 +0900
Subject: [8u-dev] Request for Approval 8146602:
	jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java test fails with
	NullPointerException
In-Reply-To: <57C6C05B.10803@oracle.com>
References: <57C6B66B.1000802@oracle.com> <57C6C05B.10803@oracle.com>
Message-ID: <bc2fc802-02af-917d-a27b-4346aef79e24@oracle.com>

approved for backport to 8u-dev

Cheers,
-Buck

On 2016/08/31 20:32, Svetlana Nikandrova wrote:
> Oh, I did it again.
>
> Ok, *this* is corrected links set:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8146602
> JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6f5da13861db
> JDK 9 review thread:
> http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010148.html
>
> Thanks and sorry for all this spam,
> Svetlana
>
> On 31.08.2016 13:50, Svetlana Nikandrova wrote:
>> (corrected link, please ignore my previous mail with this subj)
>>
>> Hello,
>>
>> please approve this test fix backport. Applied cleanly.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8146602
>> <https://bugs.openjdk.java.net/browse/JDK-8164533>
>> JDK 9 changeset: hg.openjdk.java.net/jdk9/dev/jdk/rev/6f5da13861db
>> <http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c5a832e62e0f>
>> JDK 9 review thread:
>> http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010148.html
>> <http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014751.html>
>>
>>
>> Thank you,
>> Svetlana
>

From rob.mckenna at oracle.com  Wed Aug 31 13:48:23 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 31 Aug 2016 14:48:23 +0100
Subject: [8u] RFA for JDK-8152438: Threads may do significant work out of
	the non-shared overflow buffer
In-Reply-To: <0e518206-e1ff-4659-9222-fd3903061ac8@default>
References: <0e518206-e1ff-4659-9222-fd3903061ac8@default>
Message-ID: <20160831134823.GA4689@vimes>

Please add an appropriate noreg label

Approved

	-Rob

On 31/08/16 03:45, Shafi Ahmad wrote:
> Hi,
> 
> Please approve this backport (patch doesn't apply cleanly) to 8u-dev.
> 
> Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8152438
> Webrev: http://cr.openjdk.java.net/~shshahma/8152438/webrev.00/
> Jdk8 review link: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024397.html
> Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-May/018147.html
> 
> Regards,
> Shafi

From alexander.vorobyev at oracle.com  Wed Aug 31 15:12:33 2016
From: alexander.vorobyev at oracle.com (Alexander Vorobyev)
Date: Wed, 31 Aug 2016 18:12:33 +0300
Subject: [8u-dev] Request for review: JDK-8151295: runtime/ErrorHandling
	fails when using jtreg 4.1 b13
In-Reply-To: <571A0E80.80903@oracle.com>
References: <542E8041.1010101@oracle.com> <5718DC9E.6070907@oracle.com>
	<CA+kOe08qkp796YWpdh2wwtK0=N8hxet=66h-SyMOqU4AXs6UwA@mail.gmail.com>
	<571A0E80.80903@oracle.com>
Message-ID: <ae1cb0b3-d2eb-62c3-114d-fa2976b82171@oracle.com>

Please review this fix for JDK 8.

I explained in my previous comment, why current code works in JDK 9 but 
does not work in JDK 8.


On 22.04.2016 14:44, Alexander Vorobyev wrote:
> JDK 9 does contain jdk.test.lib.* in hotspot/test/testlibrary so there 
> is no problem.
> But we are talking about JDK 8 here. There is no jdk.test.lib.* in 
> hotspot/test/teslibray. Instead, it contains 
> com.oracle.java.testlibrary.*
> So the main point of this fix is to use libraries which are available 
> in the hotspot testsuite.
>
> In the future, I guess,  com.oracle.java.testlibrary.* should be 
> renamed to jdk.test.lib.* (like in JDK 9 
> https://bugs.openjdk.java.net/browse/JDK-8067013)
>
> On 21.04.2016 19:14, Martin Buchholz wrote:
>> How does jdk9 work then?
>> Answering my own question, I think it's:
>>
>> # Path to libraries in the topmost test directory. This is needed so 
>> @library
>> # does not need ../../ notation to reach them
>> external.lib.roots = ../../
>>
>> On Thu, Apr 21, 2016 at 6:58 AM, Alexander Vorobyev
>> <alexander.vorobyev at oracle.com> wrote:
>>> Hi All,
>>>
>>> I'd like review for JDK-8151295
>>> (https://bugs.openjdk.java.net/browse/JDK-8151295)
>>>
>>> Looks like new version of jtreg by default does not allow to use 
>>> libraries
>>> from the outside of test suite. So I guess jdk.test.lib.* in 
>>> affected tests
>>> should be changed to com.oracle.java.testlibrary.* which is 
>>> available in the
>>> hotspot/test testsuite. At least until it renamed to jdk.testlibrary 
>>> (like
>>> here https://bugs.openjdk.java.net/browse/JDK-8067013).
>>>
>>>
>>>
>>> Here is webrev:
>>> http://cr.openjdk.java.net/~avorobye/8151295/
>>>
>>>
>>> Thanks,
>>> Alexander
>>>
>>>
>>>
>