From fweimer at redhat.com  Tue Jan  2 19:01:35 2018
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 2 Jan 2018 20:01:35 +0100
Subject: ASSEMBLY_EXCEPTION should be removed ?
In-Reply-To: <CA+3eh1109wuMqnQcFZwB1mNn3uKP2+8Y0aQb6ADWsRURch8trA@mail.gmail.com>
References: <CA+3eh1109wuMqnQcFZwB1mNn3uKP2+8Y0aQb6ADWsRURch8trA@mail.gmail.com>
Message-ID: <665fe2ec-c4ba-8b3e-efa1-5e77b7debdb9@redhat.com>

On 12/20/2017 11:15 AM, Volker Simonis wrote:
> in the course of the recent licensing cleanups I've just realized that
> the OpenJDK sources as well as the generated images still contain the
> ASSEMBLY_EXCEPTION license file [1].
> 
> I think this is just a leftover of the first OpenJDK versions which
> still required some binary parts provided by Sun at time in order to
> build and run successfully. As far as I can tell, this is not
> necessary since at least OpenJDK 7 so I think the ASSEMBLY_EXCEPTION
> file could also be removed.
> 
> What do you think?

Category 4 (?Any files in the OpenJDK distribution that are made 
available at openjdk.java.net, openjdk.dev.java.net, or 
download.java.net under an open source license other than GPL, and your 
derivatives thereof that are in compliance with the applicable open 
source license?) still looks relevant because it clarifies, among other 
things, that the combination of GPLv2-licensed OpenJDK code with code 
licenses under the Apache License, Version 2.0, is redistributable.

Thanks,
Florian

From volker.simonis at gmail.com  Wed Jan  3 14:56:12 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 3 Jan 2018 15:56:12 +0100
Subject: ASSEMBLY_EXCEPTION should be removed ?
In-Reply-To: <665fe2ec-c4ba-8b3e-efa1-5e77b7debdb9@redhat.com>
References: <CA+3eh1109wuMqnQcFZwB1mNn3uKP2+8Y0aQb6ADWsRURch8trA@mail.gmail.com>
 <665fe2ec-c4ba-8b3e-efa1-5e77b7debdb9@redhat.com>
Message-ID: <CA+3eh11y9jAf1wcNoS1vid=RUfaM-jycw+CL588-N+qfuDGg-g@mail.gmail.com>

On Tue, Jan 2, 2018 at 8:01 PM, Florian Weimer <fweimer at redhat.com> wrote:
> On 12/20/2017 11:15 AM, Volker Simonis wrote:
>>
>> in the course of the recent licensing cleanups I've just realized that
>> the OpenJDK sources as well as the generated images still contain the
>> ASSEMBLY_EXCEPTION license file [1].
>>
>> I think this is just a leftover of the first OpenJDK versions which
>> still required some binary parts provided by Sun at time in order to
>> build and run successfully. As far as I can tell, this is not
>> necessary since at least OpenJDK 7 so I think the ASSEMBLY_EXCEPTION
>> file could also be removed.
>>
>> What do you think?
>
>
> Category 4 (?Any files in the OpenJDK distribution that are made available
> at openjdk.java.net, openjdk.dev.java.net, or download.java.net under an
> open source license other than GPL, and your derivatives thereof that are in
> compliance with the applicable open source license?) still looks relevant
> because it clarifies, among other things, that the combination of
> GPLv2-licensed OpenJDK code with code licenses under the Apache License,
> Version 2.0, is redistributable.
>

Yes, I agree with you. I've only looked at the ASSEMBLY_EXCEPTION from
the perspective of the binary plugs which were delivered with the
first versions of OpenJDK 6 (and which are covered by section 3 of the
"OpenJDK Designated Exception Modules" [1] document you cite from). So
actually only that third section of that exceptions modules document
could be removed which is probably not worth the work.

Thanks for pointing this out,
Volker

[1] http://openjdk.java.net/legal/exception-modules-2007-05-08.html

> Thanks,
> Florian

From volker.simonis at gmail.com  Sun Jan  7 12:10:05 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sun, 07 Jan 2018 12:10:05 +0000
Subject: Runtime code generation and barriers in migrating away from
 JVM-interal APIs
In-Reply-To: <CA+DM0A=7Lpq=VsDf0x_LtHb_8DGY+g1x4a=Lb-aTgmupzf1eng@mail.gmail.com>
References: <CA+DM0A=7Lpq=VsDf0x_LtHb_8DGY+g1x4a=Lb-aTgmupzf1eng@mail.gmail.com>
Message-ID: <CA+3eh10E6ZBZMgZUHr-0Y0yKSELBGk003OOGpb7amDO+SdKpoA@mail.gmail.com>

Hi Rafael,

thanks for the nice write up and your IMO reasonable suggestions.

I?m forwarding your mail to jdk-dev and core-libs-dev which are more
appropriate for this topic (adoption-discuss is more about bundling  and
distros).

Regards,
Volker

------- Weitergeleitete Nachricht ------
Von: Rafael Winterhalter <rafael.wth at gmail.com>
Datum: So. 7. Jan. 2018 um 00:08
Betreff: Runtime code generation and barriers in migrating away from
JVM-interal APIs
An: <adoption-discuss at openjdk.java.net>


Hello,

I am the author of Byte Buddy and a maintainer of cglib, two of the major
code generation libraries in the Java ecosystem. Both libraries are
downloaded about 160 million times a year and I wanted to give a report and
opinion on the current state of moving away from JVM-internal APIs to save
and officially supported alternatives.

When code generation tools define classes at runtime, there are currently
different alternatives to achieving that:

1) Using sun.misc.Unsafe::defineClass to define a class directly. This is a
fairly easy API that even allows defining classes in the bootstrap loader.
2) Accessing protected methods of java.lang.ClassLoader via Java
reflection. This allows more fine-grained access to class loading by
respecting class loading locks etc.
3) Creating a custom class loader as a parent of the class loader of a
proxied class. This avoids any use of internal API but limits proxying to
public (and since Java 9 also exported) classes and their protected and
public methods.
4) Using a Java agent to define classes using the Instrumentation API.
Using this API, it is also possible to gain access to internal APIs as it
becomes possible to open encapsulated APIs.
5) Using JNI to define classes using its APIs or to avoid encapsulation
altogether.

Of course, strategies (1) and (2) were always discouraged and might no
longer work in a future Java release due to the encapsulation of internal
APIs. Yet, as of Java 9, most code generation tools achieved Java 9
compatibility by migrating from solution (2) to solution (1) thanks to the
jdk.unsupported module. Method (5) is rarely used as it requires the
inclusion of C code for something that can be achieved easier.

As of Java 9, the JVM offers a new approach to defining classes:

6) Using java.lang.invoke.MethodHandles.Lookup::defineClass

While Byte Buddy supports this new approach as a user-chosen class
definition strategy, for most use cases, the API does not offer sufficient
comfort. Code generation is mainly used for the following two purposes:

A) When defining a proxy, the proxy class is normally defined in the same
package as the proxied class. Doing so, a proxy can be created for
package-private classes and it can proxy package-private methods. Using
strategy (6), it is however not possible to define a class in a package
outside of the package that has created the lookup as this would require
PACKAGE access for the target package. If the proxy is created by another
module then the module of the proxied class, this access right is never
available, even if the proxied class?s module opens its package to the
module that generates the proxy. In this context, Strategy (3) is not an
option either as the runtime package of the child class loader would be
different to the user class package?s class loader.

B) When programming a Java agent, a class enhancement makes it sometimes
necessary to define an auxiliary class in the same package as the
instrumented class. This is similar to javac?s need for such classes where
it sometimes defines anonymous classes to provide a certain type for using
an API. Unfortunately, the ClassFileTransformer::transform method does not
provide a method handle lookup for the package of the instrumented class.
At the same time, the Java agent itself typically lives in a different
package then the instrumented class such that it cannot create its own
lookup what makes (6) inapplicable. Of course, (3) is not an option in this
case either.

For scenario (A) one could argue that for many use cases, access to
package-private classes and methods is not necessary as it breaks the Java
programming language's encapsulation model. However, giving such access has
been proven useful in the past: the Spring framework does for example
induce a bean scope when defining a Java configuration class?s method as
package-private. And for the Mockito framework, such access allows for the
creation of package-private mocks what avoids that users have to extend the
scope of such classes only for a unit test.

For (B), a Java agent is able to access internal APIs by opening packages.
Providing a method handle lookup for the target class would however offer a
cleaner, more standardized approach. It is however unclear what lookupClass
the method handle lookup would be assigned to as the instrumented class is
not necessarily loaded when the class file transformer is applied.

Additionally, some proxying tools such as Mockito require an API to
instantiate a class without invoking a constructor. This way, a mock can be
created without triggering any user code which might have unwanted
side-effects or throw an exception for invalid inputs that are unknown to
the mocking framework. I understand that such instantiations are frowned
upon as they break the object model. But again, this possibility has proven
to be very useful in the past and it would be too bad if such libraries
could no longer be maintained in the future.

To create instances without invoking a constructor, there are currently
several options:

7) Use sun.misc.Unsafe::allocateInstance or the also internal reflection
factory. Such use is often done via the Objenesis library. If such access
was encapsulated, a Java agent could still open these APIs.
8) Using JNI to avoid encapsulation or allocating an instance without a
constructor call from JNI.

Again, (8) is a rarely chosen approach but (7) via the use of Objenesis is
still common.

At a result, even with Java 9 being supported by many popular frameworks, a
migration away from internal APIs has not yet been achieved. I would
therefore like to suggest the following extensions:

C) When a module opens a package, other modules should gain package access
to this package when creating method handle lookups. This way, if a user
opens a package containing Spring beans to the Spring framework, it could
proxy all of these beans as it does today. Since opening a package also
permits reflection on package-private types and methods of this package,
this is not a security concern either.

D) A class file transformer should be provided with an instance of a method
handle lookup for the instrumented class as an argument. This way, Java
agents gain an easy and standardized way of defining auxiliary classes what
is currently rather cumbersome.

E) There should be a jdk.test module that is not resolved by default and
that is not part of a non-JDK distribution of the JVM that contains an API
that allows for the instantiation of classes without a constructor
invocation. By depending on this module, test libraries that offer such
insecure abilities can also make their intention clear that a library is
meant for test and not for production. With Mockito, we regularly get
inquiries about performance issues when the library is used in production
systems what it is not designed for. This module could also include an API
for getting hold of an Instrumentation instance for the current JVM
process. This would be useful for many testing libraries such as Mockito
and also for testing Java agents under development. Currently, it is
necessary to self-attach using the attachment API. Since Java 9, it is
additionally required to explicitly allow such self-attachment or to use an
intermediate Java process to avoid the constraint.

With these three extensions, I believe that the many users of code
generation tools could easily migrate away from the use of internal APIs in
a few months what would allow a full encapsulation of JVM-internal APIs
without any major disruptions.

Thank you for your time and feedback on my proposal!

Best regards, Rafael

From peter.levart at gmail.com  Sun Jan  7 16:40:40 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 7 Jan 2018 17:40:40 +0100
Subject: Runtime code generation and barriers in migrating away from
 JVM-interal APIs
In-Reply-To: <CA+3eh10E6ZBZMgZUHr-0Y0yKSELBGk003OOGpb7amDO+SdKpoA@mail.gmail.com>
References: <CA+DM0A=7Lpq=VsDf0x_LtHb_8DGY+g1x4a=Lb-aTgmupzf1eng@mail.gmail.com>
 <CA+3eh10E6ZBZMgZUHr-0Y0yKSELBGk003OOGpb7amDO+SdKpoA@mail.gmail.com>
Message-ID: <d8a21fa6-6d3c-2ef2-2dd5-02580a998789@gmail.com>

Hi Rafael,

On 01/07/18 13:10, Volker Simonis wrote:
> At a result, even with Java 9 being supported by many popular frameworks, a
> migration away from internal APIs has not yet been achieved. I would
> therefore like to suggest the following extensions:
>
> C) When a module opens a package, other modules should gain package access
> to this package when creating method handle lookups. This way, if a user
> opens a package containing Spring beans to the Spring framework, it could
> proxy all of these beans as it does today. Since opening a package also
> permits reflection on package-private types and methods of this package,
> this is not a security concern either.

Have you checked the new JDK 9 method: 
java.lang.invoke.MethodHandles#privateLookupIn ?

I believe it should do the trick.

Regards, Peter


From rafael.wth at gmail.com  Sun Jan  7 17:46:33 2018
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sun, 7 Jan 2018 18:46:33 +0100
Subject: Runtime code generation and barriers in migrating away from
 JVM-interal APIs
In-Reply-To: <d8a21fa6-6d3c-2ef2-2dd5-02580a998789@gmail.com>
References: <CA+DM0A=7Lpq=VsDf0x_LtHb_8DGY+g1x4a=Lb-aTgmupzf1eng@mail.gmail.com>
 <CA+3eh10E6ZBZMgZUHr-0Y0yKSELBGk003OOGpb7amDO+SdKpoA@mail.gmail.com>
 <d8a21fa6-6d3c-2ef2-2dd5-02580a998789@gmail.com>
Message-ID: <CA+DM0Anh8QM49mxqwwEVALTv2TJ+vSyjdFB5qaY=TEoVfFHC4g@mail.gmail.com>

You are right Peter, that does work. I assumed that the module to which a
package was opened automatically received the access rights for any lookup
object, thanks for pointing it out to me. This makes my proposal of C
obsolete.

I hope that D and E are considered nevertheless!

Also, thank you Volker for forwarding this to the correct mailinglists.

2018-01-07 17:40 GMT+01:00 Peter Levart <peter.levart at gmail.com>:

> Hi Rafael,
>
> On 01/07/18 13:10, Volker Simonis wrote:
>
> At a result, even with Java 9 being supported by many popular frameworks, a
> migration away from internal APIs has not yet been achieved. I would
> therefore like to suggest the following extensions:
>
> C) When a module opens a package, other modules should gain package access
> to this package when creating method handle lookups. This way, if a user
> opens a package containing Spring beans to the Spring framework, it could
> proxy all of these beans as it does today. Since opening a package also
> permits reflection on package-private types and methods of this package,
> this is not a security concern either.
>
>
> Have you checked the new JDK 9 method: java.lang.invoke.MethodHandles#privateLookupIn
> ?
>
> I believe it should do the trick.
>
> Regards, Peter
>
>

From devnexen at gmail.com  Mon Jan  8 14:12:21 2018
From: devnexen at gmail.com (David CARLIER)
Date: Mon, 8 Jan 2018 14:12:21 +0000
Subject: [PATCH] Crypto EC - avoids possible memset compiler optimisation
Message-ID: <CA+XhMqwfwoVRkBiyrT60rmjW-8iUej8mx0TvQXhmZAN0nNkv-w@mail.gmail.com>

Hi,

Here a little patch proposal which is usually relevant in cryptographics
matters. Usually memset/bzero/... is used to clear private structures but
the compiler can possibly optimize those calls but with this change we can
unsure sensitive data is properly zero'ed using if possible native calls or
memory fence.

Kind regards.

Note : Messages get rejected all the time on core-libs-dev mailing list.
-------------- next part --------------
diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c
--- a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c
+++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c
@@ -59,11 +59,7 @@
 #ifdef _KERNEL
 #define PORT_ZFree(p, l)                bzero((p), (l)); kmem_free((p), (l))
 #else
-#ifndef _WIN32
-#define PORT_ZFree(p, l)                bzero((p), (l)); free((p))
-#else
-#define PORT_ZFree(p, l)                memset((p), 0, (l)); free((p))
-#endif /* _WIN32 */
+#define PORT_ZFree(p, l)                mp_safe_memzero((p), (l)); free((p))
 #endif
 
 /*
@@ -323,7 +319,7 @@
     if (privKeyLen >= len) {
         memcpy(key->privateValue.data, privKeyBytes, len);
     } else {
-        memset(key->privateValue.data, 0, (len - privKeyLen));
+        mp_safe_memzero(key->privateValue.data, (len - privKeyLen));
         memcpy(key->privateValue.data + (len - privKeyLen), privKeyBytes, privKeyLen);
     }
 
@@ -415,7 +411,7 @@
     CHECK_MPI_OK( mp_mod(&privKeyVal, &order_1, &privKeyVal) );
     CHECK_MPI_OK( mp_add(&privKeyVal, &one, &privKeyVal) );
     CHECK_MPI_OK( mp_to_fixlen_octets(&privKeyVal, privKeyBytes, len) );
-    memset(privKeyBytes+len, 0, len);
+    mp_safe_memzero(privKeyBytes+len, len);
 cleanup:
     mp_clear(&privKeyVal);
     mp_clear(&order_1);
@@ -592,7 +588,7 @@
         return SECFailure;
     }
 
-    memset(derivedSecret, 0, sizeof *derivedSecret);
+    mp_safe_memzero(derivedSecret, sizeof *derivedSecret);
     len = (ecParams->fieldID.size + 7) >> 3;
     pointQ.len = 2*len + 1;
     if ((pointQ.data = PORT_Alloc(2*len + 1, kmflag)) == NULL) goto cleanup;
diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c b/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c
--- a/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c
+++ b/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c
@@ -2077,6 +2077,20 @@
   return n;
 }
 
+void mp_safe_memzero(void *a, mp_size len)
+{
+#if defined(_WIN32)
+  SecureZeroMemory(a, len);
+#elif defined(__FreeBSD__) || defined(__OpenBSD__)
+  explicit_bzero(a, len);
+#elif defined(__NetBSD__)
+  explicit_memset(a, 0, len);
+#else
+  memset(a, 0, len);
+  __asm__ volatile("" :: "r"(a) : "memory");
+#endif
+}
+
 /* Given a and prime p, computes c and k such that a*c == 2**k (mod p).
 ** Returns k (positive) or error (negative).
 ** This technique from the paper "Fast Modular Reciprocals" (unpublished)
diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.h b/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.h
--- a/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.h
+++ b/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.h
@@ -351,6 +351,7 @@
 
 /* Miscellaneous */
 mp_size mp_trailing_zeros(const mp_int *mp);
+void mp_safe_memzero(void *, mp_size);
 
 #define MP_CHECKOK(x)  if (MP_OKAY > (res = (x))) goto CLEANUP
 #define MP_CHECKERR(x) if (MP_OKAY > (res = (x))) goto CLEANUP

From christoph.langer at sap.com  Mon Jan  8 14:48:06 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 8 Jan 2018 14:48:06 +0000
Subject: [PATCH] Crypto EC - avoids possible memset compiler optimisation
In-Reply-To: <CA+XhMqwfwoVRkBiyrT60rmjW-8iUej8mx0TvQXhmZAN0nNkv-w@mail.gmail.com>
References: <CA+XhMqwfwoVRkBiyrT60rmjW-8iUej8mx0TvQXhmZAN0nNkv-w@mail.gmail.com>
Message-ID: <fd970e18c37e4dfd91d50b7e2681d84b@sap.com>

Hi David,

I think you should rather post this on the security-dev mailing list.

As for attachments, this is always critical. Don't know whether security-dev will accept it. You could paste the diff in textual form into your mail or create a webrev.

Best regards
Christoph

-----Original Message-----
From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of David CARLIER
Sent: Montag, 8. Januar 2018 15:12
To: jdk-dev at openjdk.java.net
Subject: [PATCH] Crypto EC - avoids possible memset compiler optimisation

Hi,

Here a little patch proposal which is usually relevant in cryptographics
matters. Usually memset/bzero/... is used to clear private structures but
the compiler can possibly optimize those calls but with this change we can
unsure sensitive data is properly zero'ed using if possible native calls or
memory fence.

Kind regards.

Note : Messages get rejected all the time on core-libs-dev mailing list.

From aoqi at loongson.cn  Tue Jan  9 10:16:24 2018
From: aoqi at loongson.cn (Ao Qi)
Date: Tue, 9 Jan 2018 18:16:24 +0800
Subject: [PATCH] Fail to build zero on x86
Message-ID: <CALjzQn5pOL2Skxjk=7mcF+8_m56fbiLBBU78=vSrc-+FJM8q3A@mail.gmail.com>

Hi,

I found it failed to build zero. The repository I used is
http://hg.openjdk.java.net/jdk/jdk
I get this error (on Ubuntu 16.04 x86):

$ sh configure  --with-boot-jdk=/my-path-to-jdk9 --with-jvm-variants=zero
$ make hotspot
Building target 'hotspot' in configuration
'linux-x86_64-normal-zero-release'
Compiling 2 files for BUILD_JVMTI_TOOLS
Creating support/modules_libs/java.base/libjsig.so from 1 file(s)
Creating support/modules_libs/java.base/server/libjvm.so from 578 file(s)
Creating hotspot/variant-zero/libjvm/gtest/libjvm.so from 76 file(s)
Creating hotspot/variant-zero/libjvm/gtest/gtestLauncher from 1 file(s)
/home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp: In
function 'static void
SafepointSynchronize::check_for_lazy_critical_native(JavaThread*,
JavaThreadState)':
/home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp:730:25:
error: '<anonymous>' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
     if (stub_cb != NULL &&
                         ^
/home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp: In
static member function 'static void
SafepointSynchronize::check_for_lazy_critical_native(JavaThread*,
JavaThreadState)':
/home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp:730:25:
error: '<anonymous>' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1plus: all warnings being treated as errors
lib/CompileJvm.gmk:212: recipe for target
'/home/loongson/aoqi/jdk10/jdk/build/linux-x86_64-normal-zero-release/hotspot/variant-zero/libjvm/objs/safepoint.o'
failed
make[3]: ***
[/home/loongson/aoqi/jdk10/jdk/build/linux-x86_64-normal-zero-release/hotspot/variant-zero/libjvm/objs/safepoint.o]
Error 1
make[3]: *** Waiting for unfinished jobs....
make/Main.gmk:268: recipe for target 'hotspot-zero-libs' failed
make[2]: *** [hotspot-zero-libs] Error 1

ERROR: Build failed for target 'hotspot' in configuration
'linux-x86_64-normal-zero-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-zero_libjvm_objs_safepoint.o:
/home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp: In
function 'static void
SafepointSynchronize::check_for_lazy_critical_native(JavaThread*,
JavaThreadState)':
/home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp:730:25:
error: '<anonymous>' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
     if (stub_cb != NULL &&
                         ^
/home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp: In
static member function 'static void
SafepointSynchronize::check_for_lazy_critical_native(JavaThread*,
JavaThreadState)':
/home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp:730:25:
error: '<anonymous>' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1plus: all warnings being treated as errors

* All command lines available in
/home/loongson/aoqi/jdk10/jdk/build/linux-x86_64-normal-zero-release/make-support/failure-logs.
=== End of repeated output ===

=== Make failed targets repeated here ===
lib/CompileJvm.gmk:212: recipe for target
'/home/loongson/aoqi/jdk10/jdk/build/linux-x86_64-normal-zero-release/hotspot/variant-zero/libjvm/objs/safepoint.o'
failed
make/Main.gmk:268: recipe for target 'hotspot-zero-libs' failed
=== End of repeated output ===

Hint: Try searching the build log for the name of the first failed target.
Hint: See doc/building.html#troubleshooting for assistance.

/home/loongson/aoqi/jdk10/jdk/make/Init.gmk:291: recipe for target 'main'
failed
make[1]: *** [main] Error 1
/home/loongson/aoqi/jdk10/jdk/make/Init.gmk:186: recipe for target
'hotspot' failed
make: *** [hotspot] Error 2


I made a small patch to pass the build. Could someone help to review and
submit this patch? I had signed OCA.

patch:

diff -r 9a29aa153c20 src/hotspot/cpu/zero/frame_zero.inline.hpp
--- a/src/hotspot/cpu/zero/frame_zero.inline.hpp Mon Jan 08 07:13:27 2018
-0800
+++ b/src/hotspot/cpu/zero/frame_zero.inline.hpp Tue Jan 09 15:38:05 2018
+0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights
reserved.
  * Copyright 2007, 2008, 2009, 2010 Red Hat, Inc.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
@@ -43,23 +43,16 @@
 inline frame::frame(ZeroFrame* zf, intptr_t* sp) {
   _zeroframe = zf;
   _sp = sp;
+  _cb = NULL;
+  _deopt_state = not_deoptimized;
   switch (zeroframe()->type()) {
   case ZeroFrame::ENTRY_FRAME:
     _pc = StubRoutines::call_stub_return_pc();
-    _cb = NULL;
-    _deopt_state = not_deoptimized;
     break;

-  case ZeroFrame::INTERPRETER_FRAME:
-    _pc = NULL;
-    _cb = NULL;
-    _deopt_state = not_deoptimized;
-    break;
-
+  case ZeroFrame::INTERPRETER_FRAME: // fall through
   case ZeroFrame::FAKE_STUB_FRAME:
     _pc = NULL;
-    _cb = NULL;
-    _deopt_state = not_deoptimized;
     break;

   default:


Thanks,
Ao Qi

From li.jiang at oracle.com  Wed Jan 10 06:26:25 2018
From: li.jiang at oracle.com (Leo Jiang)
Date: Wed, 10 Jan 2018 14:26:25 +0800
Subject: RFR: 8194717 : JDK 10 L10n resource file update - msg drop 10
Message-ID: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>

Hi all,

Please help to review the changes for L10n resource file update message drop 10. This is the first message drop for JDK 
10 L10n resource file update, we will run next drops in forthcoming weeks.

Some localized resource files are updated as English resource changed, some just because of bug fix, e.g. in 
awt_de.properties revert text to Entf for shortcut.

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

Webrev:
http://cr.openjdk.java.net/~ljiang/MsgDrop-8194717/webrev.00/

Have got build and passed the tier1/2/3 test on all platforms on Mach 5.

Thanks,
Leo

From huizhe.wang at oracle.com  Wed Jan 10 22:45:16 2018
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 10 Jan 2018 14:45:16 -0800
Subject: RFR: 8194717 : JDK 10 L10n resource file update - msg drop 10
In-Reply-To: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
References: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
Message-ID: <d9ab1d93-ad1f-c6d0-4d6a-7f158cd4ab77@oracle.com>

Hi Leo,

I looked through the java.xml portion.

The only changes were added space/whitespace in these files:
 ?src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources*.java except the _sv file.

I'm not qualified to review the lang changes (e.g. _ko, _sv), but they 
seemed to be minor wording changes.

I like the fix in CatalogMessages where the key word 'catalog' is 
untranslated.

Thanks,
Joe

On 1/9/2018 10:26 PM, Leo Jiang wrote:
> Hi all,
>
> Please help to review the changes for L10n resource file update 
> message drop 10. This is the first message drop for JDK 10 L10n 
> resource file update, we will run next drops in forthcoming weeks.
>
> Some localized resource files are updated as English resource changed, 
> some just because of bug fix, e.g. in awt_de.properties revert text to 
> Entf for shortcut.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8194717
>
> Webrev:
> http://cr.openjdk.java.net/~ljiang/MsgDrop-8194717/webrev.00/
>
> Have got build and passed the tier1/2/3 test on all platforms on Mach 5.
>
> Thanks,
> Leo


From li.jiang at oracle.com  Thu Jan 11 07:20:45 2018
From: li.jiang at oracle.com (Leo Jiang)
Date: Thu, 11 Jan 2018 15:20:45 +0800
Subject: RFR: 8194717 : JDK 10 L10n resource file update - msg drop 10
In-Reply-To: <d9ab1d93-ad1f-c6d0-4d6a-7f158cd4ab77@oracle.com>
References: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
 <d9ab1d93-ad1f-c6d0-4d6a-7f158cd4ab77@oracle.com>
Message-ID: <25c0c88f-4fb5-04e9-6c20-be33ac439d29@oracle.com>

Hi Joe,

Thank you for reviewing.

You can find the space in webrev diff as these spaces are introduced in English resource file first. The translation 
system just copy any changes into localized resource files.

For the term 'catalog' issue, I found there are inconsistent in localized versions. For some languages, e.g. zh_CN, they 
have corrected as I requested, but also we can found in some languages the term was translated again. I would ask the 
translation team to review and correct these messages, but for long term, to avoid this happens again, I suggest you add 
a comment above *each* message, like "# Not-translate term : catalog". We would kick off 2nd msg drop on 22nd January, 
if you can commit the comments into repo before this date, that would be great.

Thanks,
Leo

On 01/11/2018 06:45 AM, huizhe wang wrote:
> Hi Leo,
> 
> I looked through the java.xml portion.
> 
> The only changes were added space/whitespace in these files:
>  ?src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources*.java except the _sv file.
> 
> I'm not qualified to review the lang changes (e.g. _ko, _sv), but they seemed to be minor wording changes.
> 
> I like the fix in CatalogMessages where the key word 'catalog' is untranslated.
> 
> Thanks,
> Joe
> 
> On 1/9/2018 10:26 PM, Leo Jiang wrote:
>> Hi all,
>>
>> Please help to review the changes for L10n resource file update message drop 10. This is the first message drop for 
>> JDK 10 L10n resource file update, we will run next drops in forthcoming weeks.
>>
>> Some localized resource files are updated as English resource changed, some just because of bug fix, e.g. in 
>> awt_de.properties revert text to Entf for shortcut.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8194717
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8194717/webrev.00/
>>
>> Have got build and passed the tier1/2/3 test on all platforms on Mach 5.
>>
>> Thanks,
>> Leo
> 

From huizhe.wang at oracle.com  Thu Jan 11 21:17:10 2018
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 11 Jan 2018 13:17:10 -0800
Subject: RFR: 8194717 : JDK 10 L10n resource file update - msg drop 10
In-Reply-To: <25c0c88f-4fb5-04e9-6c20-be33ac439d29@oracle.com>
References: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
 <d9ab1d93-ad1f-c6d0-4d6a-7f158cd4ab77@oracle.com>
 <25c0c88f-4fb5-04e9-6c20-be33ac439d29@oracle.com>
Message-ID: <9fbb789d-71ba-39ef-bf6c-dffe88f1a82e@oracle.com>

Hi Leo,

That sounds fine. For 'catalog', I'll see if I can find a time to get 
that done before 1/22.

Thanks,
Joe

On 1/10/2018 11:20 PM, Leo Jiang wrote:
> Hi Joe,
>
> Thank you for reviewing.
>
> You can find the space in webrev diff as these spaces are introduced 
> in English resource file first. The translation system just copy any 
> changes into localized resource files.
>
> For the term 'catalog' issue, I found there are inconsistent in 
> localized versions. For some languages, e.g. zh_CN, they have 
> corrected as I requested, but also we can found in some languages the 
> term was translated again. I would ask the translation team to review 
> and correct these messages, but for long term, to avoid this happens 
> again, I suggest you add a comment above *each* message, like "# 
> Not-translate term : catalog". We would kick off 2nd msg drop on 22nd 
> January, if you can commit the comments into repo before this date, 
> that would be great.
>
> Thanks,
> Leo
>
> On 01/11/2018 06:45 AM, huizhe wang wrote:
>> Hi Leo,
>>
>> I looked through the java.xml portion.
>>
>> The only changes were added space/whitespace in these files:
>> ??src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources*.java 
>> except the _sv file.
>>
>> I'm not qualified to review the lang changes (e.g. _ko, _sv), but 
>> they seemed to be minor wording changes.
>>
>> I like the fix in CatalogMessages where the key word 'catalog' is 
>> untranslated.
>>
>> Thanks,
>> Joe
>>
>> On 1/9/2018 10:26 PM, Leo Jiang wrote:
>>> Hi all,
>>>
>>> Please help to review the changes for L10n resource file update 
>>> message drop 10. This is the first message drop for JDK 10 L10n 
>>> resource file update, we will run next drops in forthcoming weeks.
>>>
>>> Some localized resource files are updated as English resource 
>>> changed, some just because of bug fix, e.g. in awt_de.properties 
>>> revert text to Entf for shortcut.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8194717
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8194717/webrev.00/
>>>
>>> Have got build and passed the tier1/2/3 test on all platforms on 
>>> Mach 5.
>>>
>>> Thanks,
>>> Leo
>>


From mark.reinhold at oracle.com  Thu Jan 11 21:46:27 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 11 Jan 2018 13:46:27 -0800
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
Message-ID: <20180111134627.676325789@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 11:

  318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector
       http://openjdk.java.net/jeps/318

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Thursday,
18 January, or if they're raised and then satisfactorily answered, then
per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Thu Jan 11 22:47:43 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 11 Jan 2018 14:47:43 -0800 (PST)
Subject: JDK 10 Rampdown Phase Two: Process proposal
Message-ID: <20180111224743.8FE16146C3E@eggemoggin.niobe.net>

Per the JDK 10 schedule [1], we'll enter Rampdown Phase Two next week,
on Thursday, 18 January.

The goal of this phase is the same as it was for JDK 9: Ensure that we
fix the bugs that must be fixed in order to ensure a successful release,
and understand why we're not going to fix some bugs that perhaps ought to
be fixed.

I propose that we use the same process as for JDK 9.  I've drafted pages
for RDP 2 and the fix-request process and posted them here:

  http://openjdk.java.net/projects/jdk/10/rdp-2
  http://openjdk.java.net/projects/jdk/10/fix-request-process

This phase will run for three weeks, until 8 February, when we'll produce
an initial Release Candidate build and enter the Release Candidate phase.

JDK Committers are invited to comment on this process proposal.  If no
objections are raised in one week's time, by 23:00 UTC next Thursday,
18 January, then this is the process that we'll use.

- Mark


[1] http://openjdk.java.net/projects/jdk/10/#Schedule

From li.jiang at oracle.com  Fri Jan 12 07:08:06 2018
From: li.jiang at oracle.com (Leo Jiang)
Date: Fri, 12 Jan 2018 15:08:06 +0800
Subject: RFR: 8194717 : JDK 10 L10n resource file update - msg drop 10
In-Reply-To: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
References: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
Message-ID: <238b5140-200f-9a10-059e-73c6a86f64a4@oracle.com>

Any other feedback? Our goal for msg drop 10 is to integrate them before RDP2.

Thanks,
Leo

On 01/10/2018 02:26 PM, Leo Jiang wrote:
> Hi all,
> 
> Please help to review the changes for L10n resource file update message drop 10. This is the first message drop for JDK 
> 10 L10n resource file update, we will run next drops in forthcoming weeks.
> 
> Some localized resource files are updated as English resource changed, some just because of bug fix, e.g. in 
> awt_de.properties revert text to Entf for shortcut.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8194717
> 
> Webrev:
> http://cr.openjdk.java.net/~ljiang/MsgDrop-8194717/webrev.00/
> 
> Have got build and passed the tier1/2/3 test on all platforms on Mach 5.
> 
> Thanks,
> Leo

From li.jiang at oracle.com  Fri Jan 12 14:51:59 2018
From: li.jiang at oracle.com (Leo Jiang)
Date: Fri, 12 Jan 2018 22:51:59 +0800
Subject: [10] RFR: 8187946 : Support ISO 4217 Amendments 163 and 164
Message-ID: <8f841d1a-009a-dfec-eb12-fc2b93abfa62@oracle.com>

Hi,

Please review the currency data update to support ISO 4217 Amendments 163 and 164.

Please refer the pdf files in bug description for details of this update. In short, we need to update the STD to STN and 
its numeric name, as well as adding a cut-over time for them.

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

Webrev:
http://cr.openjdk.java.net/~ljiang/8187946/webrev.00/

Built and test passed on Mach5.

Thanks,
Leo

From naoto.sato at oracle.com  Fri Jan 12 20:13:25 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 12 Jan 2018 12:13:25 -0800
Subject: [10] RFR: 8187946 : Support ISO 4217 Amendments 163 and 164
In-Reply-To: <8f841d1a-009a-dfec-eb12-fc2b93abfa62@oracle.com>
References: <8f841d1a-009a-dfec-eb12-fc2b93abfa62@oracle.com>
Message-ID: <c3621505-fb49-23ae-4c63-2c6e0f2448ef@oracle.com>

Hi Leo,

Here are my comments:

(for amendments 163)

- Names not reflected correctly: "Azerbaijan Manat", "Lao Kip".

(for amendments 164)
- Since it's already passed the transition date for STN, you don't need 
to use the transition format (at line 473:CurrencyData.properties)

- Lacking the Philippines currency name change: "Amended currency name 
for PHILIPPINES (THE): Philippine Piso (instead of Peso)"

- Lacking historic currency changes, e.g., ALBANIA-Old_Lek-ALK-008.

Naoto

On 1/12/18 6:51 AM, Leo Jiang wrote:
> Hi,
> 
> Please review the currency data update to support ISO 4217 Amendments 
> 163 and 164.
> 
> Please refer the pdf files in bug description for details of this 
> update. In short, we need to update the STD to STN and its numeric name, 
> as well as adding a cut-over time for them.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8187946
> 
> Webrev:
> http://cr.openjdk.java.net/~ljiang/8187946/webrev.00/
> 
> Built and test passed on Mach5.
> 
> Thanks,
> Leo

From li.jiang at oracle.com  Sat Jan 13 02:22:57 2018
From: li.jiang at oracle.com (Leo Jiang)
Date: Sat, 13 Jan 2018 10:22:57 +0800
Subject: [10] RFR: 8187946 : Support ISO 4217 Amendments 163 and 164
In-Reply-To: <c3621505-fb49-23ae-4c63-2c6e0f2448ef@oracle.com>
References: <8f841d1a-009a-dfec-eb12-fc2b93abfa62@oracle.com>
 <c3621505-fb49-23ae-4c63-2c6e0f2448ef@oracle.com>
Message-ID: <53c151af-d34e-6991-cd6c-d42a65a1fbb1@oracle.com>

Hi Naoto,

Thank you for review.

- Added the updates for currency names, removed the cut-over time for STN.
- For compatibility reason, we don't update the historic currencies.

Test passed.

Please find the revised webrev:
http://cr.openjdk.java.net/~ljiang/8187946/webrev.01/

Thanks,
Leo


On 01/13/2018 04:13 AM, Naoto Sato wrote:
> Hi Leo,
> 
> Here are my comments:
> 
> (for amendments 163)
> 
> - Names not reflected correctly: "Azerbaijan Manat", "Lao Kip".
> 
> (for amendments 164)
> - Since it's already passed the transition date for STN, you don't need to use the transition format (at line 
> 473:CurrencyData.properties)
> 
> - Lacking the Philippines currency name change: "Amended currency name for PHILIPPINES (THE): Philippine Piso (instead 
> of Peso)"
> 
> - Lacking historic currency changes, e.g., ALBANIA-Old_Lek-ALK-008.
> 
> Naoto
> 
> On 1/12/18 6:51 AM, Leo Jiang wrote:
>> Hi,
>>
>> Please review the currency data update to support ISO 4217 Amendments 163 and 164.
>>
>> Please refer the pdf files in bug description for details of this update. In short, we need to update the STD to STN 
>> and its numeric name, as well as adding a cut-over time for them.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8187946
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ljiang/8187946/webrev.00/
>>
>> Built and test passed on Mach5.
>>
>> Thanks,
>> Leo

From lhochet at gmail.com  Sun Jan 14 23:11:13 2018
From: lhochet at gmail.com (Ludovic HOCHET)
Date: Mon, 15 Jan 2018 00:11:13 +0100
Subject: RFR: 8194717 : JDK 10 L10n resource file update - msg drop 10
In-Reply-To: <238b5140-200f-9a10-059e-73c6a86f64a4@oracle.com>
References: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
 <238b5140-200f-9a10-059e-73c6a86f64a4@oracle.com>
Message-ID: <CAF4R3a-K3LmZbi1RWU6Kf=c6hXNUW7o09hPF_98OBMePg6Sv+g@mail.gmail.com>

Hello Leo,
I've had a look at the _fr files.
Only one issue introduced in launcher_fr.properties:
37 : "-Xbootclasspath/a :<r?pertoires", there shouldn't be a space.

Other than that in that same file there are some parts that I would
write differently:
33: "chemin de recherche de classe de r?pertoires et de fichiers
ZIP/JAR", this looks odd to me, I'd say "chemin de recherche de
classes" leaving out the type of elements of the path to the text 2
lines after
    "Liste distincte {0} de r?pertoires", I'd say "Liste, avec
s?parateur {0}, de r?pertoires"
    "chemin de module", I'd use plural for module "chemin de modules",
likewise for "r?pertoire de module"
    "r?pertorier les modules observables et quitter", I'd use the
conjugated form "r?pertorie ... quitte" (and may be "liste" instead of
"r?pertorie"), likewise for the other commands actions verbs as is
also done by the keytool tool
    "la configuration syst?me de module", I'd say "la configuration du
syst?me de modules"
38: "dans des fichiers ou r?pertoires JAR", should be "dans des
fichiers JAR ou des r?pertoires "

And in keytool/Resources_fr.java:
138: "ne pas inviter", I'd use "ne pas demander"

Ludovic

On 12 January 2018 at 08:08, Leo Jiang <li.jiang at oracle.com> wrote:
> Any other feedback? Our goal for msg drop 10 is to integrate them before
> RDP2.
>
> Thanks,
> Leo
>
>
> On 01/10/2018 02:26 PM, Leo Jiang wrote:
>>
>> Hi all,
>>
>> Please help to review the changes for L10n resource file update message
>> drop 10. This is the first message drop for JDK 10 L10n resource file
>> update, we will run next drops in forthcoming weeks.
>>
>> Some localized resource files are updated as English resource changed,
>> some just because of bug fix, e.g. in awt_de.properties revert text to Entf
>> for shortcut.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8194717
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8194717/webrev.00/
>>
>> Have got build and passed the tier1/2/3 test on all platforms on Mach 5.
>>
>> Thanks,
>> Leo



-- 
Ludovic
-----------------------------------------

"Les formes qui differencient les etres importent peu
 si leur pensees s'unissent pour batir un univers..."
 Yoko Tsuno (in 'Les titans' by Roger Leloup)
 [The shapes that differenciate beings are not important
 if their thoughts unite to build a universe]

From lhochet at gmail.com  Sun Jan 14 23:35:13 2018
From: lhochet at gmail.com (Ludovic HOCHET)
Date: Mon, 15 Jan 2018 00:35:13 +0100
Subject: RFR: 8194717 : JDK 10 L10n resource file update - msg drop 10
In-Reply-To: <CAF4R3a-K3LmZbi1RWU6Kf=c6hXNUW7o09hPF_98OBMePg6Sv+g@mail.gmail.com>
References: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
 <238b5140-200f-9a10-059e-73c6a86f64a4@oracle.com>
 <CAF4R3a-K3LmZbi1RWU6Kf=c6hXNUW7o09hPF_98OBMePg6Sv+g@mail.gmail.com>
Message-ID: <CAF4R3a8N+KBDWXOEM6MneKzYmiGs4myaKhp_RzxPJXhyTcgD_Q@mail.gmail.com>

Leo,
I found an additional issue in launcher_fr.properties, some ' (single
quotes) are not doubled and thus don't show when the command is run.

By the way, when the command is ran the {0} for are not replaced for
--module-path and --upgrade-module-path.

Ludovic

On 15 January 2018 at 00:11, Ludovic HOCHET <lhochet at gmail.com> wrote:
> Hello Leo,
> I've had a look at the _fr files.
> Only one issue introduced in launcher_fr.properties:
> 37 : "-Xbootclasspath/a :<r?pertoires", there shouldn't be a space.
>
> Other than that in that same file there are some parts that I would
> write differently:
> 33: "chemin de recherche de classe de r?pertoires et de fichiers
> ZIP/JAR", this looks odd to me, I'd say "chemin de recherche de
> classes" leaving out the type of elements of the path to the text 2
> lines after
>     "Liste distincte {0} de r?pertoires", I'd say "Liste, avec
> s?parateur {0}, de r?pertoires"
>     "chemin de module", I'd use plural for module "chemin de modules",
> likewise for "r?pertoire de module"
>     "r?pertorier les modules observables et quitter", I'd use the
> conjugated form "r?pertorie ... quitte" (and may be "liste" instead of
> "r?pertorie"), likewise for the other commands actions verbs as is
> also done by the keytool tool
>     "la configuration syst?me de module", I'd say "la configuration du
> syst?me de modules"
> 38: "dans des fichiers ou r?pertoires JAR", should be "dans des
> fichiers JAR ou des r?pertoires "
>
> And in keytool/Resources_fr.java:
> 138: "ne pas inviter", I'd use "ne pas demander"
>
> Ludovic
>
> On 12 January 2018 at 08:08, Leo Jiang <li.jiang at oracle.com> wrote:
>> Any other feedback? Our goal for msg drop 10 is to integrate them before
>> RDP2.
>>
>> Thanks,
>> Leo
>>
>>
>> On 01/10/2018 02:26 PM, Leo Jiang wrote:
>>>
>>> Hi all,
>>>
>>> Please help to review the changes for L10n resource file update message
>>> drop 10. This is the first message drop for JDK 10 L10n resource file
>>> update, we will run next drops in forthcoming weeks.
>>>
>>> Some localized resource files are updated as English resource changed,
>>> some just because of bug fix, e.g. in awt_de.properties revert text to Entf
>>> for shortcut.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8194717
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8194717/webrev.00/
>>>
>>> Have got build and passed the tier1/2/3 test on all platforms on Mach 5.
>>>
>>> Thanks,
>>> Leo
>
>
>
> --
> Ludovic
> -----------------------------------------
>
> "Les formes qui differencient les etres importent peu
>  si leur pensees s'unissent pour batir un univers..."
>  Yoko Tsuno (in 'Les titans' by Roger Leloup)
>  [The shapes that differenciate beings are not important
>  if their thoughts unite to build a universe]



-- 
Ludovic
-----------------------------------------

"Les formes qui differencient les etres importent peu
 si leur pensees s'unissent pour batir un univers..."
 Yoko Tsuno (in 'Les titans' by Roger Leloup)
 [The shapes that differenciate beings are not important
 if their thoughts unite to build a universe]

From li.jiang at oracle.com  Mon Jan 15 03:28:38 2018
From: li.jiang at oracle.com (Leo Jiang)
Date: Mon, 15 Jan 2018 11:28:38 +0800
Subject: RFR: 8194717 : JDK 10 L10n resource file update - msg drop 10
In-Reply-To: <CAF4R3a8N+KBDWXOEM6MneKzYmiGs4myaKhp_RzxPJXhyTcgD_Q@mail.gmail.com>
References: <7b9a0c2b-a8f6-6e26-663d-f3cac01ac161@oracle.com>
 <238b5140-200f-9a10-059e-73c6a86f64a4@oracle.com>
 <CAF4R3a-K3LmZbi1RWU6Kf=c6hXNUW7o09hPF_98OBMePg6Sv+g@mail.gmail.com>
 <CAF4R3a8N+KBDWXOEM6MneKzYmiGs4myaKhp_RzxPJXhyTcgD_Q@mail.gmail.com>
Message-ID: <40feb733-3664-a3bf-4797-f1d2aaf2f553@oracle.com>

Hi Ludovic,

Thank you for review, very appreciated!

I will file bug and forward your opinion to translation team. We might fix them in msg drop 20.

Thanks,
Leo

On 01/15/2018 07:35 AM, Ludovic HOCHET wrote:
> Leo,
> I found an additional issue in launcher_fr.properties, some ' (single
> quotes) are not doubled and thus don't show when the command is run.
> 
> By the way, when the command is ran the {0} for are not replaced for
> --module-path and --upgrade-module-path.
> 
> Ludovic
> 
> On 15 January 2018 at 00:11, Ludovic HOCHET <lhochet at gmail.com> wrote:
>> Hello Leo,
>> I've had a look at the _fr files.
>> Only one issue introduced in launcher_fr.properties:
>> 37 : "-Xbootclasspath/a :<r?pertoires", there shouldn't be a space.
>>
>> Other than that in that same file there are some parts that I would
>> write differently:
>> 33: "chemin de recherche de classe de r?pertoires et de fichiers
>> ZIP/JAR", this looks odd to me, I'd say "chemin de recherche de
>> classes" leaving out the type of elements of the path to the text 2
>> lines after
>>      "Liste distincte {0} de r?pertoires", I'd say "Liste, avec
>> s?parateur {0}, de r?pertoires"
>>      "chemin de module", I'd use plural for module "chemin de modules",
>> likewise for "r?pertoire de module"
>>      "r?pertorier les modules observables et quitter", I'd use the
>> conjugated form "r?pertorie ... quitte" (and may be "liste" instead of
>> "r?pertorie"), likewise for the other commands actions verbs as is
>> also done by the keytool tool
>>      "la configuration syst?me de module", I'd say "la configuration du
>> syst?me de modules"
>> 38: "dans des fichiers ou r?pertoires JAR", should be "dans des
>> fichiers JAR ou des r?pertoires "
>>
>> And in keytool/Resources_fr.java:
>> 138: "ne pas inviter", I'd use "ne pas demander"
>>
>> Ludovic
>>
>> On 12 January 2018 at 08:08, Leo Jiang <li.jiang at oracle.com> wrote:
>>> Any other feedback? Our goal for msg drop 10 is to integrate them before
>>> RDP2.
>>>
>>> Thanks,
>>> Leo
>>>
>>>
>>> On 01/10/2018 02:26 PM, Leo Jiang wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Please help to review the changes for L10n resource file update message
>>>> drop 10. This is the first message drop for JDK 10 L10n resource file
>>>> update, we will run next drops in forthcoming weeks.
>>>>
>>>> Some localized resource files are updated as English resource changed,
>>>> some just because of bug fix, e.g. in awt_de.properties revert text to Entf
>>>> for shortcut.
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8194717
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8194717/webrev.00/
>>>>
>>>> Have got build and passed the tier1/2/3 test on all platforms on Mach 5.
>>>>
>>>> Thanks,
>>>> Leo
>>
>>
>>
>> --
>> Ludovic
>> -----------------------------------------
>>
>> "Les formes qui differencient les etres importent peu
>>   si leur pensees s'unissent pour batir un univers..."
>>   Yoko Tsuno (in 'Les titans' by Roger Leloup)
>>   [The shapes that differenciate beings are not important
>>   if their thoughts unite to build a universe]
> 
> 
> 

From mandy.chung at oracle.com  Tue Jan 16 18:54:23 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 16 Jan 2018 10:54:23 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
Message-ID: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>

|I hereby nominate Brent Christian (bchristi) to JDK Reviewer.

Brent has worked in the core libraries team for several years and
has contributed to various areas including StackWalker, ||||||Compact 
String||,
MacOS X code, class loading||||, and collections.? Prior to joining|||
the core libraries |team, he worked on the client area of the JDK for
|||many |years and focused on performance improvements to AWT, Swing,
and JavaFX.

Brent is currently a JDK committer [1] and has contributed over
60 changesets in JDK project [2].

Votes are due by January 30, 2018, 11:00 PST

Only current JDK Reviewers [3] are eligible to vote on this
nomination.? Votes must be cast in the open by replying
to this mailing list.

For Three-Vote Consensus voting instructions, see [4].

Mandy
[1] http://openjdk.java.net/census#bchristi
[2] 
http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
[3] http://openjdk.java.net/census
[4] http://openjdk.java.net/projects/#reviewer-vote

|

From james.laskey at oracle.com  Tue Jan 16 18:56:35 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 16 Jan 2018 14:56:35 -0400
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <3A24AE9B-5C67-4E1D-9AE1-19D68FB28481@oracle.com>

Vote : yes

> On Jan 16, 2018, at 2:54 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact String||,
> MacOS X code, class loading||||, and collections.  Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |


From mandy.chung at oracle.com  Tue Jan 16 18:58:01 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 16 Jan 2018 10:58:01 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <0abc8347-2064-47c2-ee00-b6ffad5c3758@oracle.com>

Vote: yes

Mandy

On 1/16/18 10:54 AM, mandy chung wrote:
> I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
>
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, Compact String,
> MacOS X code, class loading||||, and collections.? Prior to joining
> the core libraries team, he worked on the client area of the JDK for
> many years and focused on performance improvements to AWT, Swing,
> and JavaFX.
>
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
>
> Votes are due by January 30, 2018, 11:00 PST
>
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>


From naoto.sato at oracle.com  Tue Jan 16 18:56:01 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 16 Jan 2018 10:56:01 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <4fa0dff0-f346-be3c-dd0e-6dab230f2734@oracle.com>

Vote: yes

Naoto

On 1/16/18 10:54 AM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact 
> String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge() 
> 
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |

From volker.simonis at gmail.com  Tue Jan 16 18:58:25 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 16 Jan 2018 19:58:25 +0100
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <CA+3eh12FuDgobm2mDb06SG8Ks+jC+C9hv6HnjGexcM8gohmn-A@mail.gmail.com>

Vote: yes


On Tue, Jan 16, 2018 at 7:54 PM, mandy chung <mandy.chung at oracle.com> wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
>
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact
> String||,
> MacOS X code, class loading||||, and collections.  Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
>
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
>
> Votes are due by January 30, 2018, 11:00 PST
>
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>
> |

From Roger.Riggs at Oracle.com  Tue Jan 16 19:01:10 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 16 Jan 2018 14:01:10 -0500
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <cf0eb5d6-4f4e-e35d-068d-d27b6b054753@Oracle.com>

Vote: Yes

On 1/16/2018 1:54 PM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.


From sean.coffey at oracle.com  Tue Jan 16 19:02:41 2018
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 16 Jan 2018 19:02:41 +0000
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <1fa0b1ec-8206-7409-82e3-1361ce6c5977@oracle.com>

Vote: Yes

regards,
Sean.


On 16/01/2018 18:54, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
>
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact 
> String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
>
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
>
> Votes are due by January 30, 2018, 11:00 PST
>
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>
> |


From xueming.shen at oracle.com  Tue Jan 16 19:07:26 2018
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 16 Jan 2018 11:07:26 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <477A2915-6B2F-4254-A9A6-C1D06BA45F84@oracle.com>

Vote: yes

On Jan 16, 2018, at 10:54 AM, mandy chung <mandy.chung at oracle.com> wrote:

|I hereby nominate Brent Christian (bchristi) to JDK Reviewer.

Brent has worked in the core libraries team for several years and
has contributed to various areas including StackWalker, ||||||Compact String||,
MacOS X code, class loading||||, and collections.  Prior to joining|||
the core libraries |team, he worked on the client area of the JDK for
|||many |years and focused on performance improvements to AWT, Swing,
and JavaFX.

Brent is currently a JDK committer [1] and has contributed over
60 changesets in JDK project [2].

Votes are due by January 30, 2018, 11:00 PST

Only current JDK Reviewers [3] are eligible to vote on this
nomination.  Votes must be cast in the open by replying
to this mailing list.

For Three-Vote Consensus voting instructions, see [4].

Mandy
[1] http://openjdk.java.net/census#bchristi
[2] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
[3] http://openjdk.java.net/census
[4] http://openjdk.java.net/projects/#reviewer-vote

|


From brian.burkhalter at oracle.com  Tue Jan 16 19:10:46 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 16 Jan 2018 11:10:46 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <5A404A34-0CC9-48C4-922D-D9FAFF511B9F@oracle.com>

Vote: Yes

On Jan 16, 2018, at 10:54 AM, mandy chung <mandy.chung at oracle.com> wrote:

> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.


From chris.hegarty at oracle.com  Tue Jan 16 19:13:08 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 16 Jan 2018 19:13:08 +0000
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <1CE48543-04DB-49FB-A918-5381F9758FB0@oracle.com>

Vote: YES.

-Chris.

> On 16 Jan 2018, at 18:54, mandy chung <mandy.chung at oracle.com> wrote:
> 
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.


From lance.andersen at oracle.com  Tue Jan 16 19:20:24 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 16 Jan 2018 14:20:24 -0500
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <E49BE8C9-5B2C-49E1-94AB-4B7E36B33286@oracle.com>

vote: yes
> On Jan 16, 2018, at 1:54 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact String||,
> MacOS X code, class loading||||, and collections.  Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From iris.clark at oracle.com  Tue Jan 16 19:37:13 2018
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 16 Jan 2018 11:37:13 -0800 (PST)
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <b6a0cefb-cb84-4d95-9455-c3adc33c596c@default>

Vote: yes

iris

From artem.ananiev at oracle.com  Tue Jan 16 19:47:15 2018
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Tue, 16 Jan 2018 11:47:15 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <5A5E56C3.6060006@oracle.com>


Vote: yes

Artem

On 1/16/18, 10:54, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
>
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact
> String||,
> MacOS X code, class loading||||, and collections.  Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
>
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
>
> Votes are due by January 30, 2018, 11:00 PST
>
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
>
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>
> |

From huizhe.wang at oracle.com  Tue Jan 16 20:12:57 2018
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 16 Jan 2018 12:12:57 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <c86cdccf-2877-5ba7-6cd5-70fd5ce0bc9b@oracle.com>

Vote: Yes

-Joe (openjdk id: joehw)

On 1/16/2018 10:54 AM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
>
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact 
> String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
>
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
>
> Votes are due by January 30, 2018, 11:00 PST
>
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>
> |


From Alan.Bateman at oracle.com  Tue Jan 16 20:17:09 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Jan 2018 20:17:09 +0000
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <37ba6680-6e8b-4246-65e4-6ea000d65472@oracle.com>

Vote: yes

From paul.sandoz at oracle.com  Tue Jan 16 20:23:05 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 16 Jan 2018 12:23:05 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <ED00C83A-73F2-49C4-8AF8-4960927C4ECE@oracle.com>

Vote: yes

Paul.


From alexander.zuev at oracle.com  Tue Jan 16 20:36:43 2018
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Tue, 16 Jan 2018 23:36:43 +0300
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <b901f501-3e65-915c-2aaa-278f5d7a530e@oracle.com>

Vote: yes

From jesper.wilhelmsson at oracle.com  Tue Jan 16 20:45:35 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 16 Jan 2018 21:45:35 +0100
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <00E3E01A-8E0F-4CB2-827D-5311CFBC3FA1@oracle.com>

Vote: Yes
/Jesper

> On 16 Jan 2018, at 19:54, mandy chung <mandy.chung at oracle.com> wrote:
> 
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact String||,
> MacOS X code, class loading||||, and collections.  Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |


From kumar.x.srinivasan at oracle.com  Tue Jan 16 21:03:41 2018
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 16 Jan 2018 13:03:41 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <5A5E68AD.8070406@oracle.com>

Vote: yes

On 1/16/2018 10:54 AM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
>
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact 
> String||,
> MacOS X code, class loading||||, and collections.  Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
>
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
>
> Votes are due by January 30, 2018, 11:00 PST
>
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>
> |


From shade at redhat.com  Tue Jan 16 21:23:06 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jan 2018 22:23:06 +0100
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <5d7bcfe6-737e-1ae1-bf88-c8218931a604@redhat.com>

Vote: yes

On 01/16/2018 07:54 PM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> 
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |



From charlie.hunt at oracle.com  Tue Jan 16 23:50:19 2018
From: charlie.hunt at oracle.com (charlie hunt)
Date: Tue, 16 Jan 2018 17:50:19 -0600
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <20180111134627.676325789@eggemoggin.niobe.net>
References: <20180111134627.676325789@eggemoggin.niobe.net>
Message-ID: <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>

Seems with what is being proposed is essentially a ?no GC? type of ability ? a command line option of -XX:+NoGC or -XX:+UseNoGC would probably be better understood as to what it generally does, and the consequence of exhausting Java heap space since there is ?no GC?.

thanks,

charlie hunt

> On Jan 11, 2018, at 3:46 PM, mark.reinhold at oracle.com wrote:
> 
> The following JEP is proposed to target JDK 11:
> 
>  318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector
>       http://openjdk.java.net/jeps/318
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 18 January, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
> 
> - Mark
> 
> 
> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html


From vladimir.kozlov at oracle.com  Wed Jan 17 00:36:10 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Jan 2018 16:36:10 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <0cbce29a-022b-041c-452a-702e388b9368@oracle.com>

Vote: yes

On 1/16/18 10:54 AM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact 
> String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge() 
> 
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |

From philip.race at oracle.com  Wed Jan 17 00:37:43 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 16 Jan 2018 16:37:43 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <5A5E9AD7.6040603@oracle.com>

Vote: yes

-phil.

From weijun.wang at oracle.com  Wed Jan 17 00:45:20 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 17 Jan 2018 08:45:20 +0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <B0414BD1-E10B-497F-B629-F8A43CC02F4F@oracle.com>

Vote: Yes.

-Weijun

> On Jan 17, 2018, at 2:54 AM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact String||,
> MacOS X code, class loading||||, and collections.  Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |


From joe.darcy at oracle.com  Wed Jan 17 00:43:01 2018
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 16 Jan 2018 16:43:01 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <5A5E9AD7.6040603@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
 <5A5E9AD7.6040603@oracle.com>
Message-ID: <5A5E9C15.3070009@oracle.com>

Vote: yes

-Joe



From stuart.marks at oracle.com  Wed Jan 17 01:51:14 2018
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 16 Jan 2018 17:51:14 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <af21f4de-483d-8e61-50f1-665d33035f06@oracle.com>

Vote: yes

On 1/16/18 10:54 AM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge() 
> 
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |

From huaming.li at oracle.com  Wed Jan 17 08:07:57 2018
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 17 Jan 2018 16:07:57 +0800
Subject: [10] RFR: 8195478: sun/text/resources/LocaleDataTest.java fails with
 java.lang.Exception
Message-ID: <c95b2e38-e1f0-aca2-e998-348ea442f1ec@oracle.com>

Would you please review the following patch?

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

webrev as below

I have tested it locally.


Thank you

-Hamlin
------------------------------------------------------------------------

diff -r 19effb7970bc test/jdk/sun/text/resources/LocaleData
--- a/test/jdk/sun/text/resources/LocaleData??? Thu Jan 11 20:19:50 2018 
-0800
+++ b/test/jdk/sun/text/resources/LocaleData??? Wed Jan 17 16:02:25 2018 
+0800
@@ -6396,7 +6396,6 @@
 ?CurrencyNames//ang=Netherlands Antillean Guilder
 ?CurrencyNames//awg=Aruban Florin
 ?CurrencyNames//azm=Azerbaijani Manat (1993-2006)
-CurrencyNames//azn=Azerbaijani Manat
 ?CurrencyNames//bbd=Barbadian Dollar
 ?CurrencyNames//bdt=Bangladeshi Taka
 ?CurrencyNames//bgn=Bulgarian Lev

From rachna.goel at oracle.com  Wed Jan 17 08:45:11 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Wed, 17 Jan 2018 14:15:11 +0530
Subject: [10] RFR: 8195478: sun/text/resources/LocaleDataTest.java fails
 with java.lang.Exception
In-Reply-To: <c95b2e38-e1f0-aca2-e998-348ea442f1ec@oracle.com>
References: <c95b2e38-e1f0-aca2-e998-348ea442f1ec@oracle.com>
Message-ID: <9e9e8ab0-d85c-b1ba-0a9d-610cf0dfcd6f@oracle.com>

Hi Hamlin,

Just one nit, Please add bug id 8195478 to 
sun/text/resources/LocaleDataTest.java.

Thanks,

Rachna


On 1/17/2018 1:37 PM, Hamlin Li wrote:
> Would you please review the following patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8195478
>
> webrev as below
>
> I have tested it locally.
>
>
> Thank you
>
> -Hamlin
> ------------------------------------------------------------------------
>
> diff -r 19effb7970bc test/jdk/sun/text/resources/LocaleData
> --- a/test/jdk/sun/text/resources/LocaleData??? Thu Jan 11 20:19:50 
> 2018 -0800
> +++ b/test/jdk/sun/text/resources/LocaleData??? Wed Jan 17 16:02:25 
> 2018 +0800
> @@ -6396,7 +6396,6 @@
> ?CurrencyNames//ang=Netherlands Antillean Guilder
> ?CurrencyNames//awg=Aruban Florin
> ?CurrencyNames//azm=Azerbaijani Manat (1993-2006)
> -CurrencyNames//azn=Azerbaijani Manat
> ?CurrencyNames//bbd=Barbadian Dollar
> ?CurrencyNames//bdt=Bangladeshi Taka
> ?CurrencyNames//bgn=Bulgarian Lev


From huaming.li at oracle.com  Wed Jan 17 08:50:57 2018
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 17 Jan 2018 16:50:57 +0800
Subject: [10] RFR: 8195478: sun/text/resources/LocaleDataTest.java fails
 with java.lang.Exception
In-Reply-To: <9e9e8ab0-d85c-b1ba-0a9d-610cf0dfcd6f@oracle.com>
References: <c95b2e38-e1f0-aca2-e998-348ea442f1ec@oracle.com>
 <9e9e8ab0-d85c-b1ba-0a9d-610cf0dfcd6f@oracle.com>
Message-ID: <12bf2f0d-c1cb-5cf0-a559-5e59311d9e98@oracle.com>

Hi Rachna,

I'm not sure, but I think in this case (it's a test bug) @bug 8195478 
should not be added.

Thank you

-Hamlin


On 17/01/2018 4:45 PM, Rachna Goel wrote:
>
> Hi Hamlin,
>
> Just one nit, Please add bug id 8195478 to 
> sun/text/resources/LocaleDataTest.java.
>
> Thanks,
>
> Rachna
>
>
> On 1/17/2018 1:37 PM, Hamlin Li wrote:
>> Would you please review the following patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8195478
>>
>> webrev as below
>>
>> I have tested it locally.
>>
>>
>> Thank you
>>
>> -Hamlin
>> ------------------------------------------------------------------------
>>
>> diff -r 19effb7970bc test/jdk/sun/text/resources/LocaleData
>> --- a/test/jdk/sun/text/resources/LocaleData??? Thu Jan 11 20:19:50 
>> 2018 -0800
>> +++ b/test/jdk/sun/text/resources/LocaleData??? Wed Jan 17 16:02:25 
>> 2018 +0800
>> @@ -6396,7 +6396,6 @@
>> ?CurrencyNames//ang=Netherlands Antillean Guilder
>> ?CurrencyNames//awg=Aruban Florin
>> ?CurrencyNames//azm=Azerbaijani Manat (1993-2006)
>> -CurrencyNames//azn=Azerbaijani Manat
>> ?CurrencyNames//bbd=Barbadian Dollar
>> ?CurrencyNames//bdt=Bangladeshi Taka
>> ?CurrencyNames//bgn=Bulgarian Lev
>


From tobias.hartmann at oracle.com  Wed Jan 17 09:21:44 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 17 Jan 2018 10:21:44 +0100
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <fbc33913-02fd-757f-4ff7-a1360b29cf3f@oracle.com>

Vote: yes

Tobias

On 16.01.2018 19:54, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> 
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |

From shade at redhat.com  Wed Jan 17 09:43:07 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Jan 2018 10:43:07 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
Message-ID: <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>

On 01/17/2018 12:50 AM, charlie hunt wrote:
> Seems with what is being proposed is essentially a ?no GC? type of ability ? a command line
> option of -XX:+NoGC or -XX:+UseNoGC would probably be better understood as to what it generally
> does, and the consequence of exhausting Java heap space since there is ?no GC?.

How very unpoetical :) Epsilon has the origin story for its name, see the JEP. Most people,
including prospective users, know this feature under "Epsilon" and some expressed the love for the
name. So, as long as there is no overwhelming amount of strong opinions against it, I'd keep the
name as is.

-Aleksey


From adinn at redhat.com  Wed Jan 17 10:03:41 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 17 Jan 2018 10:03:41 +0000
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
Message-ID: <51145eb0-89ab-ec05-9298-819a3fd69755@redhat.com>

On 17/01/18 09:43, Aleksey Shipilev wrote:
> How very unpoetical :) Epsilon has the origin story for its name, see the JEP. Most people,
> including prospective users, know this feature under "Epsilon" and some expressed the love for the
> name. So, as long as there is no overwhelming amount of strong opinions against it, I'd keep the
> name as is.
"With arbitrarily large TLABs and arbitrarily large heap, the latency
overhead can be described by an arbitrarily low positive value, hence
the name."

Much as I relish poetry in engineered artefacts I am willing to accept
it as optional (now, as to elegance, that's another matter). However, I
agree with Aleksey that this case is more than just poetry trumping the
prosaic. The name declares a significant property of epsilon, affirming
that GC overheads can be removed for specific uses by suitable (hw and
sw) configuration but, unlike NoGC, making no claim that they can be
simply ignored. Oh, also ... poetry!

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From roman at kennke.org  Wed Jan 17 10:12:45 2018
From: roman at kennke.org (Roman Kennke)
Date: Wed, 17 Jan 2018 11:12:45 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <51145eb0-89ab-ec05-9298-819a3fd69755@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <51145eb0-89ab-ec05-9298-819a3fd69755@redhat.com>
Message-ID: <b83cd0f9-68c6-9810-090a-8c41381ae2d2@kennke.org>

Am 17.01.2018 um 11:03 schrieb Andrew Dinn:
> On 17/01/18 09:43, Aleksey Shipilev wrote:
>> How very unpoetical :) Epsilon has the origin story for its name, see the JEP. Most people,
>> including prospective users, know this feature under "Epsilon" and some expressed the love for the
>> name. So, as long as there is no overwhelming amount of strong opinions against it, I'd keep the
>> name as is.
> "With arbitrarily large TLABs and arbitrarily large heap, the latency
> overhead can be described by an arbitrarily low positive value, hence
> the name."
>
> Much as I relish poetry in engineered artefacts I am willing to accept
> it as optional (now, as to elegance, that's another matter). However, I
> agree with Aleksey that this case is more than just poetry trumping the
> prosaic. The name declares a significant property of epsilon, affirming
> that GC overheads can be removed for specific uses by suitable (hw and
> sw) configuration but, unlike NoGC, making no claim that they can be
> simply ignored. Oh, also ... poetry!
Why not also add -XX:+UseNoGC as alias for -XX:+UseEpsilonGC ? :-)

Roman

From shade at redhat.com  Wed Jan 17 10:15:42 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Jan 2018 11:15:42 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <b83cd0f9-68c6-9810-090a-8c41381ae2d2@kennke.org>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <51145eb0-89ab-ec05-9298-819a3fd69755@redhat.com>
 <b83cd0f9-68c6-9810-090a-8c41381ae2d2@kennke.org>
Message-ID: <94dd0499-aacd-362a-a5d4-d6164bedf437@redhat.com>

On 01/17/2018 11:12 AM, Roman Kennke wrote:
> Am 17.01.2018 um 11:03 schrieb Andrew Dinn:
>> On 17/01/18 09:43, Aleksey Shipilev wrote:
>>> How very unpoetical :) Epsilon has the origin story for its name, see the JEP. Most people,
>>> including prospective users, know this feature under "Epsilon" and some expressed the love for the
>>> name. So, as long as there is no overwhelming amount of strong opinions against it, I'd keep the
>>> name as is.
>> "With arbitrarily large TLABs and arbitrarily large heap, the latency
>> overhead can be described by an arbitrarily low positive value, hence
>> the name."
>>
>> Much as I relish poetry in engineered artefacts I am willing to accept
>> it as optional (now, as to elegance, that's another matter). However, I
>> agree with Aleksey that this case is more than just poetry trumping the
>> prosaic. The name declares a significant property of epsilon, affirming
>> that GC overheads can be removed for specific uses by suitable (hw and
>> sw) configuration but, unlike NoGC, making no claim that they can be
>> simply ignored. Oh, also ... poetry!
> Why not also add -XX:+UseNoGC as alias for -XX:+UseEpsilonGC ? :-)

I think it would unprecedented to have aliases for exactly the same GC implementation?

But tell you what, if we rename to -XX:+UseNoGC, this obviously tells the users what is the
consequence of using the collector. So, the part of JEP that has to "Expectations" that guard from
accidental enabling with experimental/diagnostic flag stops being that relevant. Therefore,
-XX:+UseNoGC can and should be available in product builds under product option! :)

-Aleksey


From daniel.fuchs at oracle.com  Wed Jan 17 10:26:40 2018
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 17 Jan 2018 10:26:40 +0000
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <4db7dea7-16c6-7acd-bdb9-c4c7e3e0bc00@oracle.com>

Vote: yes

best regards,

-- daniel

On 16/01/2018 18:54, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.



From vladimir.x.ivanov at oracle.com  Wed Jan 17 12:34:32 2018
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Jan 2018 15:34:32 +0300
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <b00d1fec-6d42-ae36-2990-35324e022a96@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 1/16/18 9:54 PM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact 
> String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge() 
> 
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |

From claes.redestad at oracle.com  Wed Jan 17 12:52:49 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 17 Jan 2018 13:52:49 +0100
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <bd60bb6f-4916-f537-bd85-2c8a24c92d10@oracle.com>

Vote: yes

On 2018-01-16 19:54, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.


From naoto.sato at oracle.com  Wed Jan 17 13:06:25 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 17 Jan 2018 05:06:25 -0800
Subject: [10] RFR: 8195478: sun/text/resources/LocaleDataTest.java fails
 with java.lang.Exception
In-Reply-To: <12bf2f0d-c1cb-5cf0-a559-5e59311d9e98@oracle.com>
References: <c95b2e38-e1f0-aca2-e998-348ea442f1ec@oracle.com>
 <9e9e8ab0-d85c-b1ba-0a9d-610cf0dfcd6f@oracle.com>
 <12bf2f0d-c1cb-5cf0-a559-5e59311d9e98@oracle.com>
Message-ID: <acb74257-ebf0-6913-d741-7d801447cc60@oracle.com>

Looks good to me. As Rachna mentioned, please add @bug to 
LocaleDataTest.java. No further review is needed.

Naoto

On 1/17/18 12:50 AM, Hamlin Li wrote:
> Hi Rachna,
> 
> I'm not sure, but I think in this case (it's a test bug) @bug 8195478 
> should not be added.
> 
> Thank you
> 
> -Hamlin
> 
> 
> On 17/01/2018 4:45 PM, Rachna Goel wrote:
>>
>> Hi Hamlin,
>>
>> Just one nit, Please add bug id 8195478 to 
>> sun/text/resources/LocaleDataTest.java.
>>
>> Thanks,
>>
>> Rachna
>>
>>
>> On 1/17/2018 1:37 PM, Hamlin Li wrote:
>>> Would you please review the following patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8195478
>>>
>>> webrev as below
>>>
>>> I have tested it locally.
>>>
>>>
>>> Thank you
>>>
>>> -Hamlin
>>> ------------------------------------------------------------------------
>>>
>>> diff -r 19effb7970bc test/jdk/sun/text/resources/LocaleData
>>> --- a/test/jdk/sun/text/resources/LocaleData??? Thu Jan 11 20:19:50 
>>> 2018 -0800
>>> +++ b/test/jdk/sun/text/resources/LocaleData??? Wed Jan 17 16:02:25 
>>> 2018 +0800
>>> @@ -6396,7 +6396,6 @@
>>> ?CurrencyNames//ang=Netherlands Antillean Guilder
>>> ?CurrencyNames//awg=Aruban Florin
>>> ?CurrencyNames//azm=Azerbaijani Manat (1993-2006)
>>> -CurrencyNames//azn=Azerbaijani Manat
>>> ?CurrencyNames//bbd=Barbadian Dollar
>>> ?CurrencyNames//bdt=Bangladeshi Taka
>>> ?CurrencyNames//bgn=Bulgarian Lev
>>
> 

From karen.kinnear at oracle.com  Wed Jan 17 13:41:29 2018
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 17 Jan 2018 08:41:29 -0500
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <CE79780C-F6C3-45F3-862D-E220711A27FE@oracle.com>

Vote: yes

Karen

> On Jan 16, 2018, at 1:54 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
> 
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact String||,
> MacOS X code, class loading||||, and collections.  Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
> 
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
> 
> Votes are due by January 30, 2018, 11:00 PST
> 
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [4].
> 
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
> 
> |


From charlie.hunt at oracle.com  Wed Jan 17 13:52:19 2018
From: charlie.hunt at oracle.com (charlie hunt)
Date: Wed, 17 Jan 2018 07:52:19 -0600
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
Message-ID: <D8F2D7C8-FCCA-40DF-8ACC-A410834FA83F@oracle.com>



> On Jan 17, 2018, at 3:43 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 01/17/2018 12:50 AM, charlie hunt wrote:
>> Seems with what is being proposed is essentially a ?no GC? type of ability ? a command line
>> option of -XX:+NoGC or -XX:+UseNoGC would probably be better understood as to what it generally
>> does, and the consequence of exhausting Java heap space since there is ?no GC?.
> 
> How very unpoetical :) Epsilon has the origin story for its name, see the JEP. Most people,
> including prospective users, know this feature under "Epsilon" and some expressed the love for the
> name. So, as long as there is no overwhelming amount of strong opinions against it, I'd keep the
> name as is.
> 
> -Aleksey
> 

How moronic of me to suggest something simple and so obvious. :-]

charlie



From aph at redhat.com  Wed Jan 17 16:15:08 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Jan 2018 16:15:08 +0000
Subject: Using Intellij IDEA with current JDK
Message-ID: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>

I now always get "The selected directory is not a valid home for JDK".
when selecting the JDK home directory.

Does anybody have any idea how to persuade IDEA that we need to work
on the current top-of-tree JDK?  Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From jonathan.gibbons at oracle.com  Wed Jan 17 16:56:10 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 17 Jan 2018 08:56:10 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <5375fcb9-c4c6-d92f-f694-cf4474a1a62f@oracle.com>

Vote: yes

-- Jon


On 1/16/18 10:54 AM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
>
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact 
> String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
>
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
>
> Votes are due by January 30, 2018, 11:00 PST
>
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>
> |


From david.lloyd at redhat.com  Wed Jan 17 17:47:37 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 17 Jan 2018 11:47:37 -0600
Subject: Using Intellij IDEA with current JDK
In-Reply-To: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>
References: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>
Message-ID: <CANghgrQ4meHSX6x3t5Md+Gir=Oq5v89rbmFAyb8kJ82swAmEFw@mail.gmail.com>

What I've done is to force no JDK at all.  It does present an ugly
banner[1] at the top but otherwise it seems to work fine - or did,
until the latest update[2].  If you've already set up a SDK, I think
there's no way to unset it, so you have to close IDEA, edit your
xxx.ipr or .idea/modules.xml (I think) and delete the line which
defines the SDK.

[1] See also: https://youtrack.jetbrains.com/issue/IDEA-142878
[2] The error I see at present is of the type "Package 'java.lang' is
in the unnamed module, but module 'jdk.compiler' does not read it".
Previously I had excluded module-info.java from all source roots, but
the latest update somehow determines that everything are Java 9
modules anyway.  I had done this for two reasons: firstly, there are
not module descriptors in every place where there are sources (for
example, having a separate "java.base:share" and "java.base:unix" IDEA
module causes problems because :share has a module-info.java but :unix
does not), and secondly, IDEA does not cope well with situations where
there is more than one module-info.java (for example if one is
generated from the other) or if it is simply generated to begin with.
Sigh.

On Wed, Jan 17, 2018 at 10:15 AM, Andrew Haley <aph at redhat.com> wrote:
> I now always get "The selected directory is not a valid home for JDK".
> when selecting the JDK home directory.
>
> Does anybody have any idea how to persuade IDEA that we need to work
> on the current top-of-tree JDK?  Thanks.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



-- 
- DML

From mark.reinhold at oracle.com  Wed Jan 17 19:52:44 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 17 Jan 2018 11:52:44 -0800
Subject: FYI: JDK 10 early-access builds under the GPL
Message-ID: <20180117115244.693941152@eggemoggin.niobe.net>

Early-access builds of the Oracle JDK, under the usual Oracle EA
license, have been available at http://jdk.java.net/10 for quite
a while now.  As of today that page also includes OpenJDK builds,
under the GPLv2 with the Classpath Exception.

- Mark

From coleen.phillimore at oracle.com  Wed Jan 17 20:35:36 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 17 Jan 2018 15:35:36 -0500
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <a7e3dbe1-a8ac-b0c6-5155-b9f76f34aff8@oracle.com>

Vote: yes

On 1/16/18 1:54 PM, mandy chung wrote:
> |I hereby nominate Brent Christian (bchristi) to JDK Reviewer.
>
> Brent has worked in the core libraries team for several years and
> has contributed to various areas including StackWalker, ||||||Compact 
> String||,
> MacOS X code, class loading||||, and collections.? Prior to joining|||
> the core libraries |team, he worked on the client area of the JDK for
> |||many |years and focused on performance improvements to AWT, Swing,
> and JavaFX.
>
> Brent is currently a JDK committer [1] and has contributed over
> 60 changesets in JDK project [2].
>
> Votes are due by January 30, 2018, 11:00 PST
>
> Only current JDK Reviewers [3] are eligible to vote on this
> nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [4].
>
> Mandy
> [1] http://openjdk.java.net/census#bchristi
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22bchristi%22)+or+desc(%22brent.christian%40oracle.com%22))+and+not+merge()
> [3] http://openjdk.java.net/census
> [4] http://openjdk.java.net/projects/#reviewer-vote
>
> |


From jesper.wilhelmsson at oracle.com  Wed Jan 17 21:03:36 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 17 Jan 2018 22:03:36 +0100
Subject: New JBS component for the serviceability agent
Message-ID: <90C83861-D6CF-4490-8EB4-2FC49B7A4A0A@oracle.com>

Hi,

A new JBS component is now available for the serviceability agent: hotspot/svc-agent
This means that the old label svc-sa is deprecated and any issue that had this label has been moved to the new subcomponent.

So, wherever you'd previously used the label svc-sa (mainly in hotspot/svc or in core-svc/tools) you should now use the component hotspot/svc-agent.

Thanks,
/Jesper


From volker.simonis at gmail.com  Wed Jan 17 21:14:13 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 17 Jan 2018 21:14:13 +0000
Subject: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR,
 VENDOR, but no configure flag
In-Reply-To: <925deb32-a6af-d835-3ea9-d7b09c80e688@oracle.com>
References: <CA+3eh120FU701yYt+wgnkaaETStRJzB+pwy6k6VVmT7mdDcfeA@mail.gmail.com>
 <925deb32-a6af-d835-3ea9-d7b09c80e688@oracle.com>
Message-ID: <CA+3eh13sY-SJwZTTS=d-t6F4bK0vqj9K+P11QFPt1=-8qCLDzw@mail.gmail.com>

Erik Joelsson <erik.joelsson at oracle.com> schrieb am Mi. 17. Jan. 2018 um
20:16:

> Looks good to me. I can sponsor it.


Thanks a lot Erik!

Regards,
Volker


>
> /Erik
>
>
> On 2018-01-17 08:03, Volker Simonis wrote:
> > Hi,
> >
> > can I please have a review and sponsor for this change which finally
> > exposes the various "vendor*" properties:
> >
> > java.vendor
> > java.vm.vendor
> > java.vendor.url
> > java.vendor.url.bug
> >
> > as configure arguments:
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761
> > https://bugs.openjdk.java.net/browse/JDK-8189761
> >
> > With this change, "java.vendor" and "java.vm.vendor" still default to
> > "Oracle Corporation" which is defined in System.c (for "java.vendor")
> > and in vm_version.cpp (for "java.vm.version") unless the new
> > "--with-vendor-name" option introduced by JDK-8193764 will be used in
> > the configure step.
> >
> > If the "--with-vendor-name" option will be used, its value will now,
> > with this change, also be assigned to both, the "java.vendor" and
> > "java.vm.vendor" properties. I don't think that we need a separate
> > configure option for "java.vm.vendor" because if somebody is building
> > the OpenJDK with a different VM, he will own the source code of that
> > VM anyway and can easily set "java.vm.vendor" in his code.
> >
> > For "java.vendor.url" and "java.vendor.url.bug" I've introduced the
> > two new configure options "--with-vendor-url" and
> > "--with-vendor-bug-url" which should be self explanatory. If they are
> > not set, the old default values will be used.
> >
> > In the case of a VM crash, the HotSpot displays a second, different
> > bug URL which is currently only configured in the arguments.cpp file.
> > I've exposed this URL as well to configure with the new
> > "--with-vendor-vm-bug-url" configure option. Again, if this option
> > will not use, the VM will fall back to the old default value.
> >
> > Notice that this patch also fixes a bug introduced by "8193764: Cannot
> > set COMPANY_NAME when configuring a build" because of which the jtreg
> > test "test/jdk/tools/jlink/ReleaseImplementorTest.java" fails if the
> > testee was configured without "--with-vendor-name". The problem is
> > that the code introduced by 8193764 unconditionally sets COMPANY_NAME
> > to the empty string, if no "--with-vendor-name" option was given. This
> > overrides the default setting of COMPANY_NAME=N/A from
> > $AUTOCONF_DIR/version-numbers.
> >
> > I want to bring this into jdk10 if possible.
> >
> > I need a sponsor because this change requires the regeneration of
> > "generated-configure.sh" (which I've included in the webrev for your
> > convenience only) and because it touches a HotSpot file and external
> > contributors still can't push such changes :(
> >
> > Thank you and best regards,
> > Volker
>
>

From maurizio.cimadamore at oracle.com  Wed Jan 17 21:15:55 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 17 Jan 2018 21:15:55 +0000
Subject: Using Intellij IDEA with current JDK
In-Reply-To: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>
References: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>
Message-ID: <1c13cd8f-706e-83a3-cd25-cef02025edcf@oracle.com>

Hi Andrew,
this is a bug in IntelliJ - not sure if it's already fixed in the latest 
version - you might want to try to update in case you have not done it.

The reason is that IntelliJ used to check for the presence of javah to 
see if a JDK home was valid - since javah was removed [1], that 
detection started to act up.

One workaround is to put an empty file called 'javah' in your JDK bin 
folder :-)

Maurizio


On 17/01/18 16:15, Andrew Haley wrote:
> I now always get "The selected directory is not a valid home for JDK".
> when selecting the JDK home directory.
>
> Does anybody have any idea how to persuade IDEA that we need to work
> on the current top-of-tree JDK?  Thanks.
>


From maurizio.cimadamore at oracle.com  Wed Jan 17 21:16:25 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 17 Jan 2018 21:16:25 +0000
Subject: Using Intellij IDEA with current JDK
In-Reply-To: <1c13cd8f-706e-83a3-cd25-cef02025edcf@oracle.com>
References: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>
 <1c13cd8f-706e-83a3-cd25-cef02025edcf@oracle.com>
Message-ID: <12544efa-0d23-d88f-3bb2-f7971a30761c@oracle.com>

Whoops - forgot

[1] - https://bugs.openjdk.java.net/browse/JDK-8193503 
<https://bugs.openjdk.java.net/browse/JDK-8193503>


On 17/01/18 21:15, Maurizio Cimadamore wrote:
> Hi Andrew,
> this is a bug in IntelliJ - not sure if it's already fixed in the 
> latest version - you might want to try to update in case you have not 
> done it.
>
> The reason is that IntelliJ used to check for the presence of javah to 
> see if a JDK home was valid - since javah was removed [1], that 
> detection started to act up.
>
> One workaround is to put an empty file called 'javah' in your JDK bin 
> folder :-)
>
> Maurizio
>
>
> On 17/01/18 16:15, Andrew Haley wrote:
>> I now always get "The selected directory is not a valid home for JDK".
>> when selecting the JDK home directory.
>>
>> Does anybody have any idea how to persuade IDEA that we need to work
>> on the current top-of-tree JDK?? Thanks.
>>
>


From maurizio.cimadamore at oracle.com  Wed Jan 17 21:22:53 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 17 Jan 2018 21:22:53 +0000
Subject: Using Intellij IDEA with current JDK
In-Reply-To: <12544efa-0d23-d88f-3bb2-f7971a30761c@oracle.com>
References: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>
 <1c13cd8f-706e-83a3-cd25-cef02025edcf@oracle.com>
 <12544efa-0d23-d88f-3bb2-f7971a30761c@oracle.com>
Message-ID: <fe9bb82b-8b82-f1d1-88d0-c7f21ca92c99@oracle.com>

And here's a link to the Intellij issue:

https://youtrack.jetbrains.com/issue/IDEA-183920

Says it should be in 2017.3.2, which is what I've got, so I think an 
update should fix the problem for you.

Maurizio


On 17/01/18 21:16, Maurizio Cimadamore wrote:
> Whoops - forgot
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8193503 
> <https://bugs.openjdk.java.net/browse/JDK-8193503>
>
>
> On 17/01/18 21:15, Maurizio Cimadamore wrote:
>> Hi Andrew,
>> this is a bug in IntelliJ - not sure if it's already fixed in the 
>> latest version - you might want to try to update in case you have not 
>> done it.
>>
>> The reason is that IntelliJ used to check for the presence of javah 
>> to see if a JDK home was valid - since javah was removed [1], that 
>> detection started to act up.
>>
>> One workaround is to put an empty file called 'javah' in your JDK bin 
>> folder :-)
>>
>> Maurizio
>>
>>
>> On 17/01/18 16:15, Andrew Haley wrote:
>>> I now always get "The selected directory is not a valid home for JDK".
>>> when selecting the JDK home directory.
>>>
>>> Does anybody have any idea how to persuade IDEA that we need to work
>>> on the current top-of-tree JDK?? Thanks.
>>>
>>
>


From david.holmes at oracle.com  Wed Jan 17 22:26:40 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Jan 2018 08:26:40 +1000
Subject: New JBS component for the serviceability agent
In-Reply-To: <90C83861-D6CF-4490-8EB4-2FC49B7A4A0A@oracle.com>
References: <90C83861-D6CF-4490-8EB4-2FC49B7A4A0A@oracle.com>
Message-ID: <d53caf4b-c333-ec09-ebcd-8e27a25fe67a@oracle.com>

Hi Jesper,

cc'd serviceability-dev

On 18/01/2018 7:03 AM, jesper.wilhelmsson at oracle.com wrote:
> Hi,
> 
> A new JBS component is now available for the serviceability agent: hotspot/svc-agent
> This means that the old label svc-sa is deprecated and any issue that had this label has been moved to the new subcomponent.
> 
> So, wherever you'd previously used the label svc-sa (mainly in hotspot/svc or in core-svc/tools) you should now use the component hotspot/svc-agent.

Do we have guidelines on what kind of svc issues to file where? It often 
isn't clear which components are involved.

Thanks,
David

> Thanks,
> /Jesper
> 

From jesper.wilhelmsson at oracle.com  Thu Jan 18 00:35:01 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 18 Jan 2018 01:35:01 +0100
Subject: New JBS component for the serviceability agent
In-Reply-To: <d53caf4b-c333-ec09-ebcd-8e27a25fe67a@oracle.com>
References: <90C83861-D6CF-4490-8EB4-2FC49B7A4A0A@oracle.com>
 <d53caf4b-c333-ec09-ebcd-8e27a25fe67a@oracle.com>
Message-ID: <654AB883-901B-42BB-8E2E-51740CE2D84B@oracle.com>


> On 17 Jan 2018, at 23:26, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Jesper,
> 
> cc'd serviceability-dev
> 
> On 18/01/2018 7:03 AM, jesper.wilhelmsson at oracle.com wrote:
>> Hi,
>> A new JBS component is now available for the serviceability agent: hotspot/svc-agent
>> This means that the old label svc-sa is deprecated and any issue that had this label has been moved to the new subcomponent.
>> So, wherever you'd previously used the label svc-sa (mainly in hotspot/svc or in core-svc/tools) you should now use the component hotspot/svc-agent.
> 
> Do we have guidelines on what kind of svc issues to file where? It often isn't clear which components are involved.

hotspot/svc-agent is for issues concerning the serviceability agent (code in src/jdk.hotspot.agent/* and vmStructs.cpp). JMX issues goes into core-svc/javax.management. Both of these components are considered part of the M&M area. (They also have core-svc/java.lang.management.)

As for the serviceability area there are components like: hotspot/jvmti, hotspot/svc, core-svc/debugger, core-svc/tools, core-svc/java.lang.instrument, and tools/hprof. Some of these have fairly descriptive names, the rest I leave for the serviceability folks to sort out :-)

/Jesper

> 
> Thanks,
> David
> 
>> Thanks,
>> /Jesper


From huaming.li at oracle.com  Thu Jan 18 03:56:37 2018
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 18 Jan 2018 11:56:37 +0800
Subject: [10] RFR: 8195478: sun/text/resources/LocaleDataTest.java fails
 with java.lang.Exception
In-Reply-To: <acb74257-ebf0-6913-d741-7d801447cc60@oracle.com>
References: <c95b2e38-e1f0-aca2-e998-348ea442f1ec@oracle.com>
 <9e9e8ab0-d85c-b1ba-0a9d-610cf0dfcd6f@oracle.com>
 <12bf2f0d-c1cb-5cf0-a559-5e59311d9e98@oracle.com>
 <acb74257-ebf0-6913-d741-7d801447cc60@oracle.com>
Message-ID: <7a2b8500-34a3-b7f2-fe39-5e806b558142@oracle.com>

Hi Naoto,

I have pushed the code change to http://hg.openjdk.java.net/jdk/jdk10, I 
think I need to push to 11 (http://hg.openjdk.java.net/jdk/jdk) too. Do 
I need to send out for review again?

Thank you

-Hamlin


On 17/01/2018 9:06 PM, Naoto Sato wrote:
> Looks good to me. As Rachna mentioned, please add @bug to 
> LocaleDataTest.java. No further review is needed.
>
> Naoto
>
> On 1/17/18 12:50 AM, Hamlin Li wrote:
>> Hi Rachna,
>>
>> I'm not sure, but I think in this case (it's a test bug) @bug 8195478 
>> should not be added.
>>
>> Thank you
>>
>> -Hamlin
>>
>>
>> On 17/01/2018 4:45 PM, Rachna Goel wrote:
>>>
>>> Hi Hamlin,
>>>
>>> Just one nit, Please add bug id 8195478 to 
>>> sun/text/resources/LocaleDataTest.java.
>>>
>>> Thanks,
>>>
>>> Rachna
>>>
>>>
>>> On 1/17/2018 1:37 PM, Hamlin Li wrote:
>>>> Would you please review the following patch?
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8195478
>>>>
>>>> webrev as below
>>>>
>>>> I have tested it locally.
>>>>
>>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> diff -r 19effb7970bc test/jdk/sun/text/resources/LocaleData
>>>> --- a/test/jdk/sun/text/resources/LocaleData??? Thu Jan 11 20:19:50 
>>>> 2018 -0800
>>>> +++ b/test/jdk/sun/text/resources/LocaleData??? Wed Jan 17 16:02:25 
>>>> 2018 +0800
>>>> @@ -6396,7 +6396,6 @@
>>>> ?CurrencyNames//ang=Netherlands Antillean Guilder
>>>> ?CurrencyNames//awg=Aruban Florin
>>>> ?CurrencyNames//azm=Azerbaijani Manat (1993-2006)
>>>> -CurrencyNames//azn=Azerbaijani Manat
>>>> ?CurrencyNames//bbd=Barbadian Dollar
>>>> ?CurrencyNames//bdt=Bangladeshi Taka
>>>> ?CurrencyNames//bgn=Bulgarian Lev
>>>
>>


From huaming.li at oracle.com  Thu Jan 18 06:59:22 2018
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 18 Jan 2018 14:59:22 +0800
Subject: RFR of 8194284: CheckRegisterInLog.java fails with
 java.lang.RuntimeException: CheckRegisterInLog got exception timeout
 6480000ms out of range
Message-ID: <c2a3383a-0553-ff43-8b3d-d46fab3509fe@oracle.com>

Would you please review the following patch?

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

webrev as below.


Thank you

-Hamlin

------------------------------------------------------------------------

diff -r 0dec8c41170c test/jdk/java/rmi/testlibrary/TestLibrary.java
--- a/test/jdk/java/rmi/testlibrary/TestLibrary.java??? Wed Jan 17 
20:07:50 2018 -0800
+++ b/test/jdk/java/rmi/testlibrary/TestLibrary.java??? Thu Jan 18 
14:54:50 2018 +0800
@@ -188,8 +188,12 @@
 ???? public static long computeDeadline(long timestamp, long timeout) {
 ???????? final long MAX_TIMEOUT_MS = 3_600_000L;

-??????? if (timeout < 0L || timeout > MAX_TIMEOUT_MS) {
+??????? if (timeout < 0L) {
 ???????????? throw new IllegalArgumentException("timeout " + timeout + 
"ms out of range");
+??????? } else if (timeout > MAX_TIMEOUT_MS) {
+??????????? System.out.format("timeout value(%d) exceeds 
MAX_TIMEOUT_MS(%d), "
+??????????????????? + "use MAX_TIMEOUT_MS instead!%n", timeout, 
MAX_TIMEOUT_MS);
+??????????? timeout = MAX_TIMEOUT_MS;
 ???????? }

 ???????? return timestamp + (long)(timeout * getTimeoutFactor());


From david.holmes at oracle.com  Thu Jan 18 07:15:32 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Jan 2018 17:15:32 +1000
Subject: RFR of 8194284: CheckRegisterInLog.java fails with
 java.lang.RuntimeException: CheckRegisterInLog got exception timeout
 6480000ms out of range
In-Reply-To: <c2a3383a-0553-ff43-8b3d-d46fab3509fe@oracle.com>
References: <c2a3383a-0553-ff43-8b3d-d46fab3509fe@oracle.com>
Message-ID: <961a4bb4-9deb-fc5a-7e21-cffdbdd98dc8@oracle.com>

Hi Hamlin,

This should probably be reviewed on core-libs-dev. I don't think jdk-dev 
is intended for code reviews.

On 18/01/2018 4:59 PM, Hamlin Li wrote:
> Would you please review the following patch?
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8194284
> 
> webrev as below.

I don't agree with this. Whatever is passing the incorrect timeout to 
the TestLibrary should be fixed. The bug report needs more information 
about where the incorrect value is coming from and why.

Cheers,
David

> 
> Thank you
> 
> -Hamlin
> 
> ------------------------------------------------------------------------
> 
> diff -r 0dec8c41170c test/jdk/java/rmi/testlibrary/TestLibrary.java
> --- a/test/jdk/java/rmi/testlibrary/TestLibrary.java??? Wed Jan 17 
> 20:07:50 2018 -0800
> +++ b/test/jdk/java/rmi/testlibrary/TestLibrary.java??? Thu Jan 18 
> 14:54:50 2018 +0800
> @@ -188,8 +188,12 @@
>  ???? public static long computeDeadline(long timestamp, long timeout) {
>  ???????? final long MAX_TIMEOUT_MS = 3_600_000L;
> 
> -??????? if (timeout < 0L || timeout > MAX_TIMEOUT_MS) {
> +??????? if (timeout < 0L) {
>  ???????????? throw new IllegalArgumentException("timeout " + timeout + 
> "ms out of range");
> +??????? } else if (timeout > MAX_TIMEOUT_MS) {
> +??????????? System.out.format("timeout value(%d) exceeds 
> MAX_TIMEOUT_MS(%d), "
> +??????????????????? + "use MAX_TIMEOUT_MS instead!%n", timeout, 
> MAX_TIMEOUT_MS);
> +??????????? timeout = MAX_TIMEOUT_MS;
>  ???????? }
> 
>  ???????? return timestamp + (long)(timeout * getTimeoutFactor());
> 

From serguei.spitsyn at oracle.com  Thu Jan 18 08:34:00 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 18 Jan 2018 00:34:00 -0800
Subject: CFV: New JDK Reviewer: Brent Christian
In-Reply-To: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
References: <4bad914a-c78d-5a26-959e-cf9d306d76cd@oracle.com>
Message-ID: <e0cee1ee-9551-f181-fba1-e15f69183f82@oracle.com>

Vote: yes

From stefan.johansson at oracle.com  Thu Jan 18 09:12:39 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 18 Jan 2018 10:12:39 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
Message-ID: <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>



On 2018-01-17 10:43, Aleksey Shipilev wrote:
> On 01/17/2018 12:50 AM, charlie hunt wrote:
>> Seems with what is being proposed is essentially a ?no GC? type of ability ? a command line
>> option of -XX:+NoGC or -XX:+UseNoGC would probably be better understood as to what it generally
>> does, and the consequence of exhausting Java heap space since there is ?no GC?.
> How very unpoetical :) Epsilon has the origin story for its name, see the JEP. Most people,
> including prospective users, know this feature under "Epsilon" and some expressed the love for the
> name. So, as long as there is no overwhelming amount of strong opinions against it, I'd keep the
> name as is.
I'm with Charlie here, I think -XX:+UseNoGC would be better and much 
more descriptive name for this feature.

Stefan
> -Aleksey
>


From erik.osterlund at oracle.com  Thu Jan 18 09:26:53 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 18 Jan 2018 10:26:53 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
Message-ID: <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>

Hi,

This is not a garbage collector, because it does not collect garbage. It 
is an allocator. Therefore, I also think the -XX:+UseNoGC name is more 
descriptive.
Also, is this what it always feels like to write short emails?

Thanks,
/Erik

On 2018-01-18 10:12, Stefan Johansson wrote:
>
>
> On 2018-01-17 10:43, Aleksey Shipilev wrote:
>> On 01/17/2018 12:50 AM, charlie hunt wrote:
>>> Seems with what is being proposed is essentially a ?no GC? type of 
>>> ability ? a command line
>>> option of -XX:+NoGC or -XX:+UseNoGC would probably be better 
>>> understood as to what it generally
>>> does, and the consequence of exhausting Java heap space since there 
>>> is ?no GC?.
>> How very unpoetical :) Epsilon has the origin story for its name, see 
>> the JEP. Most people,
>> including prospective users, know this feature under "Epsilon" and 
>> some expressed the love for the
>> name. So, as long as there is no overwhelming amount of strong 
>> opinions against it, I'd keep the
>> name as is.
> I'm with Charlie here, I think -XX:+UseNoGC would be better and much 
> more descriptive name for this feature.
>
> Stefan
>> -Aleksey
>>
>


From shade at redhat.com  Thu Jan 18 09:39:00 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jan 2018 10:39:00 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
Message-ID: <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>

On 01/18/2018 10:26 AM, Erik ?sterlund wrote:
> This is not a garbage collector, because it does not collect garbage. It is an allocator. 

Well, it also does the memory reclamation "ultimate garbage collection"-style [1] ;)

> Therefore, I also think the -XX:+UseNoGC name is more descriptive.
Noted. Would you then agree that -XX:+UseNoGC is descriptive enough that users know they risk sudden
OOMEs? The option name itself obviously comes with that caveat that user has to accept, and so we
don't need to protect it with experimental/diagnostic flag?

Thanks,
-Aleksey

[1] https://groups.google.com/forum/message/raw?msg=comp.lang.ada/E9bNCvDQ12k/1tezW24ZxdAJ


From benjamin.john.evans at gmail.com  Thu Jan 18 09:51:10 2018
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Thu, 18 Jan 2018 09:51:10 +0000
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
Message-ID: <CABKW8RjccRTic4ZGS=iUYM5cag3PUvbW5H1LRsYWaZWuJXS3gA@mail.gmail.com>

How about -XX:+LeakMemoryOnAllAllocations - which is fully descriptive
of what?s going on & won?t suggest to even the most unwary developer
that this is an alternative production collector?

Thanks,

Ben

On Thu, Jan 18, 2018 at 9:39 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> On 01/18/2018 10:26 AM, Erik ?sterlund wrote:
>> This is not a garbage collector, because it does not collect garbage. It is an allocator.
>
> Well, it also does the memory reclamation "ultimate garbage collection"-style [1] ;)
>
>> Therefore, I also think the -XX:+UseNoGC name is more descriptive.
> Noted. Would you then agree that -XX:+UseNoGC is descriptive enough that users know they risk sudden
> OOMEs? The option name itself obviously comes with that caveat that user has to accept, and so we
> don't need to protect it with experimental/diagnostic flag?
>
> Thanks,
> -Aleksey
>
> [1] https://groups.google.com/forum/message/raw?msg=comp.lang.ada/E9bNCvDQ12k/1tezW24ZxdAJ
>

From shade at redhat.com  Thu Jan 18 09:58:56 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jan 2018 10:58:56 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <CABKW8RjccRTic4ZGS=iUYM5cag3PUvbW5H1LRsYWaZWuJXS3gA@mail.gmail.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
 <CABKW8RjccRTic4ZGS=iUYM5cag3PUvbW5H1LRsYWaZWuJXS3gA@mail.gmail.com>
Message-ID: <2cc2c9a5-dfb1-92f4-4868-f0304882d488@redhat.com>

On 01/18/2018 10:51 AM, Ben Evans wrote:
> How about -XX:+LeakMemoryOnAllAllocations - which is fully descriptive
> of what?s going on & won?t suggest to even the most unwary developer
> that this is an alternative production collector?

Not sure if trolling, but this goes against the convention that GC selection options are suffixed
with "GC". So, it should be -XX:+LeakMemoryOnAllAllocations*GC*!

-Aleksey


From erik.osterlund at oracle.com  Thu Jan 18 10:10:04 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 18 Jan 2018 11:10:04 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
Message-ID: <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>

Hi Aleksey,

I do not feel too comfortable with this being a product flag regardless 
of the name. There is existing code that assumes that for example 
System.gc() will actually do something. Similar for assumptions that 
language features like finalizers and reference objects and queues will 
do anything at all. That makes me feel uncomfortable. Do you feel 
comfortable with exposing a product flag that breaks code relying on 
those features?

Thanks,
/Erik

On 2018-01-18 10:39, Aleksey Shipilev wrote:
> On 01/18/2018 10:26 AM, Erik ?sterlund wrote:
>> This is not a garbage collector, because it does not collect garbage. It is an allocator.
> Well, it also does the memory reclamation "ultimate garbage collection"-style [1] ;)
>
>> Therefore, I also think the -XX:+UseNoGC name is more descriptive.
> Noted. Would you then agree that -XX:+UseNoGC is descriptive enough that users know they risk sudden
> OOMEs? The option name itself obviously comes with that caveat that user has to accept, and so we
> don't need to protect it with experimental/diagnostic flag?
>
> Thanks,
> -Aleksey
>
> [1] https://groups.google.com/forum/message/raw?msg=comp.lang.ada/E9bNCvDQ12k/1tezW24ZxdAJ
>


From adinn at redhat.com  Thu Jan 18 10:15:08 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 18 Jan 2018 10:15:08 +0000
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
 <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
Message-ID: <859d291f-7dab-8c0e-1e6c-0065001f3856@redhat.com>

On 18/01/18 10:10, Erik ?sterlund wrote:
> I do not feel too comfortable with this being a product flag regardless
> of the name. There is existing code that assumes that for example
> System.gc() will actually do something. Similar for assumptions that
> language features like finalizers and reference objects and queues will
> do anything at all. That makes me feel uncomfortable. Do you feel
> comfortable with exposing a product flag that breaks code relying on
> those features?

Honestly, if we are at the point where we need to cater for those who
pass in -XX:+UseNoGC and still expect "System.gc() will actually do
something" the I believe all hope for civilization is a faint and
distant pipe dream.

Have we not bike-shedded this JEP enough already?


regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From shade at redhat.com  Thu Jan 18 10:18:54 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jan 2018 11:18:54 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
 <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
Message-ID: <6aff8f84-fb1b-90d0-3107-14f3d30cfdcc@redhat.com>

On 01/18/2018 11:10 AM, Erik ?sterlund wrote:
> I do not feel too comfortable with this being a product flag regardless of the name. There is
> existing code that assumes that for example System.gc() will actually do something. Similar for
> assumptions that language features like finalizers and reference objects and queues will do anything
> at all. That makes me feel uncomfortable. Do you feel comfortable with exposing a product flag that
> breaks code relying on those features?

I do feel comfortable about this, because JLS and JVMS specify that GC is best-effort, and therefore
any other language and library feature that depends on GC is also best-effort. This allows, among
other things: no-op GCs, reclaiming GCs that never actually do touch references or finalizers, GCs
that fully ignore System.gc (remember -XX:-DisableExplicitGC that *is* a product option?), etc.

I think users at large understand the choice of GC implementation matters in how responsive (if
ever) the language/library features are.

Thanks,
-Aleksey


From hs at tagtraum.com  Thu Jan 18 10:21:43 2018
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 18 Jan 2018 11:21:43 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <859d291f-7dab-8c0e-1e6c-0065001f3856@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
 <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
 <859d291f-7dab-8c0e-1e6c-0065001f3856@redhat.com>
Message-ID: <9A029D57-E83A-4F27-A68D-86FDD9182455@tagtraum.com>

> On Jan 18, 2018, at 11:15, Andrew Dinn <adinn at redhat.com> wrote:
> 
> On 18/01/18 10:10, Erik ?sterlund wrote:
>> I do not feel too comfortable with this being a product flag regardless
>> of the name. There is existing code that assumes that for example
>> System.gc() will actually do something. Similar for assumptions that
>> language features like finalizers and reference objects and queues will
>> do anything at all. That makes me feel uncomfortable. Do you feel
>> comfortable with exposing a product flag that breaks code relying on
>> those features?
> 
> Honestly, if we are at the point where we need to cater for those who
> pass in -XX:+UseNoGC and still expect "System.gc() will actually do
> something" the I believe all hope for civilization is a faint and
> distant pipe dream.

Indeed.

Also: ?UseNoGC" is by far the better flag name than anything epsilon. If you?re absolutely in love with ?epsilon?, make it an alias, but not the main name. Usability and accessibility beat fancy origin stories hands down, IMO.

-hendrik

From shade at redhat.com  Thu Jan 18 10:22:08 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jan 2018 11:22:08 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <859d291f-7dab-8c0e-1e6c-0065001f3856@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
 <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
 <859d291f-7dab-8c0e-1e6c-0065001f3856@redhat.com>
Message-ID: <c9061ea1-7b0b-a6c5-7d1f-595c2bcf7225@redhat.com>

On 01/18/2018 11:15 AM, Andrew Dinn wrote:
> On 18/01/18 10:10, Erik ?sterlund wrote:
>> I do not feel too comfortable with this being a product flag regardless
>> of the name. There is existing code that assumes that for example
>> System.gc() will actually do something. Similar for assumptions that
>> language features like finalizers and reference objects and queues will
>> do anything at all. That makes me feel uncomfortable. Do you feel
>> comfortable with exposing a product flag that breaks code relying on
>> those features?
> 
> Honestly, if we are at the point where we need to cater for those who
> pass in -XX:+UseNoGC and still expect "System.gc() will actually do
> something" the I believe all hope for civilization is a faint and
> distant pipe dream.
> 
> Have we not bike-shedded this JEP enough already?

The best venue for bike-shedding is obviously Twitter, so I started The Ultimately Representative
Social Study(tm) here: https://twitter.com/shipilev/status/953930664566501378

Thanks,
-Aleksey


From martijnverburg at gmail.com  Thu Jan 18 10:23:57 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 18 Jan 2018 10:23:57 +0000
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <6aff8f84-fb1b-90d0-3107-14f3d30cfdcc@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
 <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
 <6aff8f84-fb1b-90d0-3107-14f3d30cfdcc@redhat.com>
Message-ID: <CAP7YuAQE3eKKHeMvOs6Qq5pYBgZAfqPsKYm8zkjAMpDOU028Gw@mail.gmail.com>

I agree with this.  Our customers (probably representing a few thousand
folks tuning GC, small sample set I know) who explicitly change GC
allocators are 99% in the ?we?ve at least read the main docs as it?s
clearly an impactful change? camp, the remaining 1% get reminded quickly to
do so!

Cheers,
Martijn

On Thu, 18 Jan 2018 at 18:19, Aleksey Shipilev <shade at redhat.com> wrote:

> On 01/18/2018 11:10 AM, Erik ?sterlund wrote:
> > I do not feel too comfortable with this being a product flag regardless
> of the name. There is
> > existing code that assumes that for example System.gc() will actually do
> something. Similar for
> > assumptions that language features like finalizers and reference objects
> and queues will do anything
> > at all. That makes me feel uncomfortable. Do you feel comfortable with
> exposing a product flag that
> > breaks code relying on those features?
>
> I do feel comfortable about this, because JLS and JVMS specify that GC is
> best-effort, and therefore
> any other language and library feature that depends on GC is also
> best-effort. This allows, among
> other things: no-op GCs, reclaiming GCs that never actually do touch
> references or finalizers, GCs
> that fully ignore System.gc (remember -XX:-DisableExplicitGC that *is* a
> product option?), etc.
>
> I think users at large understand the choice of GC implementation matters
> in how responsive (if
> ever) the language/library features are.
>
> Thanks,
> -Aleksey
>
> --
Cheers, Martijn (Sent from Gmail Mobile)

From martijnverburg at gmail.com  Thu Jan 18 10:43:52 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 18 Jan 2018 10:43:52 +0000
Subject: FYI: JDK 10 early-access builds under the GPL
In-Reply-To: <20180117115244.693941152@eggemoggin.niobe.net>
References: <20180117115244.693941152@eggemoggin.niobe.net>
Message-ID: <CAP7YuAQfEfU4nRC6cya8hm=kDrT95S5aOHNwQ2W3QEwk4DFz8Q@mail.gmail.com>

Great news, thank you Mark and Oracle!

On Thu, 18 Jan 2018 at 03:53, <mark.reinhold at oracle.com> wrote:

> Early-access builds of the Oracle JDK, under the usual Oracle EA
> license, have been available at http://jdk.java.net/10 for quite
> a while now.  As of today that page also includes OpenJDK builds,
> under the GPLv2 with the Classpath Exception.
>
> - Mark
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From aph at redhat.com  Thu Jan 18 11:09:34 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 18 Jan 2018 11:09:34 +0000
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <bee29cef-19c5-b272-9407-b11d0a13e3c7@redhat.com>
 <75be95a2-0de8-b8a0-58a0-d1b96a2ef129@oracle.com>
Message-ID: <97b22472-0852-a313-f7c9-8e87a478915f@redhat.com>

On 18/01/18 10:10, Erik ?sterlund wrote:
> I do not feel too comfortable with this being a product flag regardless 
> of the name. There is existing code that assumes that for example 
> System.gc() will actually do something. Similar for assumptions that 
> language features like finalizers and reference objects and queues will 
> do anything at all.

Anybody who relies on finalizers and reference objects and queues to
do anything in bounded time is already assuming something not in the
spec.  They are already lost; Epsilon will reveal to them the depths
of their error.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From shade at redhat.com  Thu Jan 18 11:10:21 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jan 2018 12:10:21 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
Message-ID: <850f7694-ce3b-40b5-a3d1-907bdd64ec84@redhat.com>

On 01/18/2018 10:26 AM, Erik ?sterlund wrote:
> On 2018-01-18 10:12, Stefan Johansson wrote:
>> On 2018-01-17 10:43, Aleksey Shipilev wrote:
>>> name. So, as long as there is no overwhelming amount of strong opinions against it, I'd keep the
>>> name as is.
>> I'm with Charlie here, I think -XX:+UseNoGC would be better and much more descriptive name for
>> this feature.
> This is not a garbage collector, because it does not collect garbage. It is an allocator. Therefore,
> I also think the -XX:+UseNoGC name is more descriptive.

All right, I added -XX:+UseNoGC as the alias option to the current development patch:
  http://hg.openjdk.java.net/jdk/sandbox/rev/dd005db4ec5c

I still believe the purpose for this thread is not about getting tangled up in implementation
details and bikeshedding. We would decide which alias to drop later. Makes everyone happy at the moment?

-Aleksey


From Roger.Riggs at Oracle.com  Thu Jan 18 13:56:47 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 18 Jan 2018 08:56:47 -0500
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <850f7694-ce3b-40b5-a3d1-907bdd64ec84@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <850f7694-ce3b-40b5-a3d1-907bdd64ec84@redhat.com>
Message-ID: <10a42a39-1f8f-ee49-d558-9f99d055344d@Oracle.com>

Hi Aleksey,

Does the entire test suite pass with this collector?
In spite of Andrew's point, there are numerous tests of behavior that 
are effects/side effects of
collectors that will fail. Does the JCK pass with this option (the all 
modes rule).
If not will, will you modify all those tests to @require other 
collectors so they are not run
with -XX:+UseNoGC?

It would be bad form to commit a change that causes a large number of 
regular tests to fail.

Thanks, Roger


On 1/18/2018 6:10 AM, Aleksey Shipilev wrote:
> On 01/18/2018 10:26 AM, Erik ?sterlund wrote:
>> On 2018-01-18 10:12, Stefan Johansson wrote:
>>> On 2018-01-17 10:43, Aleksey Shipilev wrote:
>>>> name. So, as long as there is no overwhelming amount of strong opinions against it, I'd keep the
>>>> name as is.
>>> I'm with Charlie here, I think -XX:+UseNoGC would be better and much more descriptive name for
>>> this feature.
>> This is not a garbage collector, because it does not collect garbage. It is an allocator. Therefore,
>> I also think the -XX:+UseNoGC name is more descriptive.
> All right, I added -XX:+UseNoGC as the alias option to the current development patch:
>    http://hg.openjdk.java.net/jdk/sandbox/rev/dd005db4ec5c
>
> I still believe the purpose for this thread is not about getting tangled up in implementation
> details and bikeshedding. We would decide which alias to drop later. Makes everyone happy at the moment?
>
> -Aleksey
>


From shade at redhat.com  Thu Jan 18 14:14:40 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jan 2018 15:14:40 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <10a42a39-1f8f-ee49-d558-9f99d055344d@Oracle.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <850f7694-ce3b-40b5-a3d1-907bdd64ec84@redhat.com>
 <10a42a39-1f8f-ee49-d558-9f99d055344d@Oracle.com>
Message-ID: <1cb03689-dabd-de9d-5905-8a561b2bab7f@redhat.com>

Hi Roger,

On 01/18/2018 02:56 PM, Roger Riggs wrote:
> Does the entire test suite pass with this collector?
> In spite of Andrew's point, there are numerous tests of behavior that are effects/side effects of
> collectors that will fail. Does the JCK pass with this option (the all modes rule).

Haven't tried JCK with it. Epsilon comes with its own set of bounded allocation tests.

I don't think "all modes rule" applies to every single JVM mode? The applicability seems to heavily
depend on the flavor of the UseEpsilonGC/UseNoGC option. Currently it is "develop", so it is not
even available in product builds, and therefore JCK does not apply?

My view is that elevating this to "diagnostic" is also safe, because we do not provide reliability
and compatibility guarantees for those. Ditto for "experimental", although GC guys have
interpretation of it different from the definition in globals.hpp. If we do it as "product" option,
only then JCK would start to apply, right?

> It would be bad form to commit a change that causes a large number of regular tests to fail.

Sure. And we would need to exercise judgment in what tests to apply to which features.

-Aleksey


From stefan.karlsson at oracle.com  Thu Jan 18 14:29:56 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 18 Jan 2018 15:29:56 +0100
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <20180111134627.676325789@eggemoggin.niobe.net>
References: <20180111134627.676325789@eggemoggin.niobe.net>
Message-ID: <e4be006f-ef0f-062d-33cb-9b74e384897b@oracle.com>

My preferences would be:

1) Use the -XX:+UseNoGC flags, since it more clearly communicates to the 
users that this is not a fully fledged GC.

2) Don't use an alias. GC aliases tend to cause problems for the 
@requires tags in the jtreg tests.

3) Make -XX:+UseNoGC an experimental flag. I think this feature would be 
next to useless if it was only available in debug builds.

Thanks,
StefanK

On 2018-01-11 22:46, mark.reinhold at oracle.com wrote:
> The following JEP is proposed to target JDK 11:
> 
>    318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector
>         http://openjdk.java.net/jeps/318
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 18 January, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
> 
> - Mark
> 
> 
> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> 

From Roger.Riggs at Oracle.com  Thu Jan 18 14:33:45 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 18 Jan 2018 09:33:45 -0500
Subject: RFR of 8194284: CheckRegisterInLog.java fails with
 java.lang.RuntimeException: CheckRegisterInLog got exception timeout
 6480000ms out of range
In-Reply-To: <c2a3383a-0553-ff43-8b3d-d46fab3509fe@oracle.com>
References: <c2a3383a-0553-ff43-8b3d-d46fab3509fe@oracle.com>
Message-ID: <f1a227aa-613a-6a35-fda0-e2fa4155c47a@Oracle.com>

Hi Hamlin,

The base bug is that the timeoutFactor is being applied twice, once in 
the RMID constructor
and again in computeDeadline.? It is better to cleanup the 
implementation of the test library
than to fudge the values.? Either respect the timeouts passed in (remove 
the scaling from computeDeadline)
or consistently leave it to the lower level routines.? Pick 1.

Thanks, Roger


On 1/18/2018 1:59 AM, Hamlin Li wrote:
> Would you please review the following patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8194284
>
> webrev as below.
>
>
> Thank you
>
> -Hamlin
>
> ------------------------------------------------------------------------
>
> diff -r 0dec8c41170c test/jdk/java/rmi/testlibrary/TestLibrary.java
> --- a/test/jdk/java/rmi/testlibrary/TestLibrary.java??? Wed Jan 17 
> 20:07:50 2018 -0800
> +++ b/test/jdk/java/rmi/testlibrary/TestLibrary.java??? Thu Jan 18 
> 14:54:50 2018 +0800
> @@ -188,8 +188,12 @@
> ???? public static long computeDeadline(long timestamp, long timeout) {
> ???????? final long MAX_TIMEOUT_MS = 3_600_000L;
>
> -??????? if (timeout < 0L || timeout > MAX_TIMEOUT_MS) {
> +??????? if (timeout < 0L) {
> ???????????? throw new IllegalArgumentException("timeout " + timeout + 
> "ms out of range");
> +??????? } else if (timeout > MAX_TIMEOUT_MS) {
> +??????????? System.out.format("timeout value(%d) exceeds 
> MAX_TIMEOUT_MS(%d), "
> +??????????????????? + "use MAX_TIMEOUT_MS instead!%n", timeout, 
> MAX_TIMEOUT_MS);
> +??????????? timeout = MAX_TIMEOUT_MS;
> ???????? }
>
> ???????? return timestamp + (long)(timeout * getTimeoutFactor());
>


From goetz.lindenmaier at sap.com  Thu Jan 18 15:37:31 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 18 Jan 2018 15:37:31 +0000
Subject: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails with
 java.lang.AssertionError: HelpFlagsTest failed:
Message-ID: <b15953a0b9c640a49d62bcb4ca5f3ee5@sap.com>

Hi,

the most simple fix is to just exclude the four tools:
http://cr.openjdk.java.net/~goetz/wr18/8195663-fixHelpTest/webrev.01/
Unfortunately I can't test this, as my build does not contain these
tools.

If somebody tells me how to build these tools, I will adapt
the test to check them, and eventually adapt the tools to 
CSR 8191477 https://bugs.openjdk.java.net/browse/JDK-8191477.

What list should this be reviewed on? I just posted to jdk-dev for now.

Best regards,
  Goetz.

From weijun.wang at oracle.com  Thu Jan 18 15:44:08 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 18 Jan 2018 23:44:08 +0800
Subject: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails
 with java.lang.AssertionError: HelpFlagsTest failed:
In-Reply-To: <b15953a0b9c640a49d62bcb4ca5f3ee5@sap.com>
References: <b15953a0b9c640a49d62bcb4ca5f3ee5@sap.com>
Message-ID: <19A6164F-1766-4C30-8A34-05B1185D9525@oracle.com>

On Windows, there is also a ssvagent.exe.

> On Jan 18, 2018, at 11:37 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> the most simple fix is to just exclude the four tools:
> http://cr.openjdk.java.net/~goetz/wr18/8195663-fixHelpTest/webrev.01/
> Unfortunately I can't test this, as my build does not contain these
> tools.
> 
> If somebody tells me how to build these tools, I will adapt
> the test to check them, and eventually adapt the tools to 
> CSR 8191477 https://bugs.openjdk.java.net/browse/JDK-8191477.
> 
> What list should this be reviewed on? I just posted to jdk-dev for now.
> 
> Best regards,
>  Goetz.


From goetz.lindenmaier at sap.com  Thu Jan 18 16:01:52 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 18 Jan 2018 16:01:52 +0000
Subject: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails
 with java.lang.AssertionError: HelpFlagsTest failed:
In-Reply-To: <19A6164F-1766-4C30-8A34-05B1185D9525@oracle.com>
References: <b15953a0b9c640a49d62bcb4ca5f3ee5@sap.com>
 <19A6164F-1766-4C30-8A34-05B1185D9525@oracle.com>
Message-ID: <45e66d48b4224ef8a5342d8b64a2b24c@sap.com>

Hi,

Added ssvagent:
http://cr.openjdk.java.net/~goetz/wr18/8195663-fixHelpTest/webrev.02/

Best regards,
  Goetz.

> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Donnerstag, 18. Januar 2018 16:44
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Kumar Srinivasan <kumar.x.srinivasan at oracle.com>; jdk-
> dev at openjdk.java.net
> Subject: Re: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails
> with java.lang.AssertionError: HelpFlagsTest failed:
> 
> On Windows, there is also a ssvagent.exe.
> 
> > On Jan 18, 2018, at 11:37 PM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > the most simple fix is to just exclude the four tools:
> > http://cr.openjdk.java.net/~goetz/wr18/8195663-fixHelpTest/webrev.01/
> > Unfortunately I can't test this, as my build does not contain these
> > tools.
> >
> > If somebody tells me how to build these tools, I will adapt
> > the test to check them, and eventually adapt the tools to
> > CSR 8191477 https://bugs.openjdk.java.net/browse/JDK-8191477.
> >
> > What list should this be reviewed on? I just posted to jdk-dev for now.
> >
> > Best regards,
> >  Goetz.


From Derek.White at cavium.com  Thu Jan 18 16:06:27 2018
From: Derek.White at cavium.com (White, Derek)
Date: Thu, 18 Jan 2018 16:06:27 +0000
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <850f7694-ce3b-40b5-a3d1-907bdd64ec84@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <850f7694-ce3b-40b5-a3d1-907bdd64ec84@redhat.com>
Message-ID: <CY1PR0701MB1632D30CABC7299894A9FF0184E80@CY1PR0701MB1632.namprd07.prod.outlook.com>

Hi Aleksey,

I know you were looking for more nit-picking, so here it goes:

The preferred way to add an aliased option is to add an entry to the aliased_jvm_flags table in arguments.cpp. It's basically a 1-line patch vs 4 files. For completeness add a test case to VMAliasOptions.java to ensure that the alias really flips the option.

Then there's only one actual option variable, and no confusion about which is really controlling the implementation.

Oh, and since you asked: +1 on "UseNoGC".

 - Derek

> -----Original Message-----
> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of
> Aleksey Shipilev
> Sent: Thursday, January 18, 2018 6:10 AM
> To: Erik ?sterlund <erik.osterlund at oracle.com>; Stefan Johansson
> <stefan.johansson at oracle.com>; jdk-dev at openjdk.java.net
> Subject: Re: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily Low-
> Overhead Garbage Collector
> 
> On 01/18/2018 10:26 AM, Erik ?sterlund wrote:
> > On 2018-01-18 10:12, Stefan Johansson wrote:
> >> On 2018-01-17 10:43, Aleksey Shipilev wrote:
> >>> name. So, as long as there is no overwhelming amount of strong
> >>> opinions against it, I'd keep the name as is.
> >> I'm with Charlie here, I think -XX:+UseNoGC would be better and much
> >> more descriptive name for this feature.
> > This is not a garbage collector, because it does not collect garbage.
> > It is an allocator. Therefore, I also think the -XX:+UseNoGC name is more
> descriptive.
> 
> All right, I added -XX:+UseNoGC as the alias option to the current
> development patch:
>   http://hg.openjdk.java.net/jdk/sandbox/rev/dd005db4ec5c
> 
> I still believe the purpose for this thread is not about getting tangled up in
> implementation details and bikeshedding. We would decide which alias to
> drop later. Makes everyone happy at the moment?
> 
> -Aleksey


From martijnverburg at gmail.com  Thu Jan 18 16:15:47 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 18 Jan 2018 16:15:47 +0000
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <1cb03689-dabd-de9d-5905-8a561b2bab7f@redhat.com>
References: <20180111134627.676325789@eggemoggin.niobe.net>
 <F09AE5DF-558A-47F8-836B-B821B39D0467@oracle.com>
 <ddb8b1ae-3f12-ca7e-4541-7e656916eb01@redhat.com>
 <88088fa8-90af-d949-2ae5-d57a54fdea9a@oracle.com>
 <8cb51914-3020-f13d-b1e8-53f663f75a9b@oracle.com>
 <850f7694-ce3b-40b5-a3d1-907bdd64ec84@redhat.com>
 <10a42a39-1f8f-ee49-d558-9f99d055344d@Oracle.com>
 <1cb03689-dabd-de9d-5905-8a561b2bab7f@redhat.com>
Message-ID: <CAP7YuARBE1LHPr26HF2w9D7NW4Nx=ht4imytBNmOjkH-VPrW+A@mail.gmail.com>

We can run a JCK test on the Adopt build farm as an early sanity check.
I?ll liaise with Alekseyvon this- it?s the perfect use case for it!

On Thu, 18 Jan 2018 at 22:15, Aleksey Shipilev <shade at redhat.com> wrote:

> Hi Roger,
>
> On 01/18/2018 02:56 PM, Roger Riggs wrote:
> > Does the entire test suite pass with this collector?
> > In spite of Andrew's point, there are numerous tests of behavior that
> are effects/side effects of
> > collectors that will fail. Does the JCK pass with this option (the all
> modes rule).
>
> Haven't tried JCK with it. Epsilon comes with its own set of bounded
> allocation tests.
>
> I don't think "all modes rule" applies to every single JVM mode? The
> applicability seems to heavily
> depend on the flavor of the UseEpsilonGC/UseNoGC option. Currently it is
> "develop", so it is not
> even available in product builds, and therefore JCK does not apply?
>
> My view is that elevating this to "diagnostic" is also safe, because we do
> not provide reliability
> and compatibility guarantees for those. Ditto for "experimental", although
> GC guys have
> interpretation of it different from the definition in globals.hpp. If we
> do it as "product" option,
> only then JCK would start to apply, right?
>
> > It would be bad form to commit a change that causes a large number of
> regular tests to fail.
>
> Sure. And we would need to exercise judgment in what tests to apply to
> which features.
>
> -Aleksey
>
> --
Cheers, Martijn (Sent from Gmail Mobile)

From Alan.Bateman at oracle.com  Thu Jan 18 16:08:19 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Jan 2018 16:08:19 +0000
Subject: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails
 with java.lang.AssertionError: HelpFlagsTest failed:
In-Reply-To: <b15953a0b9c640a49d62bcb4ca5f3ee5@sap.com>
References: <b15953a0b9c640a49d62bcb4ca5f3ee5@sap.com>
Message-ID: <cb2420bd-b2ae-828d-842f-dc2f2d0c2bbd@oracle.com>

On 18/01/2018 15:37, Lindenmaier, Goetz wrote:
> :
>
> What list should this be reviewed on? I just posted to jdk-dev for now.
>
core-libs-dev is best for java launcher and its tests.

-Alan

From goetz.lindenmaier at sap.com  Thu Jan 18 16:24:45 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 18 Jan 2018 16:24:45 +0000
Subject: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails
 with java.lang.AssertionError: HelpFlagsTest failed:
In-Reply-To: <45e66d48b4224ef8a5342d8b64a2b24c@sap.com>
References: <b15953a0b9c640a49d62bcb4ca5f3ee5@sap.com>
 <19A6164F-1766-4C30-8A34-05B1185D9525@oracle.com>
 <45e66d48b4224ef8a5342d8b64a2b24c@sap.com>
Message-ID: <acceeebcd63e4ceba3e35c8e4f7e8fa9@sap.com>

Posting this to core-libs-dev.

Please review 
http://cr.openjdk.java.net/~goetz/wr18/8195663-fixHelpTest/webrev.02/
which excludes the Oracle proprietary tools from the test.
I can not verify this.

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of
> Lindenmaier, Goetz
> Sent: Donnerstag, 18. Januar 2018 17:02
> To: Weijun Wang <weijun.wang at oracle.com>
> Cc: jdk-dev at openjdk.java.net
> Subject: RE: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails
> with java.lang.AssertionError: HelpFlagsTest failed:
> 
> Hi,
> 
> Added ssvagent:
> http://cr.openjdk.java.net/~goetz/wr18/8195663-fixHelpTest/webrev.02/
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: Weijun Wang [mailto:weijun.wang at oracle.com]
> > Sent: Donnerstag, 18. Januar 2018 16:44
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Cc: Kumar Srinivasan <kumar.x.srinivasan at oracle.com>; jdk-
> > dev at openjdk.java.net
> > Subject: Re: RFR(XS): 8195663: jdk/tools/launcher/HelpFlagsTest.java fails
> > with java.lang.AssertionError: HelpFlagsTest failed:
> >
> > On Windows, there is also a ssvagent.exe.
> >
> > > On Jan 18, 2018, at 11:37 PM, Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com> wrote:
> > >
> > > Hi,
> > >
> > > the most simple fix is to just exclude the four tools:
> > > http://cr.openjdk.java.net/~goetz/wr18/8195663-
> fixHelpTest/webrev.01/
> > > Unfortunately I can't test this, as my build does not contain these
> > > tools.
> > >
> > > If somebody tells me how to build these tools, I will adapt
> > > the test to check them, and eventually adapt the tools to
> > > CSR 8191477 https://bugs.openjdk.java.net/browse/JDK-8191477.
> > >
> > > What list should this be reviewed on? I just posted to jdk-dev for now.
> > >
> > > Best regards,
> > >  Goetz.


From joe.darcy at oracle.com  Thu Jan 18 17:58:26 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 18 Jan 2018 09:58:26 -0800
Subject: [10] RFR: 8195478: sun/text/resources/LocaleDataTest.java fails
 with java.lang.Exception
In-Reply-To: <7a2b8500-34a3-b7f2-fe39-5e806b558142@oracle.com>
References: <c95b2e38-e1f0-aca2-e998-348ea442f1ec@oracle.com>
 <9e9e8ab0-d85c-b1ba-0a9d-610cf0dfcd6f@oracle.com>
 <12bf2f0d-c1cb-5cf0-a559-5e59311d9e98@oracle.com>
 <acb74257-ebf0-6913-d741-7d801447cc60@oracle.com>
 <7a2b8500-34a3-b7f2-fe39-5e806b558142@oracle.com>
Message-ID: <0b677472-9a12-5b3e-9837-88c66a067bfe@oracle.com>

In general, if you've pushed to JDK 10, you don't need to do anything 
else since there will be 10 -> 11 sync which will propagate the fix into 11.

HTH,

-Joe


On 1/17/2018 7:56 PM, Hamlin Li wrote:
> Hi Naoto,
>
> I have pushed the code change to http://hg.openjdk.java.net/jdk/jdk10, 
> I think I need to push to 11 (http://hg.openjdk.java.net/jdk/jdk) too. 
> Do I need to send out for review again?
>
> Thank you
>
> -Hamlin
>


From aph at redhat.com  Thu Jan 18 17:59:58 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 18 Jan 2018 17:59:58 +0000
Subject: Using Intellij IDEA with current JDK
In-Reply-To: <CANghgrQ4meHSX6x3t5Md+Gir=Oq5v89rbmFAyb8kJ82swAmEFw@mail.gmail.com>
References: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>
 <CANghgrQ4meHSX6x3t5Md+Gir=Oq5v89rbmFAyb8kJ82swAmEFw@mail.gmail.com>
Message-ID: <5ff3eb77-8639-4b1d-52e5-ad961e47af9f@redhat.com>

On 17/01/18 17:47, David Lloyd wrote:
> What I've done is to force no JDK at all.  It does present an ugly
> banner[1] at the top but otherwise it seems to work fine - or did,
> until the latest update[2].  If you've already set up a SDK, I think
> there's no way to unset it, so you have to close IDEA, edit your
> xxx.ipr or .idea/modules.xml (I think) and delete the line which
> defines the SDK.

OK, I see.  It works, kinda-sorta, but navigation is pretty useless,
and everything is covered with red squiggles.

> [1] See also: https://youtrack.jetbrains.com/issue/IDEA-142878
> [2] The error I see at present is of the type "Package 'java.lang' is
> in the unnamed module, but module 'jdk.compiler' does not read it".
> Previously I had excluded module-info.java from all source roots, but
> the latest update somehow determines that everything are Java 9
> modules anyway.  I had done this for two reasons: firstly, there are
> not module descriptors in every place where there are sources (for
> example, having a separate "java.base:share" and "java.base:unix" IDEA
> module causes problems because :share has a module-info.java but :unix
> does not), and secondly, IDEA does not cope well with situations where
> there is more than one module-info.java (for example if one is
> generated from the other) or if it is simply generated to begin with.
> Sigh.

OK, I'm starting to understand some of the problems.  Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Thu Jan 18 18:21:16 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 18 Jan 2018 18:21:16 +0000
Subject: Using Intellij IDEA with current JDK
In-Reply-To: <fe9bb82b-8b82-f1d1-88d0-c7f21ca92c99@oracle.com>
References: <0f705d35-55d7-6680-101b-05c1b3c38fac@redhat.com>
 <1c13cd8f-706e-83a3-cd25-cef02025edcf@oracle.com>
 <12544efa-0d23-d88f-3bb2-f7971a30761c@oracle.com>
 <fe9bb82b-8b82-f1d1-88d0-c7f21ca92c99@oracle.com>
Message-ID: <d430f2aa-c4ea-3b6b-15c8-0a46df4ed79c@redhat.com>

On 17/01/18 21:22, Maurizio Cimadamore wrote:
> https://youtrack.jetbrains.com/issue/IDEA-183920
> 
> Says it should be in 2017.3.2, which is what I've got, so I think an 
> update should fix the problem for you.

That one looks better, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From mark.reinhold at oracle.com  Thu Jan 18 21:46:27 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 18 Jan 2018 13:46:27 -0800
Subject: JEP proposed to target JDK 11: 320: Remove the Java EE and CORBA
 Modules
Message-ID: <20180118134627.727353590@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 11:

  320: Remove the Java EE and CORBA Modules
       http://openjdk.java.net/jeps/320

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Thursday,
25 January, or if they're raised and then satisfactorily answered, then
per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Thu Jan 18 23:01:55 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 18 Jan 2018 15:01:55 -0800
Subject: JEP proposed to target JDK 11: 318: Epsilon: An Arbitrarily
 Low-Overhead Garbage Collector
In-Reply-To: <20180111134627.676325789@eggemoggin.niobe.net>
References: <20180111134627.676325789@eggemoggin.niobe.net>
Message-ID: <20180118150155.897332765@eggemoggin.niobe.net>

2018/1/11 13:46:27 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector
>        http://openjdk.java.net/jeps/318
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 18 January, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.

Hearing no objection to the feature itself, I've targeted this JEP
to JDK 11.

Further bikeshedding of option names, debug vs. product status, and
related issues can take place on hotspot-gc-dev during code review.

- Mark

From mark.reinhold at oracle.com  Thu Jan 18 23:06:54 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 18 Jan 2018 15:06:54 -0800
Subject: JDK 10 Rampdown Phase Two: Process proposal
In-Reply-To: <20180111224743.8FE16146C3E@eggemoggin.niobe.net>
References: <20180111224743.8FE16146C3E@eggemoggin.niobe.net>
Message-ID: <20180118150654.465440426@eggemoggin.niobe.net>

2018/1/11 14:47:43 -0800, mark.reinhold at oracle.com:
> Per the JDK 10 schedule [1], we'll enter Rampdown Phase Two next week,
> on Thursday, 18 January.
> 
> The goal of this phase is the same as it was for JDK 9: Ensure that we
> fix the bugs that must be fixed in order to ensure a successful release,
> and understand why we're not going to fix some bugs that perhaps ought to
> be fixed.
> 
> I propose that we use the same process as for JDK 9.  I've drafted pages
> for RDP 2 and the fix-request process and posted them here:
> 
>   http://openjdk.java.net/projects/jdk/10/rdp-2
>   http://openjdk.java.net/projects/jdk/10/fix-request-process
> 
> This phase will run for three weeks, until 8 February, when we'll produce
> an initial Release Candidate build and enter the Release Candidate phase.
> 
> JDK Committers are invited to comment on this process proposal.  If no
> objections are raised in one week's time, by 23:00 UTC next Thursday,
> 18 January, then this is the process that we'll use.

Hearing no objections, these are the processes that we'll use for JDK 10
Rampdown Phase Two.

- Mark

From adinn at redhat.com  Fri Jan 19 18:24:12 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 19 Jan 2018 18:24:12 +0000
Subject: RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962
Message-ID: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>

The following critical patch fixes 8195685 for the latest jdkdev/jdk
tree and also jdkdev/jdk10, making it possible to run any JVM built form
them on AArch64

issue: https://bugs.openjdk.java.net/browse/JDK-8195685
webrev: http://cr.openjdk.java.net/~adinn/8195685/webrev

The patch applies cleanly to jdk10 and really needs to be pushed in
before it is frozen as it is a complete show-stopper for the AArch64 port.

Quick reviews would be welcome.

What is essentially the same patch is also needed to fix the jdk9 tree
that was used to build Oracle's 9.0.4. Here is the alternative jdk9
webrev needed to allow for different src tree layout.

jdk9u webrev: http://cr.openjdk.java.net/~adinn/8195685.jdk9

Note that the jdk9u patch is currently against the same issue as the
jdkdev patch. I don't know what to do about the official backport
process for this. Whatever need to be done is it possible to expedite
any admin process for backporting? Red Hat need this fix to get our
Fedora jdk9 AArch64 release out the door.

Testing:
The patch allows aarch64 to run a variety of simple programs where
previously it crashed almost immediately. It is essentially the same
code as was added to Red Hat's latest released jdk8 AArch64 build.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


From aph at redhat.com  Fri Jan 19 18:48:46 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Jan 2018 18:48:46 +0000
Subject: RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962
In-Reply-To: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
Message-ID: <a74ded8c-4671-9e14-208c-03c3ef845a3b@redhat.com>

On 19/01/18 18:24, Andrew Dinn wrote:
> issue: https://bugs.openjdk.java.net/browse/JDK-8195685
> webrev: http://cr.openjdk.java.net/~adinn/8195685/webrev
> 
> The patch applies cleanly to jdk10 and really needs to be pushed in
> before it is frozen as it is a complete show-stopper for the AArch64 port.
> 
> Quick reviews would be welcome.

Looks OK, thanks.

BTW, shouldn't I be in the webrev as the author?  It looks very
much like my jdk8 patch.  :-)

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From jesper.wilhelmsson at oracle.com  Fri Jan 19 19:01:09 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 19 Jan 2018 20:01:09 +0100
Subject: RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962
In-Reply-To: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
Message-ID: <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>

Hi Andrew,

Please note that we are now in RDP2 and there is a process to follow to include the fix: http://openjdk.java.net/projects/jdk/10/rdp-2 <http://openjdk.java.net/projects/jdk/10/rdp-2>

In particular you need to add the label jdk10-fix-request to the JBS issue to alert the release team about this bug. If not they don't know that they have to wait for your fix to get done.

Please don't just add the label though, there is more to it.

Thanks,
/Jesper

> On 19 Jan 2018, at 19:24, Andrew Dinn <adinn at redhat.com> wrote:
> 
> The following critical patch fixes 8195685 for the latest jdkdev/jdk
> tree and also jdkdev/jdk10, making it possible to run any JVM built form
> them on AArch64
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8195685
> webrev: http://cr.openjdk.java.net/~adinn/8195685/webrev
> 
> The patch applies cleanly to jdk10 and really needs to be pushed in
> before it is frozen as it is a complete show-stopper for the AArch64 port.
> 
> Quick reviews would be welcome.
> 
> What is essentially the same patch is also needed to fix the jdk9 tree
> that was used to build Oracle's 9.0.4. Here is the alternative jdk9
> webrev needed to allow for different src tree layout.
> 
> jdk9u webrev: http://cr.openjdk.java.net/~adinn/8195685.jdk9
> 
> Note that the jdk9u patch is currently against the same issue as the
> jdkdev patch. I don't know what to do about the official backport
> process for this. Whatever need to be done is it possible to expedite
> any admin process for backporting? Red Hat need this fix to get our
> Fedora jdk9 AArch64 release out the door.
> 
> Testing:
> The patch allows aarch64 to run a variety of simple programs where
> previously it crashed almost immediately. It is essentially the same
> code as was added to Red Hat's latest released jdk8 AArch64 build.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 


From aph at redhat.com  Fri Jan 19 19:11:51 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Jan 2018 19:11:51 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
Message-ID: <b5878209-2844-002f-fbca-b873eefd0a6b@redhat.com>

On 19/01/18 19:01, jesper.wilhelmsson at oracle.com wrote:
> In particular you need to add the label jdk10-fix-request to the JBS issue to alert the release team about this bug. If not they don't know that they have to wait for your fix to get done.
> 
> Please don't just add the label though, there is more to it.

OK.  Please help us get this done.  It's an essential fix to the
broken build caused by the fix for 8174962, so we don't have any
choice.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From alex.buckley at oracle.com  Fri Jan 19 19:52:55 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 19 Jan 2018 11:52:55 -0800
Subject: Draft JEP: Incubating Language and VM Features
Message-ID: <5A624C97.3020408@oracle.com>

Many of you are familiar with Incubator Modules from JEP 11. They let us 
ship "incubating" APIs in mainline JDK releases so that we can gather 
feedback from the largest possible pool of developers.

We've been thinking about the idea of having "incubating" features in 
the Java language and the JVM, again with the aim of maximizing 
feedback. To be clear, these would be full-fledged features of the Java 
SE Platform, in contrast to the JDK-specific nature of incubating APIs.

The draft JEP below explains our thinking. Like JEP 11, it's an 
Informational JEP rather than a Feature JEP because it outlines 
policy/principles rather than a concrete feature. Your comments are welcome.

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

Alex

From mark.reinhold at oracle.com  Fri Jan 19 20:46:59 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 19 Jan 2018 12:46:59 -0800
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <b5878209-2844-002f-fbca-b873eefd0a6b@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
 <b5878209-2844-002f-fbca-b873eefd0a6b@redhat.com>
Message-ID: <20180119124659.605005491@eggemoggin.niobe.net>

2018/1/19 11:11:51 -0800, aph at redhat.com:
> On 19/01/18 19:01, jesper.wilhelmsson at oracle.com wrote:
>> In particular you need to add the label jdk10-fix-request to the JBS issue to alert the release team about this bug. If not they don't know that they have to wait for your fix to get done.
>> 
>> Please don't just add the label though, there is more to it.
> 
> OK.  Please help us get this done.  It's an essential fix to the
> broken build caused by the fix for 8174962, so we don't have any
> choice.

The fix-request process is defined here:

  http://openjdk.java.net/projects/jdk/10/fix-request-process

- Mark

From mark.reinhold at oracle.com  Fri Jan 19 20:53:57 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 19 Jan 2018 12:53:57 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A624C97.3020408@oracle.com>
References: <5A624C97.3020408@oracle.com>
Message-ID: <20180119125357.776212892@eggemoggin.niobe.net>

2018/1/19 11:52:55 -0800, alex.buckley at oracle.com:
> ...
> 
>    https://bugs.openjdk.java.net/browse/JDK-8195734

Or, in an easier-to-read format:

  http://openjdk.java.net/jeps/8195734

- Mark

From forax at univ-mlv.fr  Fri Jan 19 23:39:11 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 20 Jan 2018 00:39:11 +0100 (CET)
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <20180119125357.776212892@eggemoggin.niobe.net>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
Message-ID: <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>

I like the whole idea, solving the problem of new features not being enough tested is a good idea but the the way the experimental flag is set is like asking for trouble.

The JEP goes into a great length to say that we only need a bit of information to mark a classfile as experimental, then explain that the way to set this experimental bit is to change semantics of the classfile version i.e. current classfile versions that support jdk 10 are the version <= 0x00360000 and it will becomes the version <= 0x0036ffff.

In section 4.1 of the JVMS,
  Oracle's Java Virtual Machine implementation in JDK release 1.0.2 supports class file format versions 45.0 through 45.3 inclusive. JDK releases 1.1.* support class file format versions in the range 45.0 through 45.65535 inclusive. For k ? 2, JDK release 1.k supports class file format versions in the range 45.0 through 44+k.0 inclusive. 
has to be changed to
  Oracle's Java Virtual Machine implementation in JDK release 1.0.2 supports class file format versions 45.0 through 45.3 inclusive. JDK releases 1.1.* support class file format versions in the range 45.0 through 45.65535 inclusive. For 2 <= k >= 10, JDK release 1.k supports class file format versions in the range 45.0 through 44+k.0 inclusive. for k >= 11, JDK release 1.k supports class file format versions in the range 55.0 through 44+k.65535   

Changing the semantics of the classfile version means changing all the libraries that deals with bytecode but more importantly, it also means changing all the tools that use these libraries because usually the semantics is not used by the bytecode libraries but by the code that use them.

Furthermore, the text of the JEP says that no access flags are available, this is not true, 
here are the access_flags defined (again section 4.1 of the JVMS)
  ACC_PUBLIC 	  0x0001 Declared public; may be accessed from outside its package.
  ACC_FINAL 	  0x0010 Declared final; no subclasses allowed.
  ACC_SUPER 	  0x0020 Treat superclass methods specially when invoked by the invokespecial instruction.
  ACC_INTERFACE   0x0200 Is an interface, not a class.
  ACC_ABSTRACT 	  0x0400 Declared abstract; must not be instantiated.
  ACC_SYNTHETIC   0x1000 Declared synthetic; not present in the source code.
  ACC_ANNOTATION  0x2000 Declared as an annotation type.
  ACC_ENUM 	  0x4000 Declared as an enum type.
  ACC_MODULE 	  0x8000 Is a module, not a class or interface.

so 0x0002, 0x0004, 0x0008, 0x0040, 0x0080, 0x0100, 0x0800 are free, and you can also use combinations.

You can also add a new empty class attribute "Experimental" exactly like Deprecated is a class attribute,
we do not care about the size of the attribute given that the class is an experimental class, so 99.99..% of the classes will be marked experimental. 

So let's all agree that this is nice JEP and that the way to mark a class experimental is to add an attribute Experimental to the classfile.

regards,
R?mi 

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> ?: "Alex Buckley" <alex.buckley at oracle.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Vendredi 19 Janvier 2018 21:53:57
> Objet: Re: Draft JEP: Incubating Language and VM Features

> 2018/1/19 11:52:55 -0800, alex.buckley at oracle.com:
>> ...
>> 
>>    https://bugs.openjdk.java.net/browse/JDK-8195734
> 
> Or, in an easier-to-read format:
> 
>  http://openjdk.java.net/jeps/8195734
> 
> - Mark

From john.r.rose at oracle.com  Sat Jan 20 00:24:03 2018
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 19 Jan 2018 16:24:03 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
Message-ID: <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>

On Jan 19, 2018, at 3:39 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> So let's all agree that this is nice JEP and that the way to mark a class experimental is to add an attribute Experimental to the classfile.

Remi, you are glossing over a big point here:  We are going to be experimenting
with constant pool formats.  You can't read the access_flags or any attributes
until you have parsed the constant pool.  It is unreasonable to parse the constant
pool before you know whether it is allowed to have experimental features in it.
This leaves the magic number, major and minor versions, and the CP length
itself as channels to carry the experimental bit.  Of those, the most reasonable
and intuitive is the minor version.

So it's the minor version.  Next question:  What bit pattern?  Best answer,
AFAIK is to reserve one bit and concentrate on that.  That leaves the other
minor version bits untouched and free for other uses.

Next question:  Does anybody actually *use* the minor version bits?  The
spec suggests they were in play once, but I have *never* seen anybody use
them to carry information in modern versions of Java.  If those 16 bits are
always zero, then clearly we can steal one of them.  And I think we have
both the habit and the right of declaring that they must be zero and are
reserved for future extensions, such as an experimental flag.

? John

P.S. In fact (separate conversation) I would like to reserve *another* minor
version bit to denote "private use plane", meaning that projects like
Valhalla can mark their prototype classfiles using the minor version
in such a way that there is guaranteed to be never any standard JVM
that will ever load those prototype classfiles.


From Derek.White at cavium.com  Sat Jan 20 01:06:33 2018
From: Derek.White at cavium.com (White, Derek)
Date: Sat, 20 Jan 2018 01:06:33 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <20180119124659.605005491@eggemoggin.niobe.net>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
 <b5878209-2844-002f-fbca-b873eefd0a6b@redhat.com>
 <20180119124659.605005491@eggemoggin.niobe.net>
Message-ID: <CY1PR0701MB1632A2C08E8D6ECFB482C3B784EE0@CY1PR0701MB1632.namprd07.prod.outlook.com>

Hi Mark,

Just a suggestion for future versions of the "Fix-Request Process":
 - I'd think that for port-specific patches (like this one), the Porting Lead should be consulted as the expert on this part of code base. 

Maybe Dalibor is the representative of all of the Porters, but you have this funny situation where Andrew has to ask Dalibor to review, who will likely defer back to Andrew.

Just a thought!

 -Derek

> -----Original Message-----
> From: aarch64-port-dev [mailto:aarch64-port-dev-
> bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com
> Sent: Friday, January 19, 2018 3:47 PM
> To: Andrew Haley <aph at redhat.com>
> Cc: jesper.wilhelmsson at oracle.com; jdk-dev at openjdk.java.net; aarch64-
> port-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot
> build with JDK-8174962
> 
> 2018/1/19 11:11:51 -0800, aph at redhat.com:
> > On 19/01/18 19:01, jesper.wilhelmsson at oracle.com wrote:
> >> In particular you need to add the label jdk10-fix-request to the JBS issue to
> alert the release team about this bug. If not they don't know that they have
> to wait for your fix to get done.
> >>
> >> Please don't just add the label though, there is more to it.
> >
> > OK.  Please help us get this done.  It's an essential fix to the
> > broken build caused by the fix for 8174962, so we don't have any
> > choice.
> 
> The fix-request process is defined here:
> 
>   http://openjdk.java.net/projects/jdk/10/fix-request-process
> 
> - Mark

From alex.buckley at oracle.com  Sat Jan 20 01:04:48 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 19 Jan 2018 17:04:48 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
Message-ID: <5A6295B0.8040506@oracle.com>

"Incubation is not a mechanism for experimentation and risk-taking."

An incubating feature has evolved beyond a successful experiment. We're 
sure enough of its scope and quality to commit it to the Java SE 
Platform. Any number of the mature language features in recent years 
could have been incubated to get that last ounce of feedback from 
developers. Yes, we have to admit the possibility that an incubating 
feature might be dropped -- "Sounds like a failed experiment!", I hear 
you cry -- but there is no sense with an incubating feature of 
tinkering, rough edges, version 0.1 quality, unsupported status, etc.

Alex

On 1/19/2018 3:39 PM, Remi Forax wrote:
> I like the whole idea, solving the problem of new features not being
> enough tested is a good idea but the the way the experimental flag is
> set is like asking for trouble.
>
> The JEP goes into a great length to say that we only need a bit of
> information to mark a classfile as experimental, then explain that
> the way to set this experimental bit is to change semantics of the
> classfile version i.e. current classfile versions that support jdk 10
> are the version <= 0x00360000 and it will becomes the version <=
> 0x0036ffff.
>
> You can also add a new empty class attribute "Experimental" exactly
> like Deprecated is a class attribute, we do not care about the size
> of the attribute given that the class is an experimental class, so
> 99.99..% of the classes will be marked experimental.
>
> So let's all agree that this is nice JEP and that the way to mark a
> class experimental is to add an attribute Experimental to the
> classfile.

From fridrich.strba at suse.com  Sat Jan 20 05:14:58 2018
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Sat, 20 Jan 2018 06:14:58 +0100
Subject: =?US-ASCII?Q?Re:_[aarch64-port-dev_]_RFR:_8195685:_AArc?=
 =?US-ASCII?Q?h64:_AArch64_cannot=0D_=09build=09with_JDK-8174962?=
Message-ID: <q7fbct9ukcn5foeusmyj06ub.1516425298382@email.android.com>

Just a heads up that this particular commit broke even the Zero build. I have no right to comment in bugzilla, so stating it here.
F.


Sent from my Samsung Galaxy smartphone.-------- Original message --------From: "White, Derek" <Derek.White at cavium.com> Date: 20/01/2018  02:06  (GMT+01:00) To: mark.reinhold at oracle.com, Andrew Haley <aph at redhat.com> Cc: jesper.wilhelmsson at oracle.com, jdk-dev at openjdk.java.net, aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot
 	build	with JDK-8174962 
Hi Mark,

Just a suggestion for future versions of the "Fix-Request Process":
 - I'd think that for port-specific patches (like this one), the Porting Lead should be consulted as the expert on this part of code base. 

Maybe Dalibor is the representative of all of the Porters, but you have this funny situation where Andrew has to ask Dalibor to review, who will likely defer back to Andrew.

Just a thought!

 -Derek

> -----Original Message-----
> From: aarch64-port-dev [mailto:aarch64-port-dev-
> bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com
> Sent: Friday, January 19, 2018 3:47 PM
> To: Andrew Haley <aph at redhat.com>
> Cc: jesper.wilhelmsson at oracle.com; jdk-dev at openjdk.java.net; aarch64-
> port-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot
> build with JDK-8174962
> 
> 2018/1/19 11:11:51 -0800, aph at redhat.com:
> > On 19/01/18 19:01, jesper.wilhelmsson at oracle.com wrote:
> >> In particular you need to add the label jdk10-fix-request to the JBS issue to
> alert the release team about this bug. If not they don't know that they have
> to wait for your fix to get done.
> >>
> >> Please don't just add the label though, there is more to it.
> >
> > OK.? Please help us get this done.? It's an essential fix to the
> > broken build caused by the fix for 8174962, so we don't have any
> > choice.
> 
> The fix-request process is defined here:
> 
>?? http://openjdk.java.net/projects/jdk/10/fix-request-process
> 
> - Mark


From aph at redhat.com  Sat Jan 20 09:17:16 2018
From: aph at redhat.com (Andrew Haley)
Date: Sat, 20 Jan 2018 09:17:16 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <q7fbct9ukcn5foeusmyj06ub.1516425298382@email.android.com>
References: <q7fbct9ukcn5foeusmyj06ub.1516425298382@email.android.com>
Message-ID: <2ba79522-b459-e3bd-25a0-f85e77d38054@redhat.com>

On 20/01/18 05:14, Fridrich Strba wrote:
> Just a heads up that this particular commit broke even the Zero build. I have no right to comment in bugzilla, so stating it here.

Yeah, we know.  We have a patch for that too.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Sat Jan 20 11:54:53 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Sat, 20 Jan 2018 11:54:53 +0000
Subject: RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962
In-Reply-To: <a74ded8c-4671-9e14-208c-03c3ef845a3b@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <a74ded8c-4671-9e14-208c-03c3ef845a3b@redhat.com>
Message-ID: <97154783-f499-a566-4bfe-2405fa7613f4@redhat.com>

On 19/01/18 18:48, Andrew Haley wrote:
> On 19/01/18 18:24, Andrew Dinn wrote:
>> issue: https://bugs.openjdk.java.net/browse/JDK-8195685
>> webrev: http://cr.openjdk.java.net/~adinn/8195685/webrev
>>
>> The patch applies cleanly to jdk10 and really needs to be pushed in
>> before it is frozen as it is a complete show-stopper for the AArch64 port.
>>
>> Quick reviews would be welcome.
> 
> Looks OK, thanks.

Thank you for the review.

> BTW, shouldn't I be in the webrev as the author?  It looks very
> much like my jdk8 patch.  :-)
Yes indeed it is essentially your patch. I actually went through each of
the x86 changes myself making corrections line by line and -- lo and
behold -- produced exactly the same result for jdkdev/jdk, jdk10 and
jdk9 (call me Pierre Menard, author of the Quixote). I admit I may
possibly have had your jdk8 patch beside me for reference :-)

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From forax at univ-mlv.fr  Sat Jan 20 12:13:10 2018
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 20 Jan 2018 13:13:10 +0100 (CET)
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
Message-ID: <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" <john.r.rose at oracle.com>
> ?: "R?mi Forax" <forax at univ-mlv.fr>
> Cc: "Alex Buckley" <alex.buckley at oracle.com>, "jdk-dev"
> <jdk-dev at openjdk.java.net>
> Envoy?: Samedi 20 Janvier 2018 01:24:03
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On Jan 19, 2018, at 3:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> So let's all agree that this is nice JEP and that the way to mark a class
>> experimental is to add an attribute Experimental to the classfile.

> Remi, you are glossing over a big point here: We are going to be experimenting
> with constant pool formats. You can't read the access_flags or any attributes
> until you have parsed the constant pool.

Ok, better explanation that no access_flags left. 

But the classfile format has been designed to be extensible, which means that even if a VM doesn't know a constant pool attribute, it knows that this is an unknown constant pool attribute because the attribute tag is unknown, so a VM doesn't support experimental features will reject the classfile. 

A VM that doesn't support experimental features doesn't have to support new constant pool attributes while parsing the constant pool, it just have to reject the class because it doesn't support it which is already mandated by the current vm spec. 

> It is unreasonable to parse the constant
> pool before you know whether it is allowed to have experimental features in it.

I disagree, for a VM that support experimental features, i find it reasonable to parse the constant pool with the new attributes given that if the class is not marked as experimental, an error will be thrown. 
it's just a belt and braces approach. You do not have to just support the constant pool attribute, you also have to have the class attribute Experimental. 

> This leaves the magic number, major and minor versions, and the CP length
> itself as channels to carry the experimental bit. Of those, the most reasonable
> and intuitive is the minor version.

if you put yourself in a corner, then changing the minor version is the best you can do, but you do not have to go to that corner in the first place. 

The classfile format has been designed to be extensible, we should rely on it. 

> So it's the minor version. Next question: What bit pattern? Best answer,
> AFAIK is to reserve one bit and concentrate on that. That leaves the other
> minor version bits untouched and free for other uses.

> Next question: Does anybody actually *use* the minor version bits? The
> spec suggests they were in play once, but I have *never* seen anybody use
> them to carry information in modern versions of Java. If those 16 bits are
> always zero, then clearly we can steal one of them. And I think we have
> both the habit and the right of declaring that they must be zero and are
> reserved for future extensions, such as an experimental flag.

Changing the semantics of minor_version has a high cost, mostly because major_version and minor_version are seen as one unique integer, so changing the semantics of the minor_version implies changing the semantics of the classfile version. 

> ? John

R?mi 

> P.S. In fact (separate conversation) I would like to reserve *another* minor
> version bit to denote "private use plane", meaning that projects like
> Valhalla can mark their prototype classfiles using the minor version
> in such a way that there is guaranteed to be never any standard JVM
> that will ever load those prototype classfiles.

From adinn at redhat.com  Sat Jan 20 12:14:07 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Sat, 20 Jan 2018 12:14:07 +0000
Subject: RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962
In-Reply-To: <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
Message-ID: <2da9653a-43fe-939a-9c85-17c0d545d39b@redhat.com>

Hi Jesper,

On 19/01/18 19:01, jesper.wilhelmsson at oracle.com wrote:
> Please note that we are now in RDP2 and there is a process to follow to
> include the fix:?http://openjdk.java.net/projects/jdk/10/rdp-2
> 
> In particular you need to add the label?jdk10-fix-request to the JBS
> issue to alert the release team about this bug. If not they don't know
> that they have to wait for your fix to get done.
> 
> Please don't just add the label though, there is more to it.
I have added the label and a Fix Request comment to the JIRA and linked
the webrev to it.

regards,


Andrew Dinn
-----------


From david.holmes at oracle.com  Sat Jan 20 23:19:03 2018
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 21 Jan 2018 09:19:03 +1000
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
Message-ID: <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>

On 20/01/2018 10:13 PM, forax at univ-mlv.fr wrote:
>> De: "John Rose" <john.r.rose at oracle.com>
>> ?: "R?mi Forax" <forax at univ-mlv.fr>
>> Cc: "Alex Buckley" <alex.buckley at oracle.com>, "jdk-dev"
>> <jdk-dev at openjdk.java.net>
>> Envoy?: Samedi 20 Janvier 2018 01:24:03
>> Objet: Re: Draft JEP: Incubating Language and VM Features
> 
>> On Jan 19, 2018, at 3:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:
> 
>>> So let's all agree that this is nice JEP and that the way to mark a class
>>> experimental is to add an attribute Experimental to the classfile.
> 
>> Remi, you are glossing over a big point here: We are going to be experimenting
>> with constant pool formats. You can't read the access_flags or any attributes
>> until you have parsed the constant pool.
> 
> Ok, better explanation that no access_flags left.
> 
> But the classfile format has been designed to be extensible, which means that even if a VM doesn't know a constant pool attribute, it knows that this is an unknown constant pool attribute because the attribute tag is unknown, so a VM doesn't support experimental features will reject the classfile.

No it can't reject the classfile ...

> A VM that doesn't support experimental features doesn't have to support new constant pool attributes while parsing the constant pool, it just have to reject the class because it doesn't support it which is already mandated by the current vm spec.

JVMS 4.7.1: "Java Virtual Machine implementations are required to 
silently ignore attributes they do not recognize."

David
-----

>> It is unreasonable to parse the constant
>> pool before you know whether it is allowed to have experimental features in it.
> 
> I disagree, for a VM that support experimental features, i find it reasonable to parse the constant pool with the new attributes given that if the class is not marked as experimental, an error will be thrown.
> it's just a belt and braces approach. You do not have to just support the constant pool attribute, you also have to have the class attribute Experimental.
> 
>> This leaves the magic number, major and minor versions, and the CP length
>> itself as channels to carry the experimental bit. Of those, the most reasonable
>> and intuitive is the minor version.
> 
> if you put yourself in a corner, then changing the minor version is the best you can do, but you do not have to go to that corner in the first place.
> 
> The classfile format has been designed to be extensible, we should rely on it.
> 
>> So it's the minor version. Next question: What bit pattern? Best answer,
>> AFAIK is to reserve one bit and concentrate on that. That leaves the other
>> minor version bits untouched and free for other uses.
> 
>> Next question: Does anybody actually *use* the minor version bits? The
>> spec suggests they were in play once, but I have *never* seen anybody use
>> them to carry information in modern versions of Java. If those 16 bits are
>> always zero, then clearly we can steal one of them. And I think we have
>> both the habit and the right of declaring that they must be zero and are
>> reserved for future extensions, such as an experimental flag.
> 
> Changing the semantics of minor_version has a high cost, mostly because major_version and minor_version are seen as one unique integer, so changing the semantics of the minor_version implies changing the semantics of the classfile version.
> 
>> ? John
> 
> R?mi
> 
>> P.S. In fact (separate conversation) I would like to reserve *another* minor
>> version bit to denote "private use plane", meaning that projects like
>> Valhalla can mark their prototype classfiles using the minor version
>> in such a way that there is guaranteed to be never any standard JVM
>> that will ever load those prototype classfiles.

From forax at univ-mlv.fr  Sat Jan 20 23:33:38 2018
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 21 Jan 2018 00:33:38 +0100 (CET)
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
Message-ID: <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>

Hi David,

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> ?: forax at univ-mlv.fr, "John Rose" <john.r.rose at oracle.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Dimanche 21 Janvier 2018 00:19:03
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On 20/01/2018 10:13 PM, forax at univ-mlv.fr wrote:
>>> De: "John Rose" <john.r.rose at oracle.com>
>>> ?: "R?mi Forax" <forax at univ-mlv.fr>
>>> Cc: "Alex Buckley" <alex.buckley at oracle.com>, "jdk-dev"
>>> <jdk-dev at openjdk.java.net>
>>> Envoy?: Samedi 20 Janvier 2018 01:24:03
>>> Objet: Re: Draft JEP: Incubating Language and VM Features
>> 
>>> On Jan 19, 2018, at 3:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>>> forax at univ-mlv.fr ] > wrote:
>> 
>>>> So let's all agree that this is nice JEP and that the way to mark a class
>>>> experimental is to add an attribute Experimental to the classfile.
>> 
>>> Remi, you are glossing over a big point here: We are going to be experimenting
>>> with constant pool formats. You can't read the access_flags or any attributes
>>> until you have parsed the constant pool.
>> 
>> Ok, better explanation that no access_flags left.
>> 
>> But the classfile format has been designed to be extensible, which means that
>> even if a VM doesn't know a constant pool attribute, it knows that this is an
>> unknown constant pool attribute because the attribute tag is unknown, so a VM
>> doesn't support experimental features will reject the classfile.
> 
> No it can't reject the classfile ...
> 
>> A VM that doesn't support experimental features doesn't have to support new
>> constant pool attributes while parsing the constant pool, it just have to
>> reject the class because it doesn't support it which is already mandated by the
>> current vm spec.
> 
> JVMS 4.7.1: "Java Virtual Machine implementations are required to
> silently ignore attributes they do not recognize."

I have used the wrong word, instead of "unknown constant pool attribute", i should have use "unknown constant pool constant".
Unknown class/method/field attribute are required to be silently ignored as you point out, but you can not do that for constant pool constant because unlike an attribute which encode its size so you can skip it, a constant pool constant doesn't provide its size only the JVMS provides the association between the kind of a constant pool constant and its size.

I hope it's more clear now ?


> 
> David
> -----

R?mi

> 
>>> It is unreasonable to parse the constant
>>> pool before you know whether it is allowed to have experimental features in it.
>> 
>> I disagree, for a VM that support experimental features, i find it reasonable to
>> parse the constant pool with the new attributes given that if the class is not
>> marked as experimental, an error will be thrown.
>> it's just a belt and braces approach. You do not have to just support the
>> constant pool attribute, you also have to have the class attribute
>> Experimental.
>> 
>>> This leaves the magic number, major and minor versions, and the CP length
>>> itself as channels to carry the experimental bit. Of those, the most reasonable
>>> and intuitive is the minor version.
>> 
>> if you put yourself in a corner, then changing the minor version is the best you
>> can do, but you do not have to go to that corner in the first place.
>> 
>> The classfile format has been designed to be extensible, we should rely on it.
>> 
>>> So it's the minor version. Next question: What bit pattern? Best answer,
>>> AFAIK is to reserve one bit and concentrate on that. That leaves the other
>>> minor version bits untouched and free for other uses.
>> 
>>> Next question: Does anybody actually *use* the minor version bits? The
>>> spec suggests they were in play once, but I have *never* seen anybody use
>>> them to carry information in modern versions of Java. If those 16 bits are
>>> always zero, then clearly we can steal one of them. And I think we have
>>> both the habit and the right of declaring that they must be zero and are
>>> reserved for future extensions, such as an experimental flag.
>> 
>> Changing the semantics of minor_version has a high cost, mostly because
>> major_version and minor_version are seen as one unique integer, so changing the
>> semantics of the minor_version implies changing the semantics of the classfile
>> version.
>> 
>>> ? John
>> 
>> R?mi
>> 
>>> P.S. In fact (separate conversation) I would like to reserve *another* minor
>>> version bit to denote "private use plane", meaning that projects like
>>> Valhalla can mark their prototype classfiles using the minor version
>>> in such a way that there is guaranteed to be never any standard JVM
> >> that will ever load those prototype classfiles.

From aph at redhat.com  Sun Jan 21 13:22:13 2018
From: aph at redhat.com (Andrew Haley)
Date: Sun, 21 Jan 2018 13:22:13 +0000
Subject: RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962
In-Reply-To: <97154783-f499-a566-4bfe-2405fa7613f4@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <a74ded8c-4671-9e14-208c-03c3ef845a3b@redhat.com>
 <97154783-f499-a566-4bfe-2405fa7613f4@redhat.com>
Message-ID: <1d699853-1b40-a099-b169-feb0e84cd19d@redhat.com>

On 20/01/18 11:54, Andrew Dinn wrote:
>> BTW, shouldn't I be in the webrev as the author?  It looks very
>> much like my jdk8 patch.  :-)
>
> Yes indeed it is essentially your patch. I actually went through each of
> the x86 changes myself making corrections line by line and -- lo and
> behold -- produced exactly the same result for jdkdev/jdk, jdk10 and
> jdk9 (call me Pierre Menard, author of the Quixote). I admit I may
> possibly have had your jdk8 patch beside me for reference :-)

Aha!  So it's mine, but it's really yours.  Carry on, that man.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Sun Jan 21 16:25:05 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Sun, 21 Jan 2018 16:25:05 +0000
Subject: RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962
In-Reply-To: <2da9653a-43fe-939a-9c85-17c0d545d39b@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
 <2da9653a-43fe-939a-9c85-17c0d545d39b@redhat.com>
Message-ID: <8017db22-6dd7-2042-d178-38c23452ef75@redhat.com>

On 20/01/18 12:14, Andrew Dinn wrote:
> On 19/01/18 19:01, jesper.wilhelmsson at oracle.com wrote:
>> Please note that we are now in RDP2 and there is a process to follow to
>> include the fix:?http://openjdk.java.net/projects/jdk/10/rdp-2
>>
>> In particular you need to add the label?jdk10-fix-request to the JBS
>> issue to alert the release team about this bug. If not they don't know
>> that they have to wait for your fix to get done.
>>
>> Please don't just add the label though, there is more to it.
> I have added the label and a Fix Request comment to the JIRA and linked
> the webrev to it.
Vladimir kindly responded to this with an approval on the JIRA. I am
still not sure where to go from here though:

  Can I/do I need to push the patch to the dev tree or the jdk10 tree?

  What do I need to do to get the patch into the jdk-updates jdk9u tree?

I'm rather confused as regards jdk9u as there is no jdk9u-dev list to
post to in order to request a backport. Red Hat wants to patch its
downstream jdk9 repos but ideally this ought to go in upstream first.
Also, the 9.0.4 Oracle release (built by AdoptOpenJDK?) is broken on
AArhc64 so it really needs a respin after this patch has been included.

Thanks in advance for any help or advice that can be offered.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From tianxiao.gu at gmail.com  Sun Jan 21 22:05:18 2018
From: tianxiao.gu at gmail.com (Tianxiao Gu)
Date: Sun, 21 Jan 2018 14:05:18 -0800
Subject: jaotc Miscompilation
Message-ID: <CAJgZ6Z8hxgmm=HduiRM9Sn86OSBcEdWMYzWe_21fJ4hfsA87fA@mail.gmail.com>

Hi All,

I found a mis-compilation bug that can be reproduced in the master of
OpenJDK 9 (http://hg.openjdk.java.net/jdk9/jdk9/) and the latest Oracle JDK
9.0.4+11.

Can anyone help me to report this bug to developers of OpenJDK 9?

Description:

The AOT mode triggers a NegativeArraySizeException while the default mode
exits normally.

Input: C0.class (via Google Drive):

https://drive.google.com/open?id=17jN-4KFrs-apHlr2jkcDmP4OdA0ophWN

Reproduce Steps:

t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/jaotc
--output C0.so C0

t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
-XX:AOTLibrary=./C0.so C0

Exception in thread "main" java.lang.NegativeArraySizeException

at C0.main(Unknown Source)

t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
C0

t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *echo $?

0

t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
--version

java 9.0.4

Java(TM) SE Runtime Environment (build 9.0.4+11)

Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/jaotc
--version

jaotc 9.0.4+11

t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *

From tobias.hartmann at oracle.com  Sun Jan 21 23:11:44 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Sun, 21 Jan 2018 15:11:44 -0800
Subject: jaotc Miscompilation
In-Reply-To: <CAJgZ6Z8hxgmm=HduiRM9Sn86OSBcEdWMYzWe_21fJ4hfsA87fA@mail.gmail.com>
References: <CAJgZ6Z8hxgmm=HduiRM9Sn86OSBcEdWMYzWe_21fJ4hfsA87fA@mail.gmail.com>
Message-ID: <cdf94aeb-24b9-74a4-0ca3-8a38e62930ce@oracle.com>

[Adding hotspot-compiler-dev]

On 21.01.2018 14:05, Tianxiao Gu wrote:
> Hi All,
> 
> I found a mis-compilation bug that can be reproduced in the master of
> OpenJDK 9 (http://hg.openjdk.java.net/jdk9/jdk9/) and the latest Oracle JDK
> 9.0.4+11.
> 
> Can anyone help me to report this bug to developers of OpenJDK 9?
> 
> Description:
> 
> The AOT mode triggers a NegativeArraySizeException while the default mode
> exits normally.
> 
> Input: C0.class (via Google Drive):
> 
> https://drive.google.com/open?id=17jN-4KFrs-apHlr2jkcDmP4OdA0ophWN
> 
> Reproduce Steps:
> 
> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/jaotc
> --output C0.so C0
> 
> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
> -XX:AOTLibrary=./C0.so C0
> 
> Exception in thread "main" java.lang.NegativeArraySizeException
> 
> at C0.main(Unknown Source)
> 
> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
> C0
> 
> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *echo $?
> 
> 0
> 
> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
> --version
> 
> java 9.0.4
> 
> Java(TM) SE Runtime Environment (build 9.0.4+11)
> 
> Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
> 
> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/jaotc
> --version
> 
> jaotc 9.0.4+11
> 
> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *
> 

From igor.veresov at oracle.com  Mon Jan 22 00:36:54 2018
From: igor.veresov at oracle.com (Igor Veresov)
Date: Sun, 21 Jan 2018 16:36:54 -0800
Subject: jaotc Miscompilation
In-Reply-To: <cdf94aeb-24b9-74a4-0ca3-8a38e62930ce@oracle.com>
References: <CAJgZ6Z8hxgmm=HduiRM9Sn86OSBcEdWMYzWe_21fJ4hfsA87fA@mail.gmail.com>
 <cdf94aeb-24b9-74a4-0ca3-8a38e62930ce@oracle.com>
Message-ID: <80AC9F89-78F0-42F0-8CE7-46D84C065E81@oracle.com>

Doesn?t seem to reproduce for me with jdk10 (on macOS). Tianxiao, could you please try an early build of jdk10 to see if there is still a problem?

igor

> On Jan 21, 2018, at 3:11 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> [Adding hotspot-compiler-dev]
> 
> On 21.01.2018 14:05, Tianxiao Gu wrote:
>> Hi All,
>> 
>> I found a mis-compilation bug that can be reproduced in the master of
>> OpenJDK 9 (http://hg.openjdk.java.net/jdk9/jdk9/) and the latest Oracle JDK
>> 9.0.4+11.
>> 
>> Can anyone help me to report this bug to developers of OpenJDK 9?
>> 
>> Description:
>> 
>> The AOT mode triggers a NegativeArraySizeException while the default mode
>> exits normally.
>> 
>> Input: C0.class (via Google Drive):
>> 
>> https://drive.google.com/open?id=17jN-4KFrs-apHlr2jkcDmP4OdA0ophWN
>> 
>> Reproduce Steps:
>> 
>> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/jaotc
>> --output C0.so C0
>> 
>> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
>> -XX:AOTLibrary=./C0.so C0
>> 
>> Exception in thread "main" java.lang.NegativeArraySizeException
>> 
>> at C0.main(Unknown Source)
>> 
>> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
>> C0
>> 
>> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *echo $?
>> 
>> 0
>> 
>> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/java
>> --version
>> 
>> java 9.0.4
>> 
>> Java(TM) SE Runtime Environment (build 9.0.4+11)
>> 
>> Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
>> 
>> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *../../jdk-9.0.4/bin/jaotc
>> --version
>> 
>> jaotc 9.0.4+11
>> 
>> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *
>> 


From vladimir.kozlov at oracle.com  Mon Jan 22 03:24:00 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sun, 21 Jan 2018 19:24:00 -0800
Subject: RFR: 8195685: AArch64: AArch64 cannot build with JDK-8174962
In-Reply-To: <8017db22-6dd7-2042-d178-38c23452ef75@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
 <2da9653a-43fe-939a-9c85-17c0d545d39b@redhat.com>
 <8017db22-6dd7-2042-d178-38c23452ef75@redhat.com>
Message-ID: <4ba39a0c-59b6-8d74-f093-6b71457b9647@oracle.com>

On 1/21/18 8:25 AM, Andrew Dinn wrote:
> On 20/01/18 12:14, Andrew Dinn wrote:
>> On 19/01/18 19:01, jesper.wilhelmsson at oracle.com wrote:
>>> Please note that we are now in RDP2 and there is a process to follow to
>>> include the fix:?http://openjdk.java.net/projects/jdk/10/rdp-2
>>>
>>> In particular you need to add the label?jdk10-fix-request to the JBS
>>> issue to alert the release team about this bug. If not they don't know
>>> that they have to wait for your fix to get done.
>>>
>>> Please don't just add the label though, there is more to it.
>> I have added the label and a Fix Request comment to the JIRA and linked
>> the webrev to it.
> Vladimir kindly responded to this with an approval on the JIRA. I am
> still not sure where to go from here though:
> 
>    Can I/do I need to push the patch to the dev tree or the jdk10 tree?

Yes, since it is arrch64 only changes, just push the fix into jdk10:

http://hg.openjdk.java.net/jdk/jdk10/


> 
>    What do I need to do to get the patch into the jdk-updates jdk9u tree?

As I understand 2018 CPU, 9.0.4 release was last one from Oracle:

http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2017-November/000024.html

http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-January/000031.html

Rob, can Andrew push this fix (only aarch64 Hotspot changes) into jdk9u 
forest?:

http://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot

Otherwise I can only suggest to talk to AdoptOpenJDK to respin aarch64 
build.

Regards,
Vladimir

> 
> I'm rather confused as regards jdk9u as there is no jdk9u-dev list to
> post to in order to request a backport. Red Hat wants to patch its
> downstream jdk9 repos but ideally this ought to go in upstream first.
> Also, the 9.0.4 Oracle release (built by AdoptOpenJDK?) is broken on
> AArhc64 so it really needs a respin after this patch has been included.
> 
> Thanks in advance for any help or advice that can be offered.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

From tianxiao.gu at gmail.com  Mon Jan 22 04:54:01 2018
From: tianxiao.gu at gmail.com (Tianxiao Gu)
Date: Sun, 21 Jan 2018 20:54:01 -0800
Subject: jaotc Miscompilation
In-Reply-To: <80AC9F89-78F0-42F0-8CE7-46D84C065E81@oracle.com>
References: <CAJgZ6Z8hxgmm=HduiRM9Sn86OSBcEdWMYzWe_21fJ4hfsA87fA@mail.gmail.com>
 <cdf94aeb-24b9-74a4-0ca3-8a38e62930ce@oracle.com>
 <80AC9F89-78F0-42F0-8CE7-46D84C065E81@oracle.com>
Message-ID: <CAJgZ6Z9GU=ORukreY+DqQawYHY64Ub3K=U3yN3vJWtKoudTfJA@mail.gmail.com>

Thanks, Igor, this bug has been fixed in the latest jdk10. I also cannot
reproduce it with jdk10.

On Sun, Jan 21, 2018 at 4:36 PM, Igor Veresov <igor.veresov at oracle.com>
wrote:

> Doesn?t seem to reproduce for me with jdk10 (on macOS). Tianxiao, could
> you please try an early build of jdk10 to see if there is still a problem?
>
> igor
>
> > On Jan 21, 2018, at 3:11 PM, Tobias Hartmann <tobias.hartmann at oracle.com>
> wrote:
> >
> > [Adding hotspot-compiler-dev]
> >
> > On 21.01.2018 14:05, Tianxiao Gu wrote:
> >> Hi All,
> >>
> >> I found a mis-compilation bug that can be reproduced in the master of
> >> OpenJDK 9 (http://hg.openjdk.java.net/jdk9/jdk9/) and the latest
> Oracle JDK
> >> 9.0.4+11.
> >>
> >> Can anyone help me to report this bug to developers of OpenJDK 9?
> >>
> >> Description:
> >>
> >> The AOT mode triggers a NegativeArraySizeException while the default
> mode
> >> exits normally.
> >>
> >> Input: C0.class (via Google Drive):
> >>
> >> https://drive.google.com/open?id=17jN-4KFrs-apHlr2jkcDmP4OdA0ophWN
> >>
> >> Reproduce Steps:
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> *../../jdk-9.0.4/bin/jaotc
> >> --output C0.so C0
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> *../../jdk-9.0.4/bin/java
> >> -XX:AOTLibrary=./C0.so C0
> >>
> >> Exception in thread "main" java.lang.NegativeArraySizeException
> >>
> >> at C0.main(Unknown Source)
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> *../../jdk-9.0.4/bin/java
> >> C0
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *echo $?
> >>
> >> 0
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> *../../jdk-9.0.4/bin/java
> >> --version
> >>
> >> java 9.0.4
> >>
> >> Java(TM) SE Runtime Environment (build 9.0.4+11)
> >>
> >> Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> *../../jdk-9.0.4/bin/jaotc
> >> --version
> >>
> >> jaotc 9.0.4+11
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *
> >>
>
>

From ningsheng.jian at linaro.org  Mon Jan 22 07:16:46 2018
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Mon, 22 Jan 2018 15:16:46 +0800
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
Message-ID: <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>

Hi Andrew,

I can apply your patch cleanly to jdk10 except for some warnings about
tabs found instead of spaces. I also launched a JTreg test for your
patch, but one new failure found:
test/hotspot/jtreg/gtest/GTestWrapper.java. Details updated in JBS.
Could you please take a look?

Thanks,
Ningsheng

On 20 January 2018 at 02:24, Andrew Dinn <adinn at redhat.com> wrote:
> The following critical patch fixes 8195685 for the latest jdkdev/jdk
> tree and also jdkdev/jdk10, making it possible to run any JVM built form
> them on AArch64
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8195685
> webrev: http://cr.openjdk.java.net/~adinn/8195685/webrev
>
> The patch applies cleanly to jdk10 and really needs to be pushed in
> before it is frozen as it is a complete show-stopper for the AArch64 port.
>
> Quick reviews would be welcome.
>
> What is essentially the same patch is also needed to fix the jdk9 tree
> that was used to build Oracle's 9.0.4. Here is the alternative jdk9
> webrev needed to allow for different src tree layout.
>
> jdk9u webrev: http://cr.openjdk.java.net/~adinn/8195685.jdk9
>
> Note that the jdk9u patch is currently against the same issue as the
> jdkdev patch. I don't know what to do about the official backport
> process for this. Whatever need to be done is it possible to expedite
> any admin process for backporting? Red Hat need this fix to get our
> Fedora jdk9 AArch64 release out the door.
>
> Testing:
> The patch allows aarch64 to run a variety of simple programs where
> previously it crashed almost immediately. It is essentially the same
> code as was added to Red Hat's latest released jdk8 AArch64 build.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>

From adinn at redhat.com  Mon Jan 22 10:24:08 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 22 Jan 2018 10:24:08 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
Message-ID: <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>

Hi Ningsheng,

On 22/01/18 07:16, Ningsheng Jian wrote:
> I can apply your patch cleanly to jdk10 except for some warnings about
> tabs found instead of spaces. I also launched a JTreg test for your
> patch, but one new failure found:
> test/hotspot/jtreg/gtest/GTestWrapper.java. Details updated in JBS.
> Could you please take a look?
Thanks for finding this problem. It relates to generation of a vtable
stub at the point where it creates code to lookup a vtable entry. The
code changes in the patch for 8195685 involve changes to code in a
different path which relates to generation of an itable stub and lookup
of a itable entry. So, I am not sure if this new error is a problem with
the fix or is an existing bug which has just manifested for other reasons.

Looking at the place where the error occurs it seems that the problem is
this call in MacroAssembler::lookup_virtual_method

  vtable_offset_in_bytes += vtable_index.as_constant() * wordSize;
  ldr(method_result, Address(recv_klass, vtable_offset_in_bytes));

It looks as if vtable_offset_in_bytes is out of range.

I will need to debug to see if this is what is going on. In the meantime
I'll hold off on pushing the patch to the jdk and jdk10 trees.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From aph at redhat.com  Mon Jan 22 11:32:08 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 22 Jan 2018 11:32:08 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <4ba39a0c-59b6-8d74-f093-6b71457b9647@oracle.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <866F750F-B87D-4ED0-A9D1-FDE50889C8E2@oracle.com>
 <2da9653a-43fe-939a-9c85-17c0d545d39b@redhat.com>
 <8017db22-6dd7-2042-d178-38c23452ef75@redhat.com>
 <4ba39a0c-59b6-8d74-f093-6b71457b9647@oracle.com>
Message-ID: <184fe65b-3ff8-04c7-9355-bac3d1742245@redhat.com>

On 22/01/18 03:24, Vladimir Kozlov wrote:
> On 1/21/18 8:25 AM, Andrew Dinn wrote:
>> On 20/01/18 12:14, Andrew Dinn wrote:
>>> On 19/01/18 19:01, jesper.wilhelmsson at oracle.com wrote:
>>>> Please note that we are now in RDP2 and there is a process to follow to
>>>> include the fix: http://openjdk.java.net/projects/jdk/10/rdp-2
>>>>
>>>> In particular you need to add the label jdk10-fix-request to the JBS
>>>> issue to alert the release team about this bug. If not they don't know
>>>> that they have to wait for your fix to get done.
>>>>
>>>> Please don't just add the label though, there is more to it.
>>> I have added the label and a Fix Request comment to the JIRA and linked
>>> the webrev to it.
>> Vladimir kindly responded to this with an approval on the JIRA. I am
>> still not sure where to go from here though:
>>
>>    Can I/do I need to push the patch to the dev tree or the jdk10 tree?
> 
> Yes, since it is arrch64 only changes, just push the fix into jdk10:
> 
> http://hg.openjdk.java.net/jdk/jdk10/
> 
>>    What do I need to do to get the patch into the jdk-updates jdk9u tree?
> 
> As I understand 2018 CPU, 9.0.4 release was last one from Oracle:
> 
> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2017-November/000024.html
> 
> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-January/000031.html
>
> Rob, can Andrew push this fix (only aarch64 Hotspot changes) into jdk9u
> forest?:
>
> http://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot

If Oracle doesn't want to do another release from jdk9u that's
entirely up to them, but Oracle broke the AArch64 port in JDK9, and we
need to fix it.  You can't go breaking ports and then disallowing
people from checking in the necessary fixes.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Mon Jan 22 12:41:39 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 22 Jan 2018 12:41:39 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
Message-ID: <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>

Hi Ningsheng,

I believe this is an unrelated bug and that this test could never have
worked before the patch.

The failing gtest executes this code:

TEST_VM(code, vtableStubs) {
  // Should be in VM to use locks
  ThreadInVMfromNative ThreadInVMfromNative(JavaThread::current());

  VtableStubs::find_vtable_stub(0); // min vtable index
  for (int i = 0; i < 15; i++) {
    VtableStubs::find_vtable_stub((1 << i) - 1);
    VtableStubs::find_vtable_stub((1 << i));
  }
  VtableStubs::find_vtable_stub((1 << 15) - 1); // max vtable index
}

So, it is calling VtableStubs::find_vtable_stub with values up to 1<< 15.

Method find_vtable_stub calls passes the index along to
create_vtable_stub which again passes it on to method
MacroAssembler::lookup_virtual_method. This index is a constant so it is
scaled by wordSize and passed directly to ldr. I guess a size check is
needed to detect offsets that cannto be inserted as an immediate.

    vtable_offset_in_bytes += vtable_index.as_constant() * wordSize;
    ldr(method_result, Address(recv_klass, vtable_offset_in_bytes));

So, I'm going to push the current (8195685) patch as is and leave this
problem to be handled as a separate issue. Thanks for testing the patch.
I'll add you to the list of reviewers before pushing.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From aph at redhat.com  Mon Jan 22 14:48:19 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 22 Jan 2018 14:48:19 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
Message-ID: <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>

On 22/01/18 12:41, Andrew Dinn wrote:
> Hi Ningsheng,
> 
> I believe this is an unrelated bug and that this test could never have
> worked before the patch.

This test is new.  It is part of 8174962: Better interface invocations.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From fairoz.matte at oracle.com  Mon Jan 22 07:12:50 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Sun, 21 Jan 2018 23:12:50 -0800 (PST)
Subject: jaotc Miscompilation
In-Reply-To: <80AC9F89-78F0-42F0-8CE7-46D84C065E81@oracle.com>
References: <CAJgZ6Z8hxgmm=HduiRM9Sn86OSBcEdWMYzWe_21fJ4hfsA87fA@mail.gmail.com>
 <cdf94aeb-24b9-74a4-0ca3-8a38e62930ce@oracle.com>
 <80AC9F89-78F0-42F0-8CE7-46D84C065E81@oracle.com>
Message-ID: <30602b1c-1b5f-485e-83b0-1a8ae890b573@default>

Hi Tianxiao Gu,

This issue has been already fixed in 10 ea b34, which confirms the below result. 
9.0.4 GA - Fail 
10 ea b33 - Fail 
10 ea b34 - Pass 
10 ea b40 -Pass

Updated in https://bugs.openjdk.java.net/browse/JDK-8195838 

Thanks,
Fairoz

> -----Original Message-----
> From: Igor Veresov
> Sent: Monday, January 22, 2018 6:07 AM
> To: Tobias Hartmann <tobias.hartmann at oracle.com>
> Cc: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; jdk-
> dev at openjdk.java.net; Tianxiao Gu <tianxiao.gu at gmail.com>
> Subject: Re: jaotc Miscompilation
> 
> Doesn?t seem to reproduce for me with jdk10 (on macOS). Tianxiao, could
> you please try an early build of jdk10 to see if there is still a problem?
> 
> igor
> 
> > On Jan 21, 2018, at 3:11 PM, Tobias Hartmann
> <tobias.hartmann at oracle.com> wrote:
> >
> > [Adding hotspot-compiler-dev]
> >
> > On 21.01.2018 14:05, Tianxiao Gu wrote:
> >> Hi All,
> >>
> >> I found a mis-compilation bug that can be reproduced in the master of
> >> OpenJDK 9 (http://hg.openjdk.java.net/jdk9/jdk9/) and the latest
> >> Oracle JDK 9.0.4+11.
> >>
> >> Can anyone help me to report this bug to developers of OpenJDK 9?
> >>
> >> Description:
> >>
> >> The AOT mode triggers a NegativeArraySizeException while the default
> >> mode exits normally.
> >>
> >> Input: C0.class (via Google Drive):
> >>
> >> https://drive.google.com/open?id=17jN-4KFrs-
> apHlr2jkcDmP4OdA0ophWN
> >>
> >> Reproduce Steps:
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> >> *../../jdk-9.0.4/bin/jaotc --output C0.so C0
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> >> *../../jdk-9.0.4/bin/java -XX:AOTLibrary=./C0.so C0
> >>
> >> Exception in thread "main" java.lang.NegativeArraySizeException
> >>
> >> at C0.main(Unknown Source)
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> >> *../../jdk-9.0.4/bin/java
> >> C0
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *echo $?
> >>
> >> 0
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> >> *../../jdk-9.0.4/bin/java --version
> >>
> >> java 9.0.4
> >>
> >> Java(TM) SE Runtime Environment (build 9.0.4+11)
> >>
> >> Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>>
> >> *../../jdk-9.0.4/bin/jaotc --version
> >>
> >> jaotc 9.0.4+11
> >>
> >> t@~/Projects/JVMTesting/bugs/20180120224049 *>>> *
> >>
> 

From alex.buckley at oracle.com  Mon Jan 22 18:50:51 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 22 Jan 2018 10:50:51 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
Message-ID: <5A66328B.4030408@oracle.com>

On 1/20/2018 3:33 PM, forax at univ-mlv.fr wrote:
> I have used the wrong word, instead of "unknown constant pool
> attribute", i should have use "unknown constant pool constant".
> Unknown class/method/field attribute are required to be silently
> ignored as you point out, but you can not do that for constant pool
> constant because unlike an attribute which encode its size so you can
> skip it, a constant pool constant doesn't provide its size only the
> JVMS provides the association between the kind of a constant pool
> constant and its size.

Let's suppose we have a Java SE 11-compliant JVM implementation and a 
55.0 class file. You're saying that a new kind of entry in the constant 
pool is a cleaner way to signal the presence of class file content 
that's incubating in SE 11 than a non-zero minor_version. Please explain 
why because I don't see it.

Alex

From forax at univ-mlv.fr  Mon Jan 22 19:21:43 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 22 Jan 2018 20:21:43 +0100 (CET)
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A66328B.4030408@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
Message-ID: <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>

Hi Alex,

----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Lundi 22 Janvier 2018 19:50:51
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On 1/20/2018 3:33 PM, forax at univ-mlv.fr wrote:
>> I have used the wrong word, instead of "unknown constant pool
>> attribute", i should have use "unknown constant pool constant".
>> Unknown class/method/field attribute are required to be silently
>> ignored as you point out, but you can not do that for constant pool
>> constant because unlike an attribute which encode its size so you can
>> skip it, a constant pool constant doesn't provide its size only the
>> JVMS provides the association between the kind of a constant pool
>> constant and its size.
> 
> Let's suppose we have a Java SE 11-compliant JVM implementation and a
> 55.0 class file. You're saying that a new kind of entry in the constant
> pool is a cleaner way to signal the presence of class file content
> that's incubating in SE 11 than a non-zero minor_version. Please explain
> why because I don't see it.

No, i do not propose to mark an experimental class with an unknown constant pool constant.

I said that using a class attribute to mark expertimental classes is better because it doesn't change the semantics of the classfile version.
But this come with an issue if the experimental feature add a new constant pool constant and the VM doesn't support experimental features, in this peculiar case, i said that throwing an error because the class is invalid because it contains an invalid constant pool constant instead of throwing an error because the VM doesn't support experimental classes is Ok.  

> 
> Alex

R?mi

From alex.buckley at oracle.com  Mon Jan 22 19:44:42 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 22 Jan 2018 11:44:42 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
Message-ID: <5A663F2A.1030101@oracle.com>

On 1/22/2018 11:21 AM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Alex Buckley" <alex.buckley at oracle.com> ?: "jdk-dev"
>> Let's suppose we have a Java SE 11-compliant JVM implementation and
>> a 55.0 class file. You're saying that a new kind of entry in the
>> constant pool is a cleaner way to signal the presence of class file
>> content that's incubating in SE 11 than a non-zero minor_version.
>> Please explain why because I don't see it.
>
> No, i do not propose to mark an experimental class with an unknown
> constant pool constant.
>
> I said that using a class attribute to mark expertimental classes is
> better because it doesn't change the semantics of the classfile
> version.

First, you keep saying experimental but I tried very hard in the JEP to 
distingush incubating features from experimental features. I sent a mail 
about this last week but it seems to have missed the mark again. 
Incubating != experimental.

Moving on, it appears you want to ring-fence the minor_version item. You 
do not want it to have a first-class meaning, even in new class files 
(SE 11 and greater). Why not?

> But this come with an issue if the experimental feature add
> a new constant pool constant and the VM doesn't support experimental
> features, in this peculiar case, i said that throwing an error
> because the class is invalid because it contains an invalid constant
> pool constant instead of throwing an error because the VM doesn't
> support experimental classes is Ok.

It's not very nice for the user if a JVM implementation sometimes 
rejects unsupported incubating content cleanly (based on detecting the 
attribute) while at other times throwing errors for the 
really-unsupported unsupported incubating content (in the constant pool).

Alex

From jonathan.gibbons at oracle.com  Mon Jan 22 20:14:40 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 22 Jan 2018 12:14:40 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A663F2A.1030101@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
Message-ID: <8bec665b-e47b-30ef-4999-0119e5e0a2b5@oracle.com>

Whilst I support the use of the minor_version field as proposed, with 
this proposed bit, and the additional bit proposed by John Rose earlier 
in this thread, the value is trending away from being a "minor version 
number" and towards being "version flags".

-- Jon


On 1/22/18 11:44 AM, Alex Buckley wrote:
> On 1/22/2018 11:21 AM, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "Alex Buckley" <alex.buckley at oracle.com> ?: "jdk-dev"
>>> Let's suppose we have a Java SE 11-compliant JVM implementation and
>>> a 55.0 class file. You're saying that a new kind of entry in the
>>> constant pool is a cleaner way to signal the presence of class file
>>> content that's incubating in SE 11 than a non-zero minor_version.
>>> Please explain why because I don't see it.
>>
>> No, i do not propose to mark an experimental class with an unknown
>> constant pool constant.
>>
>> I said that using a class attribute to mark expertimental classes is
>> better because it doesn't change the semantics of the classfile
>> version.
>
> First, you keep saying experimental but I tried very hard in the JEP 
> to distingush incubating features from experimental features. I sent a 
> mail about this last week but it seems to have missed the mark again. 
> Incubating != experimental.
>
> Moving on, it appears you want to ring-fence the minor_version item. 
> You do not want it to have a first-class meaning, even in new class 
> files (SE 11 and greater). Why not?
>
>> But this come with an issue if the experimental feature add
>> a new constant pool constant and the VM doesn't support experimental
>> features, in this peculiar case, i said that throwing an error
>> because the class is invalid because it contains an invalid constant
>> pool constant instead of throwing an error because the VM doesn't
>> support experimental classes is Ok.
>
> It's not very nice for the user if a JVM implementation sometimes 
> rejects unsupported incubating content cleanly (based on detecting the 
> attribute) while at other times throwing errors for the 
> really-unsupported unsupported incubating content (in the constant pool).
>
> Alex


From forax at univ-mlv.fr  Mon Jan 22 22:49:12 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 22 Jan 2018 23:49:12 +0100 (CET)
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A663F2A.1030101@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
Message-ID: <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>



----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Lundi 22 Janvier 2018 20:44:42
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On 1/22/2018 11:21 AM, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "Alex Buckley" <alex.buckley at oracle.com> ?: "jdk-dev"
>>> Let's suppose we have a Java SE 11-compliant JVM implementation and
>>> a 55.0 class file. You're saying that a new kind of entry in the
>>> constant pool is a cleaner way to signal the presence of class file
>>> content that's incubating in SE 11 than a non-zero minor_version.
>>> Please explain why because I don't see it.
>>
>> No, i do not propose to mark an experimental class with an unknown
>> constant pool constant.
>>
>> I said that using a class attribute to mark expertimental classes is
>> better because it doesn't change the semantics of the classfile
>> version.
> 
> First, you keep saying experimental but I tried very hard in the JEP to
> distingush incubating features from experimental features. I sent a mail
> about this last week but it seems to have missed the mark again.
> Incubating != experimental.

my bad, sorry for that.

> 
> Moving on, it appears you want to ring-fence the minor_version item. You
> do not want it to have a first-class meaning, even in new class files
> (SE 11 and greater). Why not?

because a lot of bytecode tools provide the version as an int to the applications that used them and not as a pair of major and minor versions, so those applications will break. The fact that the minor version is 0 since a long time is encoded in the assumption that classfile version == classfile major_version into a lot of codes.

By example, take a look to the code of sun.tools.jar.FingerPrint in the jdk,
there is a method:
  public boolean isCompatibleVersion(FingerPrint that) {
      return attrs.version >= that.attrs.version;
  }
it compares two classfile versions without separating the major and the minor versions, this is ok now, it will be a mess if the minor version is used to encode the fact that a class is incubating.

> 
>> But this come with an issue if the experimental feature add
>> a new constant pool constant and the VM doesn't support experimental
>> features, in this peculiar case, i said that throwing an error
>> because the class is invalid because it contains an invalid constant
>> pool constant instead of throwing an error because the VM doesn't
>> support experimental classes is Ok.
> 
> It's not very nice for the user if a JVM implementation sometimes
> rejects unsupported incubating content cleanly (based on detecting the
> attribute) while at other times throwing errors for the
> really-unsupported unsupported incubating content (in the constant pool).

no, it's not nice, but it's the lesser of two evils.

you can be like Don Quixote and fight all those bad codes, because there are really bad codes or you can be a little more pragmatic and recognize that you can not change the minor version, this ship has sailed a long ago. 

> 
> Alex

R?mi

From joe.darcy at oracle.com  Mon Jan 22 22:55:42 2018
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 22 Jan 2018 14:55:42 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A6295B0.8040506@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <20180119125357.776212892@eggemoggin.niobe.net>
 <146886352.2360622.1516405151974.JavaMail.zimbra@u-pem.fr>
 <5A6295B0.8040506@oracle.com>
Message-ID: <5A666BEE.3020100@oracle.com>

On 1/19/2018 5:04 PM, Alex Buckley wrote:
> "Incubation is not a mechanism for experimentation and risk-taking."
>
> An incubating feature has evolved beyond a successful experiment. 
> We're sure enough of its scope and quality to commit it to the Java SE 
> Platform. Any number of the mature language features in recent years 
> could have been incubated to get that last ounce of feedback from 
> developers. Yes, we have to admit the possibility that an incubating 
> feature might be dropped -- "Sounds like a failed experiment!", I hear 
> you cry -- but there is no sense with an incubating feature of 
> tinkering, rough edges, version 0.1 quality, unsupported status, etc.
>

I'd like to illustrate the benefits of an incubator for language 
features using the development of one of the Project Coin features, 
try-with-resources.

The try-with-resources statement was the largest of the Coin features. 
In August of 2010, early access builds JDK 7 had a full implementation 
of the try-with-resources feature, with a detailed specification, 
compiler implementation, and library support. Feedback on using the 
feature was solicited on various channels. [1]

The most substantial feedback came five months later about null handling 
of the statement. [2] (HT R?mi) The following month, after due 
consideration the expert group for JSR 334 decided to change the null 
handling semantics as suggested. [3]

JDK 7 was a multi-year release and could accomodate and act on feedback 
provided several months after a production-quality implementation of the 
feature was available for use. However, the timeline of feedback above 
would of course be problematic to act on within a six-month release cycle.

Without an incubation facility, with a six-month release cycle it is 
unlikely feedback received at that relative time could be reflected in 
the GA build. That would leave two general options: live with the 
suboptimal original semantics of the feature or, in a future release, 
make an incompatible change to the language feature, one of the kinds of 
changes the platform has generally avoided.

An incubation facility provides a helpful path to offer solid features 
for feedback before all the details need be written in stone.

Cheers,

-Joe

[1] 
https://blogs.oracle.com/darcy/project-coin%3a-try-out-try-with-resources,
http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002822.html

[2] http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002961.html

[3] 
http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003077.html


From maaartinus at gmail.com  Mon Jan 22 23:14:43 2018
From: maaartinus at gmail.com (Martin Grajcar)
Date: Tue, 23 Jan 2018 00:14:43 +0100
Subject: Missing trivial optimization in String equals
Message-ID: <CAGsWfGi4g_cNY=eS1W=FRDoJHtybtruRb_XrUPPhCpKgMxzAWw@mail.gmail.com>

It looks like when testing equality of Strings, there's no test if the two
arrays are actually the same object. This was impossible before Java 8u20
(as no two strings used to share arrays), but it's well possible with
-XX:+UseStringDeduplication.

Maybe someone here cares...

Regards,
Martin.

http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
share/classes/java/lang/String.java#l1014
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
share/classes/java/lang/StringLatin1.java#l89
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
share/classes/java/lang/StringUTF16.java#l258

From alex.buckley at oracle.com  Mon Jan 22 23:14:43 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 22 Jan 2018 15:14:43 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
References: <5A624C97.3020408@oracle.com>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
Message-ID: <5A667063.6020603@oracle.com>

On 1/22/2018 2:49 PM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Alex Buckley" <alex.buckley at oracle.com> Moving on, it appears
>> you want to ring-fence the minor_version item. You do not want it
>> to have a first-class meaning, even in new class files (SE 11 and
>> greater). Why not?
>
> because a lot of bytecode tools provide the version as an int to the
> applications that used them and not as a pair of major and minor
> versions, so those applications will break. The fact that the minor
> version is 0 since a long time is encoded in the assumption that
> classfile version == classfile major_version into a lot of codes.

This boils down to saying that we can never use minor_version for 
anything, because so many stacks assume minor_version is insignificant. 
OK, your point is clearly made.

I note that class files with incubating content might look very strange 
by ordinary standards. For example, super_class might point to a 
constant pool entry which is not a CONSTANT_Class_info, so there is no 
chance of pre-existing applications understanding a class hierarchy 
naively exposed by the bytecode tool. The protocol between the 
application and the tool would need some adjustment to support the class 
file's expanded definition of "superclass".

Any other comments on the JEP?

Alex

From claes.redestad at oracle.com  Tue Jan 23 00:13:49 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 23 Jan 2018 01:13:49 +0100
Subject: Missing trivial optimization in String equals
In-Reply-To: <CAGsWfGi4g_cNY=eS1W=FRDoJHtybtruRb_XrUPPhCpKgMxzAWw@mail.gmail.com>
References: <CAGsWfGi4g_cNY=eS1W=FRDoJHtybtruRb_XrUPPhCpKgMxzAWw@mail.gmail.com>
Message-ID: <2d1717b3-8dc9-7a03-5bb4-7b5de36c81bf@oracle.com>

Hi,

do you have an example application that is spending significant time
comparing the contents of such identical arrays and would benefit? I would
guess such comparisons are about twice as fast as typical ones due to
having to load half as much from memory. ;-)

If there's a valid optimization case, though, then it would only be
realizable when UseStringDeduplication is enabled. Thus it's crucial not
to regress all the other cases that won't benefit (Parallel, Serial, ...),
and as String::equals is often a very hot method then even a few added
instructions that only compare data we've already loaded into registers
might be too much. Or maybe not.

As String::equals is routinely replaced by a C2 intrinsic[1] that's
where we should look to optimize (not so much in the JDK library code).
I think it'd be straightforward to train that intrinsic to only emit the
test when the related feature is enabled. Maybe the kind folks over at
hotspot-compiler-dev at openjdk.java.net might be able to give some pointers.
If so I'd invite you to set up a set of experiments and see if this can
have a benefit.

Regards

/Claes

[1]
http://hg.openjdk.java.net/jdk/jdk/file/e1876e6b57b6/src/hotspot/share/opto/library_call.cpp#l1116


On 2018-01-23 00:14, Martin Grajcar wrote:
> It looks like when testing equality of Strings, there's no test if the two
> arrays are actually the same object. This was impossible before Java 8u20
> (as no two strings used to share arrays), but it's well possible with
> -XX:+UseStringDeduplication.
>
> Maybe someone here cares...
>
> Regards,
> Martin.
>
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
> share/classes/java/lang/String.java#l1014
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
> share/classes/java/lang/StringLatin1.java#l89
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
> share/classes/java/lang/StringUTF16.java#l258


From volker.simonis at gmail.com  Tue Jan 23 00:46:04 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 23 Jan 2018 00:46:04 +0000
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A667063.6020603@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
Message-ID: <CA+3eh13q8ZKGEj7zpekHZ6SQZjQ34807g0mq4qnB1H8Qye9JYA@mail.gmail.com>

Alex Buckley <alex.buckley at oracle.com> schrieb am Di. 23. Jan. 2018 um
00:15:

> On 1/22/2018 2:49 PM, Remi Forax wrote:
> > ----- Mail original -----
> >> De: "Alex Buckley" <alex.buckley at oracle.com> Moving on, it appears
> >> you want to ring-fence the minor_version item. You do not want it
> >> to have a first-class meaning, even in new class files (SE 11 and
> >> greater). Why not?
> >
> > because a lot of bytecode tools provide the version as an int to the
> > applications that used them and not as a pair of major and minor
> > versions, so those applications will break. The fact that the minor
> > version is 0 since a long time is encoded in the assumption that
> > classfile version == classfile major_version into a lot of codes.
>
> This boils down to saying that we can never use minor_version for
> anything, because so many stacks assume minor_version is insignificant.
> OK, your point is clearly made.
>
> I note that class files with incubating content might look very strange
> by ordinary standards. For example, super_class might point to a
> constant pool entry which is not a CONSTANT_Class_info, so there is no
> chance of pre-existing applications understanding a class hierarchy
> naively exposed by the bytecode tool. The protocol between the
> application and the tool would need some adjustment to support the class
> file's expanded definition of "superclass".
>
> Any other comments on the JEP?
>

1. You don?t mention long- and short-term realeases in the JEP at all. I
know you argue that wether a release is long- or a short-term one is a
vendor and not a standards/specification question - and I can agree with
that opinion.

Nevertheless I think it would be strange to introduce an incubating feature
in a long term release (say Java 11), then refine it in Java 12 and make it
persistent in Java 13. In reality, Java 11 will be supported for at least 3
years or more, but 12 and 13 for six month only. So the old, deprecated
version of the incubating feature from Java 11 will probably get a much
higher adoption than the final one from Java 12 and 13 (at least until the
next long term release). I think we can already see that adoption of
short-term releases is quite low in the industry (everybody is waiting for
Java 11).

Furthermore, while understandable, the claim that a version N+1 isn?t
allowed to support the incubating feature of version N will even further
decrease the adoption rate of short term releases if they differ incubating
feature wise.

Finally, the JEP doesn?t specify if version N may (silently or explicitly)
support version N+1?s incubating features. This may be attractive for LTS
releases.

I don?t know how this dilemma could be solved, but I think in reality it
will make a significant difference if an incubating feature will be
introduced in a long- or short-term release.

2. You use the example of the ?_? character to advertise the incubating
features as a means to change the Java platform faster (i.e. within the
course of one instead of two major releases) in a backwards incompatible
way. Not sure everybody will see that as a desirable feature. Especially
not if that means within 6 month!

3. You write that the decision wether an incubating feature should become
permanent is ?left to the judgment and expertise of the Spec. Lead of the
Java SE Platform?. Shouldn?t that actually be decided by the corresponding
JSR Expert Group and the JCP EC?

Regards,
Volker


> Alex
>

From ningsheng.jian at linaro.org  Tue Jan 23 01:39:09 2018
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Tue, 23 Jan 2018 09:39:09 +0800
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
Message-ID: <CACO5V=aS8fLWxTwUZWTfQMLoSXj_pQty-u7NWhpqkVZcuUxiCQ@mail.gmail.com>

On 22 January 2018 at 22:48, Andrew Haley <aph at redhat.com> wrote:
> On 22/01/18 12:41, Andrew Dinn wrote:
>> Hi Ningsheng,
>>
>> I believe this is an unrelated bug and that this test could never have
>> worked before the patch.
>
> This test is new.  It is part of 8174962: Better interface invocations.

I saw Andrew Dinn had created 8195859 to track it. Thanks!

Regards,
Ningsheng

From ningsheng.jian at linaro.org  Tue Jan 23 05:49:52 2018
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Tue, 23 Jan 2018 13:49:52 +0800
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
Message-ID: <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>

Hi Andrew,

I see the patch has also been pushed to jdk/hs and jdk/jdk, but there
is no "8174962: Better interface invocations" in those trees yet... It
will break build without 8174962.

Do you know when 8174962 will be ported to jdk forest?

Thanks,
Ningsheng

On 22 January 2018 at 22:48, Andrew Haley <aph at redhat.com> wrote:
> On 22/01/18 12:41, Andrew Dinn wrote:
>> Hi Ningsheng,
>>
>> I believe this is an unrelated bug and that this test could never have
>> worked before the patch.
>
> This test is new.  It is part of 8174962: Better interface invocations.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From fridrich.strba at suse.com  Tue Jan 23 06:56:40 2018
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Tue, 23 Jan 2018 07:56:40 +0100
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
 <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
Message-ID: <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>

On 23/01/18 06:49, Ningsheng Jian wrote:
> I see the patch has also been pushed to jdk/hs and jdk/jdk, but there
> is no "8174962: Better interface invocations" in those trees yet... It
> will break build without 8174962.

Whereas it is true that the jdk/hs does not have jdk-10+40 synced and
thus does not have the fix 8174962, the jdk/jdk has the jdk-10+40 synced
and thus the commit is there as are the s390/ppc part of it. So, the
jdk/jdk should be buildable.

Cheers

Fridrich


From ningsheng.jian at linaro.org  Tue Jan 23 07:13:28 2018
From: ningsheng.jian at linaro.org (Ningsheng Jian)
Date: Tue, 23 Jan 2018 15:13:28 +0800
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
 <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
 <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>
Message-ID: <CACO5V=bxg0SPkNOL2H1nKcehCqRu7iJ3YNjFJya9mBrhkM1_Kg@mail.gmail.com>

Oh, yes. I've messed up my local repos. jdk/jdk is synced, but jdk/hs
is not. So jdk/jdk should be OK, but jdk/hs is not buildable so far.

Thanks,
Ningsheng

On 23 January 2018 at 14:56, Fridrich Strba <fridrich.strba at suse.com> wrote:
> On 23/01/18 06:49, Ningsheng Jian wrote:
>> I see the patch has also been pushed to jdk/hs and jdk/jdk, but there
>> is no "8174962: Better interface invocations" in those trees yet... It
>> will break build without 8174962.
>
> Whereas it is true that the jdk/hs does not have jdk-10+40 synced and
> thus does not have the fix 8174962, the jdk/jdk has the jdk-10+40 synced
> and thus the commit is there as are the s390/ppc part of it. So, the
> jdk/jdk should be buildable.
>
> Cheers
>
> Fridrich
>

From forax at univ-mlv.fr  Tue Jan 23 08:35:08 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 23 Jan 2018 09:35:08 +0100 (CET)
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A667063.6020603@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
Message-ID: <502575277.632297.1516696508787.JavaMail.zimbra@u-pem.fr>



----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Mardi 23 Janvier 2018 00:14:43
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On 1/22/2018 2:49 PM, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "Alex Buckley" <alex.buckley at oracle.com> Moving on, it appears
>>> you want to ring-fence the minor_version item. You do not want it
>>> to have a first-class meaning, even in new class files (SE 11 and
>>> greater). Why not?
>>
>> because a lot of bytecode tools provide the version as an int to the
>> applications that used them and not as a pair of major and minor
>> versions, so those applications will break. The fact that the minor
>> version is 0 since a long time is encoded in the assumption that
>> classfile version == classfile major_version into a lot of codes.
> 
> This boils down to saying that we can never use minor_version for
> anything, because so many stacks assume minor_version is insignificant.
> OK, your point is clearly made.

and the fact that changing the minor version will hinder the adoption of incubating classes in the Java ecosystem.

Let's say I want to use the incubating features, i test with spring and it blows up,
let say i'm a good citizen and i report the issue to the spring bug tracker, what will be the answer ?
  1) ok, let's see all our dependencies where we have the wrong assumption that the classfile version is equivalent to the major version.
  2) it's an incubating class, we do not support them.

and perhaps using Spring is the wrong example, because they are very active in the community, so may be they will come with a patch.
Nevertheless, changing the classfile version semantics goes against the adoption of the very feature you want to promote.

> 
> I note that class files with incubating content might look very strange
> by ordinary standards. For example, super_class might point to a
> constant pool entry which is not a CONSTANT_Class_info, so there is no
> chance of pre-existing applications understanding a class hierarchy
> naively exposed by the bytecode tool. The protocol between the
> application and the tool would need some adjustment to support the class
> file's expanded definition of "superclass".

yes, right, so we can not use a class attribute, we have to add an ACC_INCUBATOR to flag the class access_flags instead (the other choice i propose in my first email on that subject).

> 
> Any other comments on the JEP?
> 
> Alex

R?mi

From adinn at redhat.com  Tue Jan 23 08:46:05 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 23 Jan 2018 08:46:05 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <CACO5V=bxg0SPkNOL2H1nKcehCqRu7iJ3YNjFJya9mBrhkM1_Kg@mail.gmail.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
 <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
 <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>
 <CACO5V=bxg0SPkNOL2H1nKcehCqRu7iJ3YNjFJya9mBrhkM1_Kg@mail.gmail.com>
Message-ID: <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com>

On 23/01/18 07:13, Ningsheng Jian wrote:
> Oh, yes. I've messed up my local repos. jdk/jdk is synced, but jdk/hs
> is not. So jdk/jdk should be OK, but jdk/hs is not buildable so far.
Oh dear.

I am afraid I messed up by pushing the patch for 8195685 to both
jdkdev/jdk and jdkdev/hs. While the former was correct and approved by
Vladimir the latter was a stupid neglect of the appropriate protocol on
my part. Apologies for making such a mess.

Is there a recommended way to revert this change?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From adinn at redhat.com  Tue Jan 23 08:53:06 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 23 Jan 2018 08:53:06 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
Message-ID: <6b933a93-1a05-1879-270f-d616bfc9ae32@redhat.com>



On 22/01/18 14:48, Andrew Haley wrote:
> On 22/01/18 12:41, Andrew Dinn wrote:
>> Hi Ningsheng,
>>
>> I believe this is an unrelated bug and that this test could never have
>> worked before the patch.
> 
> This test is new.  It is part of 8174962: Better interface invocations.

Well, that explains that then! So, it has found its first bug.

I raised JDK-8195859 and have a patch which I will post soon.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


From adinn at redhat.com  Tue Jan 23 10:16:13 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 23 Jan 2018 10:16:13 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
 <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
 <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>
 <CACO5V=bxg0SPkNOL2H1nKcehCqRu7iJ3YNjFJya9mBrhkM1_Kg@mail.gmail.com>
 <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com>
Message-ID: <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com>

On 23/01/18 08:46, Andrew Dinn wrote:
> I am afraid I messed up by pushing the patch for 8195685 to both
> jdkdev/jdk and jdkdev/hs. While the former was correct and approved by
> Vladimir the latter was a stupid neglect of the appropriate protocol on
> my part. Apologies for making such a mess.
The patch included below reverts the erroneous push of 8195685 to
jdk/hs. I'm not sure of the procedure to get this into the repo but
until that is resolved this can be used by anyone working on AArch64 to
get their hg tree back to a clean state.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
# HG changeset patch
# User adinn
# Date 1516702051 0
#      Tue Jan 23 10:07:31 2018 +0000
# Node ID a7e77acacaad73682a6dd70801502dad55450d41
# Parent  8f451978683ce3193c302f6140ecf05afee1754a
revert wrong commit of 8195685

diff -r 8f451978683c -r a7e77acacaad
src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
--- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp	Tue Jan 23
08:55:47 2018 +0100
+++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp	Tue Jan 23
10:07:31 2018 +0000
@@ -963,12 +963,8 @@
                                              RegisterOrConstant
itable_index,
                                              Register method_result,
                                              Register scan_temp,
-                                             Label& L_no_such_interface,
-                         bool return_method) {
-  assert_different_registers(recv_klass, intf_klass, scan_temp);
-  assert_different_registers(method_result, intf_klass, scan_temp);
-  assert(recv_klass != method_result || !return_method,
-     "recv_klass can be destroyed when method isn't needed");
+                                             Label& L_no_such_interface) {
+  assert_different_registers(recv_klass, intf_klass, method_result,
scan_temp);
   assert(itable_index.is_constant() || itable_index.as_register() ==
method_result,
          "caller must use same register for non-constant itable index
as for method");

@@ -986,14 +982,12 @@
   lea(scan_temp, Address(recv_klass, scan_temp, Address::lsl(3)));
   add(scan_temp, scan_temp, vtable_base);

-  if (return_method) {
-    // Adjust recv_klass by scaled itable_index, so we can free
itable_index.
-    assert(itableMethodEntry::size() * wordSize == wordSize, "adjust
the scaling in the code below");
-    // lea(recv_klass, Address(recv_klass, itable_index,
Address::times_ptr, itentry_off));
-    lea(recv_klass, Address(recv_klass, itable_index, Address::lsl(3)));
-    if (itentry_off)
-      add(recv_klass, recv_klass, itentry_off);
-  }
+  // Adjust recv_klass by scaled itable_index, so we can free itable_index.
+  assert(itableMethodEntry::size() * wordSize == wordSize, "adjust the
scaling in the code below");
+  // lea(recv_klass, Address(recv_klass, itable_index,
Address::times_ptr, itentry_off));
+  lea(recv_klass, Address(recv_klass, itable_index, Address::lsl(3)));
+  if (itentry_off)
+    add(recv_klass, recv_klass, itentry_off);

   // for (scan = klass->itable(); scan->interface() != NULL; scan +=
scan_step) {
   //   if (scan->interface() == intf) {
@@ -1027,10 +1021,8 @@
   bind(found_method);

   // Got a hit.
-  if (return_method) {
-    ldrw(scan_temp, Address(scan_temp,
itableOffsetEntry::offset_offset_in_bytes()));
-    ldr(method_result, Address(recv_klass, scan_temp, Address::uxtw(0)));
-  }
+  ldr(scan_temp, Address(scan_temp,
itableOffsetEntry::offset_offset_in_bytes()));
+  ldr(method_result, Address(recv_klass, scan_temp));
 }

 // virtual method calling
diff -r 8f451978683c -r a7e77acacaad
src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
--- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp	Tue Jan 23
08:55:47 2018 +0100
+++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp	Tue Jan 23
10:07:31 2018 +0000
@@ -875,8 +875,7 @@
                                RegisterOrConstant itable_index,
                                Register method_result,
                                Register scan_temp,
-                               Label& no_such_interface,
-                   bool return_method = true);
+                               Label& no_such_interface);

   // virtual method calling
   // n.b. x86 allows RegisterOrConstant for vtable_index
diff -r 8f451978683c -r a7e77acacaad
src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
--- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp	Tue Jan 23
08:55:47 2018 +0100
+++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp	Tue Jan 23
10:07:31 2018 +0000
@@ -3279,11 +3279,11 @@
   transition(vtos, vtos);
   assert(byte_no == f1_byte, "use this argument");

-  prepare_invoke(byte_no, r0, rmethod,  // get f1 Klass*, f2 Method*
+  prepare_invoke(byte_no, r0, rmethod,  // get f1 Klass*, f2 itable index
                  r2, r3); // recv, flags

   // r0: interface klass (from f1)
-  // rmethod: method (from f2)
+  // rmethod: itable index (from f2)
   // r2: receiver
   // r3: flags

@@ -3302,27 +3302,10 @@
   __ null_check(r2, oopDesc::klass_offset_in_bytes());
   __ load_klass(r3, r2);

-  Label no_such_interface, no_such_method;
-
-  // Receiver subtype check against REFC.
-  // Superklass in r0. Subklass in r3. Blows rscratch2, r13
-  __ lookup_interface_method(// inputs: rec. class, interface, itable index
-                             r3, r0, noreg,
-                             // outputs: scan temp. reg, scan temp. reg
-                             rscratch2, r13,
-                             no_such_interface,
-                             /*return_method=*/false);
-
   // profile this call
   __ profile_virtual_call(r3, r13, r19);

-  // Get declaring interface class from method, and itable index
-  __ ldr(r0, Address(rmethod, Method::const_offset()));
-  __ ldr(r0, Address(r0, ConstMethod::constants_offset()));
-  __ ldr(r0, Address(r0, ConstantPool::pool_holder_offset_in_bytes()));
-  __ ldrw(rmethod, Address(rmethod, Method::itable_index_offset()));
-  __ subw(rmethod, rmethod, Method::itable_index_max);
-  __ negw(rmethod, rmethod);
+  Label no_such_interface, no_such_method;

   __ lookup_interface_method(// inputs: rec. class, interface, itable index
                              r3, r0, rmethod,
diff -r 8f451978683c -r a7e77acacaad
src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp
--- a/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp	Tue Jan 23
08:55:47 2018 +0100
+++ b/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp	Tue Jan 23
10:07:31 2018 +0000
@@ -29,7 +29,6 @@
 #include "code/vtableStubs.hpp"
 #include "interp_masm_aarch64.hpp"
 #include "memory/resourceArea.hpp"
-#include "oops/compiledICHolder.hpp"
 #include "oops/instanceKlass.hpp"
 #include "oops/klassVtable.hpp"
 #include "runtime/sharedRuntime.hpp"
@@ -141,44 +140,28 @@
 #endif

   // Entry arguments:
-  //  rscratch2: CompiledICHolder
+  //  rscratch2: Interface
   //  j_rarg0: Receiver

-
-  // Most registers are in use; we'll use r0, rmethod, r10, r11
-  const Register recv_klass_reg     = r10;
-  const Register holder_klass_reg   = r0; // declaring interface klass
(DECC)
-  const Register resolved_klass_reg = rmethod; // resolved interface
klass (REFC)
-  const Register temp_reg           = r11;
-  const Register icholder_reg       = rscratch2;
-
-  Label L_no_such_interface;
-
-  __ ldr(resolved_klass_reg, Address(icholder_reg,
CompiledICHolder::holder_klass_offset()));
-  __ ldr(holder_klass_reg,   Address(icholder_reg,
CompiledICHolder::holder_metadata_offset()));
+  // Free registers (non-args) are r0 (interface), rmethod

   // get receiver (need to skip return address on top of stack)
+
   assert(VtableStub::receiver_location() == j_rarg0->as_VMReg(),
"receiver expected in j_rarg0");
   // get receiver klass (also an implicit null-check)
   address npe_addr = __ pc();
-  __ load_klass(recv_klass_reg, j_rarg0);

-  // Receiver subtype check against REFC.
-  // Destroys recv_klass_reg value.
-  __ lookup_interface_method(// inputs: rec. class, interface
-                             recv_klass_reg, resolved_klass_reg, noreg,
-                             // outputs:  scan temp. reg1, scan temp. reg2
-                             recv_klass_reg, temp_reg,
-                             L_no_such_interface,
-                             /*return_method=*/false);
+  // Most registers are in use; we'll use r0, rmethod, r10, r11
+  __ load_klass(r10, j_rarg0);

-  // Get selected method from declaring class and itable index
-  __ load_klass(recv_klass_reg, j_rarg0);   // restore recv_klass_reg
+  Label throw_icce;
+
+  // Get Method* and entrypoint for compiler
   __ lookup_interface_method(// inputs: rec. class, interface, itable index
-                       recv_klass_reg, holder_klass_reg, itable_index,
-                       // outputs: method, scan temp. reg
-                       rmethod, temp_reg,
-                       L_no_such_interface);
+                             r10, rscratch2, itable_index,
+                             // outputs: method, scan temp. reg
+                             rmethod, r11,
+                             throw_icce);

   // method (rmethod): Method*
   // j_rarg0: receiver
@@ -200,7 +183,7 @@
   __ ldr(rscratch1, Address(rmethod, Method::from_compiled_offset()));
   __ br(rscratch1);

-  __ bind(L_no_such_interface);
+  __ bind(throw_icce);
   __
far_jump(RuntimeAddress(StubRoutines::throw_IncompatibleClassChangeError_entry()));

   __ flush();
@@ -222,11 +205,11 @@
   int size = DebugVtables ? 216 : 0;
   if (CountCompiledCalls)
     size += 6 * 4;
-  // FIXME: vtable stubs only need 36 bytes
+  // FIXME
   if (is_vtable_stub)
     size += 52;
   else
-    size += 176;
+    size += 104;
   return size;

   // In order to tune these parameters, run the JVM with VM options
@@ -234,58 +217,33 @@
   // actual itable stubs.  Run it with -Xmx31G -XX:+UseCompressedOops.
   //
   // If Universe::narrow_klass_base is nonzero, decoding a compressed
-  // class can take zeveral instructions.
+  // class can take zeveral instructions.  Run it with -Xmx31G
+  // -XX:+UseCompressedOops.
   //
   // The JVM98 app. _202_jess has a megamorphic interface call.
   // The itable code looks like this:
-
-  //    ldr    xmethod, [xscratch2,#CompiledICHolder::holder_klass_offset]
-  //    ldr    x0, [xscratch2]
-  //    ldr    w10, [x1,#oopDesc::klass_offset_in_bytes]
-  //    mov    xheapbase, #0x3c000000                //
#narrow_klass_base
-  //    movk    xheapbase, #0x3f7, lsl #32
-  //    add    x10, xheapbase, x10
-  //    mov    xheapbase, #0xe7ff0000                //   #heapbase
-  //    movk    xheapbase, #0x3f7, lsl #32
-  //    ldr    w11, [x10,#vtable_length_offset]
-  //    add    x11, x10, x11, uxtx #3
-  //    add    x11, x11, #itableMethodEntry::method_offset_in_bytes
-  //    ldr    x10, [x11]
-  //    cmp    xmethod, x10
-  //    b.eq    found_method
-  // search:
-  //    cbz    x10, no_such_interface
-  //    add    x11, x11, #0x10
-  //    ldr    x10, [x11]
-  //    cmp    xmethod, x10
-  //    b.ne    search
-  // found_method:
-  //    ldr    w10, [x1,#oopDesc::klass_offset_in_bytes]
-  //    mov    xheapbase, #0x3c000000                //
#narrow_klass_base
-  //    movk    xheapbase, #0x3f7, lsl #32
-  //    add    x10, xheapbase, x10
-  //    mov    xheapbase, #0xe7ff0000                //   #heapbase
-  //    movk    xheapbase, #0x3f7, lsl #32
-  //    ldr    w11, [x10,#vtable_length_offset]
-  //    add    x11, x10, x11, uxtx #3
-  //    add    x11, x11, #itableMethodEntry::method_offset_in_bytes
-  //    add    x10, x10, #itentry_off
-  //    ldr    xmethod, [x11]
-  //    cmp    x0, xmethod
-  //    b.eq    found_method2
-  // search2:
-  //    cbz    xmethod, 0x000003ffa872e6cc
-  //    add    x11, x11, #0x10
-  //    ldr    xmethod, [x11]
-  //    cmp    x0, xmethod
-  //    b.ne    search2
-  // found_method2:
-  //    ldr    w11, [x11,#itableOffsetEntry::offset_offset_in_bytes]
-  //    ldr    xmethod, [x10,w11,uxtw]
-  //    ldr    xscratch1, [xmethod,#Method::from_compiled_offset]
-  //    br    xscratch1
-  // no_such_interface:
-  //    b      throw_ICCE_entry
+  // Decoding VtableStub itbl[1]@12
+  //     ldr     w10, [x1,#8]
+  //     lsl     x10, x10, #3
+  //     ldr     w11, [x10,#280]
+  //     add     x11, x10, x11, uxtx #3
+  //     add     x11, x11, #0x1b8
+  //     ldr     x12, [x11]
+  //     cmp     x9, x12
+  //     b.eq    success
+  // loop:
+  //     cbz     x12, throw_icce
+  //     add     x11, x11, #0x10
+  //     ldr     x12, [x11]
+  //     cmp     x9, x12
+  //     b.ne    loop
+  // success:
+  //     ldr     x11, [x11,#8]
+  //     ldr     x12, [x10,x11]
+  //     ldr     x8, [x12,#72]
+  //     br      x8
+  // throw_icce:
+  //     b      throw_ICCE_entry

 }

----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8195685.revert.patch
Type: text/x-patch
Size: 12201 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jdk-dev/attachments/20180123/762b5b6b/8195685.revert-0001.patch>

From david.holmes at oracle.com  Tue Jan 23 10:36:42 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 23 Jan 2018 20:36:42 +1000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
 <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
 <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>
 <CACO5V=bxg0SPkNOL2H1nKcehCqRu7iJ3YNjFJya9mBrhkM1_Kg@mail.gmail.com>
 <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com>
 <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com>
Message-ID: <7c83e330-769e-847a-6f33-85962e004b57@oracle.com>

Adding in hotspot-dev and Jesper

Hi Andrew,

On 23/01/2018 8:16 PM, Andrew Dinn wrote:
> On 23/01/18 08:46, Andrew Dinn wrote:
>> I am afraid I messed up by pushing the patch for 8195685 to both
>> jdkdev/jdk and jdkdev/hs. While the former was correct and approved by
>> Vladimir the latter was a stupid neglect of the appropriate protocol on
>> my part. Apologies for making such a mess.
> The patch included below reverts the erroneous push of 8195685 to
> jdk/hs. I'm not sure of the procedure to get this into the repo but
> until that is resolved this can be used by anyone working on AArch64 to
> get their hg tree back to a clean state.

I don't think you want to push this to jdk/hs, else you'll have a worse 
problem. If this undoes the fix, and the changeset with the fix is 
already seen to be in jdk/hs then when we sync with jdk/jdk we will end 
up without the fix!

You may be lucky in that Jesper has been holding off pulling jdk/jdk 
into jdk/hs due to some test failures in jdk/jdk. If those are fixed 
(and I know one has been) then Jesper may merge jdk/jdk to jdk/hs "real 
soon now" and all the necessary pieces will be in place in jdk/hs.

David

> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 
> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
> # HG changeset patch
> # User adinn
> # Date 1516702051 0
> #      Tue Jan 23 10:07:31 2018 +0000
> # Node ID a7e77acacaad73682a6dd70801502dad55450d41
> # Parent  8f451978683ce3193c302f6140ecf05afee1754a
> revert wrong commit of 8195685
> 
> diff -r 8f451978683c -r a7e77acacaad
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
> --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp	Tue Jan 23
> 08:55:47 2018 +0100
> +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp	Tue Jan 23
> 10:07:31 2018 +0000
> @@ -963,12 +963,8 @@
>                                                RegisterOrConstant
> itable_index,
>                                                Register method_result,
>                                                Register scan_temp,
> -                                             Label& L_no_such_interface,
> -                         bool return_method) {
> -  assert_different_registers(recv_klass, intf_klass, scan_temp);
> -  assert_different_registers(method_result, intf_klass, scan_temp);
> -  assert(recv_klass != method_result || !return_method,
> -     "recv_klass can be destroyed when method isn't needed");
> +                                             Label& L_no_such_interface) {
> +  assert_different_registers(recv_klass, intf_klass, method_result,
> scan_temp);
>     assert(itable_index.is_constant() || itable_index.as_register() ==
> method_result,
>            "caller must use same register for non-constant itable index
> as for method");
> 
> @@ -986,14 +982,12 @@
>     lea(scan_temp, Address(recv_klass, scan_temp, Address::lsl(3)));
>     add(scan_temp, scan_temp, vtable_base);
> 
> -  if (return_method) {
> -    // Adjust recv_klass by scaled itable_index, so we can free
> itable_index.
> -    assert(itableMethodEntry::size() * wordSize == wordSize, "adjust
> the scaling in the code below");
> -    // lea(recv_klass, Address(recv_klass, itable_index,
> Address::times_ptr, itentry_off));
> -    lea(recv_klass, Address(recv_klass, itable_index, Address::lsl(3)));
> -    if (itentry_off)
> -      add(recv_klass, recv_klass, itentry_off);
> -  }
> +  // Adjust recv_klass by scaled itable_index, so we can free itable_index.
> +  assert(itableMethodEntry::size() * wordSize == wordSize, "adjust the
> scaling in the code below");
> +  // lea(recv_klass, Address(recv_klass, itable_index,
> Address::times_ptr, itentry_off));
> +  lea(recv_klass, Address(recv_klass, itable_index, Address::lsl(3)));
> +  if (itentry_off)
> +    add(recv_klass, recv_klass, itentry_off);
> 
>     // for (scan = klass->itable(); scan->interface() != NULL; scan +=
> scan_step) {
>     //   if (scan->interface() == intf) {
> @@ -1027,10 +1021,8 @@
>     bind(found_method);
> 
>     // Got a hit.
> -  if (return_method) {
> -    ldrw(scan_temp, Address(scan_temp,
> itableOffsetEntry::offset_offset_in_bytes()));
> -    ldr(method_result, Address(recv_klass, scan_temp, Address::uxtw(0)));
> -  }
> +  ldr(scan_temp, Address(scan_temp,
> itableOffsetEntry::offset_offset_in_bytes()));
> +  ldr(method_result, Address(recv_klass, scan_temp));
>   }
> 
>   // virtual method calling
> diff -r 8f451978683c -r a7e77acacaad
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
> --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp	Tue Jan 23
> 08:55:47 2018 +0100
> +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp	Tue Jan 23
> 10:07:31 2018 +0000
> @@ -875,8 +875,7 @@
>                                  RegisterOrConstant itable_index,
>                                  Register method_result,
>                                  Register scan_temp,
> -                               Label& no_such_interface,
> -                   bool return_method = true);
> +                               Label& no_such_interface);
> 
>     // virtual method calling
>     // n.b. x86 allows RegisterOrConstant for vtable_index
> diff -r 8f451978683c -r a7e77acacaad
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
> --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp	Tue Jan 23
> 08:55:47 2018 +0100
> +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp	Tue Jan 23
> 10:07:31 2018 +0000
> @@ -3279,11 +3279,11 @@
>     transition(vtos, vtos);
>     assert(byte_no == f1_byte, "use this argument");
> 
> -  prepare_invoke(byte_no, r0, rmethod,  // get f1 Klass*, f2 Method*
> +  prepare_invoke(byte_no, r0, rmethod,  // get f1 Klass*, f2 itable index
>                    r2, r3); // recv, flags
> 
>     // r0: interface klass (from f1)
> -  // rmethod: method (from f2)
> +  // rmethod: itable index (from f2)
>     // r2: receiver
>     // r3: flags
> 
> @@ -3302,27 +3302,10 @@
>     __ null_check(r2, oopDesc::klass_offset_in_bytes());
>     __ load_klass(r3, r2);
> 
> -  Label no_such_interface, no_such_method;
> -
> -  // Receiver subtype check against REFC.
> -  // Superklass in r0. Subklass in r3. Blows rscratch2, r13
> -  __ lookup_interface_method(// inputs: rec. class, interface, itable index
> -                             r3, r0, noreg,
> -                             // outputs: scan temp. reg, scan temp. reg
> -                             rscratch2, r13,
> -                             no_such_interface,
> -                             /*return_method=*/false);
> -
>     // profile this call
>     __ profile_virtual_call(r3, r13, r19);
> 
> -  // Get declaring interface class from method, and itable index
> -  __ ldr(r0, Address(rmethod, Method::const_offset()));
> -  __ ldr(r0, Address(r0, ConstMethod::constants_offset()));
> -  __ ldr(r0, Address(r0, ConstantPool::pool_holder_offset_in_bytes()));
> -  __ ldrw(rmethod, Address(rmethod, Method::itable_index_offset()));
> -  __ subw(rmethod, rmethod, Method::itable_index_max);
> -  __ negw(rmethod, rmethod);
> +  Label no_such_interface, no_such_method;
> 
>     __ lookup_interface_method(// inputs: rec. class, interface, itable index
>                                r3, r0, rmethod,
> diff -r 8f451978683c -r a7e77acacaad
> src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp
> --- a/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp	Tue Jan 23
> 08:55:47 2018 +0100
> +++ b/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp	Tue Jan 23
> 10:07:31 2018 +0000
> @@ -29,7 +29,6 @@
>   #include "code/vtableStubs.hpp"
>   #include "interp_masm_aarch64.hpp"
>   #include "memory/resourceArea.hpp"
> -#include "oops/compiledICHolder.hpp"
>   #include "oops/instanceKlass.hpp"
>   #include "oops/klassVtable.hpp"
>   #include "runtime/sharedRuntime.hpp"
> @@ -141,44 +140,28 @@
>   #endif
> 
>     // Entry arguments:
> -  //  rscratch2: CompiledICHolder
> +  //  rscratch2: Interface
>     //  j_rarg0: Receiver
> 
> -
> -  // Most registers are in use; we'll use r0, rmethod, r10, r11
> -  const Register recv_klass_reg     = r10;
> -  const Register holder_klass_reg   = r0; // declaring interface klass
> (DECC)
> -  const Register resolved_klass_reg = rmethod; // resolved interface
> klass (REFC)
> -  const Register temp_reg           = r11;
> -  const Register icholder_reg       = rscratch2;
> -
> -  Label L_no_such_interface;
> -
> -  __ ldr(resolved_klass_reg, Address(icholder_reg,
> CompiledICHolder::holder_klass_offset()));
> -  __ ldr(holder_klass_reg,   Address(icholder_reg,
> CompiledICHolder::holder_metadata_offset()));
> +  // Free registers (non-args) are r0 (interface), rmethod
> 
>     // get receiver (need to skip return address on top of stack)
> +
>     assert(VtableStub::receiver_location() == j_rarg0->as_VMReg(),
> "receiver expected in j_rarg0");
>     // get receiver klass (also an implicit null-check)
>     address npe_addr = __ pc();
> -  __ load_klass(recv_klass_reg, j_rarg0);
> 
> -  // Receiver subtype check against REFC.
> -  // Destroys recv_klass_reg value.
> -  __ lookup_interface_method(// inputs: rec. class, interface
> -                             recv_klass_reg, resolved_klass_reg, noreg,
> -                             // outputs:  scan temp. reg1, scan temp. reg2
> -                             recv_klass_reg, temp_reg,
> -                             L_no_such_interface,
> -                             /*return_method=*/false);
> +  // Most registers are in use; we'll use r0, rmethod, r10, r11
> +  __ load_klass(r10, j_rarg0);
> 
> -  // Get selected method from declaring class and itable index
> -  __ load_klass(recv_klass_reg, j_rarg0);   // restore recv_klass_reg
> +  Label throw_icce;
> +
> +  // Get Method* and entrypoint for compiler
>     __ lookup_interface_method(// inputs: rec. class, interface, itable index
> -                       recv_klass_reg, holder_klass_reg, itable_index,
> -                       // outputs: method, scan temp. reg
> -                       rmethod, temp_reg,
> -                       L_no_such_interface);
> +                             r10, rscratch2, itable_index,
> +                             // outputs: method, scan temp. reg
> +                             rmethod, r11,
> +                             throw_icce);
> 
>     // method (rmethod): Method*
>     // j_rarg0: receiver
> @@ -200,7 +183,7 @@
>     __ ldr(rscratch1, Address(rmethod, Method::from_compiled_offset()));
>     __ br(rscratch1);
> 
> -  __ bind(L_no_such_interface);
> +  __ bind(throw_icce);
>     __
> far_jump(RuntimeAddress(StubRoutines::throw_IncompatibleClassChangeError_entry()));
> 
>     __ flush();
> @@ -222,11 +205,11 @@
>     int size = DebugVtables ? 216 : 0;
>     if (CountCompiledCalls)
>       size += 6 * 4;
> -  // FIXME: vtable stubs only need 36 bytes
> +  // FIXME
>     if (is_vtable_stub)
>       size += 52;
>     else
> -    size += 176;
> +    size += 104;
>     return size;
> 
>     // In order to tune these parameters, run the JVM with VM options
> @@ -234,58 +217,33 @@
>     // actual itable stubs.  Run it with -Xmx31G -XX:+UseCompressedOops.
>     //
>     // If Universe::narrow_klass_base is nonzero, decoding a compressed
> -  // class can take zeveral instructions.
> +  // class can take zeveral instructions.  Run it with -Xmx31G
> +  // -XX:+UseCompressedOops.
>     //
>     // The JVM98 app. _202_jess has a megamorphic interface call.
>     // The itable code looks like this:
> -
> -  //    ldr    xmethod, [xscratch2,#CompiledICHolder::holder_klass_offset]
> -  //    ldr    x0, [xscratch2]
> -  //    ldr    w10, [x1,#oopDesc::klass_offset_in_bytes]
> -  //    mov    xheapbase, #0x3c000000                //
> #narrow_klass_base
> -  //    movk    xheapbase, #0x3f7, lsl #32
> -  //    add    x10, xheapbase, x10
> -  //    mov    xheapbase, #0xe7ff0000                //   #heapbase
> -  //    movk    xheapbase, #0x3f7, lsl #32
> -  //    ldr    w11, [x10,#vtable_length_offset]
> -  //    add    x11, x10, x11, uxtx #3
> -  //    add    x11, x11, #itableMethodEntry::method_offset_in_bytes
> -  //    ldr    x10, [x11]
> -  //    cmp    xmethod, x10
> -  //    b.eq    found_method
> -  // search:
> -  //    cbz    x10, no_such_interface
> -  //    add    x11, x11, #0x10
> -  //    ldr    x10, [x11]
> -  //    cmp    xmethod, x10
> -  //    b.ne    search
> -  // found_method:
> -  //    ldr    w10, [x1,#oopDesc::klass_offset_in_bytes]
> -  //    mov    xheapbase, #0x3c000000                //
> #narrow_klass_base
> -  //    movk    xheapbase, #0x3f7, lsl #32
> -  //    add    x10, xheapbase, x10
> -  //    mov    xheapbase, #0xe7ff0000                //   #heapbase
> -  //    movk    xheapbase, #0x3f7, lsl #32
> -  //    ldr    w11, [x10,#vtable_length_offset]
> -  //    add    x11, x10, x11, uxtx #3
> -  //    add    x11, x11, #itableMethodEntry::method_offset_in_bytes
> -  //    add    x10, x10, #itentry_off
> -  //    ldr    xmethod, [x11]
> -  //    cmp    x0, xmethod
> -  //    b.eq    found_method2
> -  // search2:
> -  //    cbz    xmethod, 0x000003ffa872e6cc
> -  //    add    x11, x11, #0x10
> -  //    ldr    xmethod, [x11]
> -  //    cmp    x0, xmethod
> -  //    b.ne    search2
> -  // found_method2:
> -  //    ldr    w11, [x11,#itableOffsetEntry::offset_offset_in_bytes]
> -  //    ldr    xmethod, [x10,w11,uxtw]
> -  //    ldr    xscratch1, [xmethod,#Method::from_compiled_offset]
> -  //    br    xscratch1
> -  // no_such_interface:
> -  //    b      throw_ICCE_entry
> +  // Decoding VtableStub itbl[1]@12
> +  //     ldr     w10, [x1,#8]
> +  //     lsl     x10, x10, #3
> +  //     ldr     w11, [x10,#280]
> +  //     add     x11, x10, x11, uxtx #3
> +  //     add     x11, x11, #0x1b8
> +  //     ldr     x12, [x11]
> +  //     cmp     x9, x12
> +  //     b.eq    success
> +  // loop:
> +  //     cbz     x12, throw_icce
> +  //     add     x11, x11, #0x10
> +  //     ldr     x12, [x11]
> +  //     cmp     x9, x12
> +  //     b.ne    loop
> +  // success:
> +  //     ldr     x11, [x11,#8]
> +  //     ldr     x12, [x10,x11]
> +  //     ldr     x8, [x12,#72]
> +  //     br      x8
> +  // throw_icce:
> +  //     b      throw_ICCE_entry
> 
>   }
> 
> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
> 

From Alan.Bateman at oracle.com  Tue Jan 23 10:44:23 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Jan 2018 10:44:23 +0000
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A667063.6020603@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
Message-ID: <37c88586-12fc-1fbf-9a3a-c1d579bb4f8c@oracle.com>

On 22/01/2018 23:14, Alex Buckley wrote:
> :
>
> Any other comments on the JEP?
It looks very good. A few comments/questions:

The case where an incubating language or VM feature relies on (or 
"associated informally with") an incubating API is clear - the VM must 
resolve the module with the API that the feature depends on (the 
jdk.incubator.strings module and its classfile package is a good 
example). The other direction, where an incubating module contains code 
that relies on an incubating language or VM feature isn't as clear - are 
all bits in the minor_version field of the module-info.class all set or 
maybe the JDK-specific ModuleResolution attribute has a flag to indicate 
that it needs the VM to run with support for incubating VM features 
enabled? I'm asking because there it wouldn't be hard to check the 
mismatch at startup o avoid a CFE some time later.

The "Run time" shows the java launcher taking a flag to enable the 
support. A detail for this section is that it will likely be a VM option 
rather than a java launcher option (users of the java launcher will not 
see the difference). This is because every VM is required to support a 
way to enable incubating VM features so it has to be enabled when 
creating the VM (JNI CreateJavaVM etc.).

The JEP is SE scope but I assume a few JDK or OpenJDK topics will come 
up. Are jtreg enhancements useful to support compiling and running 
tests? Do we want jlink to support including modules that depend on 
incubating VM features?

-Alan

From adinn at redhat.com  Tue Jan 23 10:54:23 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 23 Jan 2018 10:54:23 +0000
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <7c83e330-769e-847a-6f33-85962e004b57@oracle.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
 <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
 <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>
 <CACO5V=bxg0SPkNOL2H1nKcehCqRu7iJ3YNjFJya9mBrhkM1_Kg@mail.gmail.com>
 <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com>
 <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com>
 <7c83e330-769e-847a-6f33-85962e004b57@oracle.com>
Message-ID: <45b525dc-2554-b441-bf27-9c2a9bb520c6@redhat.com>

Hi David,

On 23/01/18 10:36, David Holmes wrote:
> Adding in hotspot-dev and Jesper

Thanks!

> I don't think you want to push this to jdk/hs, else you'll have a worse
> problem. If this undoes the fix, and the changeset with the fix is
> already seen to be in jdk/hs then when we sync with jdk/jdk we will end
> up without the fix!

Yeah, I thought that was probably going to be the problem.

> You may be lucky in that Jesper has been holding off pulling jdk/jdk
> into jdk/hs due to some test failures in jdk/jdk. If those are fixed
> (and I know one has been) then Jesper may merge jdk/jdk to jdk/hs "real
> soon now" and all the necessary pieces will be in place in jdk/hs.
Yes, I guess once the other changes make it in "real soon" the out of
order, early application of this one will not matter. Thanks for
explaining things and, once again, apologies for the mess.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From jesper.wilhelmsson at oracle.com  Tue Jan 23 14:17:55 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 23 Jan 2018 15:17:55 +0100
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <45b525dc-2554-b441-bf27-9c2a9bb520c6@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
 <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
 <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>
 <CACO5V=bxg0SPkNOL2H1nKcehCqRu7iJ3YNjFJya9mBrhkM1_Kg@mail.gmail.com>
 <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com>
 <81a1f298-25fe-62a1-1f33-151a6dcf9ff5@redhat.com>
 <7c83e330-769e-847a-6f33-85962e004b57@oracle.com>
 <45b525dc-2554-b441-bf27-9c2a9bb520c6@redhat.com>
Message-ID: <04B7021B-3F93-45DE-9A1F-728FD4DB0DA6@oracle.com>


> On 23 Jan 2018, at 11:54, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Hi David,
> 
> On 23/01/18 10:36, David Holmes wrote:
>> Adding in hotspot-dev and Jesper
> 
> Thanks!
> 
>> I don't think you want to push this to jdk/hs, else you'll have a worse
>> problem. If this undoes the fix, and the changeset with the fix is
>> already seen to be in jdk/hs then when we sync with jdk/jdk we will end
>> up without the fix!
> 
> Yeah, I thought that was probably going to be the problem.
> 
>> You may be lucky in that Jesper has been holding off pulling jdk/jdk
>> into jdk/hs due to some test failures in jdk/jdk. If those are fixed
>> (and I know one has been) then Jesper may merge jdk/jdk to jdk/hs "real
>> soon now" and all the necessary pieces will be in place in jdk/hs.
> Yes, I guess once the other changes make it in "real soon" the out of
> order, early application of this one will not matter. Thanks for
> explaining things and, once again, apologies for the mess.

The merge is done. I'll just run a sanity test cycle on the result and then pull jdk/jdk into jdk/hs provided there are no errors.
/Jesper


> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


From vladimir.kozlov at oracle.com  Tue Jan 23 16:56:39 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Jan 2018 08:56:39 -0800
Subject: [aarch64-port-dev ] RFR: 8195685: AArch64: AArch64 cannot build
 with JDK-8174962
In-Reply-To: <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com>
References: <cdc6d8dc-977e-124b-53b5-1393bbaa227b@redhat.com>
 <CACO5V=ZUqvJZcBQdB+2PDaHWCPYLpshMXhyfCJ0QFie9aGW3DA@mail.gmail.com>
 <099d09c1-93e6-dd29-68da-4a9a9cb5e420@redhat.com>
 <ee66e203-e47c-56ed-58f7-0f2680ea3f87@redhat.com>
 <f4b0fea2-36c5-a9f2-a42d-f466a1d57699@redhat.com>
 <CACO5V=ZgCtWYuPoobY4Z1OUTQk35vgCRM+9iyddE-bVqKFCiyA@mail.gmail.com>
 <b259e7cd-389d-1f7e-31e1-c4290e20399c@suse.com>
 <CACO5V=bxg0SPkNOL2H1nKcehCqRu7iJ3YNjFJya9mBrhkM1_Kg@mail.gmail.com>
 <0aecad5e-30e5-1b90-5d48-f45a6144e215@redhat.com>
Message-ID: <f5ca73ba-a371-a4c7-1eba-c0b773fbc074@oracle.com>

If the fix is exactly the same - it should be fine. We allow duplicated (same bug fix) changesets 
now (to resolve problems when we do forward auto-merge from previous release).

Vladimir

On 1/23/18 12:46 AM, Andrew Dinn wrote:
> On 23/01/18 07:13, Ningsheng Jian wrote:
>> Oh, yes. I've messed up my local repos. jdk/jdk is synced, but jdk/hs
>> is not. So jdk/jdk should be OK, but jdk/hs is not buildable so far.
> Oh dear.
> 
> I am afraid I messed up by pushing the patch for 8195685 to both
> jdkdev/jdk and jdkdev/hs. While the former was correct and approved by
> Vladimir the latter was a stupid neglect of the appropriate protocol on
> my part. Apologies for making such a mess.
> 
> Is there a recommended way to revert this change?
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

From alex.buckley at oracle.com  Tue Jan 23 20:21:38 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 23 Jan 2018 12:21:38 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <502575277.632297.1516696508787.JavaMail.zimbra@u-pem.fr>
References: <5A624C97.3020408@oracle.com>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
 <502575277.632297.1516696508787.JavaMail.zimbra@u-pem.fr>
Message-ID: <5A679952.8030906@oracle.com>

On 1/23/2018 12:35 AM, Remi Forax wrote:
> Let's say I want to use the incubating features, i test with spring
> and it blows up, let say i'm a good citizen and i report the issue to
> the spring bug tracker, what will be the answer ? 1) ok, let's see
> all our dependencies where we have the wrong assumption that the
> classfile version is equivalent to the major version. 2) it's an
> incubating class, we do not support them.
>
> and perhaps using Spring is the wrong example, because they are very
> active in the community, so may be they will come with a patch.
> Nevertheless, changing the classfile version semantics goes against
> the adoption of the very feature you want to promote.

It's not a goal that Spring (or more likely, the bytecode tools that 
Spring uses) can instantly understand class files which contain 
incubating content. Adoption will not be free. For example, the 
incubating content might be a (previously unused) bit in 
ClassFile.access_flags that signifies "This is a data class, so the VM 
should generate equals/hashCode methods under circumstances X and Y ... 
oh, and super_class need not point to a CONSTANT_Class_info." As we said 
earlier, the application (Spring) will have to be fixed to handle the 
novel classes it now sees being returned from bytecode tools. The 0xffff 
minor_version is just the canary in the coalmine -- a ClassFile with 
major.minor 55.0 and ACC_INCUBATOR lurking in access_flags is just as 
much trouble for pre-11 frameworks/tools as a ClassFile with 55.0xffff. 
Ultimately, none of these signals can guarantee that incubating classes 
are treated right by every application and tool, so we'll use the simple 
and direct mechanism of minor_version.

I'll clarify in the JEP that the reason why ClassFile.access_flags is 
not used to signal incubation is because the joint set of flags in 
ClassFile/field_info/method_info is (i) already very busy (_every_ 
bitmask is already allocated to some flag) and (ii) should be reserved 
for actual class/field/method properties rather than the "meta" property 
of incubation.

Alex

From mark.reinhold at oracle.com  Tue Jan 23 20:33:43 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 23 Jan 2018 12:33:43 -0800 (PST)
Subject: JDK submit repo
Message-ID: <20180123203343.45042150D72@eggemoggin.niobe.net>

The submit repo is now open for pushes from any JDK Committer:

  http://hg.openjdk.java.net/jdk/submit

If you push a branch whose name starts with "JDK-" into this repo
then it will automatically be built and tested on Oracle's internal
build system, and a summary of the results will be e-mailed back to
you.  This typically takes a couple of hours.  If one or more tests
fail then you can contact an Oracle engineer to get more information
about the failures.

The default branch of the submit repo is automatically kept in sync
with the main-line repo, jdk/jdk.

This is (obviously) not the complete open build-and-test system that
we'd all like to see in the long run, but until we have such a system
it will hopefully help us be a bit more productive.

More information:

  https://wiki.openjdk.java.net/display/Build/Submit+Repo

(Unlike the first prototype, which some of you helped to test last
 summer, this version does not automatically push your change into
 some other repo if all the tests pass, and there are no plans to
 implement that feature due to recent build-system changes.)

- Mark

From alex.buckley at oracle.com  Tue Jan 23 20:52:32 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 23 Jan 2018 12:52:32 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <CA+3eh13q8ZKGEj7zpekHZ6SQZjQ34807g0mq4qnB1H8Qye9JYA@mail.gmail.com>
References: <5A624C97.3020408@oracle.com>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
 <CA+3eh13q8ZKGEj7zpekHZ6SQZjQ34807g0mq4qnB1H8Qye9JYA@mail.gmail.com>
Message-ID: <5A67A090.1040204@oracle.com>

On 1/22/2018 4:46 PM, Volker Simonis wrote:
> 1. You don?t mention long- and short-term realeases in the JEP at all. I
> know you argue that wether a release is long- or a short-term one is a
> vendor and not a standards/specification question - and I can agree with
> that opinion.
>
> Nevertheless I think it would be strange to introduce an incubating
> feature in a long term release (say Java 11), then refine it in Java 12
> and make it persistent in Java 13. In reality, Java 11 will be supported
> for at least 3 years or more, but 12 and 13 for six month only. So the
> old, deprecated version of the incubating feature from Java 11 will
> probably get a much higher adoption than the final one from Java 12 and
> 13 (at least until the next long term release). I think we can already
> see that adoption of short-term releases is quite low in the industry
> (everybody is waiting for Java 11).

As you say, vendor issues such as support, certification, and training 
are not discussed in the JEP. Your comments are well taken nonetheless.

> Furthermore, while understandable, the claim that a version N+1 isn?t
> allowed to support the incubating feature of version N will even further
> decrease the adoption rate of short term releases if they differ
> incubating feature wise.

If Java SE N+1 chooses to drop a feature that was incubating in Java SE 
N, then presumably there is a reason for that. Maybe the feature 
re-incubates in N+1 and is much more popular and people flock to N+1.

> Finally, the JEP doesn?t specify if version N may (silently or
> explicitly) support version N+1?s incubating features. This may be
> attractive for LTS releases.

If Java SE N had no notion of feature X, and Java SE N+1 introduced X as 
an incubating feature, then there is no realistic possibility of doing a 
Maintenance Release of SE N to add an incubating feature X.

> I don?t know how this dilemma could be solved, but I think in reality it
> will make a significant difference if an incubating feature will be
> introduced in a long- or short-term release.

Understood.

> 2. You use the example of the ?_? character to advertise the incubating
> features as a means to change the Java platform faster (i.e. within the
> course of one instead of two major releases) in a backwards incompatible
> way. Not sure everybody will see that as a desirable feature. Especially
> not if that means within 6 month!

I accept it's not an exciting incubating feature even for people who 
wish the Java language would remove features faster, but it has the 
benefit of mapping directly to something we really did, and in 
timeframes (JDK 8 and 9) that people readily recall. Obviously the 
faster cadence will affect the release of all incubating content 
(incubating APIs in incubator modules as well as incubating language/VM 
features).

> 3. You write that the decision wether an incubating feature should
> become permanent is ?left to the judgment and expertise of the Spec.
> Lead of the Java SE Platform?. Shouldn?t that actually be decided by the
> corresponding JSR Expert Group and the JCP EC?

I meant to write "... the Spec Lead of the Umbrella JSR for the Java SE 
$N+1 Platform", who of course takes the decision in consultation with 
the Expert Group of that JSR. Nothing in this JEP should be interpreted 
as changing how Umbrella JSRs go through the JCP.

Alex

From alex.buckley at oracle.com  Tue Jan 23 20:59:10 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 23 Jan 2018 12:59:10 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <37c88586-12fc-1fbf-9a3a-c1d579bb4f8c@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
 <37c88586-12fc-1fbf-9a3a-c1d579bb4f8c@oracle.com>
Message-ID: <5A67A21E.2020306@oracle.com>

On 1/23/2018 2:44 AM, Alan Bateman wrote:
> The case where an incubating language or VM feature relies on (or
> "associated informally with") an incubating API is clear - the VM must
> resolve the module with the API that the feature depends on (the
> jdk.incubator.strings module and its classfile package is a good
> example). The other direction, where an incubating module contains code
> that relies on an incubating language or VM feature isn't as clear - are
> all bits in the minor_version field of the module-info.class all set or
> maybe the JDK-specific ModuleResolution attribute has a flag to indicate
> that it needs the VM to run with support for incubating VM features
> enabled? I'm asking because there it wouldn't be hard to check the
> mismatch at startup o avoid a CFE some time later.

I understand the scenario, plus there are other enhancements we need to 
discuss for incubating APIs, to better link them to incubating language 
and VM features. But let's cross those bridges later.

> The "Run time" shows the java launcher taking a flag to enable the
> support. A detail for this section is that it will likely be a VM option
> rather than a java launcher option (users of the java launcher will not
> see the difference). This is because every VM is required to support a
> way to enable incubating VM features so it has to be enabled when
> creating the VM (JNI CreateJavaVM etc.).

OK.

> The JEP is SE scope but I assume a few JDK or OpenJDK topics will come
> up. Are jtreg enhancements useful to support compiling and running
> tests? Do we want jlink to support including modules that depend on
> incubating VM features?

Maybe, but let's get the JEP submitted first.

Alex

From maaartinus at gmail.com  Wed Jan 24 01:48:49 2018
From: maaartinus at gmail.com (Martin Grajcar)
Date: Wed, 24 Jan 2018 02:48:49 +0100
Subject: Missing trivial optimization in String equals
In-Reply-To: <2d1717b3-8dc9-7a03-5bb4-7b5de36c81bf@oracle.com>
References: <CAGsWfGi4g_cNY=eS1W=FRDoJHtybtruRb_XrUPPhCpKgMxzAWw@mail.gmail.com>
 <2d1717b3-8dc9-7a03-5bb4-7b5de36c81bf@oracle.com>
Message-ID: <CAGsWfGj47xK=gA-36mkLptsLbCR-DyST_DyH8kBAXmTSqyxeXw@mail.gmail.com>

Hi!

On Tue, Jan 23, 2018 at 1:13 AM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi,
>
> do you have an example application that is spending significant time
> comparing the contents of such identical arrays and would benefit?


no, it was just a random idea.

I would
> guess such comparisons are about twice as fast as typical ones due to
> having to load half as much from memory. ;-)
>

Actually, no data has to be loaded if the arrays are the same object.
It's simple O(1) test, which may or may not save an O(n) test.


> If there's a valid optimization case, though, then it would only be
> realizable when UseStringDeduplication is enabled. Thus it's crucial not
> to regress all the other cases that won't benefit (Parallel, Serial, ...),
> and as String::equals is often a very hot method then even a few added
> instructions that only compare data we've already loaded into registers
> might be too much. Or maybe not.
>

Sure, without deduplication switched on, the test is completely pointless.
Otherwise, the more deduplication gets done, the more useful is may get.

As String::equals is routinely replaced by a C2 intrinsic[1] that's
> where we should look to optimize (not so much in the JDK library code).
>

Thank you, I knew, it happens, but didn't know where.
However, it's the @HotSpotIntrinsicCandidate methods in StringLatin1
and StringUTF16, what gets intrinsified,
but I'd suggest to put the test just before the coder comparison at line
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
share/classes/java/lang/String.java#l1020
in order to maximize the possible gain.
There's no reason to test the coder when the arrays happen to be the same
object
as this is only possible due to the deduplication, which tests it already.


> I think it'd be straightforward to train that intrinsic to only emit the
> test when the related feature is enabled. Maybe the kind folks over at
> hotspot-compiler-dev at openjdk.java.net might be able to give some pointers.
> If so I'd invite you to set up a set of experiments and see if this can
> have a benefit.
>

Because of the intrinsic being tied to the concrete methods rather than to
the code inside,
I'd have to modify and compile the JVM sources, which needs way more time
than I can spend on it in the moment. :(
A benchmark written using a copy of the method would be too unrealistic,
as the copied comparison uses no intrinsic and is much slower (
https://stackoverflow.com/q/15586997/581205).

Anyway, we know, that an arbitrary high speed up is possible as the O(n)
comparison gets eliminated.
A benchmark showing this can surely be constructed,
but what has to be measured is the tiny slowdown in cases when it doesn't
help
and that needs to re-run existing benchmarks.

Actually, I'd propose something more fancy (added two more independent
trivial optimization ideas):

    public boolean equals(Object anObject) {
        if (this == anObject) {
            return true;
        }
        if (anObject instanceof String) {
            String aString = (String)anObject;

            // IDEA 1 - as discussed above
            // USE_STRING_DEDUPLICATION is a constant to be eliminated by
JIT
            // just like it happens with COMPACT_STRINGS [2].
            if (USE_STRING_DEDUPLICATION && value == aString.value) {
                // We know that the coders are the same here.
                return true;
            }

            // IDEA 2 - add a trivial test possibly avoiding the loop
            // Testing the length first because of it being more probable
to differ.
            if (value.length == aString.value.length && coder() ==
aString.coder()) {

                // IDEA 3 - remove a needless test of coder()
                // Not testing the coder as all we need is byte array
content equality.
                // StringLatin1.equals is applicable for UTF-8, too.
                return StringLatin1.equals(value, aString.value);
            }
        }
        return false;
    }

Regards,
Martin.

[2]:
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/share/classes/java/lang/String.java#l197

Regards
>
> /Claes
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/file/e1876e6b57b6/src/hot
> spot/share/opto/library_call.cpp#l1116
>
>
>
> On 2018-01-23 00:14, Martin Grajcar wrote:
>
>> It looks like when testing equality of Strings, there's no test if the two
>> arrays are actually the same object. This was impossible before Java 8u20
>> (as no two strings used to share arrays), but it's well possible with
>> -XX:+UseStringDeduplication.
>>
>> Maybe someone here cares...
>>
>> Regards,
>> Martin.
>>
>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811
>> /src/java.base/
>> share/classes/java/lang/String.java#l1014
>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811
>> /src/java.base/
>> share/classes/java/lang/StringLatin1.java#l89
>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811
>> /src/java.base/
>> share/classes/java/lang/StringUTF16.java#l258
>>
>
>

From forax at univ-mlv.fr  Wed Jan 24 07:25:38 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 24 Jan 2018 08:25:38 +0100 (CET)
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A679952.8030906@oracle.com>
References: <5A624C97.3020408@oracle.com> <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
 <502575277.632297.1516696508787.JavaMail.zimbra@u-pem.fr>
 <5A679952.8030906@oracle.com>
Message-ID: <1134978037.1134609.1516778738572.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> ?: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Mardi 23 Janvier 2018 21:21:38
> Objet: Re: Draft JEP: Incubating Language and VM Features

> On 1/23/2018 12:35 AM, Remi Forax wrote:
>> Let's say I want to use the incubating features, i test with spring
>> and it blows up, let say i'm a good citizen and i report the issue to
>> the spring bug tracker, what will be the answer ? 1) ok, let's see
>> all our dependencies where we have the wrong assumption that the
>> classfile version is equivalent to the major version. 2) it's an
>> incubating class, we do not support them.
>>
>> and perhaps using Spring is the wrong example, because they are very
>> active in the community, so may be they will come with a patch.
>> Nevertheless, changing the classfile version semantics goes against
>> the adoption of the very feature you want to promote.
> 
> It's not a goal that Spring (or more likely, the bytecode tools that
> Spring uses) can instantly understand class files which contain
> incubating content.

If you change the minor version, you do not need to only update the bytecode tool but also modify the classes of Spring that uses the bytecode tool.

> Adoption will not be free. For example, the
> incubating content might be a (previously unused) bit in
> ClassFile.access_flags that signifies "This is a data class, so the VM
> should generate equals/hashCode methods under circumstances X and Y ...
> oh, and super_class need not point to a CONSTANT_Class_info." As we said
> earlier, the application (Spring) will have to be fixed to handle the
> novel classes it now sees being returned from bytecode tools. The 0xffff
> minor_version is just the canary in the coalmine -- a ClassFile with
> major.minor 55.0 and ACC_INCUBATOR lurking in access_flags is just as
> much trouble for pre-11 frameworks/tools as a ClassFile with 55.0xffff.
> Ultimately, none of these signals can guarantee that incubating classes
> are treated right by every application and tool, so we'll use the simple
> and direct mechanism of minor_version.
> 
> I'll clarify in the JEP that the reason why ClassFile.access_flags is
> not used to signal incubation is because the joint set of flags in
> ClassFile/field_info/method_info is (i) already very busy (_every_
> bitmask is already allocated to some flag) and (ii) should be reserved
> for actual class/field/method properties rather than the "meta" property
> of incubation.
> 
> Alex

Anyway, i think that changing the minor version is not the best choice but i do not think it's necessary to discuss more on the classfile representation of this feature, let's move on :)

R?mi
 

 

From volker.simonis at gmail.com  Wed Jan 24 08:24:19 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 24 Jan 2018 09:24:19 +0100
Subject: JDK submit repo
In-Reply-To: <20180123203343.45042150D72@eggemoggin.niobe.net>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
Message-ID: <CA+3eh12OPnLmmDC=gJQ+YT5Wa+ctHJyHQ7M-ckch-ZGC+8AQ1w@mail.gmail.com>

On Tue, Jan 23, 2018 at 9:33 PM,  <mark.reinhold at oracle.com> wrote:
> The submit repo is now open for pushes from any JDK Committer:
>
>   http://hg.openjdk.java.net/jdk/submit
>

Hi Mark,

thanks a lot for pushing this forward!

> If you push a branch whose name starts with "JDK-" into this repo
> then it will automatically be built and tested on Oracle's internal
> build system, and a summary of the results will be e-mailed back to
> you.  This typically takes a couple of hours.  If one or more tests
> fail then you can contact an Oracle engineer to get more information
> about the failures.
>
> The default branch of the submit repo is automatically kept in sync
> with the main-line repo, jdk/jdk.
>
> This is (obviously) not the complete open build-and-test system that
> we'd all like to see in the long run, but until we have such a system
> it will hopefully help us be a bit more productive.
>
> More information:
>
>   https://wiki.openjdk.java.net/display/Build/Submit+Repo
>
> (Unlike the first prototype, which some of you helped to test last
>  summer, this version does not automatically push your change into
>  some other repo if all the tests pass, and there are no plans to
>  implement that feature due to recent build-system changes.)
>

The FAQ says:

Q: If all the tests pass, will my change be automatically be pushed to
the main-line JDK repo?
A: No. You'll need to do that yourself.

So what does that mean. If I have a hotspot change and all the tests
pass, am I now allowed to push that myself ?

If the answer is "yes", there's still the problem that hotspot changes
should go into jdk/hs but the submit repo mirrors jdk/jdk so what I've
tested in the submit repo might be slightly different from what I will
actually push.

If the answer is "no", than when will we finally get there ?

The other question applies for changes which touch any of the
configure files and require the re-generation of
generated-configure.sh. If such a change passes all tests in the
submit repo, can I push it into the jdk/jdk myself or do I still need
a sponsor?

Thank you and best regards,
Volker

> - Mark

From volker.simonis at gmail.com  Wed Jan 24 09:30:16 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 24 Jan 2018 10:30:16 +0100
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A67A090.1040204@oracle.com>
References: <5A624C97.3020408@oracle.com>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
 <CA+3eh13q8ZKGEj7zpekHZ6SQZjQ34807g0mq4qnB1H8Qye9JYA@mail.gmail.com>
 <5A67A090.1040204@oracle.com>
Message-ID: <CA+3eh10nZrY=+oa5cCYtgQeZhg3ugDzcpJ1P2X7inmoSOcUySA@mail.gmail.com>

On Tue, Jan 23, 2018 at 9:52 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> On 1/22/2018 4:46 PM, Volker Simonis wrote:
>>
>> 1. You don?t mention long- and short-term realeases in the JEP at all. I
>> know you argue that wether a release is long- or a short-term one is a
>> vendor and not a standards/specification question - and I can agree with
>> that opinion.
>>
>> Nevertheless I think it would be strange to introduce an incubating
>> feature in a long term release (say Java 11), then refine it in Java 12
>> and make it persistent in Java 13. In reality, Java 11 will be supported
>> for at least 3 years or more, but 12 and 13 for six month only. So the
>> old, deprecated version of the incubating feature from Java 11 will
>> probably get a much higher adoption than the final one from Java 12 and
>> 13 (at least until the next long term release). I think we can already
>> see that adoption of short-term releases is quite low in the industry
>> (everybody is waiting for Java 11).
>
>
> As you say, vendor issues such as support, certification, and training are
> not discussed in the JEP. Your comments are well taken nonetheless.
>
>> Furthermore, while understandable, the claim that a version N+1 isn?t
>> allowed to support the incubating feature of version N will even further
>> decrease the adoption rate of short term releases if they differ
>> incubating feature wise.
>
>
> If Java SE N+1 chooses to drop a feature that was incubating in Java SE N,
> then presumably there is a reason for that. Maybe the feature re-incubates
> in N+1 and is much more popular and people flock to N+1.
>
>> Finally, the JEP doesn?t specify if version N may (silently or
>> explicitly) support version N+1?s incubating features. This may be
>> attractive for LTS releases.
>
>
> If Java SE N had no notion of feature X, and Java SE N+1 introduced X as an
> incubating feature, then there is no realistic possibility of doing a
> Maintenance Release of SE N to add an incubating feature X.
>

I don't meant to do this in a "Maintenance Release of SE N". The
question was if a Java vendor can do that in his implementation of
"Java N" if that implementation still passes the "Java N TCK".

As an example take LVTI (JEP 286) which will come in Java 10. Can I
support that in my Java 9 VM ? I'm pretty sure I will pass all the TCK
9 tests even if I don't hide the feature behind a flag, because TCK N
can not realistically test that a Java N implementation doesn't
support N+1 features (because at the time TCK N was written, the
feature in question may have not even existed).

For features which extend the public API, that's a little different,
because the TCK does test that Java N only exports the Java N public
APIs and nothing more. But I could still support new N+1 features and
hide them behind a flag which I don't use during certification. I
could even use the "--incubating" flag for that purpose, because from
my understanding the flag is just mentioned as an example in the JEP
and will not be part of the Java SE standard.

Would such an approach be acceptable?

>> I don?t know how this dilemma could be solved, but I think in reality it
>> will make a significant difference if an incubating feature will be
>> introduced in a long- or short-term release.
>
>
> Understood.
>
>> 2. You use the example of the ?_? character to advertise the incubating
>> features as a means to change the Java platform faster (i.e. within the
>> course of one instead of two major releases) in a backwards incompatible
>> way. Not sure everybody will see that as a desirable feature. Especially
>> not if that means within 6 month!
>
>
> I accept it's not an exciting incubating feature even for people who wish
> the Java language would remove features faster, but it has the benefit of
> mapping directly to something we really did, and in timeframes (JDK 8 and 9)
> that people readily recall. Obviously the faster cadence will affect the
> release of all incubating content (incubating APIs in incubator modules as
> well as incubating language/VM features).
>
>> 3. You write that the decision wether an incubating feature should
>> become permanent is ?left to the judgment and expertise of the Spec.
>> Lead of the Java SE Platform?. Shouldn?t that actually be decided by the
>> corresponding JSR Expert Group and the JCP EC?
>
>
> I meant to write "... the Spec Lead of the Umbrella JSR for the Java SE $N+1
> Platform", who of course takes the decision in consultation with the Expert
> Group of that JSR. Nothing in this JEP should be interpreted as changing how
> Umbrella JSRs go through the JCP.
>
> Alex

From dalibor.topic at oracle.com  Wed Jan 24 10:04:46 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 24 Jan 2018 11:04:46 +0100
Subject: JDK submit repo
In-Reply-To: <20180123203343.45042150D72@eggemoggin.niobe.net>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
Message-ID: <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>



On 23.01.2018 21:33, mark.reinhold at oracle.com wrote:
> If you push a branch whose name starts with "JDK-" into this repo
> then it will automatically be built and tested on Oracle's internal
> build system, and a summary of the results will be e-mailed back to
> you.  This typically takes a couple of hours.  If one or more tests
> fail then you can contact an Oracle engineer to get more information
> about the failures.

Since the wiki

* doesn't say how to contact that engineer
* doesn't say how to work with them

that might be a hurdle too steep in some cases.

As the only contact given on the wiki is ops at openjdk, I assume it will 
get more than its fair share of test failures to forward through email 
chains in search of that engineer. That would be unfortunate.

Instead, I would suggest explicitly advising Comitters with test 
failures to forward them to the jdk-dev mailing list in search of an 
Oracle engineer.

Or, ideally, the system could simply send those e-mails announcing 
failures to the Committer with a CC: to jdk-dev, taking out the manual 
part of Oracle engineer search and forwarding e-mails around out of the 
process.

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 david.holmes at oracle.com  Wed Jan 24 10:25:16 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 Jan 2018 20:25:16 +1000
Subject: JDK submit repo
In-Reply-To: <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
Message-ID: <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>

On 24/01/2018 8:04 PM, dalibor topic wrote:
> On 23.01.2018 21:33, mark.reinhold at oracle.com wrote:
>> If you push a branch whose name starts with "JDK-" into this repo
>> then it will automatically be built and tested on Oracle's internal
>> build system, and a summary of the results will be e-mailed back to
>> you.? This typically takes a couple of hours.? If one or more tests
>> fail then you can contact an Oracle engineer to get more information
>> about the failures.
> 
> Since the wiki
> 
> * doesn't say how to contact that engineer
> * doesn't say how to work with them
> 
> that might be a hurdle too steep in some cases.
> 
> As the only contact given on the wiki is ops at openjdk, I assume it will 
> get more than its fair share of test failures to forward through email 
> chains in search of that engineer. That would be unfortunate.
> 
> Instead, I would suggest explicitly advising Comitters with test 
> failures to forward them to the jdk-dev mailing list in search of an 
> Oracle engineer.

I would not advise that as not all engineers hang out on jdk-dev. Rather 
they should forward to xxx-dev where xxx relates to the component on 
which they were working: hotspot-dev, hotspot-runtime-dev, 
core-libs-dev, net-dev etc

> Or, ideally, the system could simply send those e-mails announcing 
> failures to the Committer with a CC: to jdk-dev, taking out the manual 
> part of Oracle engineer search and forwarding e-mails around out of the 
> process.

Please no! :)

The way I see this working is as follows:

- contributor works on a fix and gets it working locally on whatever 
systems they have available to them
- contributor then wants to test further and so submits to submit repo
- contributor gets response email:
a) all good: contributor sends RFR to xxx-dev
b) not all good: contributor sends prelim-RFR to xxx-dev and includes 
failure info, and waits for help on the failures

Cheers,
David
------

> cheers,
> dalibor topic
> 

From jesper.wilhelmsson at oracle.com  Wed Jan 24 11:11:21 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 24 Jan 2018 12:11:21 +0100
Subject: JDK submit repo
In-Reply-To: <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
 <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
Message-ID: <FB0CB5D8-9A35-4B83-BCDE-7624FF38BA05@oracle.com>


> On 24 Jan 2018, at 11:25, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 24/01/2018 8:04 PM, dalibor topic wrote:
>> On 23.01.2018 21:33, mark.reinhold at oracle.com wrote:
>>> If you push a branch whose name starts with "JDK-" into this repo
>>> then it will automatically be built and tested on Oracle's internal
>>> build system, and a summary of the results will be e-mailed back to
>>> you.  This typically takes a couple of hours.  If one or more tests
>>> fail then you can contact an Oracle engineer to get more information
>>> about the failures.
>> Since the wiki
>> * doesn't say how to contact that engineer
>> * doesn't say how to work with them
>> that might be a hurdle too steep in some cases.
>> As the only contact given on the wiki is ops at openjdk, I assume it will get more than its fair share of test failures to forward through email chains in search of that engineer. That would be unfortunate.
>> Instead, I would suggest explicitly advising Comitters with test failures to forward them to the jdk-dev mailing list in search of an Oracle engineer.
> 
> I would not advise that as not all engineers hang out on jdk-dev. Rather they should forward to xxx-dev where xxx relates to the component on which they were working: hotspot-dev, hotspot-runtime-dev, core-libs-dev, net-dev etc
> 
>> Or, ideally, the system could simply send those e-mails announcing failures to the Committer with a CC: to jdk-dev, taking out the manual part of Oracle engineer search and forwarding e-mails around out of the process.
> 
> Please no! :)

+1

I don't think we should assume that every single test failure will need Oracle assistance. It's quite likely that developers will send their code through the system more than once before deciding to go ask for help.
/Jesper

> 
> The way I see this working is as follows:
> 
> - contributor works on a fix and gets it working locally on whatever systems they have available to them
> - contributor then wants to test further and so submits to submit repo
> - contributor gets response email:
> a) all good: contributor sends RFR to xxx-dev
> b) not all good: contributor sends prelim-RFR to xxx-dev and includes failure info, and waits for help on the failures
> 
> Cheers,
> David
> ------
> 
>> cheers,
>> dalibor topic


From adinn at redhat.com  Wed Jan 24 11:18:41 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 24 Jan 2018 11:18:41 +0000
Subject: JDK submit repo
In-Reply-To: <20180123203343.45042150D72@eggemoggin.niobe.net>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
Message-ID: <924e4487-1ae9-e9f5-7e6e-83dc69704d34@redhat.com>

On 23/01/18 20:33, mark.reinhold at oracle.com wrote:
> The submit repo is now open for pushes from any JDK Committer:
> 
>   http://hg.openjdk.java.net/jdk/submit
Hurrah!

> This is (obviously) not the complete open build-and-test system that
> we'd all like to see in the long run, but until we have such a system
> it will hopefully help us be a bit more productive.

True but, nevertheless, thanks very much for setting this up. I am sure
it will be very helpful.

regards,


Andrew Dinn
-----------


From shade at redhat.com  Wed Jan 24 12:00:49 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 24 Jan 2018 13:00:49 +0100
Subject: JDK submit repo
In-Reply-To: <20180123203343.45042150D72@eggemoggin.niobe.net>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
Message-ID: <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com>

On 01/23/2018 09:33 PM, mark.reinhold at oracle.com wrote:
> The submit repo is now open for pushes from any JDK Committer:
> 
>   http://hg.openjdk.java.net/jdk/submit
> 
> If you push a branch whose name starts with "JDK-" into this repo
> then it will automatically be built and tested on Oracle's internal
> build system, and a summary of the results will be e-mailed back to
> you.  This typically takes a couple of hours.  If one or more tests
> fail then you can contact an Oracle engineer to get more information
> about the failures.

Excellent, thank you! Trying it now!

> The default branch of the submit repo is automatically kept in sync
> with the main-line repo, jdk/jdk.

Which gives us the important tip for dealing with uber-large monorepo: clone/copy the jdk/jdk repo
from somewhere local, update .hg/hgrc to point to jdk/submit, and hg pull the updates. This saves
significant amount of time and bandwidth, especially if checking out from Europe.

Alternatively, you can pick up the workspace tarball from here:
  https://builds.shipilev.net/workspaces/jdk-submit.tar.xz

> This is (obviously) not the complete open build-and-test system that
> we'd all like to see in the long run, but until we have such a system
> it will hopefully help us be a bit more productive.

This thing look oddly similar to JDK Sandbox. For the features that are already in Sandbox under the
named branches, does it make sense to provide the same kind of service? The push to Sandbox does not
always means push to testing system though. Maybe we can split "push" and "request-to-run"?

E.g. can committers have the interface to request the testing run for a given forest+branch within
hg.openjdk.java.net? This will cover projects that have their own repos, projects that have named
branches in JDK Sandbox, and JDK Submit repository would be the dumping ground for simpler transient
work that does not exist in any repo yet. This will also avoid contaminating JDK Submit repository
with lots of code (e.g. putting the *entire* multi-KLOC JDK project under the branch there?).

Committers already have SSH keys set up, so CLI might be the easiest answer, like this:

 $ ssh shade at submit.openjdk.java.net submit http://hg.openjdk.java.net/amber/amber/ condy

It also opens up the way to print gross sanity-check errors right away, provide options for the run,
reject some things right away, etc. Pretty sure it would be the very same code that is now ran by
Mercurial repo hooks or whatever?

Thanks,
-Aleksey



From yasuenag at gmail.com  Wed Jan 24 12:25:23 2018
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 24 Jan 2018 21:25:23 +0900
Subject: JDK submit repo
In-Reply-To: <20180123203343.45042150D72@eggemoggin.niobe.net>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
Message-ID: <8d355b02-e667-7dc7-50de-599243ae0389@gmail.com>

On 2018/01/24 5:33, mark.reinhold at oracle.com wrote:
> The submit repo is now open for pushes from any JDK Committer:
> 
>    http://hg.openjdk.java.net/jdk/submit
> 
> If you push a branch whose name starts with "JDK-" into this repo
> then it will automatically be built and tested on Oracle's internal
> build system, and a summary of the results will be e-mailed back to
> you.  This typically takes a couple of hours.

I think it is very good news for non-oracle committers - like me!

> If one or more tests
> fail then you can contact an Oracle engineer to get more information
> about the failures.
> 
> The default branch of the submit repo is automatically kept in sync
> with the main-line repo, jdk/jdk.
> 
> This is (obviously) not the complete open build-and-test system that
> we'd all like to see in the long run, but until we have such a system
> it will hopefully help us be a bit more productive.

I hope that non-oracle committers can access test result directly.
We might encounter the failure in some time. If so, I want to fix it rapidly and want to rerun the test. (It might be failed :-)


Thanks,

Yasumasa


> More information:
> 
>    https://wiki.openjdk.java.net/display/Build/Submit+Repo
> 
> (Unlike the first prototype, which some of you helped to test last
>   summer, this version does not automatically push your change into
>   some other repo if all the tests pass, and there are no plans to
>   implement that feature due to recent build-system changes.)
> 
> - Mark
> 

From jesper.wilhelmsson at oracle.com  Wed Jan 24 13:21:40 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 24 Jan 2018 14:21:40 +0100
Subject: JDK submit repo
In-Reply-To: <CA+3eh12OPnLmmDC=gJQ+YT5Wa+ctHJyHQ7M-ckch-ZGC+8AQ1w@mail.gmail.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <CA+3eh12OPnLmmDC=gJQ+YT5Wa+ctHJyHQ7M-ckch-ZGC+8AQ1w@mail.gmail.com>
Message-ID: <14D77EEF-9589-4A2B-9DBE-522A3DFBB53C@oracle.com>

Hi Volker,

> The FAQ says:
> 
> Q: If all the tests pass, will my change be automatically be pushed to
> the main-line JDK repo?
> A: No. You'll need to do that yourself.
> 
> So what does that mean. If I have a hotspot change and all the tests
> pass, am I now allowed to push that myself ?
> 

This is not a complete answer, but I'm working on it.

Currently the set of tests run in JDK submit does not include all the HotSpot tests that we run on all pushes in jdk/hs. My hope is that we will be able to sync that going forward to make the JDK submit more useful for HotSpot developers.

Internally we do no longer use the JPRT pre-commit test system that some may have heard of in the past. Instead we use post-commit continuous integration (CI) that is running several tiers of tests. This is one step closer to allowing non-Oracle Contributors to push HotSpot code directly. Once the JDK submit runs all required HotSpot CI tiers we will be almost there.

> If the answer is "yes", there's still the problem that hotspot changes
> should go into jdk/hs but the submit repo mirrors jdk/jdk so what I've
> tested in the submit repo might be slightly different from what I will
> actually push.

This is another problem. I'm trying to enable more frequent integrations between jdk/jdk and jdk/hs, but currently there is up to a week delay in getting changes from hs to jdk. Again it is a question of when and where we run different HotSpot tiers.

You could pull the latest HotSpot changes into your branch before sending it to JDK submit I guess.

/Jesper

> 
> If the answer is "no", than when will we finally get there ?
> 
> The other question applies for changes which touch any of the
> configure files and require the re-generation of
> generated-configure.sh. If such a change passes all tests in the
> submit repo, can I push it into the jdk/jdk myself or do I still need
> a sponsor?
> 
> Thank you and best regards,
> Volker
> 
>> - Mark


From dalibor.topic at oracle.com  Wed Jan 24 13:29:05 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 24 Jan 2018 14:29:05 +0100
Subject: JDK submit repo
In-Reply-To: <FB0CB5D8-9A35-4B83-BCDE-7624FF38BA05@oracle.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
 <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
 <FB0CB5D8-9A35-4B83-BCDE-7624FF38BA05@oracle.com>
Message-ID: <869559fb-623e-935f-fa87-1b8c84dd9e31@oracle.com>

On 24.01.2018 12:11, jesper.wilhelmsson at oracle.com wrote:
> It's quite likely that developers will send their code through the system more than once before deciding to go ask for help.

Considering that "A job usually takes a couple of hours to complete.", 
that effectively means you have at best up to four 'shots' at getting 
code through the system in an eight hour work day.

So I suspect a many Committers will find it more effective to ask for 
help from an Oracle engineer right after the initial failure, rather 
then resubmitting the code (unchanged ?) repeatedly, and hoping for the 
best.

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 charlie.hunt at oracle.com  Wed Jan 24 13:37:04 2018
From: charlie.hunt at oracle.com (charlie hunt)
Date: Wed, 24 Jan 2018 07:37:04 -0600
Subject: Missing trivial optimization in String equals
In-Reply-To: <CAGsWfGj47xK=gA-36mkLptsLbCR-DyST_DyH8kBAXmTSqyxeXw@mail.gmail.com>
References: <CAGsWfGi4g_cNY=eS1W=FRDoJHtybtruRb_XrUPPhCpKgMxzAWw@mail.gmail.com>
 <2d1717b3-8dc9-7a03-5bb4-7b5de36c81bf@oracle.com>
 <CAGsWfGj47xK=gA-36mkLptsLbCR-DyST_DyH8kBAXmTSqyxeXw@mail.gmail.com>
Message-ID: <AB1982D6-84E9-46D2-950C-8E22825FD74D@oracle.com>

Hi Martin,

In short, the string equals methods for StringLatin1 and StringUTF16 methods have instrinsics that compare their respective array lengths.

Long strong, there was an enormous amount of optimization work (many intrinsics) implemented and re-worked on the String object for the Compact Strings feature (http://openjdk.java.net/jeps/254 <http://openjdk.java.net/jeps/254>) in JDK 9.
To drive that optimization work, there was a lot of String microbenchmarks and analysis done. You can find performance analysis information on String.equals() at http://cr.openjdk.java.net/~shade/density/equals.txt <http://cr.openjdk.java.net/~shade/density/equals.txt>.

hths,

charlie

> On Jan 23, 2018, at 7:48 PM, Martin Grajcar <maaartinus at gmail.com> wrote:
> 
> Hi!
> 
> On Tue, Jan 23, 2018 at 1:13 AM, Claes Redestad <claes.redestad at oracle.com>
> wrote:
> 
>> Hi,
>> 
>> do you have an example application that is spending significant time
>> comparing the contents of such identical arrays and would benefit?
> 
> 
> no, it was just a random idea.
> 
> I would
>> guess such comparisons are about twice as fast as typical ones due to
>> having to load half as much from memory. ;-)
>> 
> 
> Actually, no data has to be loaded if the arrays are the same object.
> It's simple O(1) test, which may or may not save an O(n) test.
> 
> 
>> If there's a valid optimization case, though, then it would only be
>> realizable when UseStringDeduplication is enabled. Thus it's crucial not
>> to regress all the other cases that won't benefit (Parallel, Serial, ...),
>> and as String::equals is often a very hot method then even a few added
>> instructions that only compare data we've already loaded into registers
>> might be too much. Or maybe not.
>> 
> 
> Sure, without deduplication switched on, the test is completely pointless.
> Otherwise, the more deduplication gets done, the more useful is may get.
> 
> As String::equals is routinely replaced by a C2 intrinsic[1] that's
>> where we should look to optimize (not so much in the JDK library code).
>> 
> 
> Thank you, I knew, it happens, but didn't know where.
> However, it's the @HotSpotIntrinsicCandidate methods in StringLatin1
> and StringUTF16, what gets intrinsified,
> but I'd suggest to put the test just before the coder comparison at line
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
> share/classes/java/lang/String.java#l1020
> in order to maximize the possible gain.
> There's no reason to test the coder when the arrays happen to be the same
> object
> as this is only possible due to the deduplication, which tests it already.
> 
> 
>> I think it'd be straightforward to train that intrinsic to only emit the
>> test when the related feature is enabled. Maybe the kind folks over at
>> hotspot-compiler-dev at openjdk.java.net might be able to give some pointers.
>> If so I'd invite you to set up a set of experiments and see if this can
>> have a benefit.
>> 
> 
> Because of the intrinsic being tied to the concrete methods rather than to
> the code inside,
> I'd have to modify and compile the JVM sources, which needs way more time
> than I can spend on it in the moment. :(
> A benchmark written using a copy of the method would be too unrealistic,
> as the copied comparison uses no intrinsic and is much slower (
> https://stackoverflow.com/q/15586997/581205).
> 
> Anyway, we know, that an arbitrary high speed up is possible as the O(n)
> comparison gets eliminated.
> A benchmark showing this can surely be constructed,
> but what has to be measured is the tiny slowdown in cases when it doesn't
> help
> and that needs to re-run existing benchmarks.
> 
> Actually, I'd propose something more fancy (added two more independent
> trivial optimization ideas):
> 
>    public boolean equals(Object anObject) {
>        if (this == anObject) {
>            return true;
>        }
>        if (anObject instanceof String) {
>            String aString = (String)anObject;
> 
>            // IDEA 1 - as discussed above
>            // USE_STRING_DEDUPLICATION is a constant to be eliminated by
> JIT
>            // just like it happens with COMPACT_STRINGS [2].
>            if (USE_STRING_DEDUPLICATION && value == aString.value) {
>                // We know that the coders are the same here.
>                return true;
>            }
> 
>            // IDEA 2 - add a trivial test possibly avoiding the loop
>            // Testing the length first because of it being more probable
> to differ.
>            if (value.length == aString.value.length && coder() ==
> aString.coder()) {
> 
>                // IDEA 3 - remove a needless test of coder()
>                // Not testing the coder as all we need is byte array
> content equality.
>                // StringLatin1.equals is applicable for UTF-8, too.
>                return StringLatin1.equals(value, aString.value);
>            }
>        }
>        return false;
>    }
> 
> Regards,
> Martin.
> 
> [2]:
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/share/classes/java/lang/String.java#l197
> 
> Regards
>> 
>> /Claes
>> 
>> [1]
>> http://hg.openjdk.java.net/jdk/jdk/file/e1876e6b57b6/src/hot
>> spot/share/opto/library_call.cpp#l1116
>> 
>> 
>> 
>> On 2018-01-23 00:14, Martin Grajcar wrote:
>> 
>>> It looks like when testing equality of Strings, there's no test if the two
>>> arrays are actually the same object. This was impossible before Java 8u20
>>> (as no two strings used to share arrays), but it's well possible with
>>> -XX:+UseStringDeduplication.
>>> 
>>> Maybe someone here cares...
>>> 
>>> Regards,
>>> Martin.
>>> 
>>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811
>>> /src/java.base/
>>> share/classes/java/lang/String.java#l1014
>>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811
>>> /src/java.base/
>>> share/classes/java/lang/StringLatin1.java#l89
>>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811
>>> /src/java.base/
>>> share/classes/java/lang/StringUTF16.java#l258
>>> 
>> 
>> 


From dalibor.topic at oracle.com  Wed Jan 24 14:18:01 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 24 Jan 2018 15:18:01 +0100
Subject: JDK submit repo
In-Reply-To: <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
 <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
Message-ID: <3e2876e5-3d63-1ed1-23b3-abfdb34a37d4@oracle.com>



On 24.01.2018 11:25, David Holmes wrote:
> The way I see this working is as follows:
> 
> - contributor works on a fix and gets it working locally on whatever 
> systems they have available to them
> - contributor then wants to test further and so submits to submit repo
> - contributor gets response email:
> a) all good: contributor sends RFR to xxx-dev
> b) not all good: contributor sends prelim-RFR to xxx-dev and includes 
> failure info, and waits for help on the failures

Ultimately, whatever way to find the right Oracle engineer is documented 
is fine with me.

It just needs to be documented, and documented in a way that's easy and 
obvious to follow for someone who doesn't have the time to learn the 
lore and history of OpenJDK organization into core-libs-dev, 
serviceability-dev and hotspot-dev, etc.

This is an extremely confusing area for new comers.

For example, I'll put myself in the shoes of someone sending in their 
first change to the system. Let it be some small HotSpot tweak, like 
fixing some compiler warning in zero.

If the submission of my HotSpot change only fails running an nio jtreg 
test on OS X (assuming OS X is a supported configuration, of course), 
should I contact

a) zero-dev (I tried to patch zero)
b) hotspot-dev (which is part of hotspot)
c) nio-dev (which is where the failing test came from)
d) mac-osx-dev (which is the platform the test failed on)
e) jtreg-dev (on the chance that it's some jtreg issue)
f) jdk-dev (because I'm  building the JDK after all)
g) ops (because ops is listed on the wiki)

to find the right Oracle engineer to work with?

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 weijun.wang at oracle.com  Wed Jan 24 14:29:03 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 24 Jan 2018 22:29:03 +0800
Subject: JDK submit repo
In-Reply-To: <3e2876e5-3d63-1ed1-23b3-abfdb34a37d4@oracle.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
 <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
 <3e2876e5-3d63-1ed1-23b3-abfdb34a37d4@oracle.com>
Message-ID: <8BB66F71-A519-4375-ABBC-38B30FFA7781@oracle.com>



> On Jan 24, 2018, at 10:18 PM, dalibor topic <dalibor.topic at oracle.com> wrote:
> 
> 
> 
> On 24.01.2018 11:25, David Holmes wrote:
>> The way I see this working is as follows:
>> - contributor works on a fix and gets it working locally on whatever systems they have available to them
>> - contributor then wants to test further and so submits to submit repo
>> - contributor gets response email:
>> a) all good: contributor sends RFR to xxx-dev
>> b) not all good: contributor sends prelim-RFR to xxx-dev and includes failure info, and waits for help on the failures
> 
> Ultimately, whatever way to find the right Oracle engineer is documented is fine with me.
> 
> It just needs to be documented, and documented in a way that's easy and obvious to follow for someone who doesn't have the time to learn the lore and history of OpenJDK organization into core-libs-dev, serviceability-dev and hotspot-dev, etc.
> 
> This is an extremely confusing area for new comers.
> 
> For example, I'll put myself in the shoes of someone sending in their first change to the system. Let it be some small HotSpot tweak, like fixing some compiler warning in zero.
> 
> If the submission of my HotSpot change only fails running an nio jtreg test on OS X (assuming OS X is a supported configuration, of course), should I contact
> 
> a) zero-dev (I tried to patch zero)
> b) hotspot-dev (which is part of hotspot)

Either of above. If you are fixing zero, mostly likely you have started discussing it on one of the lists above. If anyone else on those lists are interested in the fix, he/she will help you find a better list to talk about the failure.

This is a community of people helping each other, I don't think a guide will be precise enough to allow a newcomer to find out which list is better.

--Max

> c) nio-dev (which is where the failing test came from)
> d) mac-osx-dev (which is the platform the test failed on)
> e) jtreg-dev (on the chance that it's some jtreg issue)
> f) jdk-dev (because I'm  building the JDK after all)
> g) ops (because ops is listed on the wiki)
> 
> to find the right Oracle engineer to work with?
> 
> 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 mark.reinhold at oracle.com  Wed Jan 24 16:17:34 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 24 Jan 2018 08:17:34 -0800
Subject: JDK submit repo
In-Reply-To: <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
Message-ID: <20180124081734.43711657@eggemoggin.niobe.net>

2018/1/24 2:04:46 -0800, dalibor.topic at oracle.com:
> On 23.01.2018 21:33, mark.reinhold at oracle.com wrote:
>> If you push a branch whose name starts with "JDK-" into this repo
>> then it will automatically be built and tested on Oracle's internal
>> build system, and a summary of the results will be e-mailed back to
>> you.  This typically takes a couple of hours.  If one or more tests
>> fail then you can contact an Oracle engineer to get more information
>> about the failures.
> 
> Since the wiki
> 
> * doesn't say how to contact that engineer
> * doesn't say how to work with them
> 
> that might be a hurdle too steep in some cases.
> 
> As the only contact given on the wiki is ops at openjdk, I assume it will 
> get more than its fair share of test failures to forward through email 
> chains in search of that engineer. That would be unfortunate.

Yes.

> Instead, I would suggest explicitly advising Comitters with test 
> failures to forward them to the jdk-dev mailing list in search of an 
> Oracle engineer.

Please, no.  Asking jdk-dev should be the option of last resort.  If
you're working on a fix for something then you've hopefully already
discussed it on the appropriate list.  I agree that we should make it
easier for newcomers to figure out which list to go to, but spamming
jdk-dev is not the answer.

- Mark

From mark.reinhold at oracle.com  Wed Jan 24 16:19:29 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 24 Jan 2018 08:19:29 -0800
Subject: JDK submit repo
In-Reply-To: <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
 <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
Message-ID: <20180124081929.122664659@eggemoggin.niobe.net>

2018/1/24 2:25:16 -0800, david.holmes at oracle.com:
> On 24/01/2018 8:04 PM, dalibor topic wrote:
>> ...
>> 
>> Instead, I would suggest explicitly advising Comitters with test 
>> failures to forward them to the jdk-dev mailing list in search of an 
>> Oracle engineer.
> 
> I would not advise that as not all engineers hang out on jdk-dev.

If you actively work on the JDK then you should be subscribed
to jdk-dev.  Otherwise you're roaming around in the dark.

- Mark

From maurizio.cimadamore at oracle.com  Wed Jan 24 18:46:10 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 24 Jan 2018 18:46:10 +0000
Subject: RFR 8196081: Add support for customized intellij project templates
Message-ID: <e8430d86-0e71-d822-5d00-f22434a5c8ee@oracle.com>

Hi,
the webrev here:

http://cr.openjdk.java.net/~mcimadamore/8196081/

Contains a refresh of the IntelliJ project for JDK. Here's a list of the 
enhancements:

* Added support for overriding standard template settings with other 
ones defined in user-defined folder (this can be done by specifying the 
env variable TEMPLATES_OVERRIDES)

* Cleaned up unused part of the build.xml script used for 
building/cleaning/rebuilding the project; the new ant file is a thin 
wrapper around make, with no extra magic added; also removed unused ant 
variable from the ant.xml template file

* Fixed some broken settings: removed exclusion for src folder (which 
caused the VCS plugin not to highlight changes in the source code) and 
removed addition of test source root (as that causes red squiggly lines 
because some of the tests define mocked up versions of j.l.Object which 
confuse the IDE)

* Consolidate logic in idea.gmk by replacing ad-hoc target 
"FindIdeaModuleSrcDirs" with the official "FindModuleSrcDirs" one

Cheers
Maurizio



From alex.buckley at oracle.com  Wed Jan 24 19:27:06 2018
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 24 Jan 2018 11:27:06 -0800
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <CA+3eh10nZrY=+oa5cCYtgQeZhg3ugDzcpJ1P2X7inmoSOcUySA@mail.gmail.com>
References: <5A624C97.3020408@oracle.com>
 <57BC5B36-03BB-4A55-B122-D178E1307104@oracle.com>
 <739826618.2492791.1516450390320.JavaMail.zimbra@u-pem.fr>
 <e2ed6d92-5005-c93e-33a9-2447f9986e8e@oracle.com>
 <673830208.2560837.1516491218107.JavaMail.zimbra@u-pem.fr>
 <5A66328B.4030408@oracle.com>
 <716147835.526255.1516648903685.JavaMail.zimbra@u-pem.fr>
 <5A663F2A.1030101@oracle.com>
 <1030071852.558410.1516661352663.JavaMail.zimbra@u-pem.fr>
 <5A667063.6020603@oracle.com>
 <CA+3eh13q8ZKGEj7zpekHZ6SQZjQ34807g0mq4qnB1H8Qye9JYA@mail.gmail.com>
 <5A67A090.1040204@oracle.com>
 <CA+3eh10nZrY=+oa5cCYtgQeZhg3ugDzcpJ1P2X7inmoSOcUySA@mail.gmail.com>
Message-ID: <5A68DE0A.2080407@oracle.com>

On 1/24/2018 1:30 AM, Volker Simonis wrote:
>>> Finally, the JEP doesn?t specify if version N may (silently or
>>> explicitly) support version N+1?s incubating features. This may be
>>> attractive for LTS releases.
>>
>> If Java SE N had no notion of feature X, and Java SE N+1 introduced X as an
>> incubating feature, then there is no realistic possibility of doing a
>> Maintenance Release of SE N to add an incubating feature X.
>
> I don't meant to do this in a "Maintenance Release of SE N". The
> question was if a Java vendor can do that in his implementation of
> "Java N" if that implementation still passes the "Java N TCK".

The JEP was careful to avoid vendor issues, and the above is a 
vendor-specific question, so I am unable to answer it here.

I think most people would agree that taking a final-and-permanent 
feature in Java SE $N+1 (say, LVTI in Java SE 10) and adding it behind 
an --incubating flag in an implementation of Java SE $N is very weird. 
After all, the feature was not listed as incubating in the relevant 
appendix of the Java SE $N Platform specification. And "Nothing in this 
JEP should be interpreted as encouraging or allowing fragmentation of 
the Java SE Platform."

Alex

From magnus.ihse.bursie at oracle.com  Wed Jan 24 23:20:58 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 25 Jan 2018 00:20:58 +0100
Subject: RFR 8196081: Add support for customized intellij project templates
In-Reply-To: <e8430d86-0e71-d822-5d00-f22434a5c8ee@oracle.com>
References: <e8430d86-0e71-d822-5d00-f22434a5c8ee@oracle.com>
Message-ID: <0305f327-d6c2-b872-193e-703dfa04a805@oracle.com>


On 2018-01-24 19:46, Maurizio Cimadamore wrote:
> Hi,
> the webrev here:
>
> http://cr.openjdk.java.net/~mcimadamore/8196081/

Looks good to me.

/Magnus

>
> Contains a refresh of the IntelliJ project for JDK. Here's a list of 
> the enhancements:
>
> * Added support for overriding standard template settings with other 
> ones defined in user-defined folder (this can be done by specifying 
> the env variable TEMPLATES_OVERRIDES)
>
> * Cleaned up unused part of the build.xml script used for 
> building/cleaning/rebuilding the project; the new ant file is a thin 
> wrapper around make, with no extra magic added; also removed unused 
> ant variable from the ant.xml template file
>
> * Fixed some broken settings: removed exclusion for src folder (which 
> caused the VCS plugin not to highlight changes in the source code) and 
> removed addition of test source root (as that causes red squiggly 
> lines because some of the tests define mocked up versions of 
> j.l.Object which confuse the IDE)
>
> * Consolidate logic in idea.gmk by replacing ad-hoc target 
> "FindIdeaModuleSrcDirs" with the official "FindModuleSrcDirs" one
>
> Cheers
> Maurizio
>
>


From martijnverburg at gmail.com  Wed Jan 24 23:30:35 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 24 Jan 2018 23:30:35 +0000
Subject: JDK submit repo
In-Reply-To: <20180124081734.43711657@eggemoggin.niobe.net>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
 <20180124081734.43711657@eggemoggin.niobe.net>
Message-ID: <CAP7YuAQu6eMaY5-ShGtG6zm+FSkugvgEQKrkpB=qo1Xf20C6eQ@mail.gmail.com>

The adoption group has a spreadsheet of code areas mapped to mailing
lists.  Happy to put this data where best for folks, let me know!

On Thu, 25 Jan 2018 at 05:18, <mark.reinhold at oracle.com> wrote:

> 2018/1/24 2:04:46 -0800, dalibor.topic at oracle.com:
> > On 23.01.2018 21:33, mark.reinhold at oracle.com wrote:
> >> If you push a branch whose name starts with "JDK-" into this repo
> >> then it will automatically be built and tested on Oracle's internal
> >> build system, and a summary of the results will be e-mailed back to
> >> you.  This typically takes a couple of hours.  If one or more tests
> >> fail then you can contact an Oracle engineer to get more information
> >> about the failures.
> >
> > Since the wiki
> >
> > * doesn't say how to contact that engineer
> > * doesn't say how to work with them
> >
> > that might be a hurdle too steep in some cases.
> >
> > As the only contact given on the wiki is ops at openjdk, I assume it will
> > get more than its fair share of test failures to forward through email
> > chains in search of that engineer. That would be unfortunate.
>
> Yes.
>
> > Instead, I would suggest explicitly advising Comitters with test
> > failures to forward them to the jdk-dev mailing list in search of an
> > Oracle engineer.
>
> Please, no.  Asking jdk-dev should be the option of last resort.  If
> you're working on a fix for something then you've hopefully already
> discussed it on the appropriate list.  I agree that we should make it
> easier for newcomers to figure out which list to go to, but spamming
> jdk-dev is not the answer.
>
> - Mark
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From david.holmes at oracle.com  Thu Jan 25 00:48:16 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 25 Jan 2018 10:48:16 +1000
Subject: JDK submit repo
In-Reply-To: <8BB66F71-A519-4375-ABBC-38B30FFA7781@oracle.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
 <2474057f-500b-cf94-4274-04e3a0787190@oracle.com>
 <3e2876e5-3d63-1ed1-23b3-abfdb34a37d4@oracle.com>
 <8BB66F71-A519-4375-ABBC-38B30FFA7781@oracle.com>
Message-ID: <a9aed075-d904-844d-e9c4-2b89e88bd6a3@oracle.com>

On 25/01/2018 12:29 AM, Weijun Wang wrote:
>> On Jan 24, 2018, at 10:18 PM, dalibor topic <dalibor.topic at oracle.com> wrote:
>> On 24.01.2018 11:25, David Holmes wrote:
>>> The way I see this working is as follows:
>>> - contributor works on a fix and gets it working locally on whatever systems they have available to them
>>> - contributor then wants to test further and so submits to submit repo
>>> - contributor gets response email:
>>> a) all good: contributor sends RFR to xxx-dev
>>> b) not all good: contributor sends prelim-RFR to xxx-dev and includes failure info, and waits for help on the failures
>>
>> Ultimately, whatever way to find the right Oracle engineer is documented is fine with me.
>>
>> It just needs to be documented, and documented in a way that's easy and obvious to follow for someone who doesn't have the time to learn the lore and history of OpenJDK organization into core-libs-dev, serviceability-dev and hotspot-dev, etc.

We're not really talking about raw newcomers here, who are just emailing 
a patch to a mailing list. Authors and Committers should already be well 
versed in how to contribute to the area they are working in, including 
the mailing lists. Afterall we do have a wiki on this:

http://openjdk.java.net/contribute/

>> This is an extremely confusing area for new comers.
>>
>> For example, I'll put myself in the shoes of someone sending in their first change to the system. Let it be some small HotSpot tweak, like fixing some compiler warning in zero.
>>
>> If the submission of my HotSpot change only fails running an nio jtreg test on OS X (assuming OS X is a supported configuration, of course), should I contact
>>
>> a) zero-dev (I tried to patch zero)
>> b) hotspot-dev (which is part of hotspot)
> 
> Either of above. If you are fixing zero, mostly likely you have started discussing it on one of the lists above. If anyone else on those lists are interested in the fix, he/she will help you find a better list to talk about the failure.

+1

There may be some ambiguity/overlap with something like zero versus 
hotspot, but these match the area to which the bug was being applied and 
would be the first point(s) of contact.

Cheers,
David
------

> This is a community of people helping each other, I don't think a guide will be precise enough to allow a newcomer to find out which list is better.
> 
> --Max
> 
>> c) nio-dev (which is where the failing test came from)
>> d) mac-osx-dev (which is the platform the test failed on)
>> e) jtreg-dev (on the chance that it's some jtreg issue)
>> f) jdk-dev (because I'm  building the JDK after all)
>> g) ops (because ops is listed on the wiki)
>>
>> to find the right Oracle engineer to work with?
>>
>> 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 adinn at redhat.com  Thu Jan 25 11:24:44 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 25 Jan 2018 11:24:44 +0000
Subject: RFR: 8196136: AArch64: Correct register use in patch for JDK-8195685
Message-ID: <e0d7c5b4-7b56-842c-5375-ae2f48e0feb8@redhat.com>

JDK-8195685 introduced aarch64 patches to complete the interface lookup
changes made in JDK-8174962. This included a patch to the generated
itable stubs which employed r0 as a scratch register. Unfortunately,
this causes problems in the very rare case where the stub fields an
interface call with 7 arguments. r0 is used to hold the 7th argument in
the stub call so the stub code corrupts the supplied argument. This
manifested in the maven setup for jcstress tests.

The following webrev against jdk10 corrects the patch to use a safe
register (r19)

jira:   https://bugs.openjdk.java.net/browse/JDK-8196136
webrev: http://cr.openjdk.java.net/~adinn/8196136/webrev/

Reviews would be welcome.

The patch needs to be applied to jdk10 and also to the jdkdev trees. It
should also be backported to jdk9.

Testing:

This patch stops the crash that was seen running jcstress.

The patched JVM also continues successfully to run a variety of standard
Java apps.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From aph at redhat.com  Thu Jan 25 11:48:12 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Jan 2018 11:48:12 +0000
Subject: RFR: 8196136: AArch64: Correct register use in patch for
 JDK-8195685
In-Reply-To: <e0d7c5b4-7b56-842c-5375-ae2f48e0feb8@redhat.com>
References: <e0d7c5b4-7b56-842c-5375-ae2f48e0feb8@redhat.com>
Message-ID: <448731b7-a6ec-0a61-87da-c66f5825abc5@redhat.com>

On 25/01/18 11:24, Andrew Dinn wrote:
> The following webrev against jdk10 corrects the patch to use a safe
> register (r19)

OK, but please use r16 instead.  It's not used for anything else
and callee-saved register are precious.  At some point we should
move from using r13 to pass the save SP to r19, so we shouldn't
use r19 in call stubs becuse it'll be live.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adinn at redhat.com  Thu Jan 25 12:17:29 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 25 Jan 2018 12:17:29 +0000
Subject: RFR: 8196136: AArch64: Correct register use in patch for
 JDK-8195685
In-Reply-To: <448731b7-a6ec-0a61-87da-c66f5825abc5@redhat.com>
References: <e0d7c5b4-7b56-842c-5375-ae2f48e0feb8@redhat.com>
 <448731b7-a6ec-0a61-87da-c66f5825abc5@redhat.com>
Message-ID: <7f9b62a2-3520-b0f1-8b89-7be60941791f@redhat.com>



On 25/01/18 11:48, Andrew Haley wrote:
> On 25/01/18 11:24, Andrew Dinn wrote:
>> The following webrev against jdk10 corrects the patch to use a safe
>> register (r19)
> 
> OK, but please use r16 instead.  It's not used for anything else
> and callee-saved register are precious.  At some point we should
> move from using r13 to pass the save SP to r19, so we shouldn't
> use r19 in call stubs becuse it'll be live.
Revised webrev using r16

jira:   https://bugs.openjdk.java.net/browse/JDK-8196136
webrev: http://cr.openjdk.java.net/~adinn/8196136/webrev.02/

I modified itable (and vtable) stubs to use r16 instead of r19. Same
testing was successful.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From aph at redhat.com  Thu Jan 25 12:23:22 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Jan 2018 12:23:22 +0000
Subject: RFR: 8196136: AArch64: Correct register use in patch for
 JDK-8195685
In-Reply-To: <e0d7c5b4-7b56-842c-5375-ae2f48e0feb8@redhat.com>
References: <e0d7c5b4-7b56-842c-5375-ae2f48e0feb8@redhat.com>
Message-ID: <70c78716-5666-ee2a-b7cc-2f1a6fc4e0d2@redhat.com>

On 25/01/18 11:24, Andrew Dinn wrote:
> JDK-8195685 introduced aarch64 patches to complete the interface lookup
> changes made in JDK-8174962. This included a patch to the generated
> itable stubs which employed r0 as a scratch register. Unfortunately,
> this causes problems in the very rare case where the stub fields an
> interface call with 7 arguments. r0 is used to hold the 7th argument in
> the stub call so the stub code corrupts the supplied argument. This
> manifested in the maven setup for jcstress tests.

OK, I've found the call so I can confirm the diagnosis.

  Interface method
  org.codehaus.plexus.component.configurator.converters.ConfigurationConverter.fromConfiguration(
   org.codehaus.plexus.component.configurator.converters.lookup.ConverterLookup,
   org.codehaus.plexus.configuration.PlexusConfiguration,
   java.lang.Class,
   java.lang.Class,
   java.lang.ClassLoader,
   org.codehaus.plexus.component.configurator.expression.ExpressionEvaluator,
   org.codehaus.plexus.component.configurator.ConfigurationListener)

is called from

  org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(
   org.codehaus.plexus.configuration.PlexusConfiguration,
   java.lang.ClassLoader,
   org.codehaus.plexus.component.configurator.expression.ExpressionEvaluator)

fromConfiguration has 8 args (7 + this) and the arg which gets
corrupted is indeed ComponentValueSetter.listener, Argument 8 in the
call.  I can see this in the debugger:

org.codehaus.plexus.component.configurator.converters.ComponentValueSetter
{0x00000007219346c0} - klass: 'org/codehaus/plexus/component/configurator/converters/ComponentValueSetter'
 - ---- fields (total size 8 words):
 - private final 'object' 'Ljava/lang/Object;' @12  a 'org/apache/maven/plugins/shade/resource/ManifestResourceTransformer'{0x00000007219346a0} (e43268d4 e4326922)
 - private final 'fieldName' 'Ljava/lang/String;' @16  "mainClass"{0x0000000721934910} (e4326922 dfce3c71)
 - private final 'lookup' 'Lorg/codehaus/plexus/component/configurator/converters/lookup/ConverterLookup;' @20  a 'org/codehaus/plexus/component/configurator/converters/lookup/DefaultConverterLookup'{0x00000006fe71e388} (dfce3c71 0)
 - private 'setter' 'Ljava/lang/reflect/Method;' @24  NULL (0 0)
 - private 'setterParamType' 'Ljava/lang/Class;' @28  NULL (0 0)
 - private 'setterTypeConverter' 'Lorg/codehaus/plexus/component/configurator/converters/ConfigurationConverter;' @32  NULL (0 0)
 - private 'setterTypeArguments' '[Ljava/lang/reflect/Type;' @36  NULL (0 e4326aa9)
 - private 'field' 'Ljava/lang/reflect/Field;' @40  a 'java/lang/reflect/Field'{0x0000000721935548} (e4326aa9 dfc08605)
 - private 'fieldType' 'Ljava/lang/Class;' @44  a 'java/lang/Class'{0x00000006fe043028} = 'java/lang/String' (dfc08605 dfce3c9a)
 - private 'fieldTypeConverter' 'Lorg/codehaus/plexus/component/configurator/converters/ConfigurationConverter;' @48  a 'org/codehaus/plexus/component/configurator/converters/basic/StringConverter'{0x00000006fe71e4d0} (dfce3c9a 0)
 - private 'fieldTypeArguments' '[Ljava/lang/reflect/Type;' @52  NULL (0 3f99b)
 - private final 'listener' 'Lorg/codehaus/plexus/component/configurator/ConfigurationListener;' @56
Program received signal SIGSEGV, Segmentation fault.

Good catch!

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Thu Jan 25 12:24:05 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Jan 2018 12:24:05 +0000
Subject: RFR: 8196136: AArch64: Correct register use in patch for
 JDK-8195685
In-Reply-To: <7f9b62a2-3520-b0f1-8b89-7be60941791f@redhat.com>
References: <e0d7c5b4-7b56-842c-5375-ae2f48e0feb8@redhat.com>
 <448731b7-a6ec-0a61-87da-c66f5825abc5@redhat.com>
 <7f9b62a2-3520-b0f1-8b89-7be60941791f@redhat.com>
Message-ID: <f95079ad-9d75-52c6-dea0-3bc9c2a863ad@redhat.com>

On 25/01/18 12:17, Andrew Dinn wrote:
> jira:   https://bugs.openjdk.java.net/browse/JDK-8196136
> webrev: http://cr.openjdk.java.net/~adinn/8196136/webrev.02/
> 
> I modified itable (and vtable) stubs to use r16 instead of r19. Same
> testing was successful.

OK, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From mark.reinhold at oracle.com  Thu Jan 25 19:40:48 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 25 Jan 2018 11:40:48 -0800
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda
 Parameters
Message-ID: <20180125114048.564564978@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 11:

  323: Local-Variable Syntax for Lambda Parameters
       http://openjdk.java.net/jeps/323

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Thursday,
1 February, or if they're raised and then satisfactorily answered, then
per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From martijnverburg at gmail.com  Fri Jan 26 08:30:58 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 26 Jan 2018 21:30:58 +1300
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <20180125114048.564564978@eggemoggin.niobe.net>
References: <20180125114048.564564978@eggemoggin.niobe.net>
Message-ID: <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>

Hi all,

I'm struggling to understand the motivation for this JEP in terms of it
adding improved understanding or readability of source code (as the
implicit case is already covered today).

I also suspect the illegal use uses (extract below) will likely confuse and
frustrate day to day developer's who don't understand the underlying type
inference system and lead to
some heavily upvoted SO Q's.  I liken this type of frustration seen in
developers not understanding generics in full and coming undone in corner
cases where they expect the element of
'least surprise'.

------

The following examples are illegal:

(var x, y) -> x + y        // Cannot mix var and "no var" in
implicitly typed lambda expression
(var x, int y) -> x + y    // Cannot mix var and manifest types in
explicitly typed lambda expression


-------

I'm not sure I've explained myself very eloquently here, hope this has made
some sense.

Cheers,
Martijn

On 26 January 2018 at 08:40, <mark.reinhold at oracle.com> wrote:

> The following JEP is proposed to target JDK 11:
>
>   323: Local-Variable Syntax for Lambda Parameters
>        http://openjdk.java.net/jeps/323
>
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 1 February, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
>
> - Mark
>
>
> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>

From cedric.champeau at gmail.com  Fri Jan 26 08:38:23 2018
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Fri, 26 Jan 2018 09:38:23 +0100
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
Message-ID: <CADQzvmmeFBUj0QuPotA7Mc3WuUhYPZXNbA0Ci_EhXAqu9Xachg@mail.gmail.com>

Hi Martijn,

I share your thoughts. I understand the will to streamline the use of
"var". However, since

(var x, var y) -> x+y

is strictly equivalent to:

(x,y) -> x+y

I'm not sure I see the advantage of this. From my experience with Groovy,
where both are supported ( { def x, def y -> ) and ( { x,y ->), I think
most people stick with the short syntax, the longer one seems to imply
different semantics (why use a different syntax if its the same ?), where
there are not.

2018-01-26 9:30 GMT+01:00 Martijn Verburg <martijnverburg at gmail.com>:

> Hi all,
>
> I'm struggling to understand the motivation for this JEP in terms of it
> adding improved understanding or readability of source code (as the
> implicit case is already covered today).
>
> I also suspect the illegal use uses (extract below) will likely confuse and
> frustrate day to day developer's who don't understand the underlying type
> inference system and lead to
> some heavily upvoted SO Q's.  I liken this type of frustration seen in
> developers not understanding generics in full and coming undone in corner
> cases where they expect the element of
> 'least surprise'.
>
> ------
>
> The following examples are illegal:
>
> (var x, y) -> x + y        // Cannot mix var and "no var" in
> implicitly typed lambda expression
> (var x, int y) -> x + y    // Cannot mix var and manifest types in
> explicitly typed lambda expression
>
>
> -------
>
> I'm not sure I've explained myself very eloquently here, hope this has made
> some sense.
>
> Cheers,
> Martijn
>
> On 26 January 2018 at 08:40, <mark.reinhold at oracle.com> wrote:
>
> > The following JEP is proposed to target JDK 11:
> >
> >   323: Local-Variable Syntax for Lambda Parameters
> >        http://openjdk.java.net/jeps/323
> >
> > Feedback on this proposal is more than welcome, as are reasoned
> > objections.  If no such objections are raised by 23:00 UTC on Thursday,
> > 1 February, or if they're raised and then satisfactorily answered, then
> > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
> >
> > - Mark
> >
> >
> > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> >
>

From martijnverburg at gmail.com  Fri Jan 26 09:14:22 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 26 Jan 2018 22:14:22 +1300
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CADQzvmmeFBUj0QuPotA7Mc3WuUhYPZXNbA0Ci_EhXAqu9Xachg@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CADQzvmmeFBUj0QuPotA7Mc3WuUhYPZXNbA0Ci_EhXAqu9Xachg@mail.gmail.com>
Message-ID: <CAP7YuATdWSGTjfO0UadpiwuNxRiT4YOiEBi2ZFDGjVefMfXX5A@mail.gmail.com>

I'd be interested in some empirical numbers around the usage in Groovy of
the two styles of declaration!

I'm also trying hard not to get caught up only thinking about syntax here.
I know that I'm someone who's not a qualified language or VM expert and
that I've more than likely got caught up thinking about the wrong problem
(syntax vs semantics).





Cheers,
Martijn

On 26 January 2018 at 21:38, C?dric Champeau <cedric.champeau at gmail.com>
wrote:

> Hi Martijn,
>
> I share your thoughts. I understand the will to streamline the use of
> "var". However, since
>
> (var x, var y) -> x+y
>
> is strictly equivalent to:
>
> (x,y) -> x+y
>
> I'm not sure I see the advantage of this. From my experience with Groovy,
> where both are supported ( { def x, def y -> ) and ( { x,y ->), I think
> most people stick with the short syntax, the longer one seems to imply
> different semantics (why use a different syntax if its the same ?), where
> there are not.
>
> 2018-01-26 9:30 GMT+01:00 Martijn Verburg <martijnverburg at gmail.com>:
>
> > Hi all,
> >
> > I'm struggling to understand the motivation for this JEP in terms of it
> > adding improved understanding or readability of source code (as the
> > implicit case is already covered today).
> >
> > I also suspect the illegal use uses (extract below) will likely confuse
> and
> > frustrate day to day developer's who don't understand the underlying type
> > inference system and lead to
> > some heavily upvoted SO Q's.  I liken this type of frustration seen in
> > developers not understanding generics in full and coming undone in corner
> > cases where they expect the element of
> > 'least surprise'.
> >
> > ------
> >
> > The following examples are illegal:
> >
> > (var x, y) -> x + y        // Cannot mix var and "no var" in
> > implicitly typed lambda expression
> > (var x, int y) -> x + y    // Cannot mix var and manifest types in
> > explicitly typed lambda expression
> >
> >
> > -------
> >
> > I'm not sure I've explained myself very eloquently here, hope this has
> made
> > some sense.
> >
> > Cheers,
> > Martijn
> >
> > On 26 January 2018 at 08:40, <mark.reinhold at oracle.com> wrote:
> >
> > > The following JEP is proposed to target JDK 11:
> > >
> > >   323: Local-Variable Syntax for Lambda Parameters
> > >        http://openjdk.java.net/jeps/323
> > >
> > > Feedback on this proposal is more than welcome, as are reasoned
> > > objections.  If no such objections are raised by 23:00 UTC on Thursday,
> > > 1 February, or if they're raised and then satisfactorily answered, then
> > > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
> > >
> > > - Mark
> > >
> > >
> > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> > >
> >
>

From martijnverburg at gmail.com  Fri Jan 26 09:18:52 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 26 Jan 2018 22:18:52 +1300
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAP7YuATdWSGTjfO0UadpiwuNxRiT4YOiEBi2ZFDGjVefMfXX5A@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CADQzvmmeFBUj0QuPotA7Mc3WuUhYPZXNbA0Ci_EhXAqu9Xachg@mail.gmail.com>
 <CAP7YuATdWSGTjfO0UadpiwuNxRiT4YOiEBi2ZFDGjVefMfXX5A@mail.gmail.com>
Message-ID: <CAP7YuARszDzXADHZw+7mNy+8FrzDyLB=4qX_8zb8YTTpU-ucMA@mail.gmail.com>

Continuing train of thought (sorry it's late here in NZ, so I'm not being
as coherent as I should be).  I guess (var x, var y) vs (x, y) adds another
possible use case where you'll see two idiomatic styles of Java being
written in the wild. This is something which Java usually tries to avoid?
Although there are of course very good use cases where breaking from an old
idiom is very desirable.

Cheers,
Martijn

On 26 January 2018 at 22:14, Martijn Verburg <martijnverburg at gmail.com>
wrote:

> I'd be interested in some empirical numbers around the usage in Groovy of
> the two styles of declaration!
>
> I'm also trying hard not to get caught up only thinking about syntax here.
> I know that I'm someone who's not a qualified language or VM expert and
> that I've more than likely got caught up thinking about the wrong problem
> (syntax vs semantics).
>
>
>
>
>
> Cheers,
> Martijn
>
> On 26 January 2018 at 21:38, C?dric Champeau <cedric.champeau at gmail.com>
> wrote:
>
>> Hi Martijn,
>>
>> I share your thoughts. I understand the will to streamline the use of
>> "var". However, since
>>
>> (var x, var y) -> x+y
>>
>> is strictly equivalent to:
>>
>> (x,y) -> x+y
>>
>> I'm not sure I see the advantage of this. From my experience with Groovy,
>> where both are supported ( { def x, def y -> ) and ( { x,y ->), I think
>> most people stick with the short syntax, the longer one seems to imply
>> different semantics (why use a different syntax if its the same ?), where
>> there are not.
>>
>> 2018-01-26 9:30 GMT+01:00 Martijn Verburg <martijnverburg at gmail.com>:
>>
>> > Hi all,
>> >
>> > I'm struggling to understand the motivation for this JEP in terms of it
>> > adding improved understanding or readability of source code (as the
>> > implicit case is already covered today).
>> >
>> > I also suspect the illegal use uses (extract below) will likely confuse
>> and
>> > frustrate day to day developer's who don't understand the underlying
>> type
>> > inference system and lead to
>> > some heavily upvoted SO Q's.  I liken this type of frustration seen in
>> > developers not understanding generics in full and coming undone in
>> corner
>> > cases where they expect the element of
>> > 'least surprise'.
>> >
>> > ------
>> >
>> > The following examples are illegal:
>> >
>> > (var x, y) -> x + y        // Cannot mix var and "no var" in
>> > implicitly typed lambda expression
>> > (var x, int y) -> x + y    // Cannot mix var and manifest types in
>> > explicitly typed lambda expression
>> >
>> >
>> > -------
>> >
>> > I'm not sure I've explained myself very eloquently here, hope this has
>> made
>> > some sense.
>> >
>> > Cheers,
>> > Martijn
>> >
>> > On 26 January 2018 at 08:40, <mark.reinhold at oracle.com> wrote:
>> >
>> > > The following JEP is proposed to target JDK 11:
>> > >
>> > >   323: Local-Variable Syntax for Lambda Parameters
>> > >        http://openjdk.java.net/jeps/323
>> > >
>> > > Feedback on this proposal is more than welcome, as are reasoned
>> > > objections.  If no such objections are raised by 23:00 UTC on
>> Thursday,
>> > > 1 February, or if they're raised and then satisfactorily answered,
>> then
>> > > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
>> > >
>> > > - Mark
>> > >
>> > >
>> > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>> > >
>> >
>>
>
>

From benjamin.john.evans at gmail.com  Fri Jan 26 09:26:37 2018
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Fri, 26 Jan 2018 10:26:37 +0100
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <20180125114048.564564978@eggemoggin.niobe.net>
References: <20180125114048.564564978@eggemoggin.niobe.net>
Message-ID: <CABKW8Ri6jYtTL-AvTB7VGm50fOqGt91MCF2QPx5FsL+d+wZBWw@mail.gmail.com>

This is a riff on an unreleased feature.

We do not have any data on how LVTI will actually be used by the Java
community in the field yet.

It may prove to be wildly popular, or it may not. We simply don't know yet.

Therefore, why are we rushing to build on top of it as part of the
very next release?

If LVTI turns out to be hugely popular, there will be another release
along in 6 (or 12) months time where we can implement this.

But why now? Why rush, in advance of seeing how our users will
actually use the bedrock feature on which this rests?

Java already has, IMO, far too much syntactic cruft and edge cases,
much of it from the early days. It can never be fixed, and we all just
have to live with it.

Why rush to add unproven features that may just add more syntax that
needs to be worked around?

Ben


On Thu, Jan 25, 2018 at 8:40 PM,  <mark.reinhold at oracle.com> wrote:
> The following JEP is proposed to target JDK 11:
>
>   323: Local-Variable Syntax for Lambda Parameters
>        http://openjdk.java.net/jeps/323
>
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 1 February, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
>
> - Mark
>
>
> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From orionllmain at gmail.com  Fri Jan 26 09:59:38 2018
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Fri, 26 Jan 2018 16:59:38 +0700
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
Message-ID: <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>

The motivation is to allow `final` and annotations on lambda parameters:

(final var x) ? x + 1;
(@Nonnull var x) ? x + 1;

This is impossible to write with an implicitly typed lambda:

(final x) ? x + 1; // Illegal
(@Nonnull x) ? x + 1; // Illegal


2018-01-26 15:30 GMT+07:00 Martijn Verburg <martijnverburg at gmail.com>:

> Hi all,
>
> I'm struggling to understand the motivation for this JEP in terms of it
> adding improved understanding or readability of source code (as the
> implicit case is already covered today).
>
> I also suspect the illegal use uses (extract below) will likely confuse and
> frustrate day to day developer's who don't understand the underlying type
> inference system and lead to
> some heavily upvoted SO Q's.  I liken this type of frustration seen in
> developers not understanding generics in full and coming undone in corner
> cases where they expect the element of
> 'least surprise'.
>
> ------
>
> The following examples are illegal:
>
> (var x, y) -> x + y        // Cannot mix var and "no var" in
> implicitly typed lambda expression
> (var x, int y) -> x + y    // Cannot mix var and manifest types in
> explicitly typed lambda expression
>
>
> -------
>
> I'm not sure I've explained myself very eloquently here, hope this has made
> some sense.
>
> Cheers,
> Martijn
>
> On 26 January 2018 at 08:40, <mark.reinhold at oracle.com> wrote:
>
> > The following JEP is proposed to target JDK 11:
> >
> >   323: Local-Variable Syntax for Lambda Parameters
> >        http://openjdk.java.net/jeps/323
> >
> > Feedback on this proposal is more than welcome, as are reasoned
> > objections.  If no such objections are raised by 23:00 UTC on Thursday,
> > 1 February, or if they're raised and then satisfactorily answered, then
> > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
> >
> > - Mark
> >
> >
> > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> >
>

From volker.simonis at gmail.com  Fri Jan 26 10:25:56 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 26 Jan 2018 11:25:56 +0100
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <5A624C97.3020408@oracle.com>
References: <5A624C97.3020408@oracle.com>
Message-ID: <CA+3eh10QozCQbefhQH8W44BAAUR0DXC_U2HFyjFLynBAT8B+dw@mail.gmail.com>

Hi Alex,

after reasoning more about this proposal I came to the conclusion that
we actually already have a mechanism in place for exactly this use
case. It is called JSR (Java Specification Request) [0] and it is part
of the JCP process.

Numerous Java technologies have been developed as JSRs in the past.
Examples are Generics (JSR 14), InvokeDynamic (JSR 292) and JVMTI (JSR
163) to name just a few, but you can also take a look at [1] for a
complete list.

- JSRs can be developed independently of Java SE releases
- JSRs have an associated TCK
- JSRs can be easily developed independently by different vendors
- JSRs can be maintained and evolved
- JSRs can be included into an umbrella Java SE platform JSR

This all seems like a perfect fit for the use case that's being tried
to be addressed with the proposed "Incubating Language and VM
Features" JEP, however with the following additional advantages:

- we don't "pollute" the SE specification with features which may be
potentially changed in an incompatible way and/or removed every six
month.
- every Java vendor has the possibility to freely decide which JSR he
wants to support (until the JSR get's merged into the SE specification
of coarse)
- the JSRs are independent of the Java SE release (instead of the
proposed '--incubating' we could use something like
'--with-jsr=<jsr_nr>')

If Oracle doesn't like the JSR process, it can easily change and/or
improve it. Oracle is actually the only entity who can do that! If
Oracle thinks that the JSR/JCP process is broken beyond repair, it
could easily donate the whole Java SE reference implementation and TCK
to an independent organization as it already happened recently with
Java EE. That organization could then develop further Java releases in
the way envisioned by the proposed JEP.

The "Incubator Modules" process introduced with JEP 11 [2] is an
OpenJDK-only process which is fine. OpenJDK can arrange its
development processes in any way it likes. But this proposal touches
the way how the Java SE specification is created and maintained and in
my opinion that's the mission of the JCP.

Regards,
Volker

[0] https://www.jcp.org/en/jsr/overview
[1] https://www.jcp.org/en/jsr/platform?listBy=2&listByType=platform
[2] http://openjdk.java.net/jeps/11


On Fri, Jan 19, 2018 at 8:52 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> Many of you are familiar with Incubator Modules from JEP 11. They let us
> ship "incubating" APIs in mainline JDK releases so that we can gather
> feedback from the largest possible pool of developers.
>
> We've been thinking about the idea of having "incubating" features in the
> Java language and the JVM, again with the aim of maximizing feedback. To be
> clear, these would be full-fledged features of the Java SE Platform, in
> contrast to the JDK-specific nature of incubating APIs.
>
> The draft JEP below explains our thinking. Like JEP 11, it's an
> Informational JEP rather than a Feature JEP because it outlines
> policy/principles rather than a concrete feature. Your comments are welcome.
>
>   https://bugs.openjdk.java.net/browse/JDK-8195734
>
> Alex

From jbluettduncan at gmail.com  Fri Jan 26 13:47:12 2018
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Fri, 26 Jan 2018 13:47:12 +0000
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
Message-ID: <CAPMys84vi6ej67vG1LDv+-3TP0bSJ9O+dpZtFuMiAJTL-xE2xA@mail.gmail.com>

Hmm, is that not what variables like the following are for?

Function<@Nullable Integer, @Nonnull Integer> function = x -> (x == null) ?
0 : x + 1;

On 26 January 2018 at 09:59, Zheka Kozlov <orionllmain at gmail.com> wrote:

> The motivation is to allow `final` and annotations on lambda parameters:
>
> (final var x) ? x + 1;
> (@Nonnull var x) ? x + 1;
>
> This is impossible to write with an implicitly typed lambda:
>
> (final x) ? x + 1; // Illegal
> (@Nonnull x) ? x + 1; // Illegal
>
>
> 2018-01-26 15:30 GMT+07:00 Martijn Verburg <martijnverburg at gmail.com>:
>
> > Hi all,
> >
> > I'm struggling to understand the motivation for this JEP in terms of it
> > adding improved understanding or readability of source code (as the
> > implicit case is already covered today).
> >
> > I also suspect the illegal use uses (extract below) will likely confuse
> and
> > frustrate day to day developer's who don't understand the underlying type
> > inference system and lead to
> > some heavily upvoted SO Q's.  I liken this type of frustration seen in
> > developers not understanding generics in full and coming undone in corner
> > cases where they expect the element of
> > 'least surprise'.
> >
> > ------
> >
> > The following examples are illegal:
> >
> > (var x, y) -> x + y        // Cannot mix var and "no var" in
> > implicitly typed lambda expression
> > (var x, int y) -> x + y    // Cannot mix var and manifest types in
> > explicitly typed lambda expression
> >
> >
> > -------
> >
> > I'm not sure I've explained myself very eloquently here, hope this has
> made
> > some sense.
> >
> > Cheers,
> > Martijn
> >
> > On 26 January 2018 at 08:40, <mark.reinhold at oracle.com> wrote:
> >
> > > The following JEP is proposed to target JDK 11:
> > >
> > >   323: Local-Variable Syntax for Lambda Parameters
> > >        http://openjdk.java.net/jeps/323
> > >
> > > Feedback on this proposal is more than welcome, as are reasoned
> > > objections.  If no such objections are raised by 23:00 UTC on Thursday,
> > > 1 February, or if they're raised and then satisfactorily answered, then
> > > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
> > >
> > > - Mark
> > >
> > >
> > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> > >
> >
>

From adinn at redhat.com  Fri Jan 26 13:54:56 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 26 Jan 2018 13:54:56 +0000
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAPMys84vi6ej67vG1LDv+-3TP0bSJ9O+dpZtFuMiAJTL-xE2xA@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
 <CAPMys84vi6ej67vG1LDv+-3TP0bSJ9O+dpZtFuMiAJTL-xE2xA@mail.gmail.com>
Message-ID: <8528a78c-8d21-ff2b-ab27-9f32477bf9f7@redhat.com>

On 26/01/18 13:47, Jonathan Bluett-Duncan wrote:
> Hmm, is that not what variables like the following are for?
> 
> Function<@Nullable Integer, @Nonnull Integer> function = x -> (x == null) ?
> 0 : x + 1;

My, how old-school having to actually inscribe in your program the
semantics you intend for your code, plain for all to see and comprehend,
when a super-smart (TM) compiler can simply invent them for you out of
thin^H^H^H^H abundant white space.

Look how many characters it requires to make your intentions clear. Not
to mention the amount of thought required in order to be able to express
them explicitly.

This is progress and it cannot be resisted.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From jbluettduncan at gmail.com  Fri Jan 26 14:02:52 2018
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Fri, 26 Jan 2018 14:02:52 +0000
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <8528a78c-8d21-ff2b-ab27-9f32477bf9f7@redhat.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
 <CAPMys84vi6ej67vG1LDv+-3TP0bSJ9O+dpZtFuMiAJTL-xE2xA@mail.gmail.com>
 <8528a78c-8d21-ff2b-ab27-9f32477bf9f7@redhat.com>
Message-ID: <CAPMys86BwGob=t4ttef-ABJsbPzyBe2HWnFuW=VRsJBdWtEgog@mail.gmail.com>

Hi Andrew,

I admit I'm a bit lost. I struggle to see how the following:

Function<Integer, Integer> function = (@Nullable x) -> (x == null) ? 0 : x
+ 1;

would be any better than:

Function<@Nullable Integer, @Nonnull Integer> function = x -> (x == null) ?
0 : x + 1;

or even just the following (if we make the reasonable assumption that
everything is non-null by default):

Function<@Nullable Integer, Integer> function = x -> (x == null) ? 0 : x +
1;

Is there something I'm missing here? :)

Cheers,
Jonathan

On 26 January 2018 at 13:54, Andrew Dinn <adinn at redhat.com> wrote:

> On 26/01/18 13:47, Jonathan Bluett-Duncan wrote:
> > Hmm, is that not what variables like the following are for?
> >
> > Function<@Nullable Integer, @Nonnull Integer> function = x -> (x ==
> null) ?
> > 0 : x + 1;
>
> My, how old-school having to actually inscribe in your program the
> semantics you intend for your code, plain for all to see and comprehend,
> when a super-smart (TM) compiler can simply invent them for you out of
> thin^H^H^H^H abundant white space.
>
> Look how many characters it requires to make your intentions clear. Not
> to mention the amount of thought required in order to be able to express
> them explicitly.
>
> This is progress and it cannot be resisted.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>

From fweimer at redhat.com  Fri Jan 26 14:29:36 2018
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 26 Jan 2018 15:29:36 +0100
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
Message-ID: <625091a1-1176-7ac1-0c0b-f4e23a58f04e@redhat.com>

On 01/26/2018 10:59 AM, Zheka Kozlov wrote:
> The motivation is to allow `final` and annotations on lambda parameters:
> 
> (final var x) ? x + 1;
> (@Nonnull var x) ? x + 1;
> 
> This is impossible to write with an implicitly typed lambda:
> 
> (final x) ? x + 1; // Illegal
> (@Nonnull x) ? x + 1; // Illegal

Is this a useful feature?  Either the annotation can be inferred from 
the context, or it does not matter at all (it cannot be checked at run 
time due to erasure).

Based on the follow-ups, it's not clear whether this is supposed to 
apply to the method argument or a type parameter.  Syntactically, I 
would expect it to apply to the method argument.

Thanks,
Florian

From maurizio.cimadamore at oracle.com  Fri Jan 26 15:08:24 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 26 Jan 2018 15:08:24 +0000
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <20180125114048.564564978@eggemoggin.niobe.net>
References: <20180125114048.564564978@eggemoggin.niobe.net>
Message-ID: <2b25ce43-7c07-5969-ac69-2f8a3a75595e@oracle.com>

In response to the many comments in this thread, let me clarify what the 
goals are here:

* first, as in JDK 10 we have 'var' in certain places (local variable 
decl, for loop variable, try with resource variable), it seems 
consistent to apply 'var' in other places too; a lambda parameter is yet 
another case where the parameter type is implicitly typed, so it kind of 
makes sense to let the programmer be able to use 'var' if he/she so wishes.

* the second reason, which was pointed out correctly in the email, is to 
provide a path to add modifiers (such as 'final') and or annotations to 
a lambda parameter w/o the need of resorting to explicit types. That is 
IMHO a small, but valuable improvement. Also note that, while 
availability of annotations on lambdas at runtime depends on the 
translation strategy, there could be compile-time clients (e.g. 
annotation processors) that might be interested in consuming such 
annotations.

* I'm not too worried about the restriction of mixing 'var' and implicit 
parameter in the same lambda, because I'd say that mixing var and legacy 
implicitly typed param leads to less readable code IMHO. That said, 
there's actually no technical reason for enforcing this constraint, so 
this might be a point where we might have some degree of freedom (or 
which could be revised at a later date).

* There *is* a technical reason behind not allowing a mix of explicit 
and implicit parameters, so that's not up for debate. That has been the 
case since JDK 8, and it did not create any concern.

Regards
Maurizio

On 25/01/18 19:40, mark.reinhold at oracle.com wrote:
> The following JEP is proposed to target JDK 11:
>
>    323: Local-Variable Syntax for Lambda Parameters
>         http://openjdk.java.net/jeps/323
>
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 1 February, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
>
> - Mark
>
>
> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html


From aph at redhat.com  Fri Jan 26 15:09:34 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 26 Jan 2018 15:09:34 +0000
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
Message-ID: <d61e5901-f49c-786e-4b88-ef362c7392a0@redhat.com>

On 26/01/18 09:59, Zheka Kozlov wrote:
> The motivation is to allow `final` and annotations on lambda parameters:
> 
> (final var x) ? x + 1;
> (@Nonnull var x) ? x + 1;

I'm trying to understand how it makes sense to have something
that's both variable and final.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From brian.goetz at oracle.com  Fri Jan 26 16:02:38 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 26 Jan 2018 11:02:38 -0500
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <2b25ce43-7c07-5969-ac69-2f8a3a75595e@oracle.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <2b25ce43-7c07-5969-ac69-2f8a3a75595e@oracle.com>
Message-ID: <B2493821-DA82-4FA5-9D78-D227E76F17D4@oracle.com>

Additionally?

1.  It seems that part of the force behind the reactions is due to the seeming triviality of the feature.  But this is more about the more rapid cadence than about the feature itself.  The Amber EG discussed this feature in the context of local variable type inference, but chose to carve it off to reduce the risk of the main part of that feature missing the train, and then continue deliberating on the finer points of the interaction with lambdas.  This is a feature, not a bug.  

2.  Part of the motivation here is pedagogical / historical cleanup.  When we did lambdas, we found there was a lot of confusion over the various syntactic forms for lambdas (explicit, implicit, unary implicit), and early articles and textbook drafts made it seem way more complicated than it was, treating each form as its own special case.  Adding in the var form smooths out what was a bump in the explanation, now we can say

    x -> e

is just shorthand for

    (x) -> e

which is just shorthand for

    (var x) -> e

which is just shorthand for a particular instantiation of

    (T x) -> e

Defining one syntactic form in terms of another reduces the cognitive load of learning and reasoning about the feature, and helps users direct their brain cycles to the actual hard part of the feature.

Aligning the use of inference for variables and for function parameters additionally helps people learn, because by using the same syntactic indicator, people realize that it is the same concept: ?I would rather not write down the type here, please infer it.?  Each use of var strengthens the other.  

As features are added incrementally, it will periodically become sensible to clean up their interactions to reduce the number of special cases and sharp corners, not only to make the language easier to learn and reason about, but also to provide a smoother base to build future features on.  So while this feature may not get anyone excited about ?boy, I want to write my lambdas that way?, that?s not the point.  We?re not taking away your favorite syntax, we?re putting that syntax on a firmer footing.  

3.  Laying groundwork for the future.  Maurizio is correct that we are not ready to do partially implicit lambdas ( (var x, int y) -> e ), as we were similarly not ready to do in 8 when the feature first came up.  However, regularizing the syntactic basis for lambdas paves the way to a smoother path to doing so in the future, which I think we would still like to do (though it is not yet near the top of the priority list, which is why we haven?t done it yet.)

4.  I find that much of the angst about proposed new features is a generalized fear that we?re investing significant effort in something people don?t care about, which is taking resources away from things they do.  I assure you that is not the case; the spec and implementation here are trivial.  

In a perfect world, this would have been part of the LVTI JEP; for good and valid reasons, we severed it, and now we?re reattaching it.  That?s all that?s going on here.  


> On Jan 26, 2018, at 10:08 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> In response to the many comments in this thread, let me clarify what the goals are here:
> 
> * first, as in JDK 10 we have 'var' in certain places (local variable decl, for loop variable, try with resource variable), it seems consistent to apply 'var' in other places too; a lambda parameter is yet another case where the parameter type is implicitly typed, so it kind of makes sense to let the programmer be able to use 'var' if he/she so wishes.
> 
> * the second reason, which was pointed out correctly in the email, is to provide a path to add modifiers (such as 'final') and or annotations to a lambda parameter w/o the need of resorting to explicit types. That is IMHO a small, but valuable improvement. Also note that, while availability of annotations on lambdas at runtime depends on the translation strategy, there could be compile-time clients (e.g. annotation processors) that might be interested in consuming such annotations.
> 
> * I'm not too worried about the restriction of mixing 'var' and implicit parameter in the same lambda, because I'd say that mixing var and legacy implicitly typed param leads to less readable code IMHO. That said, there's actually no technical reason for enforcing this constraint, so this might be a point where we might have some degree of freedom (or which could be revised at a later date).
> 
> * There *is* a technical reason behind not allowing a mix of explicit and implicit parameters, so that's not up for debate. That has been the case since JDK 8, and it did not create any concern.
> 
> Regards
> Maurizio
> 
> On 25/01/18 19:40, mark.reinhold at oracle.com wrote:
>> The following JEP is proposed to target JDK 11:
>> 
>>   323: Local-Variable Syntax for Lambda Parameters
>>        http://openjdk.java.net/jeps/323
>> 
>> Feedback on this proposal is more than welcome, as are reasoned
>> objections.  If no such objections are raised by 23:00 UTC on Thursday,
>> 1 February, or if they're raised and then satisfactorily answered, then
>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
>> 
>> - Mark
>> 
>> 
>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> 


From brian.goetz at oracle.com  Fri Jan 26 16:15:18 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 26 Jan 2018 11:15:18 -0500
Subject: Draft JEP: Incubating Language and VM Features
In-Reply-To: <CA+3eh10QozCQbefhQH8W44BAAUR0DXC_U2HFyjFLynBAT8B+dw@mail.gmail.com>
References: <5A624C97.3020408@oracle.com>
 <CA+3eh10QozCQbefhQH8W44BAAUR0DXC_U2HFyjFLynBAT8B+dw@mail.gmail.com>
Message-ID: <FEEE29FA-AD6D-42B5-9DBC-6AFE3FEFC21D@oracle.com>

There is nothing in this JEP that is inconsistent with developing an incubating feature in the context of a component JSR.  The choice of a component JSR vs pushing spec changes directly through the platform JSR is an orthogonal one.  

The alternative approach you propose is one we could have taken, but we deliberately chose not to.  While I understand your concerns about pollution, you cite exactly what we?re trying to avoid: 

> - every Java vendor has the possibility to freely decide which JSR he
> wants to support (until the JSR get's merged into the SE specification
> of coarse)

The word for this is ?fragmentation?; that?s exactly what we don?t want.  The goal here is to eliminate a specific risk: that we get a permanent feature wrong, and we miss the chance to fix it before it becomes permanent legacy.  Incubation is a delicate balance that enables this without encouraging fragmentation.  

So yes, in an alternate universe, we could have proposed this ? but we think this is the wrong choice, so we didn?t propose it.



From dalibor.topic at oracle.com  Fri Jan 26 16:40:32 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 26 Jan 2018 17:40:32 +0100
Subject: JDK submit repo
In-Reply-To: <20180124081734.43711657@eggemoggin.niobe.net>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <c45546e5-5a65-c736-4b1c-2c29396e9934@oracle.com>
 <20180124081734.43711657@eggemoggin.niobe.net>
Message-ID: <f62ff422-d3f6-0240-c44d-f696e94fc381@oracle.com>



On 24.01.2018 17:17, mark.reinhold at oracle.com wrote:
> Yes.
> 
>> Instead, I would suggest explicitly advising Comitters with test
>> failures to forward them to the jdk-dev mailing list in search of an
>> Oracle engineer.
> 
> Please, no.  Asking jdk-dev should be the option of last resort.  If
> you're working on a fix for something then you've hopefully already
> discussed it on the appropriate list.  I agree that we should make it
> easier for newcomers to figure out which list to go to, but spamming
> jdk-dev is not the answer.

Yeah, documenting how to go from 'something failed' to finding the right 
list to post to as part of the wiki (or ideally, as part of the e-mail 
being sent out - a URL to a separate page on the wiki describing what 
steps to follow to find the right mailing list to contact) would be 
sufficient.

I think in the longer term, it would be useful for JDK and JDK Updates 
to consider adopting a mechanism similar to the Maintainers file the 
Linux kernel uses to delineate source code areas with their respective 
mailing lists to contact.

That way instructions such as the above could become rather simple, and 
ripe for further automation.

cheers,
dalibor topic

[0] https://www.kernel.org/doc/linux/MAINTAINERS
-- 
<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 mark.reinhold at oracle.com  Fri Jan 26 18:31:18 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 26 Jan 2018 10:31:18 -0800
Subject: JEP proposed to target JDK 11: 320: Remove the Java EE and CORBA
 Modules
In-Reply-To: <20180118134627.727353590@eggemoggin.niobe.net>
References: <20180118134627.727353590@eggemoggin.niobe.net>
Message-ID: <20180126103118.91304277@eggemoggin.niobe.net>

2018/1/18 13:46:27 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 11:
> 
>   320: Remove the Java EE and CORBA Modules
>        http://openjdk.java.net/jeps/320
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 25 January, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.

Hearing no objections, I've targeted this JEP to JDK 11.

- Mark

From martijnverburg at gmail.com  Sun Jan 28 21:50:42 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 29 Jan 2018 10:50:42 +1300
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
Message-ID: <CAP7YuAR6Ka8wX1fWZh_LLND29UFzfZpD7FBX5QZfrTb8ytme0Q@mail.gmail.com>

Hi Zheka,

(I'm going to try to reply to everyone since I started this discussion :-))

Whilst I'm not sure about the practically of `final var` in this situation
I can get behind the annotation support, thanks for pointing these out!

Cheers,
Martijn

On 26 January 2018 at 22:59, Zheka Kozlov <orionllmain at gmail.com> wrote:

> The motivation is to allow `final` and annotations on lambda parameters:
>
> (final var x) ? x + 1;
> (@Nonnull var x) ? x + 1;
>
> This is impossible to write with an implicitly typed lambda:
>
> (final x) ? x + 1; // Illegal
> (@Nonnull x) ? x + 1; // Illegal
>
>
> 2018-01-26 15:30 GMT+07:00 Martijn Verburg <martijnverburg at gmail.com>:
>
>> Hi all,
>>
>> I'm struggling to understand the motivation for this JEP in terms of it
>> adding improved understanding or readability of source code (as the
>> implicit case is already covered today).
>>
>> I also suspect the illegal use uses (extract below) will likely confuse
>> and
>> frustrate day to day developer's who don't understand the underlying type
>> inference system and lead to
>> some heavily upvoted SO Q's.  I liken this type of frustration seen in
>> developers not understanding generics in full and coming undone in corner
>> cases where they expect the element of
>> 'least surprise'.
>>
>> ------
>>
>> The following examples are illegal:
>>
>> (var x, y) -> x + y        // Cannot mix var and "no var" in
>> implicitly typed lambda expression
>> (var x, int y) -> x + y    // Cannot mix var and manifest types in
>> explicitly typed lambda expression
>>
>>
>> -------
>>
>> I'm not sure I've explained myself very eloquently here, hope this has
>> made
>> some sense.
>>
>> Cheers,
>> Martijn
>>
>> On 26 January 2018 at 08:40, <mark.reinhold at oracle.com> wrote:
>>
>> > The following JEP is proposed to target JDK 11:
>> >
>> >   323: Local-Variable Syntax for Lambda Parameters
>> >        http://openjdk.java.net/jeps/323
>> >
>> > Feedback on this proposal is more than welcome, as are reasoned
>> > objections.  If no such objections are raised by 23:00 UTC on Thursday,
>> > 1 February, or if they're raised and then satisfactorily answered, then
>> > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
>> >
>> > - Mark
>> >
>> >
>> > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>> >
>>
>
>

From martijnverburg at gmail.com  Sun Jan 28 22:10:28 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 29 Jan 2018 11:10:28 +1300
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <B2493821-DA82-4FA5-9D78-D227E76F17D4@oracle.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <2b25ce43-7c07-5969-ac69-2f8a3a75595e@oracle.com>
 <B2493821-DA82-4FA5-9D78-D227E76F17D4@oracle.com>
Message-ID: <CAP7YuATLK_opqoNcDKLP7Z9o=Vc5j6LiXhE-HBp1egSNwvSRyw@mail.gmail.com>

Hi all,

I'll just reply to Brian's response as he covers everything (but thanks to
everyone else who responded!)

On 27 January 2018 at 05:02, Brian Goetz <brian.goetz at oracle.com> wrote:

> Additionally?
>
> 1.  It seems that part of the force behind the reactions is due to the
> seeming triviality of the feature.  But this is more about the more rapid
> cadence than about the feature itself.  The Amber EG discussed this feature
> in the context of local variable type inference, but chose to carve it off
> to reduce the risk of the main part of that feature missing the train, and
> then continue deliberating on the finer points of the interaction with
> lambdas.  This is a feature, not a bug.
>

I personally don't have an issue it being a small or seemingly trivial
feature, this is a good thing given the new cadence :-). What I was missing
(my lack of understanding) was that this smaller feature fit into the
larger (LVTI) picture.  It might be worth (annoying as it is to have to
summarise what's already been discussed on lists) putting that sort of
summary statement in similar JEPs going forward - "This JEP is also a piece
/ stepping stone to X, Y, Z".


> 2.  Part of the motivation here is pedagogical / historical cleanup.  When
> we did lambdas, we found there was a lot of confusion over the various
> syntactic forms for lambdas (explicit, implicit, unary implicit), and early
> articles and textbook drafts made it seem way more complicated than it was,
> treating each form as its own special case.  Adding in the var form smooths
> out what was a bump in the explanation, now we can say
>
>     x -> e
>
> is just shorthand for
>
>     (x) -> e
>
> which is just shorthand for
>
>     (var x) -> e
>
> which is just shorthand for a particular instantiation of
>
>     (T x) -> e
>
> Defining one syntactic form in terms of another reduces the cognitive load
> of learning and reasoning about the feature, and helps users direct their
> brain cycles to the actual hard part of the feature.
>
> Aligning the use of inference for variables and for function parameters
> additionally helps people learn, because by using the same syntactic
> indicator, people realize that it is the same concept: ?I would rather not
> write down the type here, please infer it.?  Each use of var strengthens
> the other.
>

OK, this makes total sense and is indeed cleaner.  There will of course be
the issue of there being a lot of historical examples and literature out
there which will need to be updated with the hierarchy you described.  The
adoption group can go and find some top SO Q&A posts around this topic and
update them when the time comes (as well as adding some small blog posts
etc).

I can also see people asking "Why can't I use var in my lambda when I can
use it everywhere else?" so it's more consistent this way.


> As features are added incrementally, it will periodically become sensible
> to clean up their interactions to reduce the number of special cases and
> sharp corners, not only to make the language easier to learn and reason
> about, but also to provide a smoother base to build future features on.  So
> while this feature may not get anyone excited about ?boy, I want to write
> my lambdas that way?, that?s not the point.  We?re not taking away your
> favorite syntax, we?re putting that syntax on a firmer footing.
>

Less corner cases are most welcome and from Maurizio's response I see that
one of my corner case concerns could be resolved (assuming it becomes a
real problem) and that the other one matches existing behaviour (so it
doesn't make it worse at least), so that's OK as well.


> 3.  Laying groundwork for the future.  Maurizio is correct that we are not
> ready to do partially implicit lambdas ( (var x, int y) -> e ), as we were
> similarly not ready to do in 8 when the feature first came up.  However,
> regularizing the syntactic basis for lambdas paves the way to a smoother
> path to doing so in the future, which I think we would still like to do
> (though it is not yet near the top of the priority list, which is why we
> haven?t done it yet.)
>

Ah even better!


> 4.  I find that much of the angst about proposed new features is a
> generalized fear that we?re investing significant effort in something
> people don?t care about, which is taking resources away from things they
> do.  I assure you that is not the case; the spec and implementation here
> are trivial.
>

This certainly wasn't my personal concern, I just couldn't figure out the
stand alone value of this JEP, especially when (for me) it added more
cognitive load to the developer as opposed to less.


> In a perfect world, this would have been part of the LVTI JEP; for good
> and valid reasons, we severed it, and now we?re reattaching it.  That?s all
> that?s going on here.
>

In isolation I was scratching my head over this feature, but as part of the
LVTI JEP it totally makes sense, and I missed that hierarchy piece in my
thinking.

Thanks for taking the time to respond everyone, I appreciate it's an extra
unwelcome load when a part timer comes in and asks for explanations!

Cheers,
Martijn


>
>
> > On Jan 26, 2018, at 10:08 AM, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
> >
> > In response to the many comments in this thread, let me clarify what the
> goals are here:
> >
> > * first, as in JDK 10 we have 'var' in certain places (local variable
> decl, for loop variable, try with resource variable), it seems consistent
> to apply 'var' in other places too; a lambda parameter is yet another case
> where the parameter type is implicitly typed, so it kind of makes sense to
> let the programmer be able to use 'var' if he/she so wishes.
> >
> > * the second reason, which was pointed out correctly in the email, is to
> provide a path to add modifiers (such as 'final') and or annotations to a
> lambda parameter w/o the need of resorting to explicit types. That is IMHO
> a small, but valuable improvement. Also note that, while availability of
> annotations on lambdas at runtime depends on the translation strategy,
> there could be compile-time clients (e.g. annotation processors) that might
> be interested in consuming such annotations.
> >
> > * I'm not too worried about the restriction of mixing 'var' and implicit
> parameter in the same lambda, because I'd say that mixing var and legacy
> implicitly typed param leads to less readable code IMHO. That said, there's
> actually no technical reason for enforcing this constraint, so this might
> be a point where we might have some degree of freedom (or which could be
> revised at a later date).
> >
> > * There *is* a technical reason behind not allowing a mix of explicit
> and implicit parameters, so that's not up for debate. That has been the
> case since JDK 8, and it did not create any concern.
> >
> > Regards
> > Maurizio
> >
> > On 25/01/18 19:40, mark.reinhold at oracle.com wrote:
> >> The following JEP is proposed to target JDK 11:
> >>
> >>   323: Local-Variable Syntax for Lambda Parameters
> >>        http://openjdk.java.net/jeps/323
> >>
> >> Feedback on this proposal is more than welcome, as are reasoned
> >> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> >> 1 February, or if they're raised and then satisfactorily answered, then
> >> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
> >>
> >> - Mark
> >>
> >>
> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> >
>
>

From forax at univ-mlv.fr  Sun Jan 28 23:47:06 2018
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 29 Jan 2018 00:47:06 +0100 (CET)
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <d61e5901-f49c-786e-4b88-ef362c7392a0@redhat.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
 <d61e5901-f49c-786e-4b88-ef362c7392a0@redhat.com>
Message-ID: <703023386.4161.1517183226022.JavaMail.zimbra@u-pem.fr>

Hi Andrew,

----- Mail original -----
> De: "Andrew Haley" <aph at redhat.com>
> ?: "Zheka Kozlov" <orionllmain at gmail.com>, "Martijn Verburg" <martijnverburg at gmail.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Vendredi 26 Janvier 2018 16:09:34
> Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda Parameters

> On 26/01/18 09:59, Zheka Kozlov wrote:
>> The motivation is to allow `final` and annotations on lambda parameters:
>> 
>> (final var x) ? x + 1;
>> (@Nonnull var x) ? x + 1;
> 
> I'm trying to understand how it makes sense to have something
> that's both variable and final.

yes, 'final var' is an odd combination, 'var' means more this is a local variable and less this is something which is variable. 

In Java, you can declare a parameter of a method final which means it's a local variable that can be only assigned once, given that parameters are assigned with the calling arguments, it means that this parameter can not be re-assigned. This is just a compile time 'annotation', because marking a parameter or a local variable final is not something which is stored in the classfile (apart if you compile with the -parameters, but most people don't).

Some coding conventions, mostly the one from Google mandates that all method parameters are declared final, so since Java 8, some developers have asked to be able to declare lambda parameters final. 

In a perfect World, Google should update its coding convention because mandating to declare local variables final has the nasty side effect of blurring the distinction between final for a field which as you know has effects defined by the memory model and final on local variable which has no effect. So mandating to declare local variables final is harmful.  

> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

cheers,
R?mi

From jbluettduncan at gmail.com  Mon Jan 29 00:02:52 2018
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Mon, 29 Jan 2018 00:02:52 +0000
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <703023386.4161.1517183226022.JavaMail.zimbra@u-pem.fr>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
 <d61e5901-f49c-786e-4b88-ef362c7392a0@redhat.com>
 <703023386.4161.1517183226022.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAPMys86pEft_Hi139_c9sY09mTa7SQrQWFiB5b6+Dxf0mT7Zgg@mail.gmail.com>

Hi R?mi,

You may find my (short) response inline.

On 28 January 2018 at 23:47, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Andrew,
>
> ----- Mail original -----
> > De: "Andrew Haley" <aph at redhat.com>
> > ?: "Zheka Kozlov" <orionllmain at gmail.com>, "Martijn Verburg" <
> martijnverburg at gmail.com>
> > Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> > Envoy?: Vendredi 26 Janvier 2018 16:09:34
> > Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
> Lambda Parameters
>
> > On 26/01/18 09:59, Zheka Kozlov wrote:
> >> The motivation is to allow `final` and annotations on lambda parameters:
> >>
> >> (final var x) ? x + 1;
> >> (@Nonnull var x) ? x + 1;
> >
> > I'm trying to understand how it makes sense to have something
> > that's both variable and final.
>
> yes, 'final var' is an odd combination, 'var' means more this is a local
> variable and less this is something which is variable.
>
> In Java, you can declare a parameter of a method final which means it's a
> local variable that can be only assigned once, given that parameters are
> assigned with the calling arguments, it means that this parameter can not
> be re-assigned. This is just a compile time 'annotation', because marking a
> parameter or a local variable final is not something which is stored in the
> classfile (apart if you compile with the -parameters, but most people
> don't).
>
> Some coding conventions, mostly the one from Google mandates that all
> method parameters are declared final, so since Java 8, some developers have
> asked to be able to declare lambda parameters final.
>

Oh, do Google's coding conventions really mandate this practice? I've had a
look through the Google Java Style guide, but I can't seem to find anything
to confirm it. Do you have a source that I can check?


>
> In a perfect World, Google should update its coding convention because
> mandating to declare local variables final has the nasty side effect of
> blurring the distinction between final for a field which as you know has
> effects defined by the memory model and final on local variable which has
> no effect. So mandating to declare local variables final is harmful.
>
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
> cheers,
> R?mi
>

Cheers,
Jonathan

From jeremymanson at google.com  Mon Jan 29 05:43:49 2018
From: jeremymanson at google.com (Jeremy Manson)
Date: Sun, 28 Jan 2018 21:43:49 -0800
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAPMys86pEft_Hi139_c9sY09mTa7SQrQWFiB5b6+Dxf0mT7Zgg@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
 <d61e5901-f49c-786e-4b88-ef362c7392a0@redhat.com>
 <703023386.4161.1517183226022.JavaMail.zimbra@u-pem.fr>
 <CAPMys86pEft_Hi139_c9sY09mTa7SQrQWFiB5b6+Dxf0mT7Zgg@mail.gmail.com>
Message-ID: <CAPYFHW3y16Zt=YGMRkhZNcJDE7f48n3qMYQ87Dc9jYsFDf8_nw@mail.gmail.com>

We do not require method parameters to be final.  It isn't referenced at
all in our style guide, but we have very copious internal Java best
practices documentation; this is a very slightly modified version of the
relevant passage:
>
> On parameters and local variables*link*
> <http://go/java-practices/final#params_locals>*mode_edit*
> <https://cs.corp.google.com/#piper///depot/eng/doc/devguide/java/practices/final.md&edit=1&l=76>
> *comment*
> <https://engdoc.corp.google.com/eng/doc/devguide/java/practices/final.md?cl=head#>
>
> It would be nice if Java made parameters and local variables final by
> default. Since the need to allow reassignment is both more rare and more
> risky, it makes sense to be opt-in. Unfortunately, Java got this backward.
>
> Some developers prefer to mark all their parameters and local variables
> final unless they are reassigned. There are good reasons for this, but it
> is not clear that the advantages outweigh the costs (lower signal-to-noise,
> and especially burden of enforcement)?and so this practice is not favored
> at Google.
>
> Remember that the dangers of sloppy reassignment of locals will be limited
> if you always keep your methods short and focused. And note that as of Java
> 8 it's no longer necessary to use final on local variables to make them
> accessible from an inner class.
>
> Of course, you can still use final on a local variable when it serves
> some specific purpose. For example, you might use a blank final
> <https://en.wikipedia.org/wiki/Final_(Java)#Blank_final> to signal that
> while you *do* intend to "modify" (set) the value later, you'll do it
> only once.
>
> Available solution: projects can opt in
> <http://go/errorprone/bugpatterns#optional> to @Var Error Prone
> enforcement <http://errorprone.info/bugpattern/Var>. This inverts the
> default: the Error Prone check requires all modified parameters and local
> variables to be explictly annotated with @Var.
>

Jeremy

On Sun, Jan 28, 2018 at 4:02 PM, Jonathan Bluett-Duncan <
jbluettduncan at gmail.com> wrote:

> Hi R?mi,
>
> You may find my (short) response inline.
>
> On 28 January 2018 at 23:47, Remi Forax <forax at univ-mlv.fr> wrote:
>
> > Hi Andrew,
> >
> > ----- Mail original -----
> > > De: "Andrew Haley" <aph at redhat.com>
> > > ?: "Zheka Kozlov" <orionllmain at gmail.com>, "Martijn Verburg" <
> > martijnverburg at gmail.com>
> > > Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> > > Envoy?: Vendredi 26 Janvier 2018 16:09:34
> > > Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax
> for
> > Lambda Parameters
> >
> > > On 26/01/18 09:59, Zheka Kozlov wrote:
> > >> The motivation is to allow `final` and annotations on lambda
> parameters:
> > >>
> > >> (final var x) ? x + 1;
> > >> (@Nonnull var x) ? x + 1;
> > >
> > > I'm trying to understand how it makes sense to have something
> > > that's both variable and final.
> >
> > yes, 'final var' is an odd combination, 'var' means more this is a local
> > variable and less this is something which is variable.
> >
> > In Java, you can declare a parameter of a method final which means it's a
> > local variable that can be only assigned once, given that parameters are
> > assigned with the calling arguments, it means that this parameter can not
> > be re-assigned. This is just a compile time 'annotation', because
> marking a
> > parameter or a local variable final is not something which is stored in
> the
> > classfile (apart if you compile with the -parameters, but most people
> > don't).
> >
> > Some coding conventions, mostly the one from Google mandates that all
> > method parameters are declared final, so since Java 8, some developers
> have
> > asked to be able to declare lambda parameters final.
> >
>
> Oh, do Google's coding conventions really mandate this practice? I've had a
> look through the Google Java Style guide, but I can't seem to find anything
> to confirm it. Do you have a source that I can check?
>
>
> >
> > In a perfect World, Google should update its coding convention because
> > mandating to declare local variables final has the nasty side effect of
> > blurring the distinction between final for a field which as you know has
> > effects defined by the memory model and final on local variable which has
> > no effect. So mandating to declare local variables final is harmful.
> >
> > >
> > > --
> > > Andrew Haley
> > > Java Platform Lead Engineer
> > > Red Hat UK Ltd. <https://www.redhat.com>
> > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >
> > cheers,
> > R?mi
> >
>
> Cheers,
> Jonathan
>

From forax at univ-mlv.fr  Mon Jan 29 07:00:50 2018
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 29 Jan 2018 08:00:50 +0100 (CET)
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAPMys86pEft_Hi139_c9sY09mTa7SQrQWFiB5b6+Dxf0mT7Zgg@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
 <d61e5901-f49c-786e-4b88-ef362c7392a0@redhat.com>
 <703023386.4161.1517183226022.JavaMail.zimbra@u-pem.fr>
 <CAPMys86pEft_Hi139_c9sY09mTa7SQrQWFiB5b6+Dxf0mT7Zgg@mail.gmail.com>
Message-ID: <468572391.42214.1517209250321.JavaMail.zimbra@u-pem.fr>

> De: "Jonathan Bluett-Duncan" <jbluettduncan at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Lundi 29 Janvier 2018 01:02:52
> Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda
> Parameters

> Hi R?mi,

> You may find my (short) response inline.

Hi Johnathan, 

> On 28 January 2018 at 23:47, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> Hi Andrew,

>> ----- Mail original -----
>> > De: "Andrew Haley" < [ mailto:aph at redhat.com | aph at redhat.com ] >
>>> ?: "Zheka Kozlov" < [ mailto:orionllmain at gmail.com | orionllmain at gmail.com ] >,
>>> "Martijn Verburg" < [ mailto:martijnverburg at gmail.com |
>> > martijnverburg at gmail.com ] >
>> > Cc: "jdk-dev" < [ mailto:jdk-dev at openjdk.java.net | jdk-dev at openjdk.java.net ] >
>> > Envoy?: Vendredi 26 Janvier 2018 16:09:34
>>> Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda
>> > Parameters

>> > On 26/01/18 09:59, Zheka Kozlov wrote:
>> >> The motivation is to allow `final` and annotations on lambda parameters:

>> >> (final var x) ? x + 1;
>> >> (@Nonnull var x) ? x + 1;

>> > I'm trying to understand how it makes sense to have something
>> > that's both variable and final.

>> yes, 'final var' is an odd combination, 'var' means more this is a local
>> variable and less this is something which is variable.

>> In Java, you can declare a parameter of a method final which means it's a local
>> variable that can be only assigned once, given that parameters are assigned
>> with the calling arguments, it means that this parameter can not be
>> re-assigned. This is just a compile time 'annotation', because marking a
>> parameter or a local variable final is not something which is stored in the
>> classfile (apart if you compile with the -parameters, but most people don't).

>> Some coding conventions, mostly the one from Google mandates that all method
>> parameters are declared final, so since Java 8, some developers have asked to
>> be able to declare lambda parameters final.

> Oh, do Google's coding conventions really mandate this practice? I've had a look
> through the Google Java Style guide, but I can't seem to find anything to
> confirm it. Do you have a source that I can check?

Ok, this reply enters in the category of "never post after 1am", so i apologize, i should have checked the resources online before saying something stupid, 
i've seen code written by Googlers and ex-Googlers and from that i've stupidly thunk that it was Google thing. 

Actually, it's worst, after a quick search on the internet, it seems to be a checkstyle rule enables by default, not something written in a guide. 

>> In a perfect World, Google should update its coding convention because mandating
>> to declare local variables final has the nasty side effect of blurring the
>> distinction between final for a field which as you know has effects defined by
>> the memory model and final on local variable which has no effect. So mandating
>> to declare local variables final is harmful.


>> > --
>> > Andrew Haley
>> > Java Platform Lead Engineer
>> > Red Hat UK Ltd. < [ https://www.redhat.com/ | https://www.redhat.com ] >
>> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

>> cheers,
>> R?mi

> Cheers,
> Jonathan

regards, 
R?mi 

From forax at univ-mlv.fr  Mon Jan 29 07:01:23 2018
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 29 Jan 2018 08:01:23 +0100 (CET)
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <CAPYFHW3y16Zt=YGMRkhZNcJDE7f48n3qMYQ87Dc9jYsFDf8_nw@mail.gmail.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
 <d61e5901-f49c-786e-4b88-ef362c7392a0@redhat.com>
 <703023386.4161.1517183226022.JavaMail.zimbra@u-pem.fr>
 <CAPMys86pEft_Hi139_c9sY09mTa7SQrQWFiB5b6+Dxf0mT7Zgg@mail.gmail.com>
 <CAPYFHW3y16Zt=YGMRkhZNcJDE7f48n3qMYQ87Dc9jYsFDf8_nw@mail.gmail.com>
Message-ID: <1898543583.42290.1517209283753.JavaMail.zimbra@u-pem.fr>

Ok, cool, my bad on that. 

R?mi 

> De: "Jeremy Manson" <jeremymanson at google.com>
> ?: "Jonathan Bluett-Duncan" <jbluettduncan at gmail.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Lundi 29 Janvier 2018 06:43:49
> Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda
> Parameters

> We do not require method parameters to be final. It isn't referenced at all in
> our style guide, but we have very copious internal Java best practices
> documentation; this is a very slightly modified version of the relevant
> passage:
>> On parameters and local variables [ http://go/java-practices/final#params_locals
>> | link ] [
>> https://cs.corp.google.com/#piper///depot/eng/doc/devguide/java/practices/final.md&edit=1&l=76
>> | mode_edit ] [
>> https://engdoc.corp.google.com/eng/doc/devguide/java/practices/final.md?cl=head#
>> | comment ]

>> It would be nice if Java made parameters and local variables final by default.
>> Since the need to allow reassignment is both more rare and more risky, it makes
>> sense to be opt-in. Unfortunately, Java got this backward.

>> Some developers prefer to mark all their parameters and local variables final
>> unless they are reassigned. There are good reasons for this, but it is not
>> clear that the advantages outweigh the costs (lower signal-to-noise, and
>> especially burden of enforcement)?and so this practice is not favored at
>> Google.

>> Remember that the dangers of sloppy reassignment of locals will be limited if
>> you always keep your methods short and focused. And note that as of Java 8 it's
>> no longer necessary to use final on local variables to make them accessible
>> from an inner class.

>> Of course, you can still use final on a local variable when it serves some
>> specific purpose. For example, you might use a [
>> https://en.wikipedia.org/wiki/Final_(Java)#Blank_final | blank final ] to
>> signal that while you do intend to "modify" (set) the value later, you'll do it
>> only once.

>> Available solution: projects can [ http://go/errorprone/bugpatterns#optional |
>> opt in ] to [ http://errorprone.info/bugpattern/Var | @Var Error Prone
>> enforcement ] . This inverts the default: the Error Prone check requires all
>> modified parameters and local variables to be explictly annotated with @Var .
> Jeremy

> On Sun, Jan 28, 2018 at 4:02 PM, Jonathan Bluett-Duncan < [
> mailto:jbluettduncan at gmail.com | jbluettduncan at gmail.com ] > wrote:

>> Hi R?mi,

>> You may find my (short) response inline.

>> On 28 January 2018 at 23:47, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>> > Hi Andrew,

>> > ----- Mail original -----
>> > > De: "Andrew Haley" < [ mailto:aph at redhat.com | aph at redhat.com ] >
>>> > ?: "Zheka Kozlov" < [ mailto:orionllmain at gmail.com | orionllmain at gmail.com ] >,
>> > > "Martijn Verburg" <
>> > [ mailto:martijnverburg at gmail.com | martijnverburg at gmail.com ] >
>> > > Cc: "jdk-dev" < [ mailto:jdk-dev at openjdk.java.net | jdk-dev at openjdk.java.net ] >
>> > > Envoy?: Vendredi 26 Janvier 2018 16:09:34
>> > > Objet: Re: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
>> > Lambda Parameters

>> > > On 26/01/18 09:59, Zheka Kozlov wrote:
>> > >> The motivation is to allow `final` and annotations on lambda parameters:

>> > >> (final var x) ? x + 1;
>> > >> (@Nonnull var x) ? x + 1;

>> > > I'm trying to understand how it makes sense to have something
>> > > that's both variable and final.

>> > yes, 'final var' is an odd combination, 'var' means more this is a local
>> > variable and less this is something which is variable.

>> > In Java, you can declare a parameter of a method final which means it's a
>> > local variable that can be only assigned once, given that parameters are
>> > assigned with the calling arguments, it means that this parameter can not
>> > be re-assigned. This is just a compile time 'annotation', because marking a
>> > parameter or a local variable final is not something which is stored in the
>> > classfile (apart if you compile with the -parameters, but most people
>> > don't).

>> > Some coding conventions, mostly the one from Google mandates that all
>> > method parameters are declared final, so since Java 8, some developers have
>> > asked to be able to declare lambda parameters final.


>> Oh, do Google's coding conventions really mandate this practice? I've had a
>> look through the Google Java Style guide, but I can't seem to find anything
>> to confirm it. Do you have a source that I can check?


>> > In a perfect World, Google should update its coding convention because
>> > mandating to declare local variables final has the nasty side effect of
>> > blurring the distinction between final for a field which as you know has
>> > effects defined by the memory model and final on local variable which has
>> > no effect. So mandating to declare local variables final is harmful.


>> > > --
>> > > Andrew Haley
>> > > Java Platform Lead Engineer
>> > > Red Hat UK Ltd. < [ https://www.redhat.com/ | https://www.redhat.com ] >
>> > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

>> > cheers,
>> > R?mi


>> Cheers,
>> Jonathan

From fweimer at redhat.com  Tue Jan 30 09:21:58 2018
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 30 Jan 2018 10:21:58 +0100
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <2b25ce43-7c07-5969-ac69-2f8a3a75595e@oracle.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <2b25ce43-7c07-5969-ac69-2f8a3a75595e@oracle.com>
Message-ID: <b044e47c-4337-393f-f209-705209030765@redhat.com>

On 01/26/2018 04:08 PM, Maurizio Cimadamore wrote:
> 
> * the second reason, which was pointed out correctly in the email, is to 
> provide a path to add modifiers (such as 'final') and or annotations to 
> a lambda parameter w/o the need of resorting to explicit types.

I would love to see some more discussion how you plan to add annotation 
support without reifying the lambda.  There was a recent discussion 
about the lack of generic type information for lambdas, and people 
didn't want to add this.  Why would we do essentially the same thing for 
annotations?

On this thread, it has been suggested that the annotation on the lambda 
parameter would instead be applied to the type parameter of a generic 
type.  Was this an oversight, or is this expected to be part of a future 
design?

Thanks,
Florian

From shade at redhat.com  Tue Jan 30 10:50:45 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 30 Jan 2018 11:50:45 +0100
Subject: JDK submit repo
In-Reply-To: <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com>
Message-ID: <cc3a76aa-57a3-b305-aa63-84ed8c853a02@redhat.com>

On 01/24/2018 01:00 PM, Aleksey Shipilev wrote:
> On 01/23/2018 09:33 PM, mark.reinhold at oracle.com wrote:
>> The submit repo is now open for pushes from any JDK Committer:
>>
>>   http://hg.openjdk.java.net/jdk/submit
>>
>> If you push a branch whose name starts with "JDK-" into this repo
>> then it will automatically be built and tested on Oracle's internal
>> build system, and a summary of the results will be e-mailed back to
>> you.  This typically takes a couple of hours.  If one or more tests
>> fail then you can contact an Oracle engineer to get more information
>> about the failures.
> 
> Excellent, thank you! Trying it now!

So I have submitted JDK-8174901 five days ago, and there was silence since then. Is *this* the kinds
of thing to ask at ops@?

Thanks,
-Aleksey


From maurizio.cimadamore at oracle.com  Tue Jan 30 13:09:40 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 30 Jan 2018 13:09:40 +0000
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <703023386.4161.1517183226022.JavaMail.zimbra@u-pem.fr>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <CAP7YuAR4Fn=pfAUHJ=BDkCZ=EdnSH3x8Lsr7UPuKiENusnqUBw@mail.gmail.com>
 <CAF2POUd6PDUyo4Wu3_oUeEEw2==R3Lmcftd3Xi9zm74hxswzCA@mail.gmail.com>
 <d61e5901-f49c-786e-4b88-ef362c7392a0@redhat.com>
 <703023386.4161.1517183226022.JavaMail.zimbra@u-pem.fr>
Message-ID: <f7ca6809-fe19-a013-01bb-008111d07626@oracle.com>



On 28/01/18 23:47, Remi Forax wrote:
> yes, 'final var' is an odd combination, 'var' means more this is a local variable and less this is something which is variable.
For the record - this has nothing to do with the JEP being targeted and 
the basic local variable type inference support (JEP 286) also has this.

While I understand the concern of 'var' and 'final' seemingly pointing 
at opposite directions in the space, I must also note that the spec (and 
devs too?) has used the term 'final variables' for ages:

https://docs.oracle.com/javase/specs/jls/se9/html/jls-4.html#jls-4.12.4

Cheers
Maurizio

From maurizio.cimadamore at oracle.com  Tue Jan 30 13:27:32 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 30 Jan 2018 13:27:32 +0000
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <b044e47c-4337-393f-f209-705209030765@redhat.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <2b25ce43-7c07-5969-ac69-2f8a3a75595e@oracle.com>
 <b044e47c-4337-393f-f209-705209030765@redhat.com>
Message-ID: <eb8d2732-1b50-d89e-437d-2c857f3f2e54@oracle.com>



On 30/01/18 09:21, Florian Weimer wrote:
> On 01/26/2018 04:08 PM, Maurizio Cimadamore wrote:
>>
>> * the second reason, which was pointed out correctly in the email, is 
>> to provide a path to add modifiers (such as 'final') and or 
>> annotations to a lambda parameter w/o the need of resorting to 
>> explicit types.
>
> I would love to see some more discussion how you plan to add 
> annotation support without reifying the lambda.? There was a recent 
> discussion about the lack of generic type information for lambdas, and 
> people didn't want to add this.? Why would we do essentially the same 
> thing for annotations?
I didn't suggest we should have additional support for annotations.

That said, lambda parameters CAN be annotated today, only, the 
annotations are not guaranteed to survive until runtime. This is good 
enough for static tools (annotation processors) that need to consume 
such annotations (as said in my previous message), but not good enough 
for frameworks which need to reflectively inspect such annotations at 
runtime. This JEP in no way changes the status quo w.r.t. annotation 
support. It simply doesn't force you to put in an explicit type, should 
you really want to annotate a lambda parameter (knowing the limitations 
that annotated lambda parameters have).

See:

https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.6.4.2

"if m has an element whose value is 
java.lang.annotation.RetentionPolicy.CLASS or 
java.lang.annotation.RetentionPolicy.RUNTIME, then a Java compiler must 
ensure that a is represented in the binary representation of the class 
or interface in which a appears, *unless a annotates a local variable 
declaration or a annotates a formal parameter declaration of a lambda 
expression*."

Cheers
Maurizio
>
> On this thread, it has been suggested that the annotation on the 
> lambda parameter would instead be applied to the type parameter of a 
> generic type.? Was this an oversight, or is this expected to be part 
> of a future design?
>
> Thanks,
> Florian


From brian.goetz at oracle.com  Tue Jan 30 15:28:18 2018
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 30 Jan 2018 10:28:18 -0500
Subject: JEP proposed to target JDK 11: 323: Local-Variable Syntax for
 Lambda Parameters
In-Reply-To: <b044e47c-4337-393f-f209-705209030765@redhat.com>
References: <20180125114048.564564978@eggemoggin.niobe.net>
 <2b25ce43-7c07-5969-ac69-2f8a3a75595e@oracle.com>
 <b044e47c-4337-393f-f209-705209030765@redhat.com>
Message-ID: <662FEF57-8A3E-4B24-B19A-F18310F71986@oracle.com>

> On this thread, it has been suggested that the annotation on the lambda parameter would instead be applied to the type parameter of a generic type.  Was this an oversight, or is this expected to be part of a future design?

That sounds like someone was confused on the distinction between type annotations and declaration annotations.  When annotating a method parameter:

     m(@Foo Bar b) { }

whether @Foo annotates the declaration b or the type Bar depends on whether @Foo can be targeted at a type use or not.  Treatment of lambda parameters would be the same.  

There are no current plans to reify annotations on lambdas for reflective access at runtime.  But this doesn?t stop compile-time consumers of annotations.  You could choose to think of this as glass half full or glass half empty.

Finally, annotations is really a tertiary concern here; the main concern, as I?ve said, is regularizing the syntax (both for the various forms of lambdas itself, and between lambda parameters and local variables), and using said regularity for smoothing out future enhancements (which might include something having to do with annotations, or not.)  


From mark.reinhold at oracle.com  Tue Jan 30 15:35:02 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 30 Jan 2018 07:35:02 -0800
Subject: JDK submit repo
In-Reply-To: <cc3a76aa-57a3-b305-aa63-84ed8c853a02@redhat.com>
References: <20180123203343.45042150D72@eggemoggin.niobe.net>
 <9a655a74-d673-b03e-3c1d-b708065cba6d@redhat.com>
 <cc3a76aa-57a3-b305-aa63-84ed8c853a02@redhat.com>
Message-ID: <20180130073502.342307114@eggemoggin.niobe.net>

2018/1/30 2:50:45 -0800, Aleksey Shipilev <shade at redhat.com>:
> So I have submitted JDK-8174901 five days ago, and there was silence
> since then. Is *this* the kinds of thing to ask at ops@?

Yes.

- Mark

From philip.race at oracle.com  Tue Jan 30 19:02:29 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 30 Jan 2018 11:02:29 -0800
Subject: CFV: New JDK Reviewer: Jayathirth D V
Message-ID: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>

I hereby nominate Jayathirth D V  (openjdk id jdv) to the role of JDK 
reviewer.

Vadim has worked in the JDK client team for well over 2 years, focusing 
mostly on Java 2D, and in particular Java Image IO.

Jay is currently a JDK committer [1] and has contributed at least 44 
changesets to OpenJDK [2].

And has already been active in helping act as a reviewer on the 2d-dev 
[3] mailing list.

Votes are due by Feb 14, 2018.

Only current JDK Reviewers [4] are eligible to vote on this nomination.
Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

-phil.

[1] http://openjdk.java.net/census#jdv

[2] 
http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22jdv%22)+or+desc(%22jayathirth.d.v%40oracle.com%22))+and+not+merge()

[3] http://mail.openjdk.java.net/pipermail/2d-dev/

[4] http://openjdk.java.net/census

[5] http://openjdk.java.net/projects/#reviewer-vote

From philip.race at oracle.com  Tue Jan 30 19:04:38 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 30 Jan 2018 11:04:38 -0800
Subject: CFV: New JDK Reviewer: Jayathirth D V
In-Reply-To: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
References: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
Message-ID: <c6878fca-9ed5-dbbb-a4df-b4cb7478fcdc@oracle.com>

Vote: yes

-phil.

On 01/30/2018 11:02 AM, Phil Race wrote:
> I hereby nominate Jayathirth D V  (openjdk id jdv) to the role of JDK 
> reviewer.
>
> Vadim has worked in the JDK client team for well over 2 years, 
> focusing mostly on Java 2D, and in particular Java Image IO.
>
> Jay is currently a JDK committer [1] and has contributed at least 44 
> changesets to OpenJDK [2].
>
> And has already been active in helping act as a reviewer on the 2d-dev 
> [3] mailing list.
>
> Votes are due by Feb 14, 2018.
>
> Only current JDK Reviewers [4] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [5].
>
> -phil.
>
> [1] http://openjdk.java.net/census#jdv
>
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22jdv%22)+or+desc(%22jayathirth.d.v%40oracle.com%22))+and+not+merge()
>
> [3] http://mail.openjdk.java.net/pipermail/2d-dev/
>
> [4] http://openjdk.java.net/census
>
> [5] http://openjdk.java.net/projects/#reviewer-vote


From brian.burkhalter at oracle.com  Tue Jan 30 20:46:23 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 30 Jan 2018 12:46:23 -0800
Subject: CFV: New JDK Reviewer: Jayathirth D V
In-Reply-To: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
References: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
Message-ID: <4F9FC41F-A889-4983-9320-CA7E8FC0C28A@oracle.com>

Vote: yes

Brian

On Jan 30, 2018, at 11:02 AM, Phil Race <philip.race at oracle.com> wrote:

> I hereby nominate Jayathirth D V  (openjdk id jdv) to the role of JDK reviewer.


From mandy.chung at oracle.com  Tue Jan 30 22:13:27 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 30 Jan 2018 14:13:27 -0800
Subject: Result: New JDK Reviewer: Brent Christian
Message-ID: <dc8b7c11-5ec9-a2fc-243b-e8e1d79900b7@oracle.com>

Voting for Brent Christian [1] is now closed.

Yes: 32
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus, this is
sufficient to approve the nomination.

Mandy
[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000424.html


From Sergey.Bylokhov at oracle.com  Tue Jan 30 22:29:29 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 30 Jan 2018 14:29:29 -0800
Subject: CFV: New JDK Reviewer: Jayathirth D V
In-Reply-To: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
References: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
Message-ID: <d31af2d2-1382-0309-9413-bd9ab4bbbccc@oracle.com>

Vote: yes

On 30/01/2018 11:02, Phil Race wrote:
> I hereby nominate Jayathirth D V? (openjdk id jdv) to the role of JDK 
> reviewer.
> 
> Vadim has worked in the JDK client team for well over 2 years, focusing 
> mostly on Java 2D, and in particular Java Image IO.
> 
> Jay is currently a JDK committer [1] and has contributed at least 44 
> changesets to OpenJDK [2].
> 
> And has already been active in helping act as a reviewer on the 2d-dev 
> [3] mailing list.
> 
> Votes are due by Feb 14, 2018.
> 
> Only current JDK Reviewers [4] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> -phil.
> 
> [1] http://openjdk.java.net/census#jdv
> 
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22jdv%22)+or+desc(%22jayathirth.d.v%40oracle.com%22))+and+not+merge() 
> 
> 
> [3] http://mail.openjdk.java.net/pipermail/2d-dev/
> 
> [4] http://openjdk.java.net/census
> 
> [5] http://openjdk.java.net/projects/#reviewer-vote


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Tue Jan 30 22:35:41 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Tue, 30 Jan 2018 14:35:41 -0800
Subject: CFV: New JDK Reviewer: Jayathirth D V
In-Reply-To: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
References: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
Message-ID: <d55e72b8-5c2f-ddce-d11f-639a2d3b6dc6@oracle.com>

Vote: yes

--Semyon


On 1/30/18 11:02 AM, Phil Race wrote:
> I hereby nominate Jayathirth D V  (openjdk id jdv) to the role of JDK 
> reviewer.
>
> Vadim has worked in the JDK client team for well over 2 years, 
> focusing mostly on Java 2D, and in particular Java Image IO.
>
> Jay is currently a JDK committer [1] and has contributed at least 44 
> changesets to OpenJDK [2].
>
> And has already been active in helping act as a reviewer on the 2d-dev 
> [3] mailing list.
>
> Votes are due by Feb 14, 2018.
>
> Only current JDK Reviewers [4] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [5].
>
> -phil.
>
> [1] http://openjdk.java.net/census#jdv
>
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22jdv%22)+or+desc(%22jayathirth.d.v%40oracle.com%22))+and+not+merge()
>
> [3] http://mail.openjdk.java.net/pipermail/2d-dev/
>
> [4] http://openjdk.java.net/census
>
> [5] http://openjdk.java.net/projects/#reviewer-vote


From yue.l.liu at oracle.com  Wed Jan 31 06:30:07 2018
From: yue.l.liu at oracle.com (Yue Liu)
Date: Wed, 31 Jan 2018 14:30:07 +0800
Subject: RFR: 8196383 : JDK 10 L10n resource file update - msg drop 20
Message-ID: <389935b9-6669-602d-dc6c-79e04cc0cbc3@oracle.com>

Hi all,

Please help to review the changes for L10n resource file update message 
drop 20.

Some localized resource files are updated as English resource changed, 
some just because of issue fixing

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

Webrev:
http://cr.openjdk.java.net/~ljiang/MsgDrop-8196383/webrev.00/

Have got build and passed the tier1/2/3 test on all platforms on Mach 5.

Thanks,
Johnny


From pkapildas at gmail.com  Wed Jan 31 06:30:55 2018
From: pkapildas at gmail.com (kapil das)
Date: Wed, 31 Jan 2018 12:00:55 +0530
Subject: CFV: New JDK Reviewer: Jayathirth D V
In-Reply-To: <d55e72b8-5c2f-ddce-d11f-639a2d3b6dc6@oracle.com>
References: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
 <d55e72b8-5c2f-ddce-d11f-639a2d3b6dc6@oracle.com>
Message-ID: <CABf_PALgWKqaUkE8ANjjz32pjF5xMTP3qtTHCoOBK=J+ACeiVw@mail.gmail.com>

yes

Regatds,
kapil

On Wed, Jan 31, 2018 at 4:05 AM, <semyon.sadetsky at oracle.com> wrote:

> Vote: yes
>
> --Semyon
>
>
>
> On 1/30/18 11:02 AM, Phil Race wrote:
>
>> I hereby nominate Jayathirth D V  (openjdk id jdv) to the role of JDK
>> reviewer.
>>
>> Vadim has worked in the JDK client team for well over 2 years, focusing
>> mostly on Java 2D, and in particular Java Image IO.
>>
>> Jay is currently a JDK committer [1] and has contributed at least 44
>> changesets to OpenJDK [2].
>>
>> And has already been active in helping act as a reviewer on the 2d-dev
>> [3] mailing list.
>>
>> Votes are due by Feb 14, 2018.
>>
>> Only current JDK Reviewers [4] are eligible to vote on this nomination.
>> Votes must be cast in the open by replying to this mailing list.
>>
>> For Lazy Consensus voting instructions, see [5].
>>
>> -phil.
>>
>> [1] http://openjdk.java.net/census#jdv
>>
>> [2] http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(
>> author(%22jdv%22)+or+desc(%22jayathirth.d.v%40oracle.com%22)
>> )+and+not+merge()
>>
>> [3] http://mail.openjdk.java.net/pipermail/2d-dev/
>>
>> [4] http://openjdk.java.net/census
>>
>> [5] http://openjdk.java.net/projects/#reviewer-vote
>>
>
>

From adinn at redhat.com  Wed Jan 31 11:17:20 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 31 Jan 2018 11:17:20 +0000
Subject: CFV: New JDK Reviewer: Jayathirth D V
In-Reply-To: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
References: <18d9f4d5-ef64-856a-dbbb-417dacd4f189@oracle.com>
Message-ID: <ddbe83d5-606c-b468-e4f7-dacdb07aba8e@redhat.com>

Vote: yes

On 30/01/18 19:02, Phil Race wrote:
> I hereby nominate Jayathirth D V? (openjdk id jdv) to the role of JDK
> reviewer.
>
> Vadim has worked in the JDK client team for well over 2 years,
> focusing mostly on Java 2D, and in particular Java Image IO.
>
> Jay is currently a JDK committer [1] and has contributed at least 44
> changesets to OpenJDK [2].
>
> And has already been active in helping act as a reviewer on the 2d-dev
> [3] mailing list.
>
> Votes are due by Feb 14, 2018.
>
> Only current JDK Reviewers [4] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [5].
>
> -phil.
>
> [1] http://openjdk.java.net/census#jdv
>
> [2]
> http://hg.openjdk.java.net/jdk/jdk/log?revcount=2000&rev=(author(%22jdv%22)+or+desc(%22jayathirth.d.v%40oracle.com%22))+and+not+merge()
>
> [3] http://mail.openjdk.java.net/pipermail/2d-dev/
>
> [4] http://openjdk.java.net/census
>
> [5] http://openjdk.java.net/projects/#reviewer-vote
>

-- 
regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


From mark.reinhold at oracle.com  Wed Jan 31 17:04:01 2018
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 31 Jan 2018 09:04:01 -0800 (PST)
Subject: Informational JEP proposed for review: 12: Incubating Language and VM
 Features
Message-ID: <20180131170401.5468515E0BC@eggemoggin.niobe.net>

This recently-submitted informational JEP has already been discussed
here in draft form.

  12: Incubating Language and VM Features
      http://openjdk.java.net/jeps/12

Further comment is invited.  If no objections are raised by 23:00 UTC
on Wednesday, 7 February, or if they're raised and then satisfactorily
answered, then per the JEP 2.0 process proposal [1] I'll mark this
informational JEP as active.

(JBS does not (yet) implement the "informational" part of the JEP
 workflow, so the issue itself will be in the completed state for
 now.)

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From naoto.sato at oracle.com  Wed Jan 31 19:39:57 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 31 Jan 2018 11:39:57 -0800
Subject: RFR: 8196383 : JDK 10 L10n resource file update - msg drop 20
In-Reply-To: <389935b9-6669-602d-dc6c-79e04cc0cbc3@oracle.com>
References: <389935b9-6669-602d-dc6c-79e04cc0cbc3@oracle.com>
Message-ID: <68ba0ce5-53ca-d753-7ca5-57ec3affd5da@oracle.com>

Hi Johnny,

I just skimmed through Japanese translations, and found that the term 
"catalog" is translated into Japanese in java.xml l10n files, even 
though the affixed comments mention it should not.

These over-translations seem to have been there before this change, but 
it would be great to see them reverted to the original "catalog".

Naoto

On 1/30/18 10:30 PM, Yue Liu wrote:
> Hi all,
> 
> Please help to review the changes for L10n resource file update message 
> drop 20.
> 
> Some localized resource files are updated as English resource changed, 
> some just because of issue fixing
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8196383
> 
> Webrev:
> http://cr.openjdk.java.net/~ljiang/MsgDrop-8196383/webrev.00/
> 
> Have got build and passed the tier1/2/3 test on all platforms on Mach 5.
> 
> Thanks,
> Johnny
>