COMPOUND_TEXT charset is missing on JDK11

[Ichiroh Takiguchi]

Hello.

JDK8 Linux build has COMPOUND_TEXT charset, but it seems it's missing on 
JDK11 Linux build.
I checked Bug DB, I could not find out the reason why COMPOUND_TEXT 
charset was missing.


Could you port COMPOUND_TEXT charset from JDK8 to JDK11 ?

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

RFR: 8205184: Delegating Iterator implementations that don't delegate forEachRemaining()

[Martin Buchholz]

8205184: Delegating Iterator implementations that don't delegate
forEachRemaining()
http://cr.openjdk.java.net/~martin/webrevs/jdk/delegate-forEachRemaining/
https://bugs.openjdk.java.net/browse/JDK-8205184

RFR: jsr166 integration 2018-06

[Martin Buchholz]

JDK 11 draws nigh.

http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html

8202422: value of 'sizeCtl' in ConcurrentHashMap varies with the
constructor called
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/sizeCtl/index.html
https://bugs.openjdk.java.net/browse/JDK-8202422

8203864: Execution error in Java's Timsort
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/TimSort/index.html
https://bugs.openjdk.java.net/browse/JDK-8203864

---
We've been unable to reach agreement on 8203662 - it remains in limbo.

8203662: remove increment of modCount from ArrayList and Vector replaceAll()
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html
https://bugs.openjdk.java.net/browse/JDK-8203662

8203681: Miscellaneous changes imported from jsr166 CVS 2018-06
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
https://bugs.openjdk.java.net/browse/JDK-8203681

RE: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

[Deshpande, Vivek R]

Thanks Paul for taking some time and thinking about it.
I will make the change you have mentioned and send the patch again.

Regards,
Vivek


-Original Message-
From: Paul Sandoz [mailto:paul.san...@oracle.com] 
Sent: Thursday, June 21, 2018 3:32 PM
To: Deshpande, Vivek R 
Cc: roger.ri...@oracle.com; David Holmes ; 
core-libs-dev@openjdk.java.net; Viswanathan, Sandhya 
; Ivan Gerasimov 
Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
mismatch at first element.

Hi Vivek,

This looks better. I thought a bit more about NaNs. I am concerned about edge 
case performance regressions if the first two values are NaNs (with the same 
bit pattern). Here’s a patch on top of your patch that compares the raw bits 
for float/double elements. If you are ok with this and apply it on top of your 
patch then i don’t think there is a need for another review round.

Thanks,
Paul.


diff -r ef8fd07e4440 src/java.base/share/classes/java/nio/BufferMismatch.java
--- a/src/java.base/share/classes/java/nio/BufferMismatch.java  Thu Jun 21 
13:43:04 2018 -0700
+++ b/src/java.base/share/classes/java/nio/BufferMismatch.java  Thu Jun 21 
14:02:19 2018 -0700
@@ -118,7 +118,7 @@
 static int mismatch(FloatBuffer a, int aOff, FloatBuffer b, int bOff, int 
length) {
 int i = 0;
 if (length > 1 && a.order() == b.order()) {
-if (a.get(aOff) == b.get(bOff)) {
+if (Float.floatToRawIntBits(a.get(aOff)) == 
+ Float.floatToRawIntBits(b.get(bOff))) {
 i = ArraysSupport.vectorizedMismatch(
 a.base(), a.address + (aOff << 
ArraysSupport.LOG2_ARRAY_FLOAT_INDEX_SCALE),
 b.base(), b.address + (bOff << 
ArraysSupport.LOG2_ARRAY_FLOAT_INDEX_SCALE),
@@ -175,7 +175,7 @@
 static int mismatch(DoubleBuffer a, int aOff, DoubleBuffer b, int bOff, 
int length) {
 int i = 0;
 if (length > 0 && a.order() == b.order()) {
-if (a.get(aOff) == b.get(bOff)) {
+if (Double.doubleToRawLongBits(a.get(aOff)) == 
+ Double.doubleToRawLongBits(b.get(bOff))) {
 i = ArraysSupport.vectorizedMismatch(
 a.base(), a.address + (aOff << 
ArraysSupport.LOG2_ARRAY_DOUBLE_INDEX_SCALE),
 b.base(), b.address + (bOff << 
ArraysSupport.LOG2_ARRAY_DOUBLE_INDEX_SCALE),
diff -r ef8fd07e4440 
src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
--- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java  Thu Jun 
21 13:43:04 2018 -0700
+++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java  Thu Jun 
21 14:02:19 2018 -0700
@@ -461,7 +461,7 @@
int length) {
 int i = 0;
 if (length > 1) {
-if (a[aFromIndex] == b[bFromIndex]) { 
+if (Float.floatToRawIntBits(a[aFromIndex]) == 
+ Float.floatToRawIntBits(b[bFromIndex])) {
 int aOffset = Unsafe.ARRAY_FLOAT_BASE_OFFSET + (aFromIndex << 
LOG2_ARRAY_FLOAT_INDEX_SCALE);
 int bOffset = Unsafe.ARRAY_FLOAT_BASE_OFFSET + (bFromIndex << 
LOG2_ARRAY_FLOAT_INDEX_SCALE);
 i = vectorizedMismatch( @@ -545,7 +545,7 @@
 return -1;
 }
 int i = 0;
-if (a[aFromIndex] == b[bFromIndex]) {
+if (Double.doubleToRawLongBits(a[aFromIndex]) == 
+ Double.doubleToRawLongBits(b[bFromIndex])) {
 int aOffset = Unsafe.ARRAY_DOUBLE_BASE_OFFSET + (aFromIndex << 
LOG2_ARRAY_DOUBLE_INDEX_SCALE);
 int bOffset = Unsafe.ARRAY_DOUBLE_BASE_OFFSET + (bFromIndex << 
LOG2_ARRAY_DOUBLE_INDEX_SCALE);
 i = vectorizedMismatch(


> On Jun 21, 2018, at 11:50 AM, Deshpande, Vivek R 
>  wrote:
> 
> Hi Paul
>  
> The folding of if/else is the right way in this patch which I missed in 
> earlier webrev.
> http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.0
> 3/ I think I would keep the same earlier path if both the values are 
> NaN.
>  
> Thanks.
> Regards,
> Vivek
> From: Paul Sandoz [mailto:paul.san...@oracle.com]
> Sent: Wednesday, June 20, 2018 5:29 PM
> To: Deshpande, Vivek R 
> Cc: roger.ri...@oracle.com; David Holmes ; 
> core-libs-dev@openjdk.java.net; Viswanathan, Sandhya 
> 
> Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
> mismatch at first element.
>  
> Hi Vivek,
>  
>  459 public static int mismatch(float[] a, int aFromIndex,
>  460float[] b, int bFromIndex,
>  461int length) {
>  462 int i = 0;
>  463 if (length > 1) {
>  464 if (a[aFromIndex] != b[bFromIndex]) {
>  465 i = 0;
>  466 }
>  467 if (a[aFromIndex] == b[bFromIndex]) { 
>  
> Sorry, i don’t think i was clear. You can reduce down to a single equality 
> check, so Lines #464-466 are redundant. This does result in taking the slow 
> path if both values are NaN, which i 

Re: free(): corrupted unsorted chunks

[Oliver Kohll]

Aha, I wonder if it's configured with the APR native library for SSL. I
will check out that and those things.

Thanks
Oliver

On 21 June 2018 at 21:43:24, Bernd Eckenfels (e...@zusammenkunft.net) wrote:

Are you using any native libraries in this VM, is there a hs_err or System
core file? Can you run „ldd“ on the java launcher binary. Can you try a
OpenJDK binary distribution independent of the OS compiled version?

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Re: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

[Paul Sandoz]

Hi Vivek,

This looks better. I thought a bit more about NaNs. I am concerned about edge 
case performance regressions if the first two values are NaNs (with the same 
bit pattern). Here’s a patch on top of your patch that compares the raw bits 
for float/double elements. If you are ok with this and apply it on top of your 
patch then i don’t think there is a need for another review round.

Thanks,
Paul.


diff -r ef8fd07e4440 src/java.base/share/classes/java/nio/BufferMismatch.java
--- a/src/java.base/share/classes/java/nio/BufferMismatch.java  Thu Jun 21 
13:43:04 2018 -0700
+++ b/src/java.base/share/classes/java/nio/BufferMismatch.java  Thu Jun 21 
14:02:19 2018 -0700
@@ -118,7 +118,7 @@
 static int mismatch(FloatBuffer a, int aOff, FloatBuffer b, int bOff, int 
length) {
 int i = 0;
 if (length > 1 && a.order() == b.order()) {
-if (a.get(aOff) == b.get(bOff)) {
+if (Float.floatToRawIntBits(a.get(aOff)) == 
Float.floatToRawIntBits(b.get(bOff))) {
 i = ArraysSupport.vectorizedMismatch(
 a.base(), a.address + (aOff << 
ArraysSupport.LOG2_ARRAY_FLOAT_INDEX_SCALE),
 b.base(), b.address + (bOff << 
ArraysSupport.LOG2_ARRAY_FLOAT_INDEX_SCALE),
@@ -175,7 +175,7 @@
 static int mismatch(DoubleBuffer a, int aOff, DoubleBuffer b, int bOff, 
int length) {
 int i = 0;
 if (length > 0 && a.order() == b.order()) {
-if (a.get(aOff) == b.get(bOff)) {
+if (Double.doubleToRawLongBits(a.get(aOff)) == 
Double.doubleToRawLongBits(b.get(bOff))) {
 i = ArraysSupport.vectorizedMismatch(
 a.base(), a.address + (aOff << 
ArraysSupport.LOG2_ARRAY_DOUBLE_INDEX_SCALE),
 b.base(), b.address + (bOff << 
ArraysSupport.LOG2_ARRAY_DOUBLE_INDEX_SCALE),
diff -r ef8fd07e4440 
src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
--- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java  Thu Jun 
21 13:43:04 2018 -0700
+++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java  Thu Jun 
21 14:02:19 2018 -0700
@@ -461,7 +461,7 @@
int length) {
 int i = 0;
 if (length > 1) {
-if (a[aFromIndex] == b[bFromIndex]) { 
+if (Float.floatToRawIntBits(a[aFromIndex]) == 
Float.floatToRawIntBits(b[bFromIndex])) {
 int aOffset = Unsafe.ARRAY_FLOAT_BASE_OFFSET + (aFromIndex << 
LOG2_ARRAY_FLOAT_INDEX_SCALE);
 int bOffset = Unsafe.ARRAY_FLOAT_BASE_OFFSET + (bFromIndex << 
LOG2_ARRAY_FLOAT_INDEX_SCALE);
 i = vectorizedMismatch(
@@ -545,7 +545,7 @@
 return -1;
 }
 int i = 0;
-if (a[aFromIndex] == b[bFromIndex]) {
+if (Double.doubleToRawLongBits(a[aFromIndex]) == 
Double.doubleToRawLongBits(b[bFromIndex])) {
 int aOffset = Unsafe.ARRAY_DOUBLE_BASE_OFFSET + (aFromIndex << 
LOG2_ARRAY_DOUBLE_INDEX_SCALE);
 int bOffset = Unsafe.ARRAY_DOUBLE_BASE_OFFSET + (bFromIndex << 
LOG2_ARRAY_DOUBLE_INDEX_SCALE);
 i = vectorizedMismatch(


> On Jun 21, 2018, at 11:50 AM, Deshpande, Vivek R 
>  wrote:
> 
> Hi Paul
>  
> The folding of if/else is the right way in this patch which I missed in 
> earlier webrev.
> http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.03/
> I think I would keep the same earlier path if both the values are NaN.
>  
> Thanks.
> Regards,
> Vivek
> From: Paul Sandoz [mailto:paul.san...@oracle.com] 
> Sent: Wednesday, June 20, 2018 5:29 PM
> To: Deshpande, Vivek R 
> Cc: roger.ri...@oracle.com; David Holmes ; 
> core-libs-dev@openjdk.java.net; Viswanathan, Sandhya 
> 
> Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
> mismatch at first element.
>  
> Hi Vivek,
>  
>  459 public static int mismatch(float[] a, int aFromIndex,
>  460float[] b, int bFromIndex,
>  461int length) {
>  462 int i = 0;
>  463 if (length > 1) {
>  464 if (a[aFromIndex] != b[bFromIndex]) {
>  465 i = 0;
>  466 }
>  467 if (a[aFromIndex] == b[bFromIndex]) { 
>  
> Sorry, i don’t think i was clear. You can reduce down to a single equality 
> check, so Lines #464-466 are redundant. This does result in taking the slow 
> path if both values are NaN, which i think was the same for your previous 
> patch. If that is important we can mitigate that by performing the negation 
> of the same checks in the slow loop.
>  
> WDYT?
>  
> Paul.
>  
>  
> On Jun 20, 2018, at 5:05 PM, Deshpande, Vivek R  
> wrote:
>  
> Hi Paul
>  
> I have made the change you have suggested.
> Please find the updated webrev at this location:
> http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.02/
>  
> Regards,
> Vivek
> From: Paul Sandoz [mailto:paul.san...@oracle.com] 

Re: RFC: Add new JCA provider to support hardware RNGs

[Gustavo Romero]

Hi Bernd,

Thanks for your comments.

On 06/20/2018 05:05 PM, Bernd Eckenfels wrote:

Just a FYI under Linux when you read from urandom the Linux kernel will always 
XOR with random bytes generated with x64 rdrand instruction 
(arch_get_random_lomg() - if supported). Since it is a XOR it does not have to 
trust the quality of this black box hardware implementation.


Yes, I know to some extent how the use of rdrand on Intel by Linux
generated debates in the past.



I would not implement a generator which does not have its own software 
whitening. (And most likely there is no need for one different than urandom on 
Linux). If you do implement whitening I would use a DRBG construction and no 
longer use a (low state) SHA1PRNG.


My main concern to use 'darn' on Power was to get some additional speed and
throughput on obtaining true random numbers (or on cases where /dev/random
- which blocks - was preferred to /dev/urandom). That concern seems valid
specially when the code is not JITed yet by the C2 compiler (so for
Interpreted and C1 Compiler). Anyway, the idea to have a separated provider
and that the use of the intrinsic is by no means enabled by default is to
let the user to decide if he/she wants to use that kind of generator. I
think OpenSSL disabled by default the use of rdrand similarly but let the
user to enable it if desired?

The idea of DRBG looks valid. I took SHA1PRNG as a fallback. But if DRBG
would be used for whitening that would need a seed from /dev/urandom?
(I'm trying to think the impact on performance here).


Best regards,
Gustavo


Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net

From: core-libs-dev  on behalf of Gustavo 
Romero 
Sent: Wednesday, June 20, 2018 2:59:47 AM
To: core-libs-dev; security-dev
Cc: vladimir.koz...@oracle.com; Doerr, Martin
Subject: RFC: Add new JCA provider to support hardware RNGs

Hi,

Please, could I get comments on the following change?

Since it's related to security, I would be glad if security
experts could also comment on that.

webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v6_rebased/

It introduces a way to get benefits from hardware instructions in userspace
that can delivery a random number and so be used to speed up and avoid
blocking in some SecureRandom methods, notably generateSeed() and
nextBytes(), without loosing the random number quality. Particularly on
Power, the new POWER9 CPUs introduced a hardware instruction called 'darn'
that can be used for that purpose.

The main idea is to add a new JCA provider called "HWTRNG" (if no better
name is suggested), adding new helper methods that can then be intrinsified
and that will be used  by generateSeed() and nextBytes(). In that sense,
this change also adds the proper mechanisms in the Interpreter,
C1 Compiler, and C2 compiler (for PPC64, but also paving the way for other
platforms) to intrinsify these helper methods that will be used in the end
by generateSeed() and nextBytes() methods. The added helpers are:

byte[] getRandomSequence0(int)
byte[] getRandomSequence1(byte[])
long validRandomLong(void)
long randomLong(void)

The helpers also take care of checking if the returned random number is
valid and attempt 10 times (as recommended by ISA) get a valid random
number before falling back to a software alternative (HWTRNG is based
mostly on JCA provider NativePRNG and so the fall back mechanism will use
the exactly same methods found in NativePRNG and hence behave similarly.
Nonetheless, in my experience such a hardware failures (which are the main
cause of a returned invalid random number) are quite rare: in my tests I
was never able to exhaust the HW RNG and force it to generate an invalid
random number).

The user, besides having to specify explicitly the use of a non-default
provider (HWTRNG), will have to unlock the VM experimental options to
effectively use the hardware RNG as an unique random source by passing
options "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics".

On Power, for the Interpreter and C1 Compiler, besides avoiding the
blocking effect of a low entropy on /dev/random, I was able to get about
126 Mbps (3x higher than the version without 'darn') on generaSeed() and
nextBytes(). The maximum theoretical value on a POWER9 machine is usually
128 Mbps.

I'll address the details about the file headers (Copyright, dates, authors,
versions, etc) after I get some feedback about this change.


Thanks in advance.

Best regards,
Gustavo

Re: Promptly freeing the per-thread cached direct buffers when a thread exits

[Florian Weimer]

* Tony Printezis:

> There are a few obvious ways to mitigate this, e.g., cause a Full GC /
> concurrent GC cycle at regular intervals. However, the best solution IMHO
> is to explicitly free any direct buffers that are still in the cache when a
> thread exits.

Why is this safe?  Couldn't these direct byte buffers be used with a
custom channel that leaks them to another thread?

Re: free(): corrupted unsorted chunks

[Bernd Eckenfels]

Are you using any native libraries in this VM, is there a hs_err or System core 
file? Can you run „ldd“ on the java launcher binary. Can you try a OpenJDK 
binary distribution independent of the OS compiled version?

Gruss
Bernd
--
http://bernd.eckenfels.net

From: core-libs-dev  on behalf of 
Oliver Kohll 
Sent: Thursday, June 21, 2018 1:59:27 PM
To: core-libs-dev@openjdk.java.net
Subject: free(): corrupted unsorted chunks

Hi,

I'm a Java developer getting a crash and error message 'free(): corrupted
unsorted chunks' in the log. this sounds like it could be a low level issue
in the core Java libraries so I'm posting here, but if it would be better
in another list (or even a different community) please let me know.

So I'm requesting help because I don't know how to debug this further. In
summary, the issue is

We're getting a crash nearly once a day on our production system, at a time
of day when it's most busy (mid morning). This crash hasn't been seen on
our development environment, which is the same apart from the server has
less memory and CPU resources.

The environment is:
* A VPS host
* Ubuntu LTS 18 (Bionic)
* The default Java 10 packaged as 11 I believe (
https://askubuntu.com/questions/1037646/why-is-openjdk-10-packaged-as-openjdk-11
)
* However, javac seems to be from JDK8:
root@server:~# file /etc/alternatives/java /etc/alternatives/javac
/etc/alternatives/java:  symbolic link to
/usr/lib/jvm/java-11-openjdk-amd64/bin/java
/etc/alternatives/javac: symbolic link to
/usr/lib/jvm/java-8-openjdk-amd64/bin/javac

We're running our webapp on Tomcat 8 (also the Ubuntu default). When this
happens, the server stops responding to HTTP requests (in fact the java
process has quit) and needs to be restarted.

The crash doesn't seem to correspond to a particular activity on the server
as far as I can see, though it's hard to tell as many people are logged in
at the same time.

Does anyone have any pointers of
a) how to track the bug further so I can report it, ideally without a big
impact on our live server
b) more immediately, any workarounds to try

In the meantime I will see if I can downgrade to JDK8 on the test server,
but I'm not sure if that's possible or whether it would make a difference.

Regards
Oliver

Re: RFR 8195650 Method references to VarHandle accessors

[mandy chung]

This looks good to me AFAICT.

Mandy

On 6/19/18 5:08 PM, Paul Sandoz wrote:

Hi,

Please review the following fix to ensure method references to
VarHandle signature polymorphic methods are supported at runtime
(specifically the method handle to a signature polymorphic method can
be loaded from the constant pool):

http://cr.openjdk.java.net/~psandoz/jdk/JDK-8195650-varhandle-mref/webrev/

I also added a “belts and braces” test to ensure a constant method
handle to MethodHandle::invokeBasic cannot be loaded if outside of
the j.l.invoke package.

Paul.

Re: RFR 8202922 Method reference identity is broken by serialization

[mandy chung]

Looks fine.

Mandy

On 6/14/18 10:41 AM, Paul Sandoz wrote:

Hi,

Please review an update to the specifications of LambdaMetafactory
and SerializedLambda to clarify that the identity of function objects
is unpredictable. A similar (informational) clarification was made to
the language specification and similar wording is used. Amusingly a
quirk of (or issue with) lambda deserialization (we count our
blessings it works as it does!) motivated this clarification.

http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202922-function-object-identity/webrev/

 CSR:

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

Thanks, Paul.

Re: RFR 8202922 Method reference identity is broken by serialization

[Jim Laskey]

+1

> On Jun 14, 2018, at 2:41 PM, Paul Sandoz  wrote:
> 
> Hi,
> 
> Please review an update to the specifications of LambdaMetafactory and 
> SerializedLambda to clarify that the identity of function objects is 
> unpredictable. A similar (informational) clarification was made to the 
> language specification and similar wording is used. Amusingly a quirk of (or 
> issue with) lambda deserialization (we count our blessings it works as it 
> does!) motivated this clarification.
> 
>  
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202922-function-object-identity/webrev/
> 
> CSR:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8205060
> 
> Thanks,
> Paul.

Re: RFR 8202922 Method reference identity is broken by serialization

[Paul Sandoz]

Gentle reminder,
Paul.

> On Jun 14, 2018, at 10:41 AM, Paul Sandoz  wrote:
> 
> Hi,
> 
> Please review an update to the specifications of LambdaMetafactory and 
> SerializedLambda to clarify that the identity of function objects is 
> unpredictable. A similar (informational) clarification was made to the 
> language specification and similar wording is used. Amusingly a quirk of (or 
> issue with) lambda deserialization (we count our blessings it works as it 
> does!) motivated this clarification.
> 
>  
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202922-function-object-identity/webrev/
> 
> CSR:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8205060
> 
> Thanks,
> Paul.

Re: RFR 8202292 : test/jdk/java/io/FileOutputStream/UnreferencedFOSClosesFd.java fails with "raw fd count wrong"

[Brian Burkhalter]

Hi Roger,

Are the three versions of listProcFD() identical? Is so, could this method be 
put in test/lib/jdk/test/lib/util/FileUtils.java instead?

Thanks,

Brian

On Jun 21, 2018, at 11:59 AM, Roger Riggs  wrote:

> Please review a test improvement to avoid spurious errors caused by 
> concurrent changes in open files during the test.
> The other existing conditions in the test are sufficient to verify the 
> correct finalize behavior.
> Some additional diagnostics are added and the tests removed from the problem 
> list.
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-count-wrong-8202292/index.html
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8202292

Re: RFR 8202292 : test/jdk/java/io/FileOutputStream/UnreferencedFOSClosesFd.java fails with "raw fd count wrong"

[mandy chung]

On 6/21/18 11:59 AM, Roger Riggs wrote:
Please review a test improvement to avoid spurious errors caused by 
concurrent changes in open files during the test.
The other existing conditions in the test are sufficient to verify the 
correct finalize behavior.
Some additional diagnostics are added and the tests removed from the 
problem list.


Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-count-wrong-8202292/index.html


The fix looks reasonable.  It's good to get this test in service again.

Do you want to keep the commented lines in the test?  Maybe add a 
comment instead.


Mandy

RFR 8202292 : test/jdk/java/io/FileOutputStream/UnreferencedFOSClosesFd.java fails with "raw fd count wrong"

[Roger Riggs]

Please review a test improvement to avoid spurious errors caused by 
concurrent changes in open files during the test.
The other existing conditions in the test are sufficient to verify the 
correct finalize behavior.
Some additional diagnostics are added and the tests removed from the 
problem list.


Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-count-wrong-8202292/index.html

Issue:
  https://bugs.openjdk.java.net/browse/JDK-8202292

Thanks, Roger

RE: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

[Deshpande, Vivek R]

Hi Paul

The folding of if/else is the right way in this patch which I missed in earlier 
webrev.
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.03/
I think I would keep the same earlier path if both the values are NaN.

Thanks.
Regards,
Vivek
From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Wednesday, June 20, 2018 5:29 PM
To: Deshpande, Vivek R 
Cc: roger.ri...@oracle.com; David Holmes ; 
core-libs-dev@openjdk.java.net; Viswanathan, Sandhya 

Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
mismatch at first element.

Hi Vivek,

 459 public static int mismatch(float[] a, int aFromIndex,
 460float[] b, int bFromIndex,
 461int length) {
 462 int i = 0;
 463 if (length > 1) {
 464 if (a[aFromIndex] != b[bFromIndex]) {
 465 i = 0;
 466 }
 467 if (a[aFromIndex] == b[bFromIndex]) {

Sorry, i don’t think i was clear. You can reduce down to a single equality 
check, so Lines #464-466 are redundant. This does result in taking the slow 
path if both values are NaN, which i think was the same for your previous 
patch. If that is important we can mitigate that by performing the negation of 
the same checks in the slow loop.

WDYT?

Paul.


On Jun 20, 2018, at 5:05 PM, Deshpande, Vivek R 
mailto:vivek.r.deshpa...@intel.com>> wrote:

Hi Paul

I have made the change you have suggested.
Please find the updated webrev at this location:
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.02/

Regards,
Vivek
From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Wednesday, June 20, 2018 2:30 PM
To: Deshpande, Vivek R 
mailto:vivek.r.deshpa...@intel.com>>
Cc: roger.ri...@oracle.com; David Holmes 
mailto:david.hol...@oracle.com>>; 
core-libs-dev@openjdk.java.net; 
Viswanathan, Sandhya 
mailto:sandhya.viswanat...@intel.com>>
Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
mismatch at first element.

 459 public static int mismatch(float[] a, int aFromIndex,
 460float[] b, int bFromIndex,
 461int length) {
 462 int i = 0;
 463 if (length > 1) {
 464 if (a[aFromIndex] != b[bFromIndex]) {
 465 i = 0;
 466 } else {

You fold the if/else to;

  if (a[aFromIndex] == b[bFromIndex]) {
  …
  }

same applies in other cases in both source files.




On Jun 20, 2018, at 1:21 PM, Deshpande, Vivek R 
mailto:vivek.r.deshpa...@intel.com>> wrote:

Hi All

I have updated the webrev with all the suggestions, which passes 
ArraysEqCmpTest.java.
Earlier webrev failed the same test.

Thanks for confirming.



This webrev also modifies the BufferMismatch.java in similar way.

Great!

Paul.



Please take a look and let me know what you think.

Updated webrev is here:
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.01/
I have also modified the bug with updated webrev.
Regards,
Vivek

From: Deshpande, Vivek R
Sent: Tuesday, June 19, 2018 10:57 AM
To: Paul Sandoz mailto:paul.san...@oracle.com>>; 
roger.ri...@oracle.com
Cc: David Holmes mailto:david.hol...@oracle.com>>; 
core-libs-dev@openjdk.java.net; 
Viswanathan, Sandhya 
mailto:sandhya.viswanat...@intel.com>>
Subject: RE: RFR(S): 8205194: Improve the Array Comparison when there is a 
mismatch at first element.

Hi Roger

I will also test with zero length arrays and let you know.
Thanks for the input.

Regards,
Vivek

From: Deshpande, Vivek R
Sent: Tuesday, June 19, 2018 10:17 AM
To: 'Paul Sandoz' mailto:paul.san...@oracle.com>>
Cc: David Holmes mailto:david.hol...@oracle.com>>; 
core-libs-dev@openjdk.java.net; 
Viswanathan, Sandhya 
mailto:sandhya.viswanat...@intel.com>>
Subject: RE: RFR(S): 8205194: Improve the Array Comparison when there is a 
mismatch at first element.

Thanks Paul for quick review. I will work on the things you have mentioned and 
get back soon.
I will also test this with test/jdk/java/util/Arrays/ArraysEqCmpTest.java.

Regards,
Vivek

From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Tuesday, June 19, 2018 9:55 AM
To: Deshpande, Vivek R 
mailto:vivek.r.deshpa...@intel.com>>
Cc: David Holmes mailto:david.hol...@oracle.com>>; 
core-libs-dev@openjdk.java.net; 
Viswanathan, Sandhya 
mailto:sandhya.viswanat...@intel.com>>
Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
mismatch at first element.

Hi Vivek,

Thanks for investigating this.


 164 public static int mismatch(boolean[] a,

 165boolean[] b,

 166int length) {

 167 int i = 0;

 168 if (a[i] != b[i])

 169   

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Tony Printezis]

Peter,

The changes to TestMaxCachedBufferSize.java look fine. One point though:
Why do you need the TmpDirectBuffersReclamation.java test? In
TestMaxCachedBufferSize.java you just call checkDirectBuffers(0, 0); after
you the main thread calls join() on the workers?

Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 1:29:38 PM, Peter Levart (peter.lev...@gmail.com) wrote:



On 06/21/2018 07:01 PM, Tony Printezis wrote:

I’m trying exactly that. :-)


Sorry, I didn't know. Here's my attempt:

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.07/

I also added @run main/othervm to TempDirectBuffersReclamation test.

Peter



—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 12:59:58 PM, Peter Levart (peter.lev...@gmail.com)
wrote:



On 06/21/2018 06:17 PM, Tony Printezis wrote:

I was saying: I looked at TestMaxCachedBufferSize and, unfortunately, I
don’t think the test makes a lot of sense right now as it checks the number
/ size of direct buffers after all the threads terminate and, with this
change, that should always be 0.


You're right. The test makes no sense now. As I understand, the test
checked that number/size of allocated temporary buffers did not exceed the
estimated calculated size by checking the MXBean immediately after threads
terminate. This will never happen after the change as they will all be
freed before checking, regardless of how many were and how much was
allocated.

Perhaps the test should be modified to include a latch so that threads wait
until the measurement is made and only then are allowed to exit...

Regards, Peter

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Peter Levart]

On 06/21/2018 07:01 PM, Tony Printezis wrote:

I’m trying exactly that. :-)


Sorry, I didn't know. Here's my attempt:

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.07/

I also added @run main/othervm to TempDirectBuffersReclamation test.

Peter




—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com 




On June 21, 2018 at 12:59:58 PM, Peter Levart (peter.lev...@gmail.com 
) wrote:





On 06/21/2018 06:17 PM, Tony Printezis wrote:
I was saying: I looked at TestMaxCachedBufferSize and, 
unfortunately, I don’t think the test makes a lot of sense right now 
as it checks the number / size of direct buffers after all the 
threads terminate and, with this change, that should always be 0.


You're right. The test makes no sense now. As I understand, the test 
checked that number/size of allocated temporary buffers did not 
exceed the estimated calculated size by checking the MXBean 
immediately after threads terminate. This will never happen after the 
change as they will all be freed before checking, regardless of how 
many were and how much was allocated.


Perhaps the test should be modified to include a latch so that 
threads wait until the measurement is made and only then are allowed 
to exit...


Regards, Peter

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Tony Printezis]

I’m trying exactly that. :-)


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 12:59:58 PM, Peter Levart (peter.lev...@gmail.com)
wrote:



On 06/21/2018 06:17 PM, Tony Printezis wrote:

I was saying: I looked at TestMaxCachedBufferSize and, unfortunately, I
don’t think the test makes a lot of sense right now as it checks the number
/ size of direct buffers after all the threads terminate and, with this
change, that should always be 0.


You're right. The test makes no sense now. As I understand, the test
checked that number/size of allocated temporary buffers did not exceed the
estimated calculated size by checking the MXBean immediately after threads
terminate. This will never happen after the change as they will all be
freed before checking, regardless of how many were and how much was
allocated.

Perhaps the test should be modified to include a latch so that threads wait
until the measurement is made and only then are allowed to exit...

Regards, Peter

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Peter Levart]

On 06/21/2018 06:17 PM, Tony Printezis wrote:
I was saying: I looked at TestMaxCachedBufferSize and, unfortunately, 
I don’t think the test makes a lot of sense right now as it checks the 
number / size of direct buffers after all the threads terminate and, 
with this change, that should always be 0.


You're right. The test makes no sense now. As I understand, the test 
checked that number/size of allocated temporary buffers did not exceed 
the estimated calculated size by checking the MXBean immediately after 
threads terminate. This will never happen after the change as they will 
all be freed before checking, regardless of how many were and how much 
was allocated.


Perhaps the test should be modified to include a latch so that threads 
wait until the measurement is made and only then are allowed to exit...


Regards, Peter

RE: RFR(S): 8205194: Improve the Array Comparison when there is a mismatch at first element.

[Deshpande, Vivek R]

Yes makes sense. Good catch :)
Thanks :)
Regards,
Vivek

-Original Message-
From: Ivan Gerasimov [mailto:ivan.gerasi...@oracle.com] 
Sent: Wednesday, June 20, 2018 5:24 PM
To: Deshpande, Vivek R 
Cc: Paul Sandoz ; core-libs-dev@openjdk.java.net
Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
mismatch at first element.

Hi Vivek!

I think you don't need this if block:

  464 if (a[aFromIndex] != b[bFromIndex]) {
  465 i = 0;
  466 }

i is already 0 anyway, and the following line is just enough.

  467 if (a[aFromIndex] == b[bFromIndex]) {

The same applies to other float/double variants.

With kind regards,
Ivan

On 6/20/18 5:05 PM, Deshpande, Vivek R wrote:
> Hi Paul
>
> I have made the change you have suggested.
> Please find the updated webrev at this location:
> http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.0
> 2/
>
> Regards,
> Vivek
> From: Paul Sandoz [mailto:paul.san...@oracle.com]
> Sent: Wednesday, June 20, 2018 2:30 PM
> To: Deshpande, Vivek R 
> Cc: roger.ri...@oracle.com; David Holmes ; 
> core-libs-dev@openjdk.java.net; Viswanathan, Sandhya 
> 
> Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
> mismatch at first element.
>
>   459 public static int mismatch(float[] a, int aFromIndex,
>   460float[] b, int bFromIndex,
>   461int length) {
>   462 int i = 0;
>   463 if (length > 1) {
>   464 if (a[aFromIndex] != b[bFromIndex]) {
>   465 i = 0;
>   466 } else {
>
> You fold the if/else to;
>
>if (a[aFromIndex] == b[bFromIndex]) {
>…
>}
>
> same applies in other cases in both source files.
>
>
>
> On Jun 20, 2018, at 1:21 PM, Deshpande, Vivek R 
> mailto:vivek.r.deshpa...@intel.com>> wrote:
>
> Hi All
>
> I have updated the webrev with all the suggestions, which passes 
> ArraysEqCmpTest.java.
> Earlier webrev failed the same test.
>
> Thanks for confirming.
>
>
> This webrev also modifies the BufferMismatch.java in similar way.
>
> Great!
>
> Paul.
>
>
> Please take a look and let me know what you think.
>
> Updated webrev is here:
> http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.0
> 1/ I have also modified the bug with updated webrev.
> Regards,
> Vivek
>
> From: Deshpande, Vivek R
> Sent: Tuesday, June 19, 2018 10:57 AM
> To: Paul Sandoz 
> mailto:paul.san...@oracle.com>>; 
> roger.ri...@oracle.com
> Cc: David Holmes 
> mailto:david.hol...@oracle.com>>; 
> core-libs-dev@openjdk.java.net; 
> Viswanathan, Sandhya 
> mailto:sandhya.viswanat...@intel.com>>
> Subject: RE: RFR(S): 8205194: Improve the Array Comparison when there is a 
> mismatch at first element.
>
> Hi Roger
>
> I will also test with zero length arrays and let you know.
> Thanks for the input.
>
> Regards,
> Vivek
>
> From: Deshpande, Vivek R
> Sent: Tuesday, June 19, 2018 10:17 AM
> To: 'Paul Sandoz' 
> mailto:paul.san...@oracle.com>>
> Cc: David Holmes 
> mailto:david.hol...@oracle.com>>; 
> core-libs-dev@openjdk.java.net; 
> Viswanathan, Sandhya 
> mailto:sandhya.viswanat...@intel.com>>
> Subject: RE: RFR(S): 8205194: Improve the Array Comparison when there is a 
> mismatch at first element.
>
> Thanks Paul for quick review. I will work on the things you have mentioned 
> and get back soon.
> I will also test this with test/jdk/java/util/Arrays/ArraysEqCmpTest.java.
>
> Regards,
> Vivek
>
> From: Paul Sandoz [mailto:paul.san...@oracle.com]
> Sent: Tuesday, June 19, 2018 9:55 AM
> To: Deshpande, Vivek R 
> mailto:vivek.r.deshpa...@intel.com>>
> Cc: David Holmes 
> mailto:david.hol...@oracle.com>>; 
> core-libs-dev@openjdk.java.net; 
> Viswanathan, Sandhya 
> mailto:sandhya.viswanat...@intel.com>>
> Subject: Re: RFR(S): 8205194: Improve the Array Comparison when there is a 
> mismatch at first element.
>
> Hi Vivek,
>
> Thanks for investigating this.
>
>
>   164 public static int mismatch(boolean[] a,
>
>   165boolean[] b,
>
>   166int length) {
>
>   167 int i = 0;
>
>   168 if (a[i] != b[i])
>
>   169 return i;
> You might as well replace the use if i with 0 and i think you can move this 
> to be performed when the length is greater than the threshold, that way you 
> don’t impact small arrays below the threshold.
>
>
>   186 public static int mismatch(boolean[] a, int aFromIndex,
>
>   187boolean[] b, int bFromIndex,
>
>   188int length) {
>
>   189 int i = 0;
>
>   190 if (a[i] != b[i])
>
>   191 return i;
> This is incorrect. You need to use aFromIndex and bFromIndex.
>
> Do you run the test 

Re: RFC: Experiment in accessing/managing persistent memory from Java

[Andrew Dinn]

Hi Paul,

Sorry for the delay in responding to this -- holiday and then an urgent
bug fix intervened . . .

On 08/06/18 01:42, Paul Sandoz wrote:
> Sandhya gave an overview to a few of us Oracle folks. I agree with
> what Sandhya says regarding the API, a small surface, and on pursuing
> an unsafe intrinsic. I like it and would encourage the writing of a
> draft JEP, especially to give this visibility.

Great! Thanks for your feedback (also to Sandhya). I'll start drafting a
JEP staright away. I'll also work on revising the current intrinsic
implementation so it is presented via Unsafe (which should be fairly
simple to achieve).

> It intersects with https://bugs.openjdk.java.net/browse/JDK-8153111
> ((bf) Allocating ByteBuffer on heterogeneous memory), which is
> attempting to be more generic.

Ok, thanks. I'll have a think about how we night try to integrate these
two approaches and see what I can work into the draft JEP.

> We might also need to increase the velocity on
> https://bugs.openjdk.java.net/browse/JDK-8180628 (retrofit direct
> buffer support for size beyond gigabyte scales), and i would be very
> interested your views on this, how you might be currently working
> around such size limitations, and what buffer enhancements would work
> for you.

I think Jonathan answered that better than I can in his response.
However, if this accelerates delivery of a fix for JDK-8180628 then all
to the good.

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

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Tony Printezis]

…and I also hadn’t attached the test. Sorry, I’m clearly very distracted
today!


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 12:17:57 PM, Tony Printezis (tprinte...@twitter.com)
wrote:

(I unfortunately pressed Send accidentally; apologies)

I was saying: I looked at TestMaxCachedBufferSize and, unfortunately, I
don’t think the test makes a lot of sense right now as it checks the number
/ size of direct buffers after all the threads terminate and, with this
change, that should always be 0.

Let me look into this and I’ll get back to you in a bit.

Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 12:14:24 PM, Tony Printezis (tprinte...@twitter.com)
wrote:

Peter,

Attached TerminatingThreadLocalTest.java. Let me know what you think (and
feel free to modify it / discard it if you don’t like it!).

Re: The test for the max cached buffer size is:
test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java. I looked at it and,
unfortunately,


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 7:07:59 AM, Peter Levart (peter.lev...@gmail.com) wrote:



On 06/20/2018 04:24 PM, Tony Printezis wrote:

Hey Peter,

I had written a test to test my version of the exit hooks. I can easily
rework it to work with yours. Interested?


Of course. Just give what you got. I can modify it as needed.


To check that the native buffers are reclaimed promptly, we should be able
to amend the test that tests the setting of the max size for the cached
buffers (i.e., check that, after all the threads have exited, the total
native count / size is 0).


Good idea. Do you happen to know which one is it?


Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 20, 2018 at 10:08:48 AM, Peter Levart (peter.lev...@gmail.com)
wrote:


On 06/18/2018 05:41 PM, Alan Bateman wrote:
>
>
> On 17/06/2018 22:20, Peter Levart wrote:
>> Update: the discussion on concurrent-interest about possible future
>> addition of public ThreadLocal.getIfPresent() or
>> ThreadLocal.isPresent() has died out, but it nevertheless reached a
>> point where ThreadLocal.isPresent() was found the least problematic.
>> So I would like to get further with this proposal using the last
>> webrev.04 version of the patch that uses ThreadLocal.isPresent()
>> internally - still package-private at the moment.
>>
>> Here's the webrev (unchanged from the day it was published):
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.04/
>>
>> Would this version be OK?
> I think looks quite good.
>
> One small nit is that the update to ThreadLocal.setInitialValue makes
> it look like all locals are registered when setting the initial value.
> What would you think about moving the instanceof check from
> TerminatingThreadLocal.register so that it's a bit more obvious.
>
> -Alan

Like the following?

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/


Do we need a test which proves that cached direct buffers are released
when thread exits or would a unit test for TerminatingThreadLocal be
enough? Maybe both?

Regards, Peter

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Tony Printezis]

(I unfortunately pressed Send accidentally; apologies)

I was saying: I looked at TestMaxCachedBufferSize and, unfortunately, I
don’t think the test makes a lot of sense right now as it checks the number
/ size of direct buffers after all the threads terminate and, with this
change, that should always be 0.

Let me look into this and I’ll get back to you in a bit.

Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 12:14:24 PM, Tony Printezis (tprinte...@twitter.com)
wrote:

Peter,

Attached TerminatingThreadLocalTest.java. Let me know what you think (and
feel free to modify it / discard it if you don’t like it!).

Re: The test for the max cached buffer size is:
test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java. I looked at it and,
unfortunately,


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 7:07:59 AM, Peter Levart (peter.lev...@gmail.com) wrote:



On 06/20/2018 04:24 PM, Tony Printezis wrote:

Hey Peter,

I had written a test to test my version of the exit hooks. I can easily
rework it to work with yours. Interested?


Of course. Just give what you got. I can modify it as needed.


To check that the native buffers are reclaimed promptly, we should be able
to amend the test that tests the setting of the max size for the cached
buffers (i.e., check that, after all the threads have exited, the total
native count / size is 0).


Good idea. Do you happen to know which one is it?


Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 20, 2018 at 10:08:48 AM, Peter Levart (peter.lev...@gmail.com)
wrote:


On 06/18/2018 05:41 PM, Alan Bateman wrote:
>
>
> On 17/06/2018 22:20, Peter Levart wrote:
>> Update: the discussion on concurrent-interest about possible future
>> addition of public ThreadLocal.getIfPresent() or
>> ThreadLocal.isPresent() has died out, but it nevertheless reached a
>> point where ThreadLocal.isPresent() was found the least problematic.
>> So I would like to get further with this proposal using the last
>> webrev.04 version of the patch that uses ThreadLocal.isPresent()
>> internally - still package-private at the moment.
>>
>> Here's the webrev (unchanged from the day it was published):
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.04/
>>
>> Would this version be OK?
> I think looks quite good.
>
> One small nit is that the update to ThreadLocal.setInitialValue makes
> it look like all locals are registered when setting the initial value.
> What would you think about moving the instanceof check from
> TerminatingThreadLocal.register so that it's a bit more obvious.
>
> -Alan

Like the following?

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/


Do we need a test which proves that cached direct buffers are released
when thread exits or would a unit test for TerminatingThreadLocal be
enough? Maybe both?

Regards, Peter

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Tony Printezis]

Peter,

Attached TerminatingThreadLocalTest.java. Let me know what you think (and
feel free to modify it / discard it if you don’t like it!).

Re: The test for the max cached buffer size is:
test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java. I looked at it and,
unfortunately,


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 21, 2018 at 7:07:59 AM, Peter Levart (peter.lev...@gmail.com) wrote:



On 06/20/2018 04:24 PM, Tony Printezis wrote:

Hey Peter,

I had written a test to test my version of the exit hooks. I can easily
rework it to work with yours. Interested?


Of course. Just give what you got. I can modify it as needed.


To check that the native buffers are reclaimed promptly, we should be able
to amend the test that tests the setting of the max size for the cached
buffers (i.e., check that, after all the threads have exited, the total
native count / size is 0).


Good idea. Do you happen to know which one is it?


Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com


On June 20, 2018 at 10:08:48 AM, Peter Levart (peter.lev...@gmail.com)
wrote:


On 06/18/2018 05:41 PM, Alan Bateman wrote:
>
>
> On 17/06/2018 22:20, Peter Levart wrote:
>> Update: the discussion on concurrent-interest about possible future
>> addition of public ThreadLocal.getIfPresent() or
>> ThreadLocal.isPresent() has died out, but it nevertheless reached a
>> point where ThreadLocal.isPresent() was found the least problematic.
>> So I would like to get further with this proposal using the last
>> webrev.04 version of the patch that uses ThreadLocal.isPresent()
>> internally - still package-private at the moment.
>>
>> Here's the webrev (unchanged from the day it was published):
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.04/
>>
>> Would this version be OK?
> I think looks quite good.
>
> One small nit is that the update to ThreadLocal.setInitialValue makes
> it look like all locals are registered when setting the initial value.
> What would you think about moving the instanceof check from
> TerminatingThreadLocal.register so that it's a bit more obvious.
>
> -Alan

Like the following?

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/


Do we need a test which proves that cached direct buffers are released
when thread exits or would a unit test for TerminatingThreadLocal be
enough? Maybe both?

Regards, Peter

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Peter Levart]

On 06/21/2018 05:53 PM, Peter Levart wrote:

Hi,

On 06/21/2018 09:42 AM, Alan Bateman wrote:



On 20/06/2018 15:08, Peter Levart wrote:


Like the following?

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/

Yes, I think this looks good.



Do we need a test which proves that cached direct buffers are 
released when thread exits or would a unit test for 
TerminatingThreadLocal be enough? Maybe both?
It will be tested by code that uses NIO from threads that exit but I 
agree it would be good to add a unit test for this.


-Alan


Here's the same patch, with tests added:

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.06/

Is this good to go? Should I submit the code to testing system first? 
Please point me to instructions (have not done that yet)...


Regards, Peter



It just occurred to me that TempDirectBuffersReclamation test may fail 
if there is concurrent activity in the VM during or even before the test 
(for example if GC/reference processing frees some direct buffers during 
the test as a consequence of activity before the test). How to cope with 
that? Would running the test in separate VM be enough?


Regards, Peter

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Peter Levart]

Hi,

On 06/21/2018 09:42 AM, Alan Bateman wrote:



On 20/06/2018 15:08, Peter Levart wrote:


Like the following?

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/

Yes, I think this looks good.



Do we need a test which proves that cached direct buffers are 
released when thread exits or would a unit test for 
TerminatingThreadLocal be enough? Maybe both?
It will be tested by code that uses NIO from threads that exit but I 
agree it would be good to add a unit test for this.


-Alan


Here's the same patch, with tests added:

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.06/

Is this good to go? Should I submit the code to testing system first? 
Please point me to instructions (have not done that yet)...


Regards, Peter

Re: free(): corrupted unsorted chunks

[Oliver Kohll]

Hi Thomas,


Unfortunately not, that was /var/log/tomcat8/catalina.out, a snippet from
just before to afterwards when I restarted is below. Everything after
'free(): corrupted unsorted chunks', from 'Note: Picked up
JDK_JAVA_OPTIONS' on was only logged on restart. The warnings are normal.


The lines before were from my application. However they're different for
each crash.


Thanks

Oliver


---


Thu 2018/06/21 09:29:19.913|Warn|Scheduler|View CTG - (Fitting Sync) has
already been scheduled again, shouldn't be reset

Thu 2018/06/21 09:29:21.639|Info|ReportDownloader|User [username] exporting
report GMP from table n0) ff - GMP

Thu 2018/06/21 09:29:23.506|Info|Scheduler|Starting action for googlesyncer
view b4) Fitting Dates (Remedial Sync)

Thu 2018/06/21 09:29:23.911|Info|Scheduler|Starting action for googlesyncer
view b5) Survey Dates (Survey Sync)

Thu 2018/06/21 09:29:23.914|Warn|GoogleSyncer|1 other calendar syncs taking
place, delaying for a minute

Thu 2018/06/21 09:29:23.941|Warn|Scheduler|View (Survey Sync) has already
been scheduled again, shouldn't be reset

Thu 2018/06/21 09:29:24.106|Info|Scheduler|Starting action for
workflowrunner view m1.0) Customer Order.orders to lock

Thu 2018/06/21 09:29:24.338|Info|Scheduler|Starting action for googlesyncer
view a) leads.AGS (Lead Sync)

*free(): corrupted unsorted chunks*

NOTE: Picked up JDK_JAVA_OPTIONS:
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED

21-Jun-2018 09:35:56.096 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/var/lib/tomcat8/common/classes], exists: [false], isDirectory:
[false], canRead: [false]

21-Jun-2018 09:35:56.102 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/var/lib/tomcat8/common], exists: [false], isDirectory: [false],
canRead: [false]

21-Jun-2018 09:35:56.102 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/usr/share/tomcat8/common/classes], exists: [false],
isDirectory: [false], canRead: [false]

21-Jun-2018 09:35:56.102 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/usr/share/tomcat8/common], exists: [false], isDirectory:
[false], canRead: [false]

21-Jun-2018 09:35:56.104 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/var/lib/tomcat8/server/classes], exists: [false], isDirectory:
[false], canRead: [false]

21-Jun-2018 09:35:56.104 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/var/lib/tomcat8/server], exists: [false], isDirectory: [false],
canRead: [false]

21-Jun-2018 09:35:56.105 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/usr/share/tomcat8/server/classes], exists: [false],
isDirectory: [false], canRead: [false]

21-Jun-2018 09:35:56.105 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/usr/share/tomcat8/server], exists: [false], isDirectory:
[false], canRead: [false]

21-Jun-2018 09:35:56.105 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/var/lib/tomcat8/shared/classes], exists: [false], isDirectory:
[false], canRead: [false]

21-Jun-2018 09:35:56.105 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/var/lib/tomcat8/shared], exists: [false], isDirectory: [false],
canRead: [false]

21-Jun-2018 09:35:56.106 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/usr/share/tomcat8/shared/classes], exists: [false],
isDirectory: [false], canRead: [false]

21-Jun-2018 09:35:56.106 WARNING [main]
org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with
directory [/usr/share/tomcat8/shared], exists: [false], isDirectory:
[false], canRead: [false]

21-Jun-2018 09:35:56.795 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin
[SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property
'debug' to '0' did not find a matching property.

21-Jun-2018 09:35:56.806 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin
[SetPropertiesRule]{Server/Service/Engine/Host/Context/Realm/Realm} Setting
property 'debug' to '99' did not find a matching property.

21-Jun-2018 09:35:56.807 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin
[SetPropertiesRule]{Server/Service/Engine/Host/Context/Realm/Realm} Setting
property 'digest' to 'MD5' did not find a matching property.

21-Jun-2018 09:35:56.809 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server version:
  Apache Tomcat/8.5.30 (Ubuntu)

21-Jun-2018 09:35:56.810 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server built:
 

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Martin Buchholz]

On Tue, Jun 19, 2018 at 6:06 AM, David Lloyd  wrote:

> It may be confusing (to some, I guess) but it is consistent: the
> ThreadLocal subclass author has absolute control over how the value is
> presented to the user.  Adding compute() or many of the other
> suggested variants will break that guarantee, which seems like kind of
> a big deal to me.
>
>
Yeah, that's a good point I didn't consider.  Any new method tends to
expose presence/absence and evade subclass' checking.  OTOH I think the
same has happened with default methods added to existing interfaces,
including Map, and I don't recall complaints about the failure of
encapsulation.  In this way, again ThreadLocal.compute would be very much
like Map.compute.


> What about introducing a different thread local API that has more
> modern behavior?  Maybe a new subclass of ThreadLocal?
>
>
The hard part is coming up with a good name.
ThreadLocalNowWithExtraMappiness ?

If we create a new class, we can consider giving get() non-mutating
behavior consistent with Map.

Re: free(): corrupted unsorted chunks

[Thomas Stüfe]

Hi Oliver,

Is there a stack trace on stderr?

Thanks, Thomas





On Thu, Jun 21, 2018 at 1:59 PM, Oliver Kohll  wrote:
> Hi,
>
> I'm a Java developer getting a crash and error message 'free(): corrupted
> unsorted chunks' in the log. this sounds like it could be a low level issue
> in the core Java libraries so I'm posting here, but if it would be better
> in another list (or even a different community) please let me know.
>
> So I'm requesting help because I don't know how to debug this further. In
> summary, the issue is
>
> We're getting a crash nearly once a day on our production system, at a time
> of day when it's most busy (mid morning). This crash hasn't been seen on
> our development environment, which is the same apart from the server has
> less memory and CPU resources.
>
> The environment is:
> * A VPS host
> * Ubuntu LTS 18 (Bionic)
> * The default Java 10 packaged as 11 I believe (
> https://askubuntu.com/questions/1037646/why-is-openjdk-10-packaged-as-openjdk-11
> )
> * However, javac seems to be from JDK8:
> root@server:~# file /etc/alternatives/java /etc/alternatives/javac
> /etc/alternatives/java:  symbolic link to
> /usr/lib/jvm/java-11-openjdk-amd64/bin/java
> /etc/alternatives/javac: symbolic link to
> /usr/lib/jvm/java-8-openjdk-amd64/bin/javac
>
> We're running our webapp on Tomcat 8 (also the Ubuntu default). When this
> happens, the server stops responding to HTTP requests (in fact the java
> process has quit) and needs to be restarted.
>
> The crash doesn't seem to correspond to a particular activity on the server
> as far as I can see, though it's hard to tell as many people are logged in
> at the same time.
>
> Does anyone have any pointers of
> a) how to track the bug further so I can report it, ideally without a big
> impact on our live server
> b) more immediately, any workarounds to try
>
> In the meantime I will see if I can downgrade to JDK8 on the test server,
> but I'm not sure if that's possible or whether it would make a difference.
>
> Regards
> Oliver

free(): corrupted unsorted chunks

[Oliver Kohll]

Hi,

I'm a Java developer getting a crash and error message 'free(): corrupted
unsorted chunks' in the log. this sounds like it could be a low level issue
in the core Java libraries so I'm posting here, but if it would be better
in another list (or even a different community) please let me know.

So I'm requesting help because I don't know how to debug this further. In
summary, the issue is

We're getting a crash nearly once a day on our production system, at a time
of day when it's most busy (mid morning). This crash hasn't been seen on
our development environment, which is the same apart from the server has
less memory and CPU resources.

The environment is:
* A VPS host
* Ubuntu LTS 18 (Bionic)
* The default Java 10 packaged as 11 I believe (
https://askubuntu.com/questions/1037646/why-is-openjdk-10-packaged-as-openjdk-11
)
* However, javac seems to be from JDK8:
root@server:~# file /etc/alternatives/java /etc/alternatives/javac
/etc/alternatives/java:  symbolic link to
/usr/lib/jvm/java-11-openjdk-amd64/bin/java
/etc/alternatives/javac: symbolic link to
/usr/lib/jvm/java-8-openjdk-amd64/bin/javac

We're running our webapp on Tomcat 8 (also the Ubuntu default). When this
happens, the server stops responding to HTTP requests (in fact the java
process has quit) and needs to be restarted.

The crash doesn't seem to correspond to a particular activity on the server
as far as I can see, though it's hard to tell as many people are logged in
at the same time.

Does anyone have any pointers of
a) how to track the bug further so I can report it, ideally without a big
impact on our live server
b) more immediately, any workarounds to try

In the meantime I will see if I can downgrade to JDK8 on the test server,
but I'm not sure if that's possible or whether it would make a difference.

Regards
Oliver

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Peter Levart]

On 06/20/2018 04:24 PM, Tony Printezis wrote:

Hey Peter,

I had written a test to test my version of the exit hooks. I can 
easily rework it to work with yours. Interested?


Of course. Just give what you got. I can modify it as needed.



To check that the native buffers are reclaimed promptly, we should be 
able to amend the test that tests the setting of the max size for the 
cached buffers (i.e., check that, after all the threads have exited, 
the total native count / size is 0).


Good idea. Do you happen to know which one is it?



Tony


—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com 




On June 20, 2018 at 10:08:48 AM, Peter Levart (peter.lev...@gmail.com 
) wrote:




On 06/18/2018 05:41 PM, Alan Bateman wrote:
>
>
> On 17/06/2018 22:20, Peter Levart wrote:
>> Update: the discussion on concurrent-interest about possible future
>> addition of public ThreadLocal.getIfPresent() or
>> ThreadLocal.isPresent() has died out, but it nevertheless reached a
>> point where ThreadLocal.isPresent() was found the least problematic.
>> So I would like to get further with this proposal using the last
>> webrev.04 version of the patch that uses ThreadLocal.isPresent()
>> internally - still package-private at the moment.
>>
>> Here's the webrev (unchanged from the day it was published):
>>
>> 
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.04/ 
 


>>
>> Would this version be OK?
> I think looks quite good.
>
> One small nit is that the update to ThreadLocal.setInitialValue makes
> it look like all locals are registered when setting the initial value.
> What would you think about moving the instanceof check from
> TerminatingThreadLocal.register so that it's a bit more obvious.
>
> -Alan

Like the following?

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/ 
 




Do we need a test which proves that cached direct buffers are released
when thread exits or would a unit test for TerminatingThreadLocal be
enough? Maybe both?

Regards, Peter

RE: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

[Pengfei Li]

Hi Bernard,

Yes, your fix is good but would be nicer if the comment in line 733 is modified 
as well since it might be misleading.
>  733 /* On AIX, readdir() returns EBADF ...

I only have Linux machines to test. But I suggest that your patch being merged 
soon as the deprecated use breaks the build on many latest Linux distributions, 
and it's hard for guys to find other POSIX platforms in a short time.

--
Thanks,
Pengfei


-Original Message-
From: B. Blaser  
Sent: Thursday, June 21, 2018 00:01
To: Pengfei Li 
Cc: kim.barr...@oracle.com; core-libs-dev@openjdk.java.net; nd ; 
build-...@openjdk.java.net
Subject: Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int 
readdir_r(DIR*, dirent*, dirent**)' is deprecated

Hi Pengfei,

On 20 June 2018 at 12:08, Pengfei Li  wrote:
> Hi
>
> I have tried the patch ( 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html ) 
> on Ubuntu 18.04 machines (x86_64 & aarch64) with glibc=2.26.1 and build is OK.
>
> There's a small issue within the following code in 
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
> Unlike readdir_r(), readdir() does not return int value. The value of res is 
> always 0 before #ifdef.
>
>  727 /* EINTR not listed as a possible error */
>  728 errno = 0;
>  729 ptr = readdir64(dirp);
>  730 res = errno;
>  731
>  732 #ifdef _AIX
>  733 /* On AIX, readdir() returns EBADF (i.e. '9') and sets 'result' to 
> NULL for the */
>  734 /* directory stream end. Otherwise, 'errno' will contain the error 
> code. */
>  735 if (res != 0) {
>  736 res = (ptr == NULL && res == EBADF) ? 0 : errno;
>  737 }
>  738 #endif
>
> May I know that if this core-libs change going to be merged recently, or more 
> platforms needs to be explored?
>
> --
> Thanks,
> Pengfei

Thanks for evaluating this patch, 'readdir()' doesn't return an 'int'
value but it sets 'errno' instead which is then assigned to 'res'.
So, I guess the fix is OK, or did I miss anything?

I've also tested it on Linux/x86_64 but ideally, the patch should be tested on 
all supported POSIX platforms before being integrated.
The JBS issue [1] doesn't mention any fix version, so I'm not sure if it'll be 
targeted to 11 or 12.

But if someone is available to test it on other POSIX platforms and review it, 
this would be nice?

Thanks,
Bernard

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

Re: Creating a charset provider module for IBM charsets

[Dave Hobbs]

Yes, the proposal is to create a new module outside the JDK.

I was originally responding to your suggestion of not including these 
charsets in java.base.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053316.html

"Separately, I think we should start a discussion here about moving some 
or all of the IBM charsets to their own service provider module. I 
realize the AIX port might want to include some of them in its build of 
java.base but they aren't interesting to include in java.base, or even 
jdk.charsets, on most platforms"

A service provider module appears to be the recommended approach according 
the Java api documentation. However writing charset classes is made a lot 
more difficult by not having the sun.nio.cs classes available. 

Should we propose adding our charsets in the java.base or jdk.charsets?

- Dave




From:   Alan Bateman 
To: Dave Hobbs , core-libs-dev@openjdk.java.net
Date:   20/06/2018 18:27
Subject:Re: Creating a charset provider module for IBM charsets



On 20/06/2018 15:52, Dave Hobbs wrote:
> Hi Alan,
>
> My understanding is that java.base only exports sun.nio.cs to 
jdk.charsets
> i.e java.base module-info.java has:
>
> ...
> exports sun.nio.cs to
>  java.desktop,
>  jdk.charsets;
> ...
>
> and jdk.charsets has:
>
> module jdk.charsets {
>  provides java.nio.charset.spi.CharsetProvider with
>  sun.nio.cs.ext.ExtendedCharsets;
> }
>
> So jdk.charsets can use sun.nio.cs, whereas my module can not.
>
> Am I missing something?
>
Are you proposing to add your module to the JDK or will it live outside? 
If the former then just extend the qualified export to add the name of 
the module. If the latter then you are out of luck as the sun.nio.cs 
infrastructure is not meant to be used outside of the JDK.

-Alan




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

[David Holmes]

Thanks John!

On 21/06/2018 6:15 AM, John Rose wrote:

Good; I like the care to distinguish "nested" classes (using the
word "enclosing") from the newer concept of "nests" and "nestmates",
as well as the careful framing of how stuff bubbles up from the classfile.

(Kudos to Alex!)


Yes this is much improved.

David


— John

On Jun 19, 2018, at 9:56 PM, David Holmes > wrote:


Some further adjustments to getNestMembers() was made. Everything 
updated in place.


Thanks,
David

On 20/06/2018 9:30 AM, David Holmes wrote:

Sorry another update is imminent ... stay tuned.
David
On 19/06/2018 2:41 PM, David Holmes wrote:
Discussions on the CSR request have led to further changes to the 
documentation involving nests and the new nest-related method. There 
are no semantic changes here just clearer explanations.


Incremental 
webrev:http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v7-incr/

Re: [core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

[David Holmes]

Thanks Paul!

David

On 21/06/2018 3:43 AM, Paul Sandoz wrote:




On Jun 19, 2018, at 10:25 PM, mandy chung  wrote:

The javadoc update looks good to me.



Same here, +1

Paul.

RE: RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr

[Markus Gronlund]

Hi Alan,

Some context might be helpful here:

The real JFR API is located in module jdk.jfr and the API handle there is this 
class jdk.jfr.Event [1]

There are multiple reasons for choosing an class as the API instead of an 
interface - most of them are driven by implementation (in the VM) and 
performance related.

As you can see in [1], the methods we are discussing here are there declared 
"final". This reflects the fact that we don't want user versions of these 
methods. We do want the signatures and the schema however so we can rework 
classes and methods in the VM.

Using a class hierarchy allows us via induction quickly decide (bit check) if a 
loading class is related to the API (which cannot be done as performant should 
the solution be based on an interface) and we want to work with invokevirtual 
and invokespecial but not so much invokeinterface.

So this solution we are discussing here is about how we can extend what we 
already have in place for JFR to also allow code in java.base to use it.

The main challenge here is with solving the module system inversion in that 
java.base can't have a compile dependency on the real JFR API located in 
jdk.jfr:

With the solution proposed by Erik, we extend our JFR VM machinery to also 
treat jdk.internal.events.Event in the same way as jdk.jfr.Event. 
Unfortunately, in order to do this, we now can't make the methods in 
jdk.internal.events.Event "final" since we will need inherit it from 
jdk.jfr.Event (which implement these methods already in the API proper). Also, 
there now needs to be careful means in the VM of avoiding jdk.jfr module 
related symbols when processing java.base events in certain states (for 
example, a module read link not having been established (yet or at all) etc).

I don’t think we should view jdk.internal.events.Event as an general API but 
instead it is a means of hooking into the JFR system at runtime, via the VM, 
avoiding the compile time dependency. 

"Regular code" should work with the jdk.jfr module proper if possible, but for 
situations that cannot handle that / don't want to add the module import for 
some reason, this is a JDK internal hook point, that can be used if needed. 
This is also the reason why it is not exported to other modules in general, it 
is mainly intended for java.base, since the inversion leave no other 
alternatives (except moving all jfr code into java.base which I think is 
probably not an option). 

In addition, nothing in jdk.internal.events.Event strongly couple with jdk.jfr 
which means it may be put to some other use for alternative implementations 
that do not have a JFR implementation say.

Hope this clarifies a bit

Thanks
Markus 

[1] https://docs.oracle.com/javase/9/docs/api/jdk/jfr/Event.html 


-Original Message-
From: Alan Bateman 
Sent: den 21 juni 2018 09:52
To: Erik Gahlin ; hotspot-jfr-...@openjdk.java.net; 
core-libs-dev 
Subject: Re: RFR: 8203629: Produce events in the JDK without a dependency on 
jdk.jfr

On 20/06/2018 18:59, Erik Gahlin wrote:
> :
>
>> Also all the methods are empty which makes me wonder if they should 
>> be abstract (as the class is abstract) or whether it should be an 
>> interface.
> Abstract is needed to prevent user from instantiating the class.
>
> The methods need to have a body, otherwise event classes in java.base 
> would need to implement the methods, which would be cumbersome. We 
> like to use a class as it simplifies the implementation if we know all 
> event classes have a common ancestor with java.lang.Object as a parent.
>
> so we can be guaranteed that the class
I'm not sure that I understand the issues here but just to say that 
jdk.internal.event is not exported so code outside of the JDK cannot directly 
instantiate instances of classes in that package. Also interfaces can have 
default methods which may go to your concern about needing to implement each of 
the 6 methods. Once Event is cleaned up with some javadoc then it will be 
easier to argue this one way or the other.

-Alan

Re: [core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

[David Holmes]

Hi Karen,

On 21/06/2018 7:42 AM, Karen Kinnear wrote:

Looks good.


Thanks. Unfortunately there were a few more minor edits "overnight". 
Everything updated in place (apologies as I wanted to include a simple 
patch but overwrote things before realising I now had no means to do so.)


Summary:

- Class-level nest definition: use nestmates instead of members to avoid 
potential confusion/conflict with reference to "private members"


"A _nest_ is a set of classes and interfaces... . The classes and 
interfaces are known as _nestmates_. One nestmate acts as the _nest 
host_, and enumerates the other nestmates which belong to the nest; each 
of them in turn records it as the nest host. ...


- getNestHost
  - replace record withenumerate when referring to nest members 
(members record their nest host; nest hosts enumerate their members)


-getNestMembers
  - replace @jvms ref with @see getNestHost



Can you send the updates to the valhalla spec experts please? We told them this 
was coming, and minor changes for
clarification.


I already did:

http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-June/000710.html

Thanks,
David



thanks,
Karen


On Jun 19, 2018, at 12:41 AM, David Holmes  wrote:

Discussions on the CSR request have led to further changes to the documentation 
involving nests and the new nest-related method. There are no semantic changes 
here just clearer explanations.

Incremental webrev: 
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v7-incr/

(don't worry if you don't see a v6, it didn't really exist).

Full webrev: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.full.v7/

Specdiffs updated in place at: 
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/specs/

Summary of changes:

- The definition of a nest etc is moved to the class-level javadoc of 
java.lang.Class, along with some other edits provided by Alex Buckley to pave 
the way for future updates
- The nest-related methods are written in a more clear and consistent way

Thanks,
David
-

On 12/06/2018 3:16 PM, David Holmes wrote:

Here is one further minor update from the CSR discussions:
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v5-incr/src/java.base/share/classes/java/lang/Class.java.cdiff.html
 Thanks,
David
On 25/05/2018 3:52 PM, David Holmes wrote:

Here are the further minor updates so far in response to all the review 
comments.

Incremental corelibs webrev:
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v3-incr/

Full corelibs webrev:
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v3/

Change summary:

src/java.base/share/classes/jdk/internal/reflect/Reflection.java
- remove inaccurate pseudo-assertion comment

test/jdk/java/lang/reflect/Nestmates/SampleNest.java
- code cleanup: <> operator

test/jdk/java/lang/reflect/Nestmates/TestReflectionAPI.java
- code cleanup: streamify duplicate removals

test/jdk/java/lang/invoke/PrivateInterfaceCall.java
- use consistent @bug number

Thanks,
David

On 22/05/2018 8:15 PM, David Holmes wrote:

Here are the updates so far in response to all the review comments.

Incremental webrev: 
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v2-incr/

Full webrev: 
http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v2/

Change summary:

src/java.base/share/classes/java/lang/Class.java
- getNesthost:
- change "any error" -> "any linkage error" as runtime errors will 
propagate. [This needs ratifying by EG]
- add clarification that primitive and array classes are not explicitly 
members of any nest and so form singleton nests
- add clarification that all nestmates are in the same package
- re-word @return text to exclude the "royal 'we'"
- fix javadoc cross references

---

Moved reflection API tests from 
test/hotspot/jtreg/runtime/Nestmates/reflectionAPI/ to 
test/jdk/java/lang/reflect/Nestmates/

---

java/lang/reflect/Nestmates/TestReflectionAPI.java

Run tests twice to show that failure reasons remain the same.

---

test/jdk/jdk/lambda/vm/InterfaceAccessFlagsTest.java

Disable test via annotation rather than commenting out.

---

src/java.base/share/classes/jdk/internal/reflect/Reflection.java

- Fix indent for nestmate access check.
- Remove unnecessary local variable

---

src/java.base/share/classes/sun/invoke/util/VerifyAccess.java

- Replace myassert with proper assert

---

Thanks,
David

On 15/05/2018 10:52 AM, David Holmes wrote:

This review is being spread across four groups: langtools, core-libs, hotspot 
and serviceability. This is the specific review thread for core-libs - webrev:

http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.corelibs.v1/

See below for full details - including annotated full webrev guiding the review.

The intent is to have JEP-181 targeted and integrated by the end of this month.

Thanks,
David
-

The nestmates project (JEP-181) introduces new classfile attributes to identify 

Re: RFR JDK-8204938: Add a test case to automatically check the updated LSR data

[Nishit Jain]

Thanks Naoto, Roger for the review. Made the suggested changes and 
pushed to the repo.


Regards,
Nishit Jain
On 21-06-2018 00:23, Roger Riggs wrote:

Hi Nishit,

Looks ok

My only comment would be to put the relative path to the 
language-subtag-registry.txt in a private static final constant
to call attention to the dependency on the source layout instead of 
burying it in the code.


$.02, Roger


On 6/20/2018 2:27 PM, naoto.s...@oracle.com wrote:

Looks good.

Naoto

On 6/20/18 3:32 AM, Nishit Jain wrote:

Hi,

Please review the fix for JDK-8204938

Bug: https://bugs.openjdk.java.net/browse/JDK-8204938
Webrev: http://cr.openjdk.java.net/~nishjain/8204938/webrev.02/

Fix: Added a test case to cross check the LSR data generated for the 
JDK APIs. So, for each lsr data update, the test case need not be 
updated, it automatically cross checks the updated lsr data.


Regards,
Nishit Jain

Re: RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr

[Alan Bateman]

On 20/06/2018 18:59, Erik Gahlin wrote:

:

Also all the methods are empty which makes me wonder if they should 
be abstract (as the class is abstract) or whether it should be an 
interface.

Abstract is needed to prevent user from instantiating the class.

The methods need to have a body, otherwise event classes in java.base 
would need to implement the methods, which would be cumbersome. We 
like to use a class as it simplifies the implementation if we know all 
event classes have a common ancestor with java.lang.Object as a parent.


so we can be guaranteed that the class
I'm not sure that I understand the issues here but just to say that 
jdk.internal.event is not exported so code outside of the JDK cannot 
directly instantiate instances of classes in that package. Also 
interfaces can have default methods which may go to your concern about 
needing to implement each of the 6 methods. Once Event is cleaned up 
with some javadoc then it will be easier to argue this one way or the other.


-Alan

Re: RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[Alan Bateman]

On 20/06/2018 15:08, Peter Levart wrote:


Like the following?

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/

Yes, I think this looks good.



Do we need a test which proves that cached direct buffers are released 
when thread exits or would a unit test for TerminatingThreadLocal be 
enough? Maybe both?
It will be tested by code that uses NIO from threads that exit but I 
agree it would be good to add a unit test for this.


-Alan