From jcbeyler at google.com  Fri Dec  1 00:58:28 2017
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 30 Nov 2017 16:58:28 -0800
Subject: RFR 8191989: TLAB Refills for Sparc
Message-ID: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>

Hi all,

The TLAB and the inline contiguous allocations handling are different for
each architecture. On certain architectures, TLAB is never actually never
refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).

The idea behind the implementation for Sparc is to do two things:
  - separate TLAB usage to contiguous allocations in eden space.
  - remove the code that augments the TLAB waste limit since that is
already done in the common code slow path

Bug: https://bugs.openjdk.java.net/browse/JDK-8191989
WebRev: *http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/
<http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/>*

Does anyone see any issues with this webrev?

Thanks for your help,
Jc

From devnexen at gmail.com  Fri Dec  1 05:17:19 2017
From: devnexen at gmail.com (David CARLIER)
Date: Fri, 1 Dec 2017 05:17:19 +0000
Subject: [PATCH] Mere code changes to silent warnings
Message-ID: <CA+XhMqxxAx1eNjunsnWTP0pit2P8AEuhYKmRQ7xOojndZgrvWw@mail.gmail.com>

HI dear list here a tiny patch proposal to silent few warnings :
- Undefined behaviour when a constant is defined as
#define A <cond> ... it is usually better this form #if <cond> #define A 1
...
- Wrong pointer comparison.
- Useless template specialisations.

Hope it helps.

Thanks.
-------------- next part --------------
diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp
--- a/src/hotspot/os/linux/os_linux.cpp
+++ b/src/hotspot/os/linux/os_linux.cpp
@@ -2153,7 +2153,7 @@
     }
 
     p = OSContainer::cpu_cpuset_memory_nodes();
-    if (p < 0)
+    if (p != NULL)
       st->print("cpu_memory_nodes() failed\n");
     else {
       st->print("cpu_memory_nodes: %s\n", p);
diff --git a/src/hotspot/share/gc/g1/heapRegionSet.hpp b/src/hotspot/share/gc/g1/heapRegionSet.hpp
--- a/src/hotspot/share/gc/g1/heapRegionSet.hpp
+++ b/src/hotspot/share/gc/g1/heapRegionSet.hpp
@@ -50,7 +50,11 @@
 // HEAP_REGION_SET_FORCE_VERIFY to be 1, or in builds in which
 // asserts are compiled in.
 #ifndef HEAP_REGION_SET_FORCE_VERIFY
-#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
+#if defined(ASSERT)
+#define HEAP_REGION_SET_FORCE_VERIFY 1
+#else
+#define HEAP_REGION_SET_FORCE_VERIFY 0
+#endif
 #endif // HEAP_REGION_SET_FORCE_VERIFY
 
 class HRSMtSafeChecker : public CHeapObj<mtGC> {
diff --git a/src/hotspot/share/oops/accessBackend.cpp b/src/hotspot/share/oops/accessBackend.cpp
--- a/src/hotspot/share/oops/accessBackend.cpp
+++ b/src/hotspot/share/oops/accessBackend.cpp
@@ -172,18 +172,3 @@
     Copy::conjoint_jlongs_atomic(src, dst, length);
   }
 }
-
-template void AccessInternal::arraycopy_conjoint<jbyte>(jbyte* src, jbyte* dst, size_t length);
-template void AccessInternal::arraycopy_conjoint<jshort>(jshort* src, jshort* dst, size_t length);
-template void AccessInternal::arraycopy_conjoint<jint>(jint* src, jint* dst, size_t length);
-template void AccessInternal::arraycopy_conjoint<jlong>(jlong* src, jlong* dst, size_t length);
-
-template void AccessInternal::arraycopy_arrayof_conjoint<jbyte>(jbyte* src, jbyte* dst, size_t length);
-template void AccessInternal::arraycopy_arrayof_conjoint<jshort>(jshort* src, jshort* dst, size_t length);
-template void AccessInternal::arraycopy_arrayof_conjoint<jint>(jint* src, jint* dst, size_t length);
-template void AccessInternal::arraycopy_arrayof_conjoint<jlong>(jlong* src, jlong* dst, size_t length);
-
-template void AccessInternal::arraycopy_conjoint_atomic<jbyte>(jbyte* src, jbyte* dst, size_t length);
-template void AccessInternal::arraycopy_conjoint_atomic<jshort>(jshort* src, jshort* dst, size_t length);
-template void AccessInternal::arraycopy_conjoint_atomic<jint>(jint* src, jint* dst, size_t length);
-template void AccessInternal::arraycopy_conjoint_atomic<jlong>(jlong* src, jlong* dst, size_t length);
diff --git a/src/hotspot/share/utilities/nativeCallStack.cpp b/src/hotspot/share/utilities/nativeCallStack.cpp
--- a/src/hotspot/share/utilities/nativeCallStack.cpp
+++ b/src/hotspot/share/utilities/nativeCallStack.cpp
@@ -37,7 +37,11 @@
     // to call os::get_native_stack. A tail call is used if _NMT_NOINLINE_ is not defined
     // (which means this is not a slowdebug build), and we are on 64-bit (except Windows).
     // This is not necessarily a rule, but what has been obvserved to date.
-#define TAIL_CALL (!defined(_NMT_NOINLINE_) && !defined(WINDOWS) && defined(_LP64))
+#if (!defined(_NMT_NOINLINE_) && !defined(WINDOWS) && defined(_LP64))
+#define TAIL_CALL 1
+#else
+#define TAIL_CALL 0
+#endif
 #if !TAIL_CALL
     toSkip++;
 #if (defined(_NMT_NOINLINE_) && defined(BSD) && defined(_LP64))

From robbin.ehn at oracle.com  Fri Dec  1 07:46:44 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 1 Dec 2017 08:46:44 +0100
Subject: TLAB Refills for x86
In-Reply-To: <CAF9BGByOTFvAdgAaG3S85yO8jov0rdA7_tiiEnU38wFxNxzoeg@mail.gmail.com>
References: <CAF9BGByOTFvAdgAaG3S85yO8jov0rdA7_tiiEnU38wFxNxzoeg@mail.gmail.com>
Message-ID: <a661c7fd-4f75-6f3e-cb62-b188a14e173b@oracle.com>

Hi JC,

Passes tier1-5 and performance testing ok.

Looks good, thanks for fixing!

/Robbin

On 2017-11-30 22:09, JC Beyler wrote:
> Hi all,
> 
> The TLAB and the inline contiguous allocations handling are different for
> each architecture. On certain architectures, TLAB is never actually never
> refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
> 
> The idea behind the implementation for x86 is to separate TLAB usage to
> contiguous allocations in eden space.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191027
> WebRev: http://cr.openjdk.java.net/~rasbold/8191027/webrev.02/
> 
> Does anyone see any issues with this webrev?
> 
> Thanks for your help,
> Jc
> 

From robbin.ehn at oracle.com  Fri Dec  1 07:47:23 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 1 Dec 2017 08:47:23 +0100
Subject: RFR 8191989: TLAB Refills for Sparc
In-Reply-To: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>
References: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>
Message-ID: <08344b1f-8e2a-d184-3f96-7157cd7e9b34@oracle.com>

Hi JC,

Passes tier1-5.

Looks good, thanks for fixing!

/Robbin

On 2017-12-01 01:58, JC Beyler wrote:
> Hi all,
> 
> The TLAB and the inline contiguous allocations handling are different for
> each architecture. On certain architectures, TLAB is never actually never
> refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
> 
> The idea behind the implementation for Sparc is to do two things:
>    - separate TLAB usage to contiguous allocations in eden space.
>    - remove the code that augments the TLAB waste limit since that is
> already done in the common code slow path
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191989
> WebRev: *http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/
> <http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/>*
> 
> Does anyone see any issues with this webrev?
> 
> Thanks for your help,
> Jc
> 

From jesper.wilhelmsson at oracle.com  Fri Dec  1 20:20:59 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 1 Dec 2017 21:20:59 +0100
Subject: JDK 10 RDP1 vs the Hotspot repo
Message-ID: <E2D6C03A-493E-489A-80DB-879F81311C44@oracle.com>

Hi HotSpot developers!

Today is December 1:st and this is the day that was announced to be the last day to push changes that must go into JDK 10 through the Hotspot repository, jdk/hs.

Tonight at 8 pm PT the Hotspot nightly will grab a snapshot of jdk/hs and run the usual nightly testing. I will then take this snapshot and start our slightly larger integration test suite that will run over the weekend to make sure stuff holds together. If there are integration blockers, already known or found by the testing, these bugs should have top priority to fix during the time left before JDK 10 enters RDP1. Once all known blockers in the snapshot are fixed I will push this snapshot to jdk/jdk. If there are blockers left by the 14:th we need to rethink our plan.

JDK 10 enters RDP1 on December 14:th. At this point a stabilization repo for JDK 10 will be created and the development repositories (e.g. jdk/jdk and jdk/hs) will be in JDK 11 mode. After this point only P1-P3 bugs can be fixed in JDK 10.

As we have some time between today and the 14:th development will continue in jdk/hs. During this period jdk/hs is still in JDK 10 mode. IF the snapshot I take tonight is integrated smoothly already next week I will try to get another hs snapshot (Friday next week) into jdk/jdk before the fork, but please note that this is a big IF.

Trying to sum this up:
P1-P3 bugfixes
Not affected by RDP1.
If pushed to jdk/hs between today and December 14 we will make sure they end up in JDK 10 eventually.
If pushed to jdk/hs after December 14 they become fixed in JDK 11 and it will be your own responsibility to backport them to JDK 10.
RFEs and P4 - P5 bugs that MUST go into JDK 10
Push to jdk/hs before 8 pm PT today
or push directly to jdk/jdk before December 14.
Please note that this option requires that you test your change extensively as this will bypass all normal VM testing that is done in jdk/hs before changes propagates to jdk/jdk.
JDK 11 changes
Do NOT push to any repository until after the fork on December 14.
Thanks,
/Jesper


From jesper.wilhelmsson at oracle.com  Fri Dec  1 20:29:45 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 1 Dec 2017 21:29:45 +0100
Subject: JDK 10 RDP1 vs the Hotspot repo
In-Reply-To: <E2D6C03A-493E-489A-80DB-879F81311C44@oracle.com>
References: <E2D6C03A-493E-489A-80DB-879F81311C44@oracle.com>
Message-ID: <8E63962F-6143-4B2A-98FB-CB21CFF77797@oracle.com>

OK, so this was actually a bullet list in my original mail... Trying again:
P1-P3 bugfixes
Not affected by RDP1.
If pushed to jdk/hs between today and December 14 we will make sure they end up in JDK 10 eventually.
If pushed to jdk/hs after December 14 they become fixed in JDK 11 and it will be your own responsibility to backport them to JDK 10.
RFEs and P4 - P5 bugs that MUST go into JDK 10
Push to jdk/hs before 8 pm PT today
or push directly to jdk/jdk before December 14.
Please note that this option requires that you test your change extensively as this will bypass all normal VM testing that is done in jdk/hs before changes propagates to jdk/jdk.
JDK 11 changes
Do NOT push to any repository until after the fork on December 14.
/Jesper


From jesper.wilhelmsson at oracle.com  Fri Dec  1 20:36:34 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 1 Dec 2017 21:36:34 +0100
Subject: JDK 10 RDP1 vs the Hotspot repo
In-Reply-To: <8E63962F-6143-4B2A-98FB-CB21CFF77797@oracle.com>
References: <E2D6C03A-493E-489A-80DB-879F81311C44@oracle.com>
 <8E63962F-6143-4B2A-98FB-CB21CFF77797@oracle.com>
Message-ID: <73E25C29-2566-43C0-9959-E9A6F94A6019@oracle.com>

That's what I get for trying to make things look good...  Ok, now without HTML.

* P1-P3 bugfixes
-- Not affected by RDP1.
-- If pushed to jdk/hs between today and December 14 we will make sure they end up in JDK 10 eventually.
-- If pushed to jdk/hs after December 14 they become fixed in JDK 11 and it will be your own responsibility to backport them to JDK 10.
* RFEs and P4 - P5 bugs that MUST go into JDK 10
-- Push to jdk/hs before 8 pm PT today
-- or push directly to jdk/jdk before December 14.
   - Please note that this option requires that you test your change extensively as this will bypass all normal VM testing that is done in jdk/hs before changes propagates to jdk/jdk.
* JDK 11 changes
-- Do NOT push to any repository until after the fork on December 14.

/Jesper


From david.holmes at oracle.com  Mon Dec  4 01:58:24 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 4 Dec 2017 11:58:24 +1000
Subject: JDK 10 RDP1 vs the Hotspot repo
In-Reply-To: <73E25C29-2566-43C0-9959-E9A6F94A6019@oracle.com>
References: <E2D6C03A-493E-489A-80DB-879F81311C44@oracle.com>
 <8E63962F-6143-4B2A-98FB-CB21CFF77797@oracle.com>
 <73E25C29-2566-43C0-9959-E9A6F94A6019@oracle.com>
Message-ID: <1db75fd7-e171-1b53-92ba-67ea9daa867f@oracle.com>

Hi Jesper,

On 2/12/2017 6:36 AM, jesper.wilhelmsson at oracle.com wrote:
> That's what I get for trying to make things look good...  Ok, now without HTML.
> 
> * P1-P3 bugfixes
> -- Not affected by RDP1.
> -- If pushed to jdk/hs between today and December 14 we will make sure they end up in JDK 10 eventually.
> -- If pushed to jdk/hs after December 14 they become fixed in JDK 11 and it will be your own responsibility to backport them to JDK 10.
> * RFEs and P4 - P5 bugs that MUST go into JDK 10
> -- Push to jdk/hs before 8 pm PT today
> -- or push directly to jdk/jdk before December 14.

If someone mistakenly pushes to hs after the deadline, but really 
intended the fix to be in 10, what should they do? Should they just do a 
direct import from jdk/hs to jdk/jdk ?

Thanks,
David

>     - Please note that this option requires that you test your change extensively as this will bypass all normal VM testing that is done in jdk/hs before changes propagates to jdk/jdk.
> * JDK 11 changes
> -- Do NOT push to any repository until after the fork on December 14.
> 
> /Jesper
> 

From magnus.ihse.bursie at oracle.com  Mon Dec  4 11:06:08 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2017 12:06:08 +0100
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
Message-ID: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>

JDK-8190484 was created as a follow-up bug to the unification of the 
duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location 
of these files. This has now been decided to be hotspot/share/include 
and hotspot/os/$OS/include, respectively.

This patch moves the relevant files there, but since this also frees up 
the src/$MODULE/native/include directories for the original purpose, it 
also unifies and simplifies the build logic for these directories, so 
that common code is executed for all modules to just copy any exported 
header files from these directories, should they exist.

I'm intending to push this to jdk-hs.

Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01

/Magnus

From david.holmes at oracle.com  Mon Dec  4 11:17:37 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 4 Dec 2017 21:17:37 +1000
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
Message-ID: <d8628ea9-5600-0812-f46d-a9516eb5bba6@oracle.com>

Hi Magnus,

On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
> JDK-8190484 was created as a follow-up bug to the unification of the 
> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location 
> of these files. This has now been decided to be hotspot/share/include 
> and hotspot/os/$OS/include, respectively.
> 
> This patch moves the relevant files there, but since this also frees up 
> the src/$MODULE/native/include directories for the original purpose, it 
> also unifies and simplifies the build logic for these directories, so 
> that common code is executed for all modules to just copy any exported 
> header files from these directories, should they exist.
> 
> I'm intending to push this to jdk-hs.

Do you want this in 10 or 11? If you want 10 then you need to push to 
jdk/jdk as there may not be another snapshot from jdk/hs.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 

Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow 
on cleanups.

Thanks,
David

> 
> /Magnus

From coleen.phillimore at oracle.com  Mon Dec  4 12:12:37 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 4 Dec 2017 07:12:37 -0500
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
Message-ID: <e16b9092-9383-266c-4ca4-ea26b416abb7@oracle.com>

I'm not a makefile expert, but think this looks like a very nice cleanup.
Thanks!
Coleen

On 12/4/17 6:06 AM, Magnus Ihse Bursie wrote:
> JDK-8190484 was created as a follow-up bug to the unification of the 
> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location 
> of these files. This has now been decided to be hotspot/share/include 
> and hotspot/os/$OS/include, respectively.
>
> This patch moves the relevant files there, but since this also frees 
> up the src/$MODULE/native/include directories for the original 
> purpose, it also unifies and simplifies the build logic for these 
> directories, so that common code is executed for all modules to just 
> copy any exported header files from these directories, should they exist.
>
> I'm intending to push this to jdk-hs.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>
> /Magnus


From magnus.ihse.bursie at oracle.com  Mon Dec  4 12:44:36 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2017 13:44:36 +0100
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <d8628ea9-5600-0812-f46d-a9516eb5bba6@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <d8628ea9-5600-0812-f46d-a9516eb5bba6@oracle.com>
Message-ID: <b86b75de-8ac3-ae70-05ce-6d221161adac@oracle.com>


On 2017-12-04 12:17, David Holmes wrote:
> Hi Magnus,
>
> On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
>> JDK-8190484 was created as a follow-up bug to the unification of the 
>> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>> location of these files. This has now been decided to be 
>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>
>> This patch moves the relevant files there, but since this also frees 
>> up the src/$MODULE/native/include directories for the original 
>> purpose, it also unifies and simplifies the build logic for these 
>> directories, so that common code is executed for all modules to just 
>> copy any exported header files from these directories, should they 
>> exist.
>>
>> I'm intending to push this to jdk-hs.
>
> Do you want this in 10 or 11? If you want 10 then you need to push to 
> jdk/jdk as there may not be another snapshot from jdk/hs.
It was targeted at 11 in the JBS issue. I don't have a strong opinion on 
forcing this into JDK 10. Also, one of the fixes it depended on was not 
yet integrated from jdk/hs to jdk/jdk.

But if you think it should go into JDK 10 and jdk/jdk, just let me know 
and I'll move the changeset there, and await the next jdk/hs -> jdk/jdk 
integration.

/Magnus

>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>
>
> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow 
> on cleanups.
>
> Thanks,
> David
>
>>
>> /Magnus


From david.holmes at oracle.com  Mon Dec  4 12:56:02 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 4 Dec 2017 22:56:02 +1000
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <b86b75de-8ac3-ae70-05ce-6d221161adac@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <d8628ea9-5600-0812-f46d-a9516eb5bba6@oracle.com>
 <b86b75de-8ac3-ae70-05ce-6d221161adac@oracle.com>
Message-ID: <168a5a98-9e15-8389-fbeb-d0cedf13a739@oracle.com>

On 4/12/2017 10:44 PM, Magnus Ihse Bursie wrote:
> On 2017-12-04 12:17, David Holmes wrote:
>> Hi Magnus,
>>
>> On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
>>> JDK-8190484 was created as a follow-up bug to the unification of the 
>>> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>> location of these files. This has now been decided to be 
>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>
>>> This patch moves the relevant files there, but since this also frees 
>>> up the src/$MODULE/native/include directories for the original 
>>> purpose, it also unifies and simplifies the build logic for these 
>>> directories, so that common code is executed for all modules to just 
>>> copy any exported header files from these directories, should they 
>>> exist.
>>>
>>> I'm intending to push this to jdk-hs.
>>
>> Do you want this in 10 or 11? If you want 10 then you need to push to 
>> jdk/jdk as there may not be another snapshot from jdk/hs.
> It was targeted at 11 in the JBS issue. I don't have a strong opinion on 
> forcing this into JDK 10. Also, one of the fixes it depended on was not 
> yet integrated from jdk/hs to jdk/jdk.
> 
> But if you think it should go into JDK 10 and jdk/jdk, just let me know 
> and I'll move the changeset there, and await the next jdk/hs -> jdk/jdk 
> integration.

Things are not quite working that way at the moment - see [1] - hs has 
potentially taken its last snapshot before JDK 10 is forked. If this 
must go into 10 then it has to be pushed direct to jdk/jdk. If it may go 
in 10 or 11, then it can go into jdk/hs (and it will end up in 10 if 
there is a second snapshot, else 11). If it is only intended for 11 then 
it must not be pushed until after the Dec 14 fork of JDK 10.

I have no opinion one way or the other.

David

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029474.html

> /Magnus
> 
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>
>>
>>
>> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow 
>> on cleanups.
>>
>> Thanks,
>> David
>>
>>>
>>> /Magnus
> 

From coleen.phillimore at oracle.com  Mon Dec  4 14:00:50 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 4 Dec 2017 09:00:50 -0500
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <168a5a98-9e15-8389-fbeb-d0cedf13a739@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <d8628ea9-5600-0812-f46d-a9516eb5bba6@oracle.com>
 <b86b75de-8ac3-ae70-05ce-6d221161adac@oracle.com>
 <168a5a98-9e15-8389-fbeb-d0cedf13a739@oracle.com>
Message-ID: <35f19183-87dc-9a11-daed-dae556762f0b@oracle.com>



On 12/4/17 7:56 AM, David Holmes wrote:
> On 4/12/2017 10:44 PM, Magnus Ihse Bursie wrote:
>> On 2017-12-04 12:17, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
>>>> JDK-8190484 was created as a follow-up bug to the unification of 
>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>> location of these files. This has now been decided to be 
>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>
>>>> This patch moves the relevant files there, but since this also 
>>>> frees up the src/$MODULE/native/include directories for the 
>>>> original purpose, it also unifies and simplifies the build logic 
>>>> for these directories, so that common code is executed for all 
>>>> modules to just copy any exported header files from these 
>>>> directories, should they exist.
>>>>
>>>> I'm intending to push this to jdk-hs.
>>>
>>> Do you want this in 10 or 11? If you want 10 then you need to push 
>>> to jdk/jdk as there may not be another snapshot from jdk/hs.
>> It was targeted at 11 in the JBS issue. I don't have a strong opinion 
>> on forcing this into JDK 10. Also, one of the fixes it depended on 
>> was not yet integrated from jdk/hs to jdk/jdk.
>>
>> But if you think it should go into JDK 10 and jdk/jdk, just let me 
>> know and I'll move the changeset there, and await the next jdk/hs -> 
>> jdk/jdk integration.
>
> Things are not quite working that way at the moment - see [1] - hs has 
> potentially taken its last snapshot before JDK 10 is forked. If this 
> must go into 10 then it has to be pushed direct to jdk/jdk. If it may 
> go in 10 or 11, then it can go into jdk/hs (and it will end up in 10 
> if there is a second snapshot, else 11). If it is only intended for 11 
> then it must not be pushed until after the Dec 14 fork of JDK 10.
>
> I have no opinion one way or the other.

It looks like > changes to jdk than hotspot so I'd pick 10 and pushing 
it to jdk/jdk.? I've retarged it to 10 in the bug.?? This looks like the 
end of a cleanup that would be nice to be all in the same release.

Coleen

>
> David
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029474.html
>
>> /Magnus
>>
>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>
>>>
>>>
>>>
>>> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the 
>>> flow on cleanups.
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> /Magnus
>>


From jesper.wilhelmsson at oracle.com  Mon Dec  4 14:04:54 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Mon, 4 Dec 2017 15:04:54 +0100
Subject: JDK 10 RDP1 vs the Hotspot repo
In-Reply-To: <1db75fd7-e171-1b53-92ba-67ea9daa867f@oracle.com>
References: <E2D6C03A-493E-489A-80DB-879F81311C44@oracle.com>
 <8E63962F-6143-4B2A-98FB-CB21CFF77797@oracle.com>
 <73E25C29-2566-43C0-9959-E9A6F94A6019@oracle.com>
 <1db75fd7-e171-1b53-92ba-67ea9daa867f@oracle.com>
Message-ID: <F9DD81C8-05B0-405D-84AF-604D614DF097@oracle.com>


> On 4 Dec 2017, at 02:58, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Jesper,
> 
> On 2/12/2017 6:36 AM, jesper.wilhelmsson at oracle.com wrote:
>> That's what I get for trying to make things look good...  Ok, now without HTML.
>> * P1-P3 bugfixes
>> -- Not affected by RDP1.
>> -- If pushed to jdk/hs between today and December 14 we will make sure they end up in JDK 10 eventually.
>> -- If pushed to jdk/hs after December 14 they become fixed in JDK 11 and it will be your own responsibility to backport them to JDK 10.
>> * RFEs and P4 - P5 bugs that MUST go into JDK 10
>> -- Push to jdk/hs before 8 pm PT today
>> -- or push directly to jdk/jdk before December 14.
> 
> If someone mistakenly pushes to hs after the deadline, but really intended the fix to be in 10, what should they do? Should they just do a direct import from jdk/hs to jdk/jdk ?
> 

Yes, a direct import is fine provided the change has been properly tested. Or notify me and I can make an adhoc snapshot before the fork to include the last fixes. After the fork has happened I will also go through all changes pushed to hs since our last integration. At this point I will make sure all P1-P3 bug fixes are pushed to the fork as well.

Thanks,
/Jesper

> Thanks,
> David
> 
>>    - Please note that this option requires that you test your change extensively as this will bypass all normal VM testing that is done in jdk/hs before changes propagates to jdk/jdk.
>> * JDK 11 changes
>> -- Do NOT push to any repository until after the fork on December 14.
>> /Jesper


From magnus.ihse.bursie at oracle.com  Mon Dec  4 15:45:52 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2017 16:45:52 +0100
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <168a5a98-9e15-8389-fbeb-d0cedf13a739@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <d8628ea9-5600-0812-f46d-a9516eb5bba6@oracle.com>
 <b86b75de-8ac3-ae70-05ce-6d221161adac@oracle.com>
 <168a5a98-9e15-8389-fbeb-d0cedf13a739@oracle.com>
Message-ID: <c535bc67-f77c-7a41-70c7-bc1aa068622e@oracle.com>

On 2017-12-04 13:56, David Holmes wrote:
> On 4/12/2017 10:44 PM, Magnus Ihse Bursie wrote:
>> On 2017-12-04 12:17, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
>>>> JDK-8190484 was created as a follow-up bug to the unification of 
>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>> location of these files. This has now been decided to be 
>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>
>>>> This patch moves the relevant files there, but since this also 
>>>> frees up the src/$MODULE/native/include directories for the 
>>>> original purpose, it also unifies and simplifies the build logic 
>>>> for these directories, so that common code is executed for all 
>>>> modules to just copy any exported header files from these 
>>>> directories, should they exist.
>>>>
>>>> I'm intending to push this to jdk-hs.
>>>
>>> Do you want this in 10 or 11? If you want 10 then you need to push 
>>> to jdk/jdk as there may not be another snapshot from jdk/hs.
>> It was targeted at 11 in the JBS issue. I don't have a strong opinion 
>> on forcing this into JDK 10. Also, one of the fixes it depended on 
>> was not yet integrated from jdk/hs to jdk/jdk.
>>
>> But if you think it should go into JDK 10 and jdk/jdk, just let me 
>> know and I'll move the changeset there, and await the next jdk/hs -> 
>> jdk/jdk integration.
>
> Things are not quite working that way at the moment - see [1] - hs has 
> potentially taken its last snapshot before JDK 10 is forked. If this 
> must go into 10 then it has to be pushed direct to jdk/jdk. If it may 
> go in 10 or 11, then it can go into jdk/hs (and it will end up in 10 
> if there is a second snapshot, else 11). If it is only intended for 11 
> then it must not be pushed until after the Dec 14 fork of JDK 10.
>
> I have no opinion one way or the other.

This patch requires a fix which is currently only in jdk/hs. I can push 
this to jdk/jdk instead, but only after that fix has been pushed from 
jdk/hs to jdk/jdk. From the mail you sent, it seems like it can 
potentially take all the time up until Dec 14. If that happens, I can't 
get this in jdk 10 no matter what I do. But I can hold on for a while 
and see if jdk/hs ends up in jdk/jdk in time before Dec 14, and if so, 
push this fix there. If it doesn't, well, seems like there's no chance 
this can get in jdk 10 whatever.

I don't think it's "intended" for 11 as much as it's a problem if it 
goes into 10, more than that someone at some point thought there would 
not be time left to fix it in jdk 10 and re-targeted it at 11. 
(Something which I didn't notice until after I written the patch.)

/Magnus


>
> David
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029474.html
>
>> /Magnus
>>
>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>
>>>
>>>
>>>
>>> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the 
>>> flow on cleanups.
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> /Magnus
>>


From tobias.hartmann at oracle.com  Mon Dec  4 16:42:50 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 4 Dec 2017 17:42:50 +0100
Subject: [10] RFR(S): 8191360: Lookup of critical JNI method causes duplicate
 library loading with leaking handler
Message-ID: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>

Hi,

please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8191360
http://cr.openjdk.java.net/~thartmann/8191360/webrev.00/

When creating a native wrapper, the compiler checks the shared library for a critical version of the native method
(-XX:+CriticalJNINatives, see comments in JDK-7013347 [1]) that can be called with reduced overhead. This is done in
NativeLookup::lookup_critical_style() with a call to dll_load() to get a handle to the (already loaded) library and a
subsequent call to dll_lookup() to get the entry address of the critical version.

The problem is that without a call to dll_unload(), this handle to the library will stay live and internal reference
counting will prevent the library from ever being unloaded (even if the native method holder is unloaded). As a result,
static fields in the library code are not reset, causing the NativeLibraryTest to fail due to unexpected field values
once the library is loaded again.

I've fixed this by closing the handle immediately after retrieving the critical entry address. This is fine because the
library is still kept alive by JNI (see JVM_LoadLibrary). As soon as the holder class and the library are unloaded (see
JVM_UnloadLibrary), the native wrapper that calls 'critical_entry' becomes unreachable and is unloaded as well.

I've also thought about passing 'RTLD_NOLOAD' to dlopen [2] but although that avoids loading the library, it still
creates a handle (that needs to be closed) if the library is already loaded.

Tested with failing test and Mach 5 hs-tier1, hs-tier2, hs-precheckin-comp (running).

Thanks,
Tobias

[1] https://bugs.openjdk.java.net/browse/JDK-7013347
[2] https://linux.die.net/man/3/dlopen

From erik.joelsson at oracle.com  Mon Dec  4 17:33:13 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 4 Dec 2017 09:33:13 -0800
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
Message-ID: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>

Hello Magnus,

The <module>-copy targets are currently only being generated for modules 
that have make/copy/Copy-<module>.gmk makefiles present. By removing 
make/copy/Copy-jdk.accessibility.gmk and 
make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer created 
so the logic in CopyCommon will not be executed.

This can be solved in two ways. Either generate <module>-copy rules for 
all modules or leave the files there with just include CopyCommon.gmk as 
the only contents. I would recommend the latter for now. Most modules do 
not need to copy anything.

Another minor note, when ordering include directories, I usually put the 
most specific dir first, so that any platform specific header file with 
the same name would override a more general one. We don't have that 
situation in this case, but I still think it's good practice.

Regarding where to push this. IMO, if it depends on a change currently 
in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't really 
matter that much.

/Erik


On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
> JDK-8190484 was created as a follow-up bug to the unification of the 
> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location 
> of these files. This has now been decided to be hotspot/share/include 
> and hotspot/os/$OS/include, respectively.
>
> This patch moves the relevant files there, but since this also frees 
> up the src/$MODULE/native/include directories for the original 
> purpose, it also unifies and simplifies the build logic for these 
> directories, so that common code is executed for all modules to just 
> copy any exported header files from these directories, should they exist.
>
> I'm intending to push this to jdk-hs.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>
> /Magnus


From mandy.chung at oracle.com  Mon Dec  4 18:17:25 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 4 Dec 2017 10:17:25 -0800
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
Message-ID: <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>



On 12/4/17 9:33 AM, Erik Joelsson wrote:
> Hello Magnus,
>
> The <module>-copy targets are currently only being generated for 
> modules that have make/copy/Copy-<module>.gmk makefiles present. By 
> removing make/copy/Copy-jdk.accessibility.gmk and 
> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer created 
> so the logic in CopyCommon will not be executed.
>
> This can be solved in two ways. Either generate <module>-copy rules 
> for all modules or leave the files there with just include 
> CopyCommon.gmk as the only contents. I would recommend the latter for 
> now. Most modules do not need to copy anything.

Is it possible to generate <module>-copy rules for module where 
src/<module>/{share, $OS}/include directory or 
make/copy/Copy-<module>.gmk is present?
>
> Another minor note, when ordering include directories, I usually put 
> the most specific dir first, so that any platform specific header file 
> with the same name would override a more general one. We don't have 
> that situation in this case, but I still think it's good practice.
>
> Regarding where to push this. IMO, if it depends on a change currently 
> in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't really 
> matter that much.
>

I would love this in JDK 10 if time permits and I am happy to see Coleen 
retarget it to 10.? This is a really nice clean up that shows the 
benefit from JEP 201 w.r.t. exported native header files.?? But this is 
not a must for JDK 10 and if it can't make 10, it's okay for 11.

Mandy


> /Erik
>
>
> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>> JDK-8190484 was created as a follow-up bug to the unification of the 
>> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>> location of these files. This has now been decided to be 
>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>
>> This patch moves the relevant files there, but since this also frees 
>> up the src/$MODULE/native/include directories for the original 
>> purpose, it also unifies and simplifies the build logic for these 
>> directories, so that common code is executed for all modules to just 
>> copy any exported header files from these directories, should they 
>> exist.
>>
>> I'm intending to push this to jdk-hs.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>>
>> /Magnus
>


From vladimir.x.ivanov at oracle.com  Mon Dec  4 18:35:11 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 4 Dec 2017 21:35:11 +0300
Subject: [10] RFR(S): 8191360: Lookup of critical JNI method causes
 duplicate library loading with leaking handler
In-Reply-To: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>
References: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>
Message-ID: <95baef7d-dbe7-ca5c-4077-d50df1ad7e29@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

PS: I'd prefer to see library-related code factored out and the library 
handle shared among 4 consecutive calls in NL::lookup_critical_entry(). 
But if you think it's too intrusive for the fix, please, file an RFE.

On 12/4/17 7:42 PM, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8191360
> http://cr.openjdk.java.net/~thartmann/8191360/webrev.00/
> 
> When creating a native wrapper, the compiler checks the shared library for a critical version of the native method
> (-XX:+CriticalJNINatives, see comments in JDK-7013347 [1]) that can be called with reduced overhead. This is done in
> NativeLookup::lookup_critical_style() with a call to dll_load() to get a handle to the (already loaded) library and a
> subsequent call to dll_lookup() to get the entry address of the critical version.
> 
> The problem is that without a call to dll_unload(), this handle to the library will stay live and internal reference
> counting will prevent the library from ever being unloaded (even if the native method holder is unloaded). As a result,
> static fields in the library code are not reset, causing the NativeLibraryTest to fail due to unexpected field values
> once the library is loaded again.
> 
> I've fixed this by closing the handle immediately after retrieving the critical entry address. This is fine because the
> library is still kept alive by JNI (see JVM_LoadLibrary). As soon as the holder class and the library are unloaded (see
> JVM_UnloadLibrary), the native wrapper that calls 'critical_entry' becomes unreachable and is unloaded as well.
> 
> I've also thought about passing 'RTLD_NOLOAD' to dlopen [2] but although that avoids loading the library, it still
> creates a handle (that needs to be closed) if the library is already loaded.
> 
> Tested with failing test and Mach 5 hs-tier1, hs-tier2, hs-precheckin-comp (running).
> 
> Thanks,
> Tobias
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-7013347
> [2] https://linux.die.net/man/3/dlopen
> 

From magnus.ihse.bursie at oracle.com  Mon Dec  4 20:40:33 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2017 21:40:33 +0100
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
Message-ID: <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>

On 2017-12-04 19:17, mandy chung wrote:
>
>
> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>> Hello Magnus,
>>
>> The <module>-copy targets are currently only being generated for 
>> modules that have make/copy/Copy-<module>.gmk makefiles present. By 
>> removing make/copy/Copy-jdk.accessibility.gmk and 
>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer 
>> created so the logic in CopyCommon will not be executed.
>>
>> This can be solved in two ways. Either generate <module>-copy rules 
>> for all modules or leave the files there with just include 
>> CopyCommon.gmk as the only contents. I would recommend the latter for 
>> now. Most modules do not need to copy anything.
>
> Is it possible to generate <module>-copy rules for module where 
> src/<module>/{share, $OS}/include directory or 
> make/copy/Copy-<module>.gmk is present?
Technically, it's of course possible. But it does not fit very well with 
the current DeclareRecipesForPhase. I agree with Erik, that for now the 
reasonable approach is to have files that only include CopyCommon. We 
can consider for future updates if it's worth generalizing this.

Updated webrev that restores the removed Copy-$MODULE.gmk files:
http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02

>>
>> Another minor note, when ordering include directories, I usually put 
>> the most specific dir first, so that any platform specific header 
>> file with the same name would override a more general one. We don't 
>> have that situation in this case, but I still think it's good practice.
>>
>> Regarding where to push this. IMO, if it depends on a change 
>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't 
>> really matter that much.
>>
>
> I would love this in JDK 10 if time permits and I am happy to see 
> Coleen retarget it to 10.? This is a really nice clean up that shows 
> the benefit from JEP 201 w.r.t. exported native header files.?? But 
> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.

Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon as 
the needed fixes are integrated from jdk/hs.

/Magnus

>
> Mandy
>
>
>> /Erik
>>
>>
>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>>> JDK-8190484 was created as a follow-up bug to the unification of the 
>>> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>> location of these files. This has now been decided to be 
>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>
>>> This patch moves the relevant files there, but since this also frees 
>>> up the src/$MODULE/native/include directories for the original 
>>> purpose, it also unifies and simplifies the build logic for these 
>>> directories, so that common code is executed for all modules to just 
>>> copy any exported header files from these directories, should they 
>>> exist.
>>>
>>> I'm intending to push this to jdk-hs.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>>>
>>> /Magnus
>>
>


From dean.long at oracle.com  Mon Dec  4 20:48:50 2017
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Mon, 4 Dec 2017 12:48:50 -0800
Subject: RFR(XS) 8192870: [Testbug] runtime/handshake/HandshakeTransitionTest
 throws NPE
Message-ID: <dc94debc-9bbb-19bb-dcbc-697dd129cdff@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8192870
http://cr.openjdk.java.net/~dlong/8192870/webrev/

When we query WhiteBox.getBooleanVMFlag("UseJVMCICompiler"), we need to 
check for null, in case JVMCI is not included in the build.

dl

From mandy.chung at oracle.com  Mon Dec  4 20:59:08 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 4 Dec 2017 12:59:08 -0800
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
 <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
Message-ID: <b4ef1f49-83f6-8294-afed-223d81f678ec@oracle.com>



On 12/4/17 12:40 PM, Magnus Ihse Bursie wrote:
> Technically, it's of course possible. But it does not fit very well 
> with the current DeclareRecipesForPhase. I agree with Erik, that for 
> now the reasonable approach is to have files that only include 
> CopyCommon. We can consider for future updates if it's worth 
> generalizing this.
>

Okay with me. ? It'd be good if we can consider this in the future so 
that it avoids creating Copy-<module>.gmk for just the include header case.

> Updated webrev that restores the removed Copy-$MODULE.gmk files:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>
>

Looks good.
>
> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon 
> as the needed fixes are integrated from jdk/hs.
>

Thank you.

Mandy


From coleen.phillimore at oracle.com  Mon Dec  4 21:01:03 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 4 Dec 2017 16:01:03 -0500
Subject: Result: New hotspot Group Member: Per Liden
Message-ID: <96d5b7c5-07cf-8808-ae1b-adcdafe97226@oracle.com>

The vote for Per Liden [1] is now closed.

Yes: 11
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Coleen Phillimore

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029140.html

From coleen.phillimore at oracle.com  Mon Dec  4 21:02:50 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 4 Dec 2017 16:02:50 -0500
Subject: Result: New hotspot Group Member: Kim Barrett
Message-ID: <c2f26d0c-3781-940c-f24b-f55d1f046a80@oracle.com>

The vote for Kim Barrett [1] is now closed.

Yes: 11
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Coleen Phillimore

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029147.html

From coleen.phillimore at oracle.com  Mon Dec  4 21:04:02 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 4 Dec 2017 16:04:02 -0500
Subject: Result: New hotspot Group Member: Per Liden
In-Reply-To: <96d5b7c5-07cf-8808-ae1b-adcdafe97226@oracle.com>
References: <96d5b7c5-07cf-8808-ae1b-adcdafe97226@oracle.com>
Message-ID: <108b1750-fb32-6ebc-7aee-ec05cac507d5@oracle.com>

including registrar.

On 12/4/17 4:01 PM, coleen.phillimore at oracle.com wrote:
> The vote for Per Liden [1] is now closed.
>
> Yes: 11
> Veto: 0
> Abstain: 0
>
> According to the Bylaws definition of Lazy Consensus, this is 
> sufficient to approve the nomination.
>
> Coleen Phillimore
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029140.html


From coleen.phillimore at oracle.com  Mon Dec  4 21:04:42 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 4 Dec 2017 16:04:42 -0500
Subject: Result: New hotspot Group Member: Kim Barrett
In-Reply-To: <c2f26d0c-3781-940c-f24b-f55d1f046a80@oracle.com>
References: <c2f26d0c-3781-940c-f24b-f55d1f046a80@oracle.com>
Message-ID: <f4c578f7-663f-417e-4ac1-6701d72f65e4@oracle.com>

Including registrar.

On 12/4/17 4:02 PM, coleen.phillimore at oracle.com wrote:
> The vote for Kim Barrett [1] is now closed.
>
> Yes: 11
> Veto: 0
> Abstain: 0
>
> According to the Bylaws definition of Lazy Consensus, this is 
> sufficient to approve the nomination.
>
> Coleen Phillimore
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029147.html


From erik.joelsson at oracle.com  Mon Dec  4 21:26:16 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 4 Dec 2017 13:26:16 -0800
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
 <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
Message-ID: <604642c5-ca4f-4692-39a9-d1fa9fd73c8d@oracle.com>

Looks good.

/Erik


On 2017-12-04 12:40, Magnus Ihse Bursie wrote:
> On 2017-12-04 19:17, mandy chung wrote:
>>
>>
>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>> Hello Magnus,
>>>
>>> The <module>-copy targets are currently only being generated for 
>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By 
>>> removing make/copy/Copy-jdk.accessibility.gmk and 
>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer 
>>> created so the logic in CopyCommon will not be executed.
>>>
>>> This can be solved in two ways. Either generate <module>-copy rules 
>>> for all modules or leave the files there with just include 
>>> CopyCommon.gmk as the only contents. I would recommend the latter 
>>> for now. Most modules do not need to copy anything.
>>
>> Is it possible to generate <module>-copy rules for module where 
>> src/<module>/{share, $OS}/include directory or 
>> make/copy/Copy-<module>.gmk is present?
> Technically, it's of course possible. But it does not fit very well 
> with the current DeclareRecipesForPhase. I agree with Erik, that for 
> now the reasonable approach is to have files that only include 
> CopyCommon. We can consider for future updates if it's worth 
> generalizing this.
>
> Updated webrev that restores the removed Copy-$MODULE.gmk files:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>
>
>>>
>>> Another minor note, when ordering include directories, I usually put 
>>> the most specific dir first, so that any platform specific header 
>>> file with the same name would override a more general one. We don't 
>>> have that situation in this case, but I still think it's good practice.
>>>
>>> Regarding where to push this. IMO, if it depends on a change 
>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 
>>> doesn't really matter that much.
>>>
>>
>> I would love this in JDK 10 if time permits and I am happy to see 
>> Coleen retarget it to 10.? This is a really nice clean up that shows 
>> the benefit from JEP 201 w.r.t. exported native header files.?? But 
>> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.
>
> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon 
> as the needed fixes are integrated from jdk/hs.
>
> /Magnus
>
>>
>> Mandy
>>
>>
>>> /Erik
>>>
>>>
>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>>>> JDK-8190484 was created as a follow-up bug to the unification of 
>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>> location of these files. This has now been decided to be 
>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>
>>>> This patch moves the relevant files there, but since this also 
>>>> frees up the src/$MODULE/native/include directories for the 
>>>> original purpose, it also unifies and simplifies the build logic 
>>>> for these directories, so that common code is executed for all 
>>>> modules to just copy any exported header files from these 
>>>> directories, should they exist.
>>>>
>>>> I'm intending to push this to jdk-hs.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>>>>
>>>> /Magnus
>>>
>>
>


From david.holmes at oracle.com  Mon Dec  4 21:46:35 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 07:46:35 +1000
Subject: [10] RFR(S): 8191360: Lookup of critical JNI method causes
 duplicate library loading with leaking handler
In-Reply-To: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>
References: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>
Message-ID: <5b0d88b5-096c-005e-e898-8bc55577a557@oracle.com>

Hi Tobias,

On 5/12/2017 2:42 AM, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8191360
> http://cr.openjdk.java.net/~thartmann/8191360/webrev.00/

The actual fix seems fine.

I'm unclear why you added the critical entry to 
test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c ?? 
The impact of that on the test is not clear to me. It also obscures 
whether the test is fixed just by the actual fix.

I agree with Vladimir that there is scope for being more efficient with 
the library handling in this code, but that's future work.

Thanks,
David

> When creating a native wrapper, the compiler checks the shared library for a critical version of the native method
> (-XX:+CriticalJNINatives, see comments in JDK-7013347 [1]) that can be called with reduced overhead. This is done in
> NativeLookup::lookup_critical_style() with a call to dll_load() to get a handle to the (already loaded) library and a
> subsequent call to dll_lookup() to get the entry address of the critical version.
> 
> The problem is that without a call to dll_unload(), this handle to the library will stay live and internal reference
> counting will prevent the library from ever being unloaded (even if the native method holder is unloaded). As a result,
> static fields in the library code are not reset, causing the NativeLibraryTest to fail due to unexpected field values
> once the library is loaded again.
> 
> I've fixed this by closing the handle immediately after retrieving the critical entry address. This is fine because the
> library is still kept alive by JNI (see JVM_LoadLibrary). As soon as the holder class and the library are unloaded (see
> JVM_UnloadLibrary), the native wrapper that calls 'critical_entry' becomes unreachable and is unloaded as well.
> 
> I've also thought about passing 'RTLD_NOLOAD' to dlopen [2] but although that avoids loading the library, it still
> creates a handle (that needs to be closed) if the library is already loaded.
> 
> Tested with failing test and Mach 5 hs-tier1, hs-tier2, hs-precheckin-comp (running).
> 
> Thanks,
> Tobias
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-7013347
> [2] https://linux.die.net/man/3/dlopen
> 

From david.holmes at oracle.com  Mon Dec  4 22:07:22 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 08:07:22 +1000
Subject: RFR(XS) 8192870: [Testbug]
 runtime/handshake/HandshakeTransitionTest throws NPE
In-Reply-To: <dc94debc-9bbb-19bb-dcbc-697dd129cdff@oracle.com>
References: <dc94debc-9bbb-19bb-dcbc-697dd129cdff@oracle.com>
Message-ID: <95ed2582-303e-25f6-5760-941342801b82@oracle.com>

Hi Dean,

On 5/12/2017 6:48 AM, dean.long at oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8192870
> http://cr.openjdk.java.net/~dlong/8192870/webrev/
> 
> When we query WhiteBox.getBooleanVMFlag("UseJVMCICompiler"), we need to 
> check for null, in case JVMCI is not included in the build.

Looks good.

Thanks,
David

> dl

From david.holmes at oracle.com  Mon Dec  4 23:28:47 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 09:28:47 +1000
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
 <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
Message-ID: <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com>

Hi Magnus,

There may be a further wart here to resolve. From the "bump the 
classfile version to 54" thread on jdk-dev:

---

 >>>> Don't you also need to update:
 >>>>
 >>>> jdk/src/java.base/share/native/include/classfile_constants.h
 >>>>
 >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53
 >>>>
 >>> I cannot find any usages for this constant, nor 
JVM_CLASSFILE_MINOR_VERSION. I will remove them.
 >>
 >> Okay. I don't know the history or use of this file, other than it 
gets included into jvm.h to export the jvm interface to the jdk.
 >>
 >
> And classfile_constants.h is also distributed with the image. I am
> unsure of the intent/history. To play it safe i will just bump the
> number.
Hmmm - that seems wrong. jvm.h is not an exported external interface 
AFAIK. And we just moved it so I don't think it will get distributed any 
more. Hmm that also suggests that classfile_constants.h may be in the 
wrong place ... I'll take this up elsewhere.

---

So is classfile_constants.h also in the wrong place? And should it be in 
the image ??

David

On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote:
> On 2017-12-04 19:17, mandy chung wrote:
>>
>>
>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>> Hello Magnus,
>>>
>>> The <module>-copy targets are currently only being generated for 
>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By 
>>> removing make/copy/Copy-jdk.accessibility.gmk and 
>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer 
>>> created so the logic in CopyCommon will not be executed.
>>>
>>> This can be solved in two ways. Either generate <module>-copy rules 
>>> for all modules or leave the files there with just include 
>>> CopyCommon.gmk as the only contents. I would recommend the latter for 
>>> now. Most modules do not need to copy anything.
>>
>> Is it possible to generate <module>-copy rules for module where 
>> src/<module>/{share, $OS}/include directory or 
>> make/copy/Copy-<module>.gmk is present?
> Technically, it's of course possible. But it does not fit very well with 
> the current DeclareRecipesForPhase. I agree with Erik, that for now the 
> reasonable approach is to have files that only include CopyCommon. We 
> can consider for future updates if it's worth generalizing this.
> 
> Updated webrev that restores the removed Copy-$MODULE.gmk files:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
> 
> 
>>>
>>> Another minor note, when ordering include directories, I usually put 
>>> the most specific dir first, so that any platform specific header 
>>> file with the same name would override a more general one. We don't 
>>> have that situation in this case, but I still think it's good practice.
>>>
>>> Regarding where to push this. IMO, if it depends on a change 
>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't 
>>> really matter that much.
>>>
>>
>> I would love this in JDK 10 if time permits and I am happy to see 
>> Coleen retarget it to 10.? This is a really nice clean up that shows 
>> the benefit from JEP 201 w.r.t. exported native header files.?? But 
>> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.
> 
> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon as 
> the needed fixes are integrated from jdk/hs.
> 
> /Magnus
> 
>>
>> Mandy
>>
>>
>>> /Erik
>>>
>>>
>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>>>> JDK-8190484 was created as a follow-up bug to the unification of the 
>>>> duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>> location of these files. This has now been decided to be 
>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>
>>>> This patch moves the relevant files there, but since this also frees 
>>>> up the src/$MODULE/native/include directories for the original 
>>>> purpose, it also unifies and simplifies the build logic for these 
>>>> directories, so that common code is executed for all modules to just 
>>>> copy any exported header files from these directories, should they 
>>>> exist.
>>>>
>>>> I'm intending to push this to jdk-hs.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>
>>>>
>>>> /Magnus
>>>
>>
> 

From magnus.ihse.bursie at oracle.com  Mon Dec  4 23:59:09 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2017 00:59:09 +0100
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
 <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
 <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com>
Message-ID: <e0eaf9f5-e2bc-15a0-32fe-40b68c8d5ebc@oracle.com>

On 2017-12-05 00:28, David Holmes wrote:
> Hi Magnus,
>
> There may be a further wart here to resolve. 
But of course...

> From the "bump the classfile version to 54" thread on jdk-dev:
>
> ---
>
> >>>> Don't you also need to update:
> >>>>
> >>>> jdk/src/java.base/share/native/include/classfile_constants.h
> >>>>
> >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53
> >>>>
> >>> I cannot find any usages for this constant, nor 
> JVM_CLASSFILE_MINOR_VERSION. I will remove them.
> >>
> >> Okay. I don't know the history or use of this file, other than it 
> gets included into jvm.h to export the jvm interface to the jdk.
> >>
> >
>> And classfile_constants.h is also distributed with the image. I am
>> unsure of the intent/history. To play it safe i will just bump the
>> number.
> Hmmm - that seems wrong. jvm.h is not an exported external interface 
> AFAIK. And we just moved it so I don't think it will get distributed 
> any more. Hmm that also suggests that classfile_constants.h may be in 
> the wrong place ... I'll take this up elsewhere.
>
> ---
>
> So is classfile_constants.h also in the wrong place? And should it be 
> in the image ??

It sounds like it. :( It's only included from jvm.h (and 
src/java.base/share/native/libverify/check_code.c) as far as I can tell. 
So it should probably move with jvm.h.

The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper 
promised me to make sure it ended up in jdk/jdk before RDP1). The good 
news is that just moving classfile_constants.h is probably simple, I 
assume all include paths are already correct.

Can you open a new bug (and/or handle it all by yourself)?

/Magnus

>
> David
>
> On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote:
>> On 2017-12-04 19:17, mandy chung wrote:
>>>
>>>
>>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>>> Hello Magnus,
>>>>
>>>> The <module>-copy targets are currently only being generated for 
>>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By 
>>>> removing make/copy/Copy-jdk.accessibility.gmk and 
>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer 
>>>> created so the logic in CopyCommon will not be executed.
>>>>
>>>> This can be solved in two ways. Either generate <module>-copy rules 
>>>> for all modules or leave the files there with just include 
>>>> CopyCommon.gmk as the only contents. I would recommend the latter 
>>>> for now. Most modules do not need to copy anything.
>>>
>>> Is it possible to generate <module>-copy rules for module where 
>>> src/<module>/{share, $OS}/include directory or 
>>> make/copy/Copy-<module>.gmk is present?
>> Technically, it's of course possible. But it does not fit very well 
>> with the current DeclareRecipesForPhase. I agree with Erik, that for 
>> now the reasonable approach is to have files that only include 
>> CopyCommon. We can consider for future updates if it's worth 
>> generalizing this.
>>
>> Updated webrev that restores the removed Copy-$MODULE.gmk files:
>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>>
>>
>>>>
>>>> Another minor note, when ordering include directories, I usually 
>>>> put the most specific dir first, so that any platform specific 
>>>> header file with the same name would override a more general one. 
>>>> We don't have that situation in this case, but I still think it's 
>>>> good practice.
>>>>
>>>> Regarding where to push this. IMO, if it depends on a change 
>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 
>>>> doesn't really matter that much.
>>>>
>>>
>>> I would love this in JDK 10 if time permits and I am happy to see 
>>> Coleen retarget it to 10.? This is a really nice clean up that shows 
>>> the benefit from JEP 201 w.r.t. exported native header files.?? But 
>>> this is not a must for JDK 10 and if it can't make 10, it's okay for 
>>> 11.
>>
>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon 
>> as the needed fixes are integrated from jdk/hs.
>>
>> /Magnus
>>
>>>
>>> Mandy
>>>
>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>>>>> JDK-8190484 was created as a follow-up bug to the unification of 
>>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>>> location of these files. This has now been decided to be 
>>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>>
>>>>> This patch moves the relevant files there, but since this also 
>>>>> frees up the src/$MODULE/native/include directories for the 
>>>>> original purpose, it also unifies and simplifies the build logic 
>>>>> for these directories, so that common code is executed for all 
>>>>> modules to just copy any exported header files from these 
>>>>> directories, should they exist.
>>>>>
>>>>> I'm intending to push this to jdk-hs.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>>> WebRev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>>
>>>>>
>>>>> /Magnus
>>>>
>>>
>>


From mandy.chung at oracle.com  Tue Dec  5 00:13:12 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 4 Dec 2017 16:13:12 -0800
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <e0eaf9f5-e2bc-15a0-32fe-40b68c8d5ebc@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
 <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
 <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com>
 <e0eaf9f5-e2bc-15a0-32fe-40b68c8d5ebc@oracle.com>
Message-ID: <04878fa7-e896-92b0-2fb9-b64c541928ca@oracle.com>



On 12/4/17 3:59 PM, Magnus Ihse Bursie wrote:
>
>>> And classfile_constants.h is also distributed with the image. I am
>>> unsure of the intent/history. To play it safe i will just bump the
>>> number.
>> Hmmm - that seems wrong. jvm.h is not an exported external interface 
>> AFAIK. And we just moved it so I don't think it will get distributed 
>> any more. Hmm that also suggests that classfile_constants.h may be in 
>> the wrong place ... I'll take this up elsewhere.
>>
>> ---
>>
>> So is classfile_constants.h also in the wrong place? And should it be 
>> in the image ??
>
> It sounds like it. :( It's only included from jvm.h (and 
> src/java.base/share/native/libverify/check_code.c) as far as I can 
> tell. So it should probably move with jvm.h.
>
> The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper 
> promised me to make sure it ended up in jdk/jdk before RDP1). The good 
> news is that just moving classfile_constants.h is probably simple, I 
> assume all include paths are already correct.
>
> Can you open a new bug (and/or handle it all by yourself)?
>

classfile_constants.h was added to ${java.home}/include in JDK 6 [1] as 
an exported interface. ? It was intended for BCI native agent to use.? 
With the removal of JVM TI demos, I think we should revisit if 
classfile_constants.h should be distributed.

As far as JDK-8190484, the changeset adequately covers the non-exported 
header files.

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

From david.holmes at oracle.com  Tue Dec  5 00:13:46 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 10:13:46 +1000
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <e0eaf9f5-e2bc-15a0-32fe-40b68c8d5ebc@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
 <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
 <1c29c2e4-ee8a-03ba-9560-5f9d0f8b4fdc@oracle.com>
 <e0eaf9f5-e2bc-15a0-32fe-40b68c8d5ebc@oracle.com>
Message-ID: <4015e9cd-d4fe-b098-efe3-cc7f72b2d1b1@oracle.com>

On 5/12/2017 9:59 AM, Magnus Ihse Bursie wrote:
> On 2017-12-05 00:28, David Holmes wrote:
>> Hi Magnus,
>>
>> There may be a further wart here to resolve. 
> But of course...
> 
>> From the "bump the classfile version to 54" thread on jdk-dev:
>>
>> ---
>>
>> >>>> Don't you also need to update:
>> >>>>
>> >>>> jdk/src/java.base/share/native/include/classfile_constants.h
>> >>>>
>> >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53
>> >>>>
>> >>> I cannot find any usages for this constant, nor 
>> JVM_CLASSFILE_MINOR_VERSION. I will remove them.
>> >>
>> >> Okay. I don't know the history or use of this file, other than it 
>> gets included into jvm.h to export the jvm interface to the jdk.
>> >>
>> >
>>> And classfile_constants.h is also distributed with the image. I am
>>> unsure of the intent/history. To play it safe i will just bump the
>>> number.
>> Hmmm - that seems wrong. jvm.h is not an exported external interface 
>> AFAIK. And we just moved it so I don't think it will get distributed 
>> any more. Hmm that also suggests that classfile_constants.h may be in 
>> the wrong place ... I'll take this up elsewhere.
>>
>> ---
>>
>> So is classfile_constants.h also in the wrong place? And should it be 
>> in the image ??
> 
> It sounds like it. :( It's only included from jvm.h (and 
> src/java.base/share/native/libverify/check_code.c) as far as I can tell. 
> So it should probably move with jvm.h.
> 
> The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper 
> promised me to make sure it ended up in jdk/jdk before RDP1). The good 
> news is that just moving classfile_constants.h is probably simple, I 
> assume all include paths are already correct.
> 
> Can you open a new bug (and/or handle it all by yourself)?

No need - Mandy just clarified this:

 > classfile_constants.h was added to ${java.home}/include in JDK 6 [1].
 > It was intended for BCI native agent to use.
 >
 > Mandy
 > [1] https://bugs.openjdk.java.net/browse/JDK-5107600

so that file should be co-located with jni.h and distributed in the image.

Thanks,
David

> /Magnus
> 
>>
>> David
>>
>> On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote:
>>> On 2017-12-04 19:17, mandy chung wrote:
>>>>
>>>>
>>>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>>>> Hello Magnus,
>>>>>
>>>>> The <module>-copy targets are currently only being generated for 
>>>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By 
>>>>> removing make/copy/Copy-jdk.accessibility.gmk and 
>>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer 
>>>>> created so the logic in CopyCommon will not be executed.
>>>>>
>>>>> This can be solved in two ways. Either generate <module>-copy rules 
>>>>> for all modules or leave the files there with just include 
>>>>> CopyCommon.gmk as the only contents. I would recommend the latter 
>>>>> for now. Most modules do not need to copy anything.
>>>>
>>>> Is it possible to generate <module>-copy rules for module where 
>>>> src/<module>/{share, $OS}/include directory or 
>>>> make/copy/Copy-<module>.gmk is present?
>>> Technically, it's of course possible. But it does not fit very well 
>>> with the current DeclareRecipesForPhase. I agree with Erik, that for 
>>> now the reasonable approach is to have files that only include 
>>> CopyCommon. We can consider for future updates if it's worth 
>>> generalizing this.
>>>
>>> Updated webrev that restores the removed Copy-$MODULE.gmk files:
>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>>>
>>>
>>>>>
>>>>> Another minor note, when ordering include directories, I usually 
>>>>> put the most specific dir first, so that any platform specific 
>>>>> header file with the same name would override a more general one. 
>>>>> We don't have that situation in this case, but I still think it's 
>>>>> good practice.
>>>>>
>>>>> Regarding where to push this. IMO, if it depends on a change 
>>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 
>>>>> doesn't really matter that much.
>>>>>
>>>>
>>>> I would love this in JDK 10 if time permits and I am happy to see 
>>>> Coleen retarget it to 10.? This is a really nice clean up that shows 
>>>> the benefit from JEP 201 w.r.t. exported native header files.?? But 
>>>> this is not a must for JDK 10 and if it can't make 10, it's okay for 
>>>> 11.
>>>
>>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon 
>>> as the needed fixes are integrated from jdk/hs.
>>>
>>> /Magnus
>>>
>>>>
>>>> Mandy
>>>>
>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>>>>>> JDK-8190484 was created as a follow-up bug to the unification of 
>>>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>>>> location of these files. This has now been decided to be 
>>>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>>>
>>>>>> This patch moves the relevant files there, but since this also 
>>>>>> frees up the src/$MODULE/native/include directories for the 
>>>>>> original purpose, it also unifies and simplifies the build logic 
>>>>>> for these directories, so that common code is executed for all 
>>>>>> modules to just copy any exported header files from these 
>>>>>> directories, should they exist.
>>>>>>
>>>>>> I'm intending to push this to jdk-hs.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>>>> WebRev: 
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>
>>>>
>>>
> 

From dean.long at oracle.com  Tue Dec  5 03:04:37 2017
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Mon, 4 Dec 2017 19:04:37 -0800
Subject: RFR(XS) 8192870: [Testbug]
 runtime/handshake/HandshakeTransitionTest throws NPE
In-Reply-To: <95ed2582-303e-25f6-5760-941342801b82@oracle.com>
References: <dc94debc-9bbb-19bb-dcbc-697dd129cdff@oracle.com>
 <95ed2582-303e-25f6-5760-941342801b82@oracle.com>
Message-ID: <be2718c3-cd82-a12c-de35-3d566b136066@oracle.com>

Thanks David.

dl


On 12/4/17 2:07 PM, David Holmes wrote:
> Hi Dean,
>
> On 5/12/2017 6:48 AM, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8192870
>> http://cr.openjdk.java.net/~dlong/8192870/webrev/
>>
>> When we query WhiteBox.getBooleanVMFlag("UseJVMCICompiler"), we need 
>> to check for null, in case JVMCI is not included in the build.
>
> Looks good.
>
> Thanks,
> David
>
>> dl


From david.holmes at oracle.com  Tue Dec  5 05:59:31 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 15:59:31 +1000
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <604642c5-ca4f-4692-39a9-d1fa9fd73c8d@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
 <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
 <604642c5-ca4f-4692-39a9-d1fa9fd73c8d@oracle.com>
Message-ID: <8ad0e61f-ec60-8deb-2fa0-127cb9ebd58b@oracle.com>

Magnus,

It seems these changes have broken all Windows builds:

Copying support/modules_include/jdk.accessibility/win32/bridge
/usr/bin/cp -fP 
'/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge' 
'/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge'
/usr/bin/cp: omitting directory 
'/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge'
CopyCommon.gmk:62: recipe for target 
'/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge' 
failed
make[3]: *** 
[/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge] 
Error 1

David
-----

On 5/12/2017 7:26 AM, Erik Joelsson wrote:
> Looks good.
> 
> /Erik
> 
> 
> On 2017-12-04 12:40, Magnus Ihse Bursie wrote:
>> On 2017-12-04 19:17, mandy chung wrote:
>>>
>>>
>>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>>> Hello Magnus,
>>>>
>>>> The <module>-copy targets are currently only being generated for 
>>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By 
>>>> removing make/copy/Copy-jdk.accessibility.gmk and 
>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer 
>>>> created so the logic in CopyCommon will not be executed.
>>>>
>>>> This can be solved in two ways. Either generate <module>-copy rules 
>>>> for all modules or leave the files there with just include 
>>>> CopyCommon.gmk as the only contents. I would recommend the latter 
>>>> for now. Most modules do not need to copy anything.
>>>
>>> Is it possible to generate <module>-copy rules for module where 
>>> src/<module>/{share, $OS}/include directory or 
>>> make/copy/Copy-<module>.gmk is present?
>> Technically, it's of course possible. But it does not fit very well 
>> with the current DeclareRecipesForPhase. I agree with Erik, that for 
>> now the reasonable approach is to have files that only include 
>> CopyCommon. We can consider for future updates if it's worth 
>> generalizing this.
>>
>> Updated webrev that restores the removed Copy-$MODULE.gmk files:
>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>>
>>
>>>>
>>>> Another minor note, when ordering include directories, I usually put 
>>>> the most specific dir first, so that any platform specific header 
>>>> file with the same name would override a more general one. We don't 
>>>> have that situation in this case, but I still think it's good practice.
>>>>
>>>> Regarding where to push this. IMO, if it depends on a change 
>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 
>>>> doesn't really matter that much.
>>>>
>>>
>>> I would love this in JDK 10 if time permits and I am happy to see 
>>> Coleen retarget it to 10.? This is a really nice clean up that shows 
>>> the benefit from JEP 201 w.r.t. exported native header files.?? But 
>>> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.
>>
>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon 
>> as the needed fixes are integrated from jdk/hs.
>>
>> /Magnus
>>
>>>
>>> Mandy
>>>
>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>>>>> JDK-8190484 was created as a follow-up bug to the unification of 
>>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>>> location of these files. This has now been decided to be 
>>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>>
>>>>> This patch moves the relevant files there, but since this also 
>>>>> frees up the src/$MODULE/native/include directories for the 
>>>>> original purpose, it also unifies and simplifies the build logic 
>>>>> for these directories, so that common code is executed for all 
>>>>> modules to just copy any exported header files from these 
>>>>> directories, should they exist.
>>>>>
>>>>> I'm intending to push this to jdk-hs.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>>> WebRev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>>
>>>>>
>>>>> /Magnus
>>>>
>>>
>>
> 

From tobias.hartmann at oracle.com  Tue Dec  5 06:16:56 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 5 Dec 2017 07:16:56 +0100
Subject: [10] RFR(S): 8191360: Lookup of critical JNI method causes
 duplicate library loading with leaking handler
In-Reply-To: <95baef7d-dbe7-ca5c-4077-d50df1ad7e29@oracle.com>
References: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>
 <95baef7d-dbe7-ca5c-4077-d50df1ad7e29@oracle.com>
Message-ID: <4ab90c35-5721-5d1b-0f9a-129584012322@oracle.com>

Hi Vladimir,

thanks for the review!

On 04.12.2017 19:35, Vladimir Ivanov wrote:
> PS: I'd prefer to see library-related code factored out and the library handle shared among 4 consecutive calls in
> NL::lookup_critical_entry(). But if you think it's too intrusive for the fix, please, file an RFE.

Yes, I've thought about this as well but decided not to do the refactoring since it's non-trivial and the fix might be
backported.

I'll file a separate RFE for that.

Best regards,
Tobias

> On 12/4/17 7:42 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch:
>> https://bugs.openjdk.java.net/browse/JDK-8191360
>> http://cr.openjdk.java.net/~thartmann/8191360/webrev.00/
>>
>> When creating a native wrapper, the compiler checks the shared library for a critical version of the native method
>> (-XX:+CriticalJNINatives, see comments in JDK-7013347 [1]) that can be called with reduced overhead. This is done in
>> NativeLookup::lookup_critical_style() with a call to dll_load() to get a handle to the (already loaded) library and a
>> subsequent call to dll_lookup() to get the entry address of the critical version.
>>
>> The problem is that without a call to dll_unload(), this handle to the library will stay live and internal reference
>> counting will prevent the library from ever being unloaded (even if the native method holder is unloaded). As a result,
>> static fields in the library code are not reset, causing the NativeLibraryTest to fail due to unexpected field values
>> once the library is loaded again.
>>
>> I've fixed this by closing the handle immediately after retrieving the critical entry address. This is fine because the
>> library is still kept alive by JNI (see JVM_LoadLibrary). As soon as the holder class and the library are unloaded (see
>> JVM_UnloadLibrary), the native wrapper that calls 'critical_entry' becomes unreachable and is unloaded as well.
>>
>> I've also thought about passing 'RTLD_NOLOAD' to dlopen [2] but although that avoids loading the library, it still
>> creates a handle (that needs to be closed) if the library is already loaded.
>>
>> Tested with failing test and Mach 5 hs-tier1, hs-tier2, hs-precheckin-comp (running).
>>
>> Thanks,
>> Tobias
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-7013347
>> [2] https://linux.die.net/man/3/dlopen
>>

From tobias.hartmann at oracle.com  Tue Dec  5 06:27:41 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 5 Dec 2017 07:27:41 +0100
Subject: [10] RFR(S): 8191360: Lookup of critical JNI method causes
 duplicate library loading with leaking handler
In-Reply-To: <5b0d88b5-096c-005e-e898-8bc55577a557@oracle.com>
References: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>
 <5b0d88b5-096c-005e-e898-8bc55577a557@oracle.com>
Message-ID: <e7c8ec08-1576-9859-4395-32bb217b0bc5@oracle.com>

Hi David,

thanks for the review!

On 04.12.2017 22:46, David Holmes wrote:
> I'm unclear why you added the critical entry to test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c ??
> The impact of that on the test is not clear to me. It also obscures whether the test is fixed just by the actual fix.

Right, I should have mentioned that in the RFR. The reason is that I first had a fix that only unloaded the shared
library if no critical method was found, i.e., if critical_entry == NULL. This fixes the crash in the original test
(because there is no critical version of the method). For additional coverage, I've added a critical entry to the test
library.

Thinking about it again, the test changes are not necessary. Here's a webrev without:
http://cr.openjdk.java.net/~thartmann/8191360/webrev.01/

> I agree with Vladimir that there is scope for being more efficient with the library handling in this code, but that's
> future work.

Right, I'll file a separate RFE and link it to the bug.

Best regards,
Tobias
>> When creating a native wrapper, the compiler checks the shared library for a critical version of the native method
>> (-XX:+CriticalJNINatives, see comments in JDK-7013347 [1]) that can be called with reduced overhead. This is done in
>> NativeLookup::lookup_critical_style() with a call to dll_load() to get a handle to the (already loaded) library and a
>> subsequent call to dll_lookup() to get the entry address of the critical version.
>>
>> The problem is that without a call to dll_unload(), this handle to the library will stay live and internal reference
>> counting will prevent the library from ever being unloaded (even if the native method holder is unloaded). As a result,
>> static fields in the library code are not reset, causing the NativeLibraryTest to fail due to unexpected field values
>> once the library is loaded again.
>>
>> I've fixed this by closing the handle immediately after retrieving the critical entry address. This is fine because the
>> library is still kept alive by JNI (see JVM_LoadLibrary). As soon as the holder class and the library are unloaded (see
>> JVM_UnloadLibrary), the native wrapper that calls 'critical_entry' becomes unreachable and is unloaded as well.
>>
>> I've also thought about passing 'RTLD_NOLOAD' to dlopen [2] but although that avoids loading the library, it still
>> creates a handle (that needs to be closed) if the library is already loaded.
>>
>> Tested with failing test and Mach 5 hs-tier1, hs-tier2, hs-precheckin-comp (running).
>>
>> Thanks,
>> Tobias
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-7013347
>> [2] https://linux.die.net/man/3/dlopen
>>

From david.holmes at oracle.com  Tue Dec  5 06:30:19 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 16:30:19 +1000
Subject: [10] RFR(S): 8191360: Lookup of critical JNI method causes
 duplicate library loading with leaking handler
In-Reply-To: <e7c8ec08-1576-9859-4395-32bb217b0bc5@oracle.com>
References: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>
 <5b0d88b5-096c-005e-e898-8bc55577a557@oracle.com>
 <e7c8ec08-1576-9859-4395-32bb217b0bc5@oracle.com>
Message-ID: <fd6b6ded-80c7-cca4-37c4-3c719b0097cb@oracle.com>

Looks good!

Thanks,
David

On 5/12/2017 4:27 PM, Tobias Hartmann wrote:
> Hi David,
> 
> thanks for the review!
> 
> On 04.12.2017 22:46, David Holmes wrote:
>> I'm unclear why you added the critical entry to test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c ??
>> The impact of that on the test is not clear to me. It also obscures whether the test is fixed just by the actual fix.
> 
> Right, I should have mentioned that in the RFR. The reason is that I first had a fix that only unloaded the shared
> library if no critical method was found, i.e., if critical_entry == NULL. This fixes the crash in the original test
> (because there is no critical version of the method). For additional coverage, I've added a critical entry to the test
> library.
> 
> Thinking about it again, the test changes are not necessary. Here's a webrev without:
> http://cr.openjdk.java.net/~thartmann/8191360/webrev.01/
> 
>> I agree with Vladimir that there is scope for being more efficient with the library handling in this code, but that's
>> future work.
> 
> Right, I'll file a separate RFE and link it to the bug.
> 
> Best regards,
> Tobias
>>> When creating a native wrapper, the compiler checks the shared library for a critical version of the native method
>>> (-XX:+CriticalJNINatives, see comments in JDK-7013347 [1]) that can be called with reduced overhead. This is done in
>>> NativeLookup::lookup_critical_style() with a call to dll_load() to get a handle to the (already loaded) library and a
>>> subsequent call to dll_lookup() to get the entry address of the critical version.
>>>
>>> The problem is that without a call to dll_unload(), this handle to the library will stay live and internal reference
>>> counting will prevent the library from ever being unloaded (even if the native method holder is unloaded). As a result,
>>> static fields in the library code are not reset, causing the NativeLibraryTest to fail due to unexpected field values
>>> once the library is loaded again.
>>>
>>> I've fixed this by closing the handle immediately after retrieving the critical entry address. This is fine because the
>>> library is still kept alive by JNI (see JVM_LoadLibrary). As soon as the holder class and the library are unloaded (see
>>> JVM_UnloadLibrary), the native wrapper that calls 'critical_entry' becomes unreachable and is unloaded as well.
>>>
>>> I've also thought about passing 'RTLD_NOLOAD' to dlopen [2] but although that avoids loading the library, it still
>>> creates a handle (that needs to be closed) if the library is already loaded.
>>>
>>> Tested with failing test and Mach 5 hs-tier1, hs-tier2, hs-precheckin-comp (running).
>>>
>>> Thanks,
>>> Tobias
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-7013347
>>> [2] https://linux.die.net/man/3/dlopen
>>>

From tobias.hartmann at oracle.com  Tue Dec  5 06:50:52 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 5 Dec 2017 07:50:52 +0100
Subject: [10] RFR(S): 8191360: Lookup of critical JNI method causes
 duplicate library loading with leaking handler
In-Reply-To: <fd6b6ded-80c7-cca4-37c4-3c719b0097cb@oracle.com>
References: <f358f598-8aa3-a0e1-723e-8a5923c5f8e7@oracle.com>
 <5b0d88b5-096c-005e-e898-8bc55577a557@oracle.com>
 <e7c8ec08-1576-9859-4395-32bb217b0bc5@oracle.com>
 <fd6b6ded-80c7-cca4-37c4-3c719b0097cb@oracle.com>
Message-ID: <85e87fe5-5f51-319b-bd54-f7dd4d4e7335@oracle.com>

Thanks David.

Best regards,
Tobias

On 05.12.2017 07:30, David Holmes wrote:
> Looks good!
> 
> Thanks,
> David
> 
> On 5/12/2017 4:27 PM, Tobias Hartmann wrote:
>> Hi David,
>>
>> thanks for the review!
>>
>> On 04.12.2017 22:46, David Holmes wrote:
>>> I'm unclear why you added the critical entry to test/jdk/java/lang/ClassLoader/nativeLibrary/libnativeLibraryTest.c ??
>>> The impact of that on the test is not clear to me. It also obscures whether the test is fixed just by the actual fix.
>>
>> Right, I should have mentioned that in the RFR. The reason is that I first had a fix that only unloaded the shared
>> library if no critical method was found, i.e., if critical_entry == NULL. This fixes the crash in the original test
>> (because there is no critical version of the method). For additional coverage, I've added a critical entry to the test
>> library.
>>
>> Thinking about it again, the test changes are not necessary. Here's a webrev without:
>> http://cr.openjdk.java.net/~thartmann/8191360/webrev.01/
>>
>>> I agree with Vladimir that there is scope for being more efficient with the library handling in this code, but that's
>>> future work.
>>
>> Right, I'll file a separate RFE and link it to the bug.
>>
>> Best regards,
>> Tobias
>>>> When creating a native wrapper, the compiler checks the shared library for a critical version of the native method
>>>> (-XX:+CriticalJNINatives, see comments in JDK-7013347 [1]) that can be called with reduced overhead. This is done in
>>>> NativeLookup::lookup_critical_style() with a call to dll_load() to get a handle to the (already loaded) library and a
>>>> subsequent call to dll_lookup() to get the entry address of the critical version.
>>>>
>>>> The problem is that without a call to dll_unload(), this handle to the library will stay live and internal reference
>>>> counting will prevent the library from ever being unloaded (even if the native method holder is unloaded). As a result,
>>>> static fields in the library code are not reset, causing the NativeLibraryTest to fail due to unexpected field values
>>>> once the library is loaded again.
>>>>
>>>> I've fixed this by closing the handle immediately after retrieving the critical entry address. This is fine because the
>>>> library is still kept alive by JNI (see JVM_LoadLibrary). As soon as the holder class and the library are unloaded (see
>>>> JVM_UnloadLibrary), the native wrapper that calls 'critical_entry' becomes unreachable and is unloaded as well.
>>>>
>>>> I've also thought about passing 'RTLD_NOLOAD' to dlopen [2] but although that avoids loading the library, it still
>>>> creates a handle (that needs to be closed) if the library is already loaded.
>>>>
>>>> Tested with failing test and Mach 5 hs-tier1, hs-tier2, hs-precheckin-comp (running).
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-7013347
>>>> [2] https://linux.die.net/man/3/dlopen
>>>>

From magnus.ihse.bursie at oracle.com  Tue Dec  5 07:40:09 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2017 08:40:09 +0100
Subject: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
In-Reply-To: <8ad0e61f-ec60-8deb-2fa0-127cb9ebd58b@oracle.com>
References: <d6362671-39d9-5129-81d0-59bf10843ab5@oracle.com>
 <9f79287b-9ca7-6546-3b8d-4b84375a3ea0@oracle.com>
 <df4e4839-f9f2-5312-f33f-e9701e005390@oracle.com>
 <27fd29ce-6a57-0c34-8948-d68f0d6cc2a1@oracle.com>
 <604642c5-ca4f-4692-39a9-d1fa9fd73c8d@oracle.com>
 <8ad0e61f-ec60-8deb-2fa0-127cb9ebd58b@oracle.com>
Message-ID: <e217cfa7-75b0-0d0c-442f-1f24a9143764@oracle.com>

On 2017-12-05 06:59, David Holmes wrote:
> Magnus,
>
> It seems these changes have broken all Windows builds:
Oh f*ck. :-(

I didn't test my re-addition of the Copy-jdk.accessibility.gmk file 
properly. :(

I opened https://bugs.openjdk.java.net/browse/JDK-8193045.

/Magnus

>
> Copying support/modules_include/jdk.accessibility/win32/bridge
> /usr/bin/cp -fP 
> '/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge' 
> '/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge' 
>
> /usr/bin/cp: omitting directory 
> '/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge'
> CopyCommon.gmk:62: recipe for target 
> '/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge' 
> failed
> make[3]: *** 
> [/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge] 
> Error 1
>
> David
> -----
>
> On 5/12/2017 7:26 AM, Erik Joelsson wrote:
>> Looks good.
>>
>> /Erik
>>
>>
>> On 2017-12-04 12:40, Magnus Ihse Bursie wrote:
>>> On 2017-12-04 19:17, mandy chung wrote:
>>>>
>>>>
>>>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>>>> Hello Magnus,
>>>>>
>>>>> The <module>-copy targets are currently only being generated for 
>>>>> modules that have make/copy/Copy-<module>.gmk makefiles present. 
>>>>> By removing make/copy/Copy-jdk.accessibility.gmk and 
>>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer 
>>>>> created so the logic in CopyCommon will not be executed.
>>>>>
>>>>> This can be solved in two ways. Either generate <module>-copy 
>>>>> rules for all modules or leave the files there with just include 
>>>>> CopyCommon.gmk as the only contents. I would recommend the latter 
>>>>> for now. Most modules do not need to copy anything.
>>>>
>>>> Is it possible to generate <module>-copy rules for module where 
>>>> src/<module>/{share, $OS}/include directory or 
>>>> make/copy/Copy-<module>.gmk is present?
>>> Technically, it's of course possible. But it does not fit very well 
>>> with the current DeclareRecipesForPhase. I agree with Erik, that for 
>>> now the reasonable approach is to have files that only include 
>>> CopyCommon. We can consider for future updates if it's worth 
>>> generalizing this.
>>>
>>> Updated webrev that restores the removed Copy-$MODULE.gmk files:
>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>>>
>>>
>>>>>
>>>>> Another minor note, when ordering include directories, I usually 
>>>>> put the most specific dir first, so that any platform specific 
>>>>> header file with the same name would override a more general one. 
>>>>> We don't have that situation in this case, but I still think it's 
>>>>> good practice.
>>>>>
>>>>> Regarding where to push this. IMO, if it depends on a change 
>>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 
>>>>> doesn't really matter that much.
>>>>>
>>>>
>>>> I would love this in JDK 10 if time permits and I am happy to see 
>>>> Coleen retarget it to 10.? This is a really nice clean up that 
>>>> shows the benefit from JEP 201 w.r.t. exported native header 
>>>> files.?? But this is not a must for JDK 10 and if it can't make 10, 
>>>> it's okay for 11.
>>>
>>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as 
>>> soon as the needed fixes are integrated from jdk/hs.
>>>
>>> /Magnus
>>>
>>>>
>>>> Mandy
>>>>
>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>> On 2017-12-04 03:06, Magnus Ihse Bursie wrote:
>>>>>> JDK-8190484 was created as a follow-up bug to the unification of 
>>>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper 
>>>>>> location of these files. This has now been decided to be 
>>>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>>>>
>>>>>> This patch moves the relevant files there, but since this also 
>>>>>> frees up the src/$MODULE/native/include directories for the 
>>>>>> original purpose, it also unifies and simplifies the build logic 
>>>>>> for these directories, so that common code is executed for all 
>>>>>> modules to just copy any exported header files from these 
>>>>>> directories, should they exist.
>>>>>>
>>>>>> I'm intending to push this to jdk-hs.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>>>> WebRev: 
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>
>>>>
>>>
>>


From magnus.ihse.bursie at oracle.com  Tue Dec  5 09:12:42 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2017 10:12:42 +0100
Subject: [urgent] RFR: JDK-8193045 JDK-8190484 breaks build on Windows
Message-ID: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com>

JDK-8190484 modifies how the copy step of the build process works. 
Unfortunately, this broke building on Windows in jdk.accessibility.

Since JDK-8190484 was pushed to jdk/hs, I intend to push this to jdk/hs 
as well.

Bug: https://bugs.openjdk.java.net/browse/JDK-8193045
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8193045-fix-broken-copy-includes/webrev.01

/Magnus


From david.holmes at oracle.com  Tue Dec  5 09:21:03 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 19:21:03 +1000
Subject: [urgent] RFR: JDK-8193045 JDK-8190484 breaks build on Windows
In-Reply-To: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com>
References: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com>
Message-ID: <4f5bdb34-871c-3e99-27af-f3dd38031292@oracle.com>

Hi Magnus,

On 5/12/2017 7:12 PM, Magnus Ihse Bursie wrote:
> JDK-8190484 modifies how the copy step of the build process works. 
> Unfortunately, this broke building on Windows in jdk.accessibility.
> 
> Since JDK-8190484 was pushed to jdk/hs, I intend to push this to jdk/hs 
> as well.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193045
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8193045-fix-broken-copy-includes/webrev.01 

This seems reasonable. You are skipping empty directories - which is 
what the build failures was choking on.

Thanks,
David

> 
> /Magnus
> 

From magnus.ihse.bursie at oracle.com  Tue Dec  5 09:30:58 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2017 10:30:58 +0100
Subject: [urgent] RFR: JDK-8193045 JDK-8190484 breaks build on Windows
In-Reply-To: <4f5bdb34-871c-3e99-27af-f3dd38031292@oracle.com>
References: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com>
 <4f5bdb34-871c-3e99-27af-f3dd38031292@oracle.com>
Message-ID: <cc4510e2-b51f-3ef0-fb4e-19bb4c7ede0c@oracle.com>

On 2017-12-05 10:21, David Holmes wrote:
> Hi Magnus,
>
> On 5/12/2017 7:12 PM, Magnus Ihse Bursie wrote:
>> JDK-8190484 modifies how the copy step of the build process works. 
>> Unfortunately, this broke building on Windows in jdk.accessibility.
>>
>> Since JDK-8190484 was pushed to jdk/hs, I intend to push this to 
>> jdk/hs as well.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193045
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8193045-fix-broken-copy-includes/webrev.01 
>
>
> This seems reasonable. 
Thanks. Do I need a second reviewer to push this?

> You are skipping empty directories - which is what the build failures 
> was choking on.
Actually, the build choked on that $(wildcard) found a directory, which 
then was sent to cp in SetupCopyFiles, but cp didn't want to copy a 
directory since it was not called (correctly) with -r.

On top of that there was also an aesthetic issue with error messages 
printed from find when looking in non-existing directories. It was ugly 
but didn't break the build.

/Magnus

>
> Thanks,
> David
>
>>
>> /Magnus
>>


From robbin.ehn at oracle.com  Tue Dec  5 09:59:11 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 5 Dec 2017 10:59:11 +0100
Subject: RFR(XS) 8192870: [Testbug]
 runtime/handshake/HandshakeTransitionTest throws NPE
In-Reply-To: <dc94debc-9bbb-19bb-dcbc-697dd129cdff@oracle.com>
References: <dc94debc-9bbb-19bb-dcbc-697dd129cdff@oracle.com>
Message-ID: <7c57cbb9-e2ea-878b-c9b5-72750fe81404@oracle.com>

On 12/04/2017 09:48 PM, dean.long at oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8192870
> http://cr.openjdk.java.net/~dlong/8192870/webrev/

Looks good and thanks for fixing!

/Robbin

> 
> When we query WhiteBox.getBooleanVMFlag("UseJVMCICompiler"), we need to check 
> for null, in case JVMCI is not included in the build.
> 
> dl

From david.holmes at oracle.com  Tue Dec  5 10:14:35 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 20:14:35 +1000
Subject: [urgent] RFR: JDK-8193045 JDK-8190484 breaks build on Windows
In-Reply-To: <cc4510e2-b51f-3ef0-fb4e-19bb4c7ede0c@oracle.com>
References: <8cf9978c-ed56-3a09-c0a5-3389619ee87f@oracle.com>
 <4f5bdb34-871c-3e99-27af-f3dd38031292@oracle.com>
 <cc4510e2-b51f-3ef0-fb4e-19bb4c7ede0c@oracle.com>
Message-ID: <9b077bf5-b672-4b81-ceae-6335bc27c009@oracle.com>

On 5/12/2017 7:30 PM, Magnus Ihse Bursie wrote:
> On 2017-12-05 10:21, David Holmes wrote:
>> Hi Magnus,
>>
>> On 5/12/2017 7:12 PM, Magnus Ihse Bursie wrote:
>>> JDK-8190484 modifies how the copy step of the build process works. 
>>> Unfortunately, this broke building on Windows in jdk.accessibility.
>>>
>>> Since JDK-8190484 was pushed to jdk/hs, I intend to push this to 
>>> jdk/hs as well.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193045
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8193045-fix-broken-copy-includes/webrev.01 
>>
>>
>>
>> This seems reasonable. 
> Thanks. Do I need a second reviewer to push this?

I don't think so - it's a build issue, and I've verified the fix myself 
in a JPRT run. :)

>> You are skipping empty directories - which is what the build failures 
>> was choking on.
> Actually, the build choked on that $(wildcard) found a directory, which 
> then was sent to cp in SetupCopyFiles, but cp didn't want to copy a 
> directory since it was not called (correctly) with -r.

Okay I was imprecise in my description :)

Thanks,
David

> On top of that there was also an aesthetic issue with error messages 
> printed from find when looking in non-existing directories. It was ugly 
> but didn't break the build.
> 
> /Magnus
> 
>>
>> Thanks,
>> David
>>
>>>
>>> /Magnus
>>>
> 

From thomas.schatzl at oracle.com  Tue Dec  5 11:07:07 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 05 Dec 2017 12:07:07 +0100
Subject: TLAB Refills for x86
In-Reply-To: <CAF9BGByOTFvAdgAaG3S85yO8jov0rdA7_tiiEnU38wFxNxzoeg@mail.gmail.com>
References: <CAF9BGByOTFvAdgAaG3S85yO8jov0rdA7_tiiEnU38wFxNxzoeg@mail.gmail.com>
Message-ID: <1512472027.2454.22.camel@oracle.com>

Hi,

On Thu, 2017-11-30 at 13:09 -0800, JC Beyler wrote:
> Hi all,
> 
> The TLAB and the inline contiguous allocations handling are different
> for
> each architecture. On certain architectures, TLAB is never actually
> never
> refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
> 
> The idea behind the implementation for x86 is to separate TLAB usage
> to
> contiguous allocations in eden space.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191027
> WebRev: http://cr.openjdk.java.net/~rasbold/8191027/webrev.02/
> 
> Does anyone see any issues with this webrev?

I only see a slight issue with the new comment on how it works: the
first time I read it, it seemed to me that step 1+2 are inclusive, not
exclusive as is implemented (there is step 4 which explains that it is
exclusive retroactively). But maybe it's just me.

Looks good otherwise.

Thomas


From thomas.schatzl at oracle.com  Tue Dec  5 11:08:18 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 05 Dec 2017 12:08:18 +0100
Subject: RFR 8191989: TLAB Refills for Sparc
In-Reply-To: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>
References: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>
Message-ID: <1512472098.2454.23.camel@oracle.com>

Hi,

On Thu, 2017-11-30 at 16:58 -0800, JC Beyler wrote:
> Hi all,
> 
> The TLAB and the inline contiguous allocations handling are different
> for
> each architecture. On certain architectures, TLAB is never actually
> never
> refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
> 
> The idea behind the implementation for Sparc is to do two things:
>   - separate TLAB usage to contiguous allocations in eden space.
>   - remove the code that augments the TLAB waste limit since that is
> already done in the common code slow path
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191989
> WebRev: *http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/
> <http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/>*
> 
> Does anyone see any issues with this webrev?

  same comment as the x86 change, otherwise looks good.

Thanks,
  Thomas

From stefan.karlsson at oracle.com  Tue Dec  5 11:23:07 2017
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 5 Dec 2017 12:23:07 +0100
Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization
 queries the wrong chunk freelist
In-Reply-To: <94651bf0-3eaa-406a-89b3-361c8408ce19@default>
References: <811da80f-e107-4d0c-903b-c109b592176e@default>
 <CAA-vtUx0QjH4QCHTNDCq1JA+-+OzMO6M1+pjOvSJ7H0g1YgzXQ@mail.gmail.com>
 <6e7c7f30-599d-4558-8c84-0360f0535cf4@default>
 <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default>
 <d55656db-f114-400c-895f-3e7878cde3fa@default>
 <CAA-vtUxYmBnr7qH+ut__D7-5roUE9OD7OmQ6yZi+xse9SrHeEQ@mail.gmail.com>
 <1c305b2e-ae87-4161-b094-c5407e9f389e@default>
 <CAA-vtUztTsFCtHUchuHRtgSw_pbxCu9qK85gZF-Y72GsSa1WzA@mail.gmail.com>
 <94651bf0-3eaa-406a-89b3-361c8408ce19@default>
Message-ID: <6862edf2-71eb-b600-d49f-7e0f765e772b@oracle.com>

Hi Muthusamy,

The backport of metaspace.cpp and metaspace.hpp looks fine but I haven't 
tracked all changes to the metaspace files for 8u-dev so a second pair 
of eyes would be good.

Two things:

1) Can you make sure that the unit test gets hooked into 
execute_internal_vm_test in:
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/b0f7174de2c5/src/share/vm/prims/jni.cpp

And test it with:
-XX:+ExecuteInternalVMTests


2) report_insufficient_metaspace has been removed in later JDKs. Ioi, is 
this addition of report_insufficient_metaspace OK?

Thanks,
StefanK


On 2017-11-17 09:59, Muthusamy Chinnathambi wrote:
> Hi Thomas,
> 
> Thanks for the review.
> 
>> . I also would prefer that the gtests you omitted should be part of the 
> change (I think before there were gtests, these kind of tests were 
> implemented as file-local static test functions and called I think via 
> whitebox.cpp ? But I wait what others say.
> 
> Yes, the test is part of 
> https://bugs.openjdk.java.net/browse/JDK-8169931 . I would be 
> backporting this as well, just that I didn?t want to pollute the current BP.
> 
> Regards,
> 
> Muthusamy C
> 
> *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> *Sent:* Friday, November 17, 2017 2:21 PM
> *To:* Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com>
> *Cc:* HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; Per 
> Liden <per.liden at oracle.com>; Stefan Karlsson 
> <stefan.karlsson at oracle.com>; Stephen Fitch <stephen.fitch at oracle.com>
> *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace 
> initialization queries the wrong chunk freelist
> 
> Hi Muthusamy,
> 
>  From the look of it updated webrev looks fine, but I do not have the 
> time to build and check on jdk8u. I also would prefer that the gtests 
> you omitted should be part of the change (I think before there were 
> gtests, these kind of tests were implemented as file-local static test 
> functions and called I think via whitebox.cpp ? But I wait what others say.
> 
> Someone from Oracle should confirm this patch. Note that Mikael left 
> Oracle, I took him off the reply list because mail bounce.
> 
> Kind Regards, Thomas
> 
> On Thu, Nov 16, 2017 at 10:08 AM, Muthusamy Chinnathambi 
> <muthusamy.chinnathambi at oracle.com 
> <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     Thanks for the review.
> 
>      > But are there gtests already in jdk8u? I thought gtests came with
>     jdk9?
> 
>      > http://openjdk.java.net/jeps/281
> 
>      > If not, how does
>     http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html
>     run or even compile?
> 
>     Yes, you are right. "test_spaceManager.cpp" should not have been
>     included here.
> 
>     Please find the updated webrev at
>     http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.01/? .
> 
>     Regards,
> 
>     Muthusamy C
> 
>     *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com
>     <mailto:thomas.stuefe at gmail.com>]
>     *Sent:* Wednesday, November 15, 2017 6:30 PM
>     *To:* Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com
>     <mailto:muthusamy.chinnathambi at oracle.com>>
>     *Cc:* HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>     <mailto:hotspot-dev at openjdk.java.net>>; Mikael Gerdin
>     <mikael.gerdin at oracle.com <mailto:mikael.gerdin at oracle.com>>; Per
>     Liden <per.liden at oracle.com <mailto:per.liden at oracle.com>>; Stefan
>     Karlsson <stefan.karlsson at oracle.com
>     <mailto:stefan.karlsson at oracle.com>>; Stephen Fitch
>     <stephen.fitch at oracle.com <mailto:stephen.fitch at oracle.com>>
>     *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace
>     initialization queries the wrong chunk freelist
> 
>     Hi Muthusamy,
> 
>     Looks okay. But are there gtests already in jdk8u? I thought gtests
>     came with jdk9?
> 
>     http://openjdk.java.net/jeps/281
> 
>     If not, how does
>     http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html
>     run or even compile?
> 
>     Thanks, Thomas
> 
>     On Wed, Nov 15, 2017 at 11:19 AM, Muthusamy Chinnathambi
>     <muthusamy.chinnathambi at oracle.com
>     <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
> 
>         Hi,
> 
>         Could someone please review this backport.
> 
>         Regards,
>         Muthusamy C
> 
>         -----Original Message-----
>         From: Muthusamy Chinnathambi
> 
>         Sent: Friday, November 10, 2017 3:27 PM
>         To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>         <mailto:hotspot-dev at openjdk.java.net>>
>         Cc: Mikael Gerdin <mikael.gerdin at oracle.com
>         <mailto:mikael.gerdin at oracle.com>>
>         Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace
>         initialization queries the wrong chunk freelist
> 
>         Hi,
> 
>         Can someone please review this.
> 
>         Thanks!
>         Muthusamy C
> 
>         -----Original Message-----
>         From: Muthusamy Chinnathambi
>         Sent: Wednesday, November 8, 2017 11:24 AM
>         To: Thomas St?fe <thomas.stuefe at gmail.com
>         <mailto:thomas.stuefe at gmail.com>>
>         Cc: Mikael Gerdin <mikael.gerdin at oracle.com
>         <mailto:mikael.gerdin at oracle.com>>; HotSpot Open Source
>         Developers <hotspot-dev at openjdk.java.net
>         <mailto:hotspot-dev at openjdk.java.net>>
>         Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace
>         initialization queries the wrong chunk freelist
> 
>         Hi Thomas,
> 
> 
> 
>          > ?the webrev link seems to be dead.
> 
>         Sorry for the trouble.
> 
>         Please find the corrected link below
> 
>         http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/
> 
> 
> 
>         Somehow the line following the link got appended to the previous
>         one leading to a dead link.
> 
> 
> 
>         Regards,
> 
>         Muthusamy C
> 
> 
> 
>         From: Thomas St?fe [mailto:thomas.stuefe at gmail.com
>         <mailto:thomas.stuefe at gmail.com>]
>         Sent: Tuesday, November 7, 2017 8:12 PM
>         To: Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com
>         <mailto:muthusamy.chinnathambi at oracle.com>>
>         Cc: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>         <mailto:hotspot-dev at openjdk.java.net>>; Mikael Gerdin
>         <mikael.gerdin at oracle.com <mailto:mikael.gerdin at oracle.com>>
>         Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace
>         initialization queries the wrong chunk freelist
> 
> 
> 
>         Hi Muthusamy,
> 
> 
> 
>         the webrev link seems to be dead.
> 
> 
> 
>         ..Thomas
> 
> 
> 
>         On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi
>         <HYPERLINK "mailto:muthusamy.chinnathambi at oracle.com
>         <mailto:muthusamy.chinnathambi at oracle.com>"muthusamy.chinnathambi at oracle.com
>         <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
> 
>         Hi,
> 
>         Please review the backport of bug: "JDK-8170395: Metaspace
>         initialization queries the wrong chunk freelist" to jdk8u-dev
> 
>         Please note that this is not a clean backport due to new entries
>         in debug.cpp and copyright changes.
> 
> 
>         Webrev: HYPERLINK
>         "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/
>         jdk9
>         <http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9> bug:
>         https://bugs.openjdk.java.net/browse/JDK-8170395
>         Original patch pushed to jdk9:
>         http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a
> 
>         Test:? Had run jtreg and jprt hotspot testsets.
> 
>         Regards,
>         Muthusamy C
> 

From martin.doerr at sap.com  Tue Dec  5 12:12:08 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 5 Dec 2017 12:12:08 +0000
Subject: TLAB Refills for x86
Message-ID: <59c0e5c16d4947cb9967f3e43965dc7e@sap.com>

Hi,

the interpreter change looks good to me (except the comment change).
I've taken a look at C1 and C2 compilers.
C2 already does it as desired: It either uses TLAB or shared eden allocation (if supported).

Unfortunately, the C1 implementation in c1_Runtime1_x86/sparc still contains a path "try_eden" when TLAB allocation fails. (Also see MacroAssembler::tlab_refill). I think this should be adapted as well. Would you agree?

Best regards,
Martin


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Thomas Schatzl
Sent: Dienstag, 5. Dezember 2017 12:07
To: JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
Subject: Re: TLAB Refills for x86

Hi,

On Thu, 2017-11-30 at 13:09 -0800, JC Beyler wrote:
> Hi all,
> 
> The TLAB and the inline contiguous allocations handling are different
> for
> each architecture. On certain architectures, TLAB is never actually
> never
> refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
> 
> The idea behind the implementation for x86 is to separate TLAB usage
> to
> contiguous allocations in eden space.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191027
> WebRev: http://cr.openjdk.java.net/~rasbold/8191027/webrev.02/
> 
> Does anyone see any issues with this webrev?

I only see a slight issue with the new comment on how it works: the
first time I read it, it seemed to me that step 1+2 are inclusive, not
exclusive as is implemented (there is step 4 which explains that it is
exclusive retroactively). But maybe it's just me.

Looks good otherwise.

Thomas


From robbin.ehn at oracle.com  Tue Dec  5 12:51:44 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 5 Dec 2017 13:51:44 +0100
Subject: TLAB Refills for x86
In-Reply-To: <59c0e5c16d4947cb9967f3e43965dc7e@sap.com>
References: <59c0e5c16d4947cb9967f3e43965dc7e@sap.com>
Message-ID: <5a8022ec-e8f6-28c7-c953-b600f8af17e8@oracle.com>

Hi Martin,

On 2017-12-05 13:12, Doerr, Martin wrote:
> Hi,
> 
> the interpreter change looks good to me (except the comment change).
> I've taken a look at C1 and C2 compilers.
> C2 already does it as desired: It either uses TLAB or shared eden allocation (if supported).
> 
> Unfortunately, the C1 implementation in c1_Runtime1_x86/sparc still contains a path "try_eden" when TLAB allocation fails. (Also see MacroAssembler::tlab_refill). I think this should be adapted as well. Would you agree?

The flag FastTLABRefill will be obsoleted in JDK 11 and we can then start removing (after Dec 14) the functionality.
In 10 we turned FastTLABRefill off by default and deprecated it. (FastTLABRefill was only actually on when using non-G1 and for C1 only)
(https://bugs.openjdk.java.net/browse/JDK-8190925)
This will be handled in a separate enhancement 'removing dead code'.

This (interpreter tlab refills) will not make 10, instead targeted for 11.
So in 11 we are aiming for a consistence behavior in all (not looked at gral) 'compilers'.

Thanks!

/Robbin

> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Thomas Schatzl
> Sent: Dienstag, 5. Dezember 2017 12:07
> To: JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
> Subject: Re: TLAB Refills for x86
> 
> Hi,
> 
> On Thu, 2017-11-30 at 13:09 -0800, JC Beyler wrote:
>> Hi all,
>>
>> The TLAB and the inline contiguous allocations handling are different
>> for
>> each architecture. On certain architectures, TLAB is never actually
>> never
>> refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
>>
>> The idea behind the implementation for x86 is to separate TLAB usage
>> to
>> contiguous allocations in eden space.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191027
>> WebRev: http://cr.openjdk.java.net/~rasbold/8191027/webrev.02/
>>
>> Does anyone see any issues with this webrev?
> 
> I only see a slight issue with the new comment on how it works: the
> first time I read it, it seemed to me that step 1+2 are inclusive, not
> exclusive as is implemented (there is step 4 which explains that it is
> exclusive retroactively). But maybe it's just me.
> 
> Looks good otherwise.
> 
> Thomas
> 

From martin.doerr at sap.com  Tue Dec  5 12:59:35 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 5 Dec 2017 12:59:35 +0000
Subject: TLAB Refills for x86
Message-ID: <c3304685625d485c96f1ae3cc4c0a430@sap.com>

Hi Robbin,

ok. Thanks for the explanation.

Best regards,
Martin


-----Original Message-----
From: Robbin Ehn [mailto:robbin.ehn at oracle.com] 
Sent: Dienstag, 5. Dezember 2017 13:52
To: Doerr, Martin <martin.doerr at sap.com>; Thomas Schatzl <thomas.schatzl at oracle.com>; JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
Subject: Re: TLAB Refills for x86

Hi Martin,

On 2017-12-05 13:12, Doerr, Martin wrote:
> Hi,
> 
> the interpreter change looks good to me (except the comment change).
> I've taken a look at C1 and C2 compilers.
> C2 already does it as desired: It either uses TLAB or shared eden allocation (if supported).
> 
> Unfortunately, the C1 implementation in c1_Runtime1_x86/sparc still contains a path "try_eden" when TLAB allocation fails. (Also see MacroAssembler::tlab_refill). I think this should be adapted as well. Would you agree?

The flag FastTLABRefill will be obsoleted in JDK 11 and we can then start removing (after Dec 14) the functionality.
In 10 we turned FastTLABRefill off by default and deprecated it. (FastTLABRefill was only actually on when using non-G1 and for C1 only)
(https://bugs.openjdk.java.net/browse/JDK-8190925)
This will be handled in a separate enhancement 'removing dead code'.

This (interpreter tlab refills) will not make 10, instead targeted for 11.
So in 11 we are aiming for a consistence behavior in all (not looked at gral) 'compilers'.

Thanks!

/Robbin

> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Thomas Schatzl
> Sent: Dienstag, 5. Dezember 2017 12:07
> To: JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
> Subject: Re: TLAB Refills for x86
> 
> Hi,
> 
> On Thu, 2017-11-30 at 13:09 -0800, JC Beyler wrote:
>> Hi all,
>>
>> The TLAB and the inline contiguous allocations handling are different
>> for
>> each architecture. On certain architectures, TLAB is never actually
>> never
>> refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
>>
>> The idea behind the implementation for x86 is to separate TLAB usage
>> to
>> contiguous allocations in eden space.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191027
>> WebRev: http://cr.openjdk.java.net/~rasbold/8191027/webrev.02/
>>
>> Does anyone see any issues with this webrev?
> 
> I only see a slight issue with the new comment on how it works: the
> first time I read it, it seemed to me that step 1+2 are inclusive, not
> exclusive as is implemented (there is step 4 which explains that it is
> exclusive retroactively). But maybe it's just me.
> 
> Looks good otherwise.
> 
> Thomas
> 

From dean.long at oracle.com  Tue Dec  5 19:15:23 2017
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Tue, 5 Dec 2017 11:15:23 -0800
Subject: RFR(XS) 8192870: [Testbug]
 runtime/handshake/HandshakeTransitionTest throws NPE
In-Reply-To: <7c57cbb9-e2ea-878b-c9b5-72750fe81404@oracle.com>
References: <dc94debc-9bbb-19bb-dcbc-697dd129cdff@oracle.com>
 <7c57cbb9-e2ea-878b-c9b5-72750fe81404@oracle.com>
Message-ID: <5fb4183a-2c2f-6423-9063-bc15610ed3ef@oracle.com>

Thanks Robbin!

dl


On 12/5/17 1:59 AM, Robbin Ehn wrote:
> On 12/04/2017 09:48 PM, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8192870
>> http://cr.openjdk.java.net/~dlong/8192870/webrev/
>
> Looks good and thanks for fixing!
>
> /Robbin
>
>>
>> When we query WhiteBox.getBooleanVMFlag("UseJVMCICompiler"), we need 
>> to check for null, in case JVMCI is not included in the build.
>>
>> dl


From irogers at google.com  Tue Dec  5 23:15:29 2017
From: irogers at google.com (Ian Rogers)
Date: Tue, 5 Dec 2017 15:15:29 -0800
Subject: JNI ReleasePrimitiveArrayCritical with mode JNI_COMMIT shouldn't end
 critical region
Message-ID: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>

From:
https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical

"The semantics of these two functions are very similar to the existing
Get/Release<primitivetype>ArrayElements functions. "

https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines

"JNI_COMMIT copy back the content but do not free the elems buffer"

Consider the pattern of:
GetPrimitiveArrayCritical(...)
ReleasePrimitiveArrayCritical(..., JNI_COMMIT)
ReleasePrimitiveArrayCritical(..., 0)

where the first release is to just achieve a copy back. For example,
jniCheck.cpp will copy back but not free a copy in the case of JNI_COMMIT
for a critical. The implementation of ReleasePrimitiveArrayCritical ignores
all arguments and so it ends the critical region even in the event of a
commit.

The attached patch makes ReleasePrimitiveArrayCritical consider the mode
argument when releasing the GCLocker.

Thanks,
Ian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hotspot.jni-release-critical-commit.patch
Type: text/x-patch
Size: 759 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20171205/d686b685/hotspot.jni-release-critical-commit.patch>

From david.holmes at oracle.com  Wed Dec  6 00:37:29 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Dec 2017 10:37:29 +1000
Subject: JNI ReleasePrimitiveArrayCritical with mode JNI_COMMIT shouldn't
 end critical region
In-Reply-To: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>
References: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>
Message-ID: <3d676bb0-f7d3-ec40-cfb8-6a905f79a434@oracle.com>

Hi Ian,

On 6/12/2017 9:15 AM, Ian Rogers wrote:
> From:
> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical

You need to see the updated spec:

https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical

That spec makes it clear:

"mode: the release mode (see Primitive Array Release Modes): 0, 
JNI_COMMIT or JNI_ABORT. Ignored if carray was a not copy."

In hotspot getCriticalArrayPrimitive never returns a copy so the mode is 
always ignored, as per the existing comment.

David
-----

> "The semantics of these two functions are very similar to the existing
> Get/Release<primitivetype>ArrayElements functions. "
> 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines
> 
> "JNI_COMMIT copy back the content but do not free the elems buffer"
> 
> Consider the pattern of:
> GetPrimitiveArrayCritical(...)
> ReleasePrimitiveArrayCritical(..., JNI_COMMIT)
> ReleasePrimitiveArrayCritical(..., 0)
> 
> where the first release is to just achieve a copy back. For example,
> jniCheck.cpp will copy back but not free a copy in the case of JNI_COMMIT
> for a critical. The implementation of ReleasePrimitiveArrayCritical ignores
> all arguments and so it ends the critical region even in the event of a
> commit.
> 
> The attached patch makes ReleasePrimitiveArrayCritical consider the mode
> argument when releasing the GCLocker.
> 
> Thanks,
> Ian
> 

From poweruserm at live.com.au  Wed Dec  6 01:02:05 2017
From: poweruserm at live.com.au (A Z)
Date: Wed, 6 Dec 2017 01:02:05 +0000
Subject: Fw: Question about JEP 306.
In-Reply-To: <SL2P216MB05888FD4F6A7FA939018219C9A380@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
References: <SL2P216MB0588D4C8406A9B1A11687B859A250@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>,
 <SL2P216MB05880BCC26D99108133DE5CA9A3B0@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>,
 <SL2P216MB05888FD4F6A7FA939018219C9A380@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
Message-ID: <SL2P216MB0588EBFF1F8B191899B3C7E29A320@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>

-I have been wondering what interest, focus or progress

is happening around OpenJDK JEP 306:


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


-As a Java feature request, could I request feature 306?
Underflow and overflow need to be eliminated
from double and float.

There could be an associativefp option. It should also be the case
that there should be a round half up for the decimal place
beyond the last one in the float or double range, to help support
all notions of

(pow(sqrt(3),2) == 3)  //true


-The other thing that there should be is a StrictMath
that works for BigInteger and BigDecimal, allowing:

pow(BigDecimal,BigDecimal)
pi(...)
e(...)
sin(Bigdecimal)
asin(Bigdecimal) ...

which would allow for any power at all, as well as the nth root.
It is also a good idea to include a radians and degrees version
of all the trig functions.


From david.holmes at oracle.com  Wed Dec  6 01:07:57 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Dec 2017 11:07:57 +1000
Subject: Fw: Question about JEP 306.
In-Reply-To: <SL2P216MB0588EBFF1F8B191899B3C7E29A320@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
References: <SL2P216MB0588D4C8406A9B1A11687B859A250@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB05880BCC26D99108133DE5CA9A3B0@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB05888FD4F6A7FA939018219C9A380@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB0588EBFF1F8B191899B3C7E29A320@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
Message-ID: <2a493b34-a717-852b-23a8-d8827be0f61e@oracle.com>

Adding core-libs-dev as both mailing lists are named in this JEP.

David

On 6/12/2017 11:02 AM, A Z wrote:
> -I have been wondering what interest, focus or progress
> 
> is happening around OpenJDK JEP 306:
> 
> 
> http://openjdk.java.net/jeps/306
> 
> 
> -As a Java feature request, could I request feature 306?
> Underflow and overflow need to be eliminated
> from double and float.
> 
> There could be an associativefp option. It should also be the case
> that there should be a round half up for the decimal place
> beyond the last one in the float or double range, to help support
> all notions of
> 
> (pow(sqrt(3),2) == 3)  //true
> 
> 
> -The other thing that there should be is a StrictMath
> that works for BigInteger and BigDecimal, allowing:
> 
> pow(BigDecimal,BigDecimal)
> pi(...)
> e(...)
> sin(Bigdecimal)
> asin(Bigdecimal) ...
> 
> which would allow for any power at all, as well as the nth root.
> It is also a good idea to include a radians and degrees version
> of all the trig functions.
> 

From poweruserm at live.com.au  Wed Dec  6 02:45:48 2017
From: poweruserm at live.com.au (A Z)
Date: Wed, 6 Dec 2017 02:45:48 +0000
Subject: Question about JEP 306.
In-Reply-To: <SL2P216MB0588EBFF1F8B191899B3C7E29A320@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
References: <SL2P216MB0588D4C8406A9B1A11687B859A250@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>,
 <SL2P216MB05880BCC26D99108133DE5CA9A3B0@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>,
 <SL2P216MB05888FD4F6A7FA939018219C9A380@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>,
 <SL2P216MB0588EBFF1F8B191899B3C7E29A320@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
Message-ID: <SL2P216MB0588D3F26253954BF5A4F9DE9A320@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>

-Does anyone know when


Joseph D. Darcy


replies and is available for reading messages

from this email list, at all, then?


Is there a UTC time when he is fielding messages?

From joe.darcy at oracle.com  Wed Dec  6 02:55:57 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 05 Dec 2017 18:55:57 -0800
Subject: Fw: Question about JEP 306.
In-Reply-To: <2a493b34-a717-852b-23a8-d8827be0f61e@oracle.com>
References: <SL2P216MB0588D4C8406A9B1A11687B859A250@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB05880BCC26D99108133DE5CA9A3B0@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB05888FD4F6A7FA939018219C9A380@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB0588EBFF1F8B191899B3C7E29A320@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <2a493b34-a717-852b-23a8-d8827be0f61e@oracle.com>
Message-ID: <5A275C3D.4060208@oracle.com>

Hello,

On 12/5/2017 5:07 PM, David Holmes wrote:
> Adding core-libs-dev as both mailing lists are named in this JEP.
>
> David
>
> On 6/12/2017 11:02 AM, A Z wrote:
>> -I have been wondering what interest, focus or progress
>>
>> is happening around OpenJDK JEP 306:

The rampdown phase for JDK 10 is beginning later this month. Since JEP 
306 is not in the process of being targeted for JDK 10, it will not be 
part of that release. However, it may be included in a subsequent JDK 
release; once we have sufficient clarity of the work needed and 
commitment to do the work, we target a JEP to a particular release.

>>
>>
>> http://openjdk.java.net/jeps/306
>>
>>
>> -As a Java feature request, could I request feature 306?
>> Underflow and overflow need to be eliminated
>> from double and float.

That is outside of the stated description of what the JEP aims to do. 
IEEE 754 arithmetic has rules about underflow and overflow, rules also 
generally followed by the Java language and JVM.

There are no plans to adopt a system like unums that avoid imprecise 
overflows to infinity by losing precision at values extremely large in 
magnitude.

>>
>> There could be an associativefp option.

Such an option is explicitly called out as a non-goal for JEP 306:

"Defining any sort of "fast-fp" or "loose-fp" (c.f. JSR 84: Floating 
Point Extensions) is out of scope for this JEP."

However, such an option could be done under another project. With 
suitable caveats about forward looking statements, no promises, etc. the 
possibility of a fast-fp option along with some of the technical issues 
that would need to be addressed is discussed in the last few minutes of 
my JVMLS talk from earlier this year:

     "Forward to the Past: The Case for Uniformly Strict Floating Point 
Arithmetic on the JVM"
     https://www.youtube.com/watch?v=qTKeU_3rhk4

The bulk of the talk is a justification for JEP 306.

>> It should also be the case
>> that there should be a round half up for the decimal place
>> beyond the last one in the float or double range, to help support
>> all notions of
>>
>> (pow(sqrt(3),2) == 3)  //true

Putting aside non-finite values like NaN and infinities, this identity 
is difficult to have hold in any fixed-precision system, including 
IEEE-style floating-point. The mathematical square root function in 
general returns irrational results for rational inputs so the result is 
fundamentally approximated.  If my rusty calculus is correct, for x >= 
0.25, the derivative of sqrt of x has magnitude less than one and is 
positive, meaning there exists some set of multiple input values that 
must get mapped to the same output value. Therefore, the information to 
do an exact inverse operation based on the output is not present just 
from a pigeon hole principle argument.

>>
>>
>> -The other thing that there should be is a StrictMath
>> that works for BigInteger and BigDecimal, allowing:
>>
>> pow(BigDecimal,BigDecimal)
>> pi(...)
>> e(...)
>> sin(Bigdecimal)
>> asin(Bigdecimal) ...
>>

Such methods would have utility and we've had enhancements request for 
those features

     JDK-4297957: Add algebraic and transcendental functions operating 
on BigDecimal

but we've closed them as will not fix.


>> which would allow for any power at all, as well as the nth root.
>> It is also a good idea to include a radians and degrees version
>> of all the trig functions.

See RFE

     JDK-6341878: add degree-based trigonometric methods to the Math class
     https://bugs.openjdk.java.net/browse/JDK-6341878

Cheers,

-Joe

From muthusamy.chinnathambi at oracle.com  Wed Dec  6 11:54:26 2017
From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi)
Date: Wed, 6 Dec 2017 03:54:26 -0800 (PST)
Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization
 queries the wrong chunk freelist
In-Reply-To: <6862edf2-71eb-b600-d49f-7e0f765e772b@oracle.com>
References: <811da80f-e107-4d0c-903b-c109b592176e@default>
 <CAA-vtUx0QjH4QCHTNDCq1JA+-+OzMO6M1+pjOvSJ7H0g1YgzXQ@mail.gmail.com>
 <6e7c7f30-599d-4558-8c84-0360f0535cf4@default>
 <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default>
 <d55656db-f114-400c-895f-3e7878cde3fa@default>
 <CAA-vtUxYmBnr7qH+ut__D7-5roUE9OD7OmQ6yZi+xse9SrHeEQ@mail.gmail.com>
 <1c305b2e-ae87-4161-b094-c5407e9f389e@default>
 <CAA-vtUztTsFCtHUchuHRtgSw_pbxCu9qK85gZF-Y72GsSa1WzA@mail.gmail.com>
 <94651bf0-3eaa-406a-89b3-361c8408ce19@default>
 <6862edf2-71eb-b600-d49f-7e0f765e772b@oracle.com>
Message-ID: <ab4920cf-9b5b-41e3-87c4-617a63c05e33@default>

Hi Stefan,

Thanks for the review 

> 1) Can you make sure that the unit test gets hooked into 
> execute_internal_vm_test in:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/b0f7174de2c5/src/share/vm/prims/jni.cpp

> And test it with:
> -XX:+ExecuteInternalVMTests
Yes. Please find the updated webrev at http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.02/  . 
Tested with  -XX:+ExecuteInternalVMTests as well.

> 2) report_insufficient_metaspace has been removed in later JDKs. Ioi, is 
> this addition of report_insufficient_metaspace OK?
I think yes.  JDK9 still has this, although seem to have been removed in 10.

> The backport of metaspace.cpp and metaspace.hpp looks fine but I haven't 
> tracked all changes to the metaspace files for 8u-dev so a second pair 
> of eyes would be good.
Agreed.
Thomas St?fe had reviewed it, although he had the concern of execution of the test case.
The updated webrev should address it.

Regards,
Muthusamy C


-----Original Message-----
From: Stefan Karlsson 
Sent: Tuesday, December 5, 2017 4:53 PM
To: Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com>; Thomas St?fe <thomas.stuefe at gmail.com>; Ioi Lam <ioi.lam at oracle.com>
Cc: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; Per Liden <per.liden at oracle.com>; Stephen Fitch <stephen.fitch at oracle.com>
Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist

Hi Muthusamy,

The backport of metaspace.cpp and metaspace.hpp looks fine but I haven't 
tracked all changes to the metaspace files for 8u-dev so a second pair 
of eyes would be good.

Two things:

1) Can you make sure that the unit test gets hooked into 
execute_internal_vm_test in:
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/b0f7174de2c5/src/share/vm/prims/jni.cpp

And test it with:
-XX:+ExecuteInternalVMTests


2) report_insufficient_metaspace has been removed in later JDKs. Ioi, is 
this addition of report_insufficient_metaspace OK?

Thanks,
StefanK


On 2017-11-17 09:59, Muthusamy Chinnathambi wrote:
> Hi Thomas,
> 
> Thanks for the review.
> 
>> . I also would prefer that the gtests you omitted should be part of the 
> change (I think before there were gtests, these kind of tests were 
> implemented as file-local static test functions and called I think via 
> whitebox.cpp ? But I wait what others say.
> 
> Yes, the test is part of 
> https://bugs.openjdk.java.net/browse/JDK-8169931 . I would be 
> backporting this as well, just that I didn?t want to pollute the current BP.
> 
> Regards,
> 
> Muthusamy C
> 
> *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> *Sent:* Friday, November 17, 2017 2:21 PM
> *To:* Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com>
> *Cc:* HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; Per 
> Liden <per.liden at oracle.com>; Stefan Karlsson 
> <stefan.karlsson at oracle.com>; Stephen Fitch <stephen.fitch at oracle.com>
> *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace 
> initialization queries the wrong chunk freelist
> 
> Hi Muthusamy,
> 
>  From the look of it updated webrev looks fine, but I do not have the 
> time to build and check on jdk8u. I also would prefer that the gtests 
> you omitted should be part of the change (I think before there were 
> gtests, these kind of tests were implemented as file-local static test 
> functions and called I think via whitebox.cpp ? But I wait what others say.
> 
> Someone from Oracle should confirm this patch. Note that Mikael left 
> Oracle, I took him off the reply list because mail bounce.
> 
> Kind Regards, Thomas
> 
> On Thu, Nov 16, 2017 at 10:08 AM, Muthusamy Chinnathambi 
> <muthusamy.chinnathambi at oracle.com 
> <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     Thanks for the review.
> 
>      > But are there gtests already in jdk8u? I thought gtests came with
>     jdk9?
> 
>      > http://openjdk.java.net/jeps/281
> 
>      > If not, how does
>     http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html
>     run or even compile?
> 
>     Yes, you are right. "test_spaceManager.cpp" should not have been
>     included here.
> 
>     Please find the updated webrev at
>     http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.01/? .
> 
>     Regards,
> 
>     Muthusamy C
> 
>     *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com
>     <mailto:thomas.stuefe at gmail.com>]
>     *Sent:* Wednesday, November 15, 2017 6:30 PM
>     *To:* Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com
>     <mailto:muthusamy.chinnathambi at oracle.com>>
>     *Cc:* HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>     <mailto:hotspot-dev at openjdk.java.net>>; Mikael Gerdin
>     <mikael.gerdin at oracle.com <mailto:mikael.gerdin at oracle.com>>; Per
>     Liden <per.liden at oracle.com <mailto:per.liden at oracle.com>>; Stefan
>     Karlsson <stefan.karlsson at oracle.com
>     <mailto:stefan.karlsson at oracle.com>>; Stephen Fitch
>     <stephen.fitch at oracle.com <mailto:stephen.fitch at oracle.com>>
>     *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace
>     initialization queries the wrong chunk freelist
> 
>     Hi Muthusamy,
> 
>     Looks okay. But are there gtests already in jdk8u? I thought gtests
>     came with jdk9?
> 
>     http://openjdk.java.net/jeps/281
> 
>     If not, how does
>     http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html
>     run or even compile?
> 
>     Thanks, Thomas
> 
>     On Wed, Nov 15, 2017 at 11:19 AM, Muthusamy Chinnathambi
>     <muthusamy.chinnathambi at oracle.com
>     <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
> 
>         Hi,
> 
>         Could someone please review this backport.
> 
>         Regards,
>         Muthusamy C
> 
>         -----Original Message-----
>         From: Muthusamy Chinnathambi
> 
>         Sent: Friday, November 10, 2017 3:27 PM
>         To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>         <mailto:hotspot-dev at openjdk.java.net>>
>         Cc: Mikael Gerdin <mikael.gerdin at oracle.com
>         <mailto:mikael.gerdin at oracle.com>>
>         Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace
>         initialization queries the wrong chunk freelist
> 
>         Hi,
> 
>         Can someone please review this.
> 
>         Thanks!
>         Muthusamy C
> 
>         -----Original Message-----
>         From: Muthusamy Chinnathambi
>         Sent: Wednesday, November 8, 2017 11:24 AM
>         To: Thomas St?fe <thomas.stuefe at gmail.com
>         <mailto:thomas.stuefe at gmail.com>>
>         Cc: Mikael Gerdin <mikael.gerdin at oracle.com
>         <mailto:mikael.gerdin at oracle.com>>; HotSpot Open Source
>         Developers <hotspot-dev at openjdk.java.net
>         <mailto:hotspot-dev at openjdk.java.net>>
>         Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace
>         initialization queries the wrong chunk freelist
> 
>         Hi Thomas,
> 
> 
> 
>          > ?the webrev link seems to be dead.
> 
>         Sorry for the trouble.
> 
>         Please find the corrected link below
> 
>         http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/
> 
> 
> 
>         Somehow the line following the link got appended to the previous
>         one leading to a dead link.
> 
> 
> 
>         Regards,
> 
>         Muthusamy C
> 
> 
> 
>         From: Thomas St?fe [mailto:thomas.stuefe at gmail.com
>         <mailto:thomas.stuefe at gmail.com>]
>         Sent: Tuesday, November 7, 2017 8:12 PM
>         To: Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com
>         <mailto:muthusamy.chinnathambi at oracle.com>>
>         Cc: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>         <mailto:hotspot-dev at openjdk.java.net>>; Mikael Gerdin
>         <mikael.gerdin at oracle.com <mailto:mikael.gerdin at oracle.com>>
>         Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace
>         initialization queries the wrong chunk freelist
> 
> 
> 
>         Hi Muthusamy,
> 
> 
> 
>         the webrev link seems to be dead.
> 
> 
> 
>         ..Thomas
> 
> 
> 
>         On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi
>         <HYPERLINK "mailto:muthusamy.chinnathambi at oracle.com
>         <mailto:muthusamy.chinnathambi at oracle.com>"muthusamy.chinnathambi at oracle.com
>         <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
> 
>         Hi,
> 
>         Please review the backport of bug: "JDK-8170395: Metaspace
>         initialization queries the wrong chunk freelist" to jdk8u-dev
> 
>         Please note that this is not a clean backport due to new entries
>         in debug.cpp and copyright changes.
> 
> 
>         Webrev: HYPERLINK
>         "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/
>         jdk9
>         <http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9> bug:
>         https://bugs.openjdk.java.net/browse/JDK-8170395
>         Original patch pushed to jdk9:
>         http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a
> 
>         Test:? Had run jtreg and jprt hotspot testsets.
> 
>         Regards,
>         Muthusamy C
> 

From stefan.karlsson at oracle.com  Wed Dec  6 12:17:02 2017
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 6 Dec 2017 13:17:02 +0100
Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization
 queries the wrong chunk freelist
In-Reply-To: <ab4920cf-9b5b-41e3-87c4-617a63c05e33@default>
References: <811da80f-e107-4d0c-903b-c109b592176e@default>
 <CAA-vtUx0QjH4QCHTNDCq1JA+-+OzMO6M1+pjOvSJ7H0g1YgzXQ@mail.gmail.com>
 <6e7c7f30-599d-4558-8c84-0360f0535cf4@default>
 <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default>
 <d55656db-f114-400c-895f-3e7878cde3fa@default>
 <CAA-vtUxYmBnr7qH+ut__D7-5roUE9OD7OmQ6yZi+xse9SrHeEQ@mail.gmail.com>
 <1c305b2e-ae87-4161-b094-c5407e9f389e@default>
 <CAA-vtUztTsFCtHUchuHRtgSw_pbxCu9qK85gZF-Y72GsSa1WzA@mail.gmail.com>
 <94651bf0-3eaa-406a-89b3-361c8408ce19@default>
 <6862edf2-71eb-b600-d49f-7e0f765e772b@oracle.com>
 <ab4920cf-9b5b-41e3-87c4-617a63c05e33@default>
Message-ID: <8db8fcaa-7a7f-4cd2-034f-4af05bbec7bd@oracle.com>



On 2017-12-06 12:54, Muthusamy Chinnathambi wrote:
> Hi Stefan,
> 
> Thanks for the review
> 
>> 1) Can you make sure that the unit test gets hooked into
>> execute_internal_vm_test in:
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/b0f7174de2c5/src/share/vm/prims/jni.cpp
> 
>> And test it with:
>> -XX:+ExecuteInternalVMTests
> Yes. Please find the updated webrev at http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.02/  .
> Tested with  -XX:+ExecuteInternalVMTests as well.

Thanks, that looks good to me.

StefanK

> 
>> 2) report_insufficient_metaspace has been removed in later JDKs. Ioi, is
>> this addition of report_insufficient_metaspace OK?
> I think yes.  JDK9 still has this, although seem to have been removed in 10.
> 
>> The backport of metaspace.cpp and metaspace.hpp looks fine but I haven't
>> tracked all changes to the metaspace files for 8u-dev so a second pair
>> of eyes would be good.
> Agreed.
> Thomas St?fe had reviewed it, although he had the concern of execution of the test case.
> The updated webrev should address it.
> 
> Regards,
> Muthusamy C
> 
> 
> -----Original Message-----
> From: Stefan Karlsson
> Sent: Tuesday, December 5, 2017 4:53 PM
> To: Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com>; Thomas St?fe <thomas.stuefe at gmail.com>; Ioi Lam <ioi.lam at oracle.com>
> Cc: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; Per Liden <per.liden at oracle.com>; Stephen Fitch <stephen.fitch at oracle.com>
> Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist
> 
> Hi Muthusamy,
> 
> The backport of metaspace.cpp and metaspace.hpp looks fine but I haven't
> tracked all changes to the metaspace files for 8u-dev so a second pair
> of eyes would be good.
> 
> Two things:
> 
> 1) Can you make sure that the unit test gets hooked into
> execute_internal_vm_test in:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/b0f7174de2c5/src/share/vm/prims/jni.cpp
> 
> And test it with:
> -XX:+ExecuteInternalVMTests
> 
> 
> 2) report_insufficient_metaspace has been removed in later JDKs. Ioi, is
> this addition of report_insufficient_metaspace OK?
> 
> Thanks,
> StefanK
> 
> 
> On 2017-11-17 09:59, Muthusamy Chinnathambi wrote:
>> Hi Thomas,
>>
>> Thanks for the review.
>>
>>> . I also would prefer that the gtests you omitted should be part of the
>> change (I think before there were gtests, these kind of tests were
>> implemented as file-local static test functions and called I think via
>> whitebox.cpp ? But I wait what others say.
>>
>> Yes, the test is part of
>> https://bugs.openjdk.java.net/browse/JDK-8169931 . I would be
>> backporting this as well, just that I didn?t want to pollute the current BP.
>>
>> Regards,
>>
>> Muthusamy C
>>
>> *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> *Sent:* Friday, November 17, 2017 2:21 PM
>> *To:* Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com>
>> *Cc:* HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; Per
>> Liden <per.liden at oracle.com>; Stefan Karlsson
>> <stefan.karlsson at oracle.com>; Stephen Fitch <stephen.fitch at oracle.com>
>> *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace
>> initialization queries the wrong chunk freelist
>>
>> Hi Muthusamy,
>>
>>   From the look of it updated webrev looks fine, but I do not have the
>> time to build and check on jdk8u. I also would prefer that the gtests
>> you omitted should be part of the change (I think before there were
>> gtests, these kind of tests were implemented as file-local static test
>> functions and called I think via whitebox.cpp ? But I wait what others say.
>>
>> Someone from Oracle should confirm this patch. Note that Mikael left
>> Oracle, I took him off the reply list because mail bounce.
>>
>> Kind Regards, Thomas
>>
>> On Thu, Nov 16, 2017 at 10:08 AM, Muthusamy Chinnathambi
>> <muthusamy.chinnathambi at oracle.com
>> <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
>>
>>      Hi Thomas,
>>
>>      Thanks for the review.
>>
>>       > But are there gtests already in jdk8u? I thought gtests came with
>>      jdk9?
>>
>>       > http://openjdk.java.net/jeps/281
>>
>>       > If not, how does
>>      http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html
>>      run or even compile?
>>
>>      Yes, you are right. "test_spaceManager.cpp" should not have been
>>      included here.
>>
>>      Please find the updated webrev at
>>      http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.01/? .
>>
>>      Regards,
>>
>>      Muthusamy C
>>
>>      *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com
>>      <mailto:thomas.stuefe at gmail.com>]
>>      *Sent:* Wednesday, November 15, 2017 6:30 PM
>>      *To:* Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com
>>      <mailto:muthusamy.chinnathambi at oracle.com>>
>>      *Cc:* HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>>      <mailto:hotspot-dev at openjdk.java.net>>; Mikael Gerdin
>>      <mikael.gerdin at oracle.com <mailto:mikael.gerdin at oracle.com>>; Per
>>      Liden <per.liden at oracle.com <mailto:per.liden at oracle.com>>; Stefan
>>      Karlsson <stefan.karlsson at oracle.com
>>      <mailto:stefan.karlsson at oracle.com>>; Stephen Fitch
>>      <stephen.fitch at oracle.com <mailto:stephen.fitch at oracle.com>>
>>      *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace
>>      initialization queries the wrong chunk freelist
>>
>>      Hi Muthusamy,
>>
>>      Looks okay. But are there gtests already in jdk8u? I thought gtests
>>      came with jdk9?
>>
>>      http://openjdk.java.net/jeps/281
>>
>>      If not, how does
>>      http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html
>>      run or even compile?
>>
>>      Thanks, Thomas
>>
>>      On Wed, Nov 15, 2017 at 11:19 AM, Muthusamy Chinnathambi
>>      <muthusamy.chinnathambi at oracle.com
>>      <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
>>
>>          Hi,
>>
>>          Could someone please review this backport.
>>
>>          Regards,
>>          Muthusamy C
>>
>>          -----Original Message-----
>>          From: Muthusamy Chinnathambi
>>
>>          Sent: Friday, November 10, 2017 3:27 PM
>>          To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>>          <mailto:hotspot-dev at openjdk.java.net>>
>>          Cc: Mikael Gerdin <mikael.gerdin at oracle.com
>>          <mailto:mikael.gerdin at oracle.com>>
>>          Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace
>>          initialization queries the wrong chunk freelist
>>
>>          Hi,
>>
>>          Can someone please review this.
>>
>>          Thanks!
>>          Muthusamy C
>>
>>          -----Original Message-----
>>          From: Muthusamy Chinnathambi
>>          Sent: Wednesday, November 8, 2017 11:24 AM
>>          To: Thomas St?fe <thomas.stuefe at gmail.com
>>          <mailto:thomas.stuefe at gmail.com>>
>>          Cc: Mikael Gerdin <mikael.gerdin at oracle.com
>>          <mailto:mikael.gerdin at oracle.com>>; HotSpot Open Source
>>          Developers <hotspot-dev at openjdk.java.net
>>          <mailto:hotspot-dev at openjdk.java.net>>
>>          Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace
>>          initialization queries the wrong chunk freelist
>>
>>          Hi Thomas,
>>
>>
>>
>>           > ?the webrev link seems to be dead.
>>
>>          Sorry for the trouble.
>>
>>          Please find the corrected link below
>>
>>          http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/
>>
>>
>>
>>          Somehow the line following the link got appended to the previous
>>          one leading to a dead link.
>>
>>
>>
>>          Regards,
>>
>>          Muthusamy C
>>
>>
>>
>>          From: Thomas St?fe [mailto:thomas.stuefe at gmail.com
>>          <mailto:thomas.stuefe at gmail.com>]
>>          Sent: Tuesday, November 7, 2017 8:12 PM
>>          To: Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com
>>          <mailto:muthusamy.chinnathambi at oracle.com>>
>>          Cc: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>>          <mailto:hotspot-dev at openjdk.java.net>>; Mikael Gerdin
>>          <mikael.gerdin at oracle.com <mailto:mikael.gerdin at oracle.com>>
>>          Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace
>>          initialization queries the wrong chunk freelist
>>
>>
>>
>>          Hi Muthusamy,
>>
>>
>>
>>          the webrev link seems to be dead.
>>
>>
>>
>>          ..Thomas
>>
>>
>>
>>          On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi
>>          <HYPERLINK "mailto:muthusamy.chinnathambi at oracle.com
>>          <mailto:muthusamy.chinnathambi at oracle.com>"muthusamy.chinnathambi at oracle.com
>>          <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
>>
>>          Hi,
>>
>>          Please review the backport of bug: "JDK-8170395: Metaspace
>>          initialization queries the wrong chunk freelist" to jdk8u-dev
>>
>>          Please note that this is not a clean backport due to new entries
>>          in debug.cpp and copyright changes.
>>
>>
>>          Webrev: HYPERLINK
>>          "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/
>>          jdk9
>>          <http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9> bug:
>>          https://bugs.openjdk.java.net/browse/JDK-8170395
>>          Original patch pushed to jdk9:
>>          http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a
>>
>>          Test:? Had run jtreg and jprt hotspot testsets.
>>
>>          Regards,
>>          Muthusamy C
>>

From joe.darcy at oracle.com  Wed Dec  6 23:15:57 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 6 Dec 2017 15:15:57 -0800
Subject: Fw: Question about JEP 306.
In-Reply-To: <5A275C3D.4060208@oracle.com>
References: <SL2P216MB0588D4C8406A9B1A11687B859A250@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB05880BCC26D99108133DE5CA9A3B0@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB05888FD4F6A7FA939018219C9A380@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <SL2P216MB0588EBFF1F8B191899B3C7E29A320@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <2a493b34-a717-852b-23a8-d8827be0f61e@oracle.com>
 <5A275C3D.4060208@oracle.com>
Message-ID: <30fb449a-63de-63ee-b7e9-b8b86aa63301@oracle.com>

PS With a more concrete example below....


On 12/5/2017 6:55 PM, Joseph D. Darcy wrote:
> Hello,
>
> On 12/5/2017 5:07 PM, David Holmes wrote:
>> Adding core-libs-dev as both mailing lists are named in this JEP.
>

[snip]

>>> It should also be the case
>>> that there should be a round half up for the decimal place
>>> beyond the last one in the float or double range, to help support
>>> all notions of
>>>
>>> (pow(sqrt(3),2) == 3)  //true
>
> Putting aside non-finite values like NaN and infinities, this identity 
> is difficult to have hold in any fixed-precision system, including 
> IEEE-style floating-point. The mathematical square root function in 
> general returns irrational results for rational inputs so the result 
> is fundamentally approximated.  If my rusty calculus is correct, for x 
> >= 0.25, the derivative of sqrt of x has magnitude less than one and 
> is positive, meaning there exists some set of multiple input values 
> that must get mapped to the same output value. Therefore, the 
> information to do an exact inverse operation based on the output is 
> not present just from a pigeon hole principle argument.

Consider the square root function on the interval [1, 2), that is the 
half-open region that includes 1 but does not include 2. This 
corresponds to the floating-point numbers with an exponent of 0. There 
are 2^52 floating-point values with this exponent. Mathematically, 
sqrt(1) = 1 and sqrt(2) ~= 1.414... Therefore, in floating-point, for 
values 1.0 <= x < 2.0, the result of sqrt(x) also has an exponent of 0. 
Now we see that there are 2^52 floating-point values with an exponent of 
0 and taking a square root of those values will only yield about 0.414 * 
2^52 distinct answers. Therefore, we see that using a fixed 
floating-point precision, the square root function on [1.0, 2.0) 
*cannot* be inverted losslessly since only a minority of the input 
elements have distinct answers.

HTH,

-Joe

From david.holmes at oracle.com  Thu Dec  7 01:25:03 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 7 Dec 2017 11:25:03 +1000
Subject: JNI ReleasePrimitiveArrayCritical with mode JNI_COMMIT shouldn't
 end critical region
In-Reply-To: <CAP-5=fXv4inQiVpk5Ey1Qhy_N+hSmGuciXcZN_k-1U0+pDKqAA@mail.gmail.com>
References: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>
 <3d676bb0-f7d3-ec40-cfb8-6a905f79a434@oracle.com>
 <CAP-5=fXv4inQiVpk5Ey1Qhy_N+hSmGuciXcZN_k-1U0+pDKqAA@mail.gmail.com>
Message-ID: <b72ab75b-84fd-2ec2-3b62-6e720052231e@oracle.com>

Hi Ian,

On 7/12/2017 4:48 AM, Ian Rogers wrote:
> Thanks David, I think we may have differing opinions on clarity :-) In 
> the case of -Xcheck:jni and with HotSpot a copy is always made, and so 

Ah I see. I was considering only the "real" functionality.

The fact the checked version of getPrimitiveArrayCritical creates a copy 
seems to be treated as an internal detail as it does not AFAICS report 
that a copy was in fact made - the passed in isCopy pointer will be set 
false by the real getPrimitiveArrayCritical.

> perhaps the attached patch causes the implementation to match the spec. 

The whole logic surrounding the management of the copy seems somewhat 
suspect to me. As you note with your patch check_wrapped_array_release 
honours the mode, which in the checked case allows, AFAICS, the 
internally made copy to "leak". So ignoring the passed in mode and 
always passing 0 to check_wrapped_array_release seems more correct.

> Given that commit doesn't free a copy, is it intended behavior that in 
> HotSpot it ends a critical region? ie In a VM that allowed copies you 
> could imagine, Get, Commit, Release and as spec-ed the critical region 
> ends at the commit if not a copy, and at the release if it is. Perhaps 
> the simplest thing is to remove the notion of commit here.

I honestly do not know what this API is really trying to achieve in that 
regard. I don't know the intended usage of "commit" mode. Why would you 
not free the copied buffer? The spec unhelpfully only states:

"The other options give the programmer more control over memory 
management and should be used with extreme care."

And if you don't free it what can you do with it? For Get*ArrayElements 
it clearly states

"The result is valid until the corresponding 
Release<PrimitiveType>ArrayElements() function is called."

so once any Release* is done, regardless of mode, it would seem the 
array (copy or not) is no longer valid and should not be accessed again. 
So I don't see any expectation that you can call Release* multiple times 
and so in terms of the critical variants I expect the critical section 
to end when Release is called - regardless of mode.

David

> Thanks,
> Ian
> 
> On Tue, Dec 5, 2017 at 4:37 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Ian,
> 
>     On 6/12/2017 9:15 AM, Ian Rogers wrote:
> 
>         From:
>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical>
> 
> 
>     You need to see the updated spec:
> 
>     https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical
>     <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical>
> 
>     That spec makes it clear:
> 
>     "mode: the release mode (see Primitive Array Release Modes): 0,
>     JNI_COMMIT or JNI_ABORT. Ignored if carray was a not copy."
> 
>     In hotspot getCriticalArrayPrimitive never returns a copy so the
>     mode is always ignored, as per the existing comment.
> 
>     David
>     -----
> 
> 
>         "The semantics of these two functions are very similar to the
>         existing
>         Get/Release<primitivetype>ArrayElements functions. "
> 
>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines>
> 
>         "JNI_COMMIT copy back the content but do not free the elems buffer"
> 
>         Consider the pattern of:
>         GetPrimitiveArrayCritical(...)
>         ReleasePrimitiveArrayCritical(..., JNI_COMMIT)
>         ReleasePrimitiveArrayCritical(..., 0)
> 
>         where the first release is to just achieve a copy back. For example,
>         jniCheck.cpp will copy back but not free a copy in the case of
>         JNI_COMMIT
>         for a critical. The implementation of
>         ReleasePrimitiveArrayCritical ignores
>         all arguments and so it ends the critical region even in the
>         event of a
>         commit.
> 
>         The attached patch makes ReleasePrimitiveArrayCritical consider
>         the mode
>         argument when releasing the GCLocker.
> 
>         Thanks,
>         Ian
> 
> 

From poweruserm at live.com.au  Thu Dec  7 01:39:05 2017
From: poweruserm at live.com.au (A Z)
Date: Thu, 7 Dec 2017 01:39:05 +0000
Subject: Java SE Maths questions.
In-Reply-To: <mailman.38989.1512561485.26058.hotspot-dev@openjdk.java.net>
References: <mailman.38989.1512561485.26058.hotspot-dev@openjdk.java.net>
Message-ID: <SL2P216MB05887BF4C5B3729F498D91949A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>

These are Java SE questions.

-Is it likely that JEP 306 could be updated in a Java update, earlier?
Apart from the assertion 'will not fix', accurate floating point
is a massive requirement.  It isn't very possible to do within-range
float or double multiplies, divides, powers, roots, or even things
in other classes like obtaining the distances between two points
(in Java2D and Java3D).

-Could there be a BigDecimal version of StrictMath
being put in to the standard libraries, under Java's own umbrella,
and not as someone else's separate library?


From david.holmes at oracle.com  Thu Dec  7 02:02:15 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 7 Dec 2017 12:02:15 +1000
Subject: Java SE Maths questions.
In-Reply-To: <SL2P216MB05887BF4C5B3729F498D91949A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
References: <mailman.38989.1512561485.26058.hotspot-dev@openjdk.java.net>
 <SL2P216MB05887BF4C5B3729F498D91949A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
Message-ID: <5883ca2a-f0a6-703a-0658-f2846a4a96d6@oracle.com>

cc'ing core-libs-dev. Despite the notation on JEP 306 I don't think 
there's anyone from hotspot active in this area and most of the below is 
about SE library classes.

David

On 7/12/2017 11:39 AM, A Z wrote:
> These are Java SE questions.
> 
> -Is it likely that JEP 306 could be updated in a Java update, earlier?
> Apart from the assertion 'will not fix', accurate floating point
> is a massive requirement.  It isn't very possible to do within-range
> float or double multiplies, divides, powers, roots, or even things
> in other classes like obtaining the distances between two points
> (in Java2D and Java3D).
> 
> -Could there be a BigDecimal version of StrictMath
> being put in to the standard libraries, under Java's own umbrella,
> and not as someone else's separate library?
> 

From poweruserm at live.com.au  Thu Dec  7 02:04:40 2017
From: poweruserm at live.com.au (A Z)
Date: Thu, 7 Dec 2017 02:04:40 +0000
Subject: hotspot-dev Digest, Vol 128, Issue 13
In-Reply-To: <mailman.39087.1512610965.26058.hotspot-dev@openjdk.java.net>
References: <mailman.39087.1512610965.26058.hotspot-dev@openjdk.java.net>
Message-ID: <SL2P216MB058869F14201818789256E729A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>

These are Java SE questions.

-Is it likely that JEP 306 could be updated in a Java update, earlier?
Apart from the assertion 'will not fix', accurate floating point
is a massive requirement.  It isn't very possible to do within-range
float or double multiplies, divides, powers, roots, or even things
in other classes like obtaining the distances between two points
(in Java2D and Java3D).

-Could there be a BigDecimal version of StrictMath
being put in to the standard libraries, under Java's own umbrella,
and not as someone else's separate library?


'Consider the square root function on the interval [1, 2), that is the
half-open region that includes 1 but does not include 2. This
corresponds to the floating-point numbers with an exponent of 0. There
are 2^52 floating-point values with this exponent. Mathematically,
sqrt(1) = 1 and sqrt(2) ~= 1.414... Therefore, in floating-point, for
values 1.0 <= x < 2.0, the result of sqrt(x) also has an exponent of 0.
Now we see that there are 2^52 floating-point values with an exponent of
0 and taking a square root of those values will only yield about 0.414 *
2^52 distinct answers. Therefore, we see that using a fixed
floating-point precision, the square root function on [1.0, 2.0)
*cannot* be inverted losslessly since only a minority of the input
elements have distinct answers.'

It is the case, however, that if the policy is taken, even slightly beyond the range of a decimal value,
e.g. that if the precision is 64, you can rationally aim to get the obverse and inverse of
a value in a function call if you round HALF_UP by means of considering the decimal
in precision 65, which is what I'm trying to suggest.  Some extra logic at the boundary zone,
to facilitate

(pow(sqrt(3),2) == 3) //true


From joe.darcy at oracle.com  Thu Dec  7 02:15:29 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 06 Dec 2017 18:15:29 -0800
Subject: Java SE Maths questions.
In-Reply-To: <5883ca2a-f0a6-703a-0658-f2846a4a96d6@oracle.com>
References: <mailman.38989.1512561485.26058.hotspot-dev@openjdk.java.net>
 <SL2P216MB05887BF4C5B3729F498D91949A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
 <5883ca2a-f0a6-703a-0658-f2846a4a96d6@oracle.com>
Message-ID: <5A28A441.6080901@oracle.com>


On 12/6/2017 6:02 PM, David Holmes wrote:
> cc'ing core-libs-dev. Despite the notation on JEP 306 I don't think 
> there's anyone from hotspot active in this area and most of the below 
> is about SE library classes.
>
> David
>
> On 7/12/2017 11:39 AM, A Z wrote:
>> These are Java SE questions.
>>
>> -Is it likely that JEP 306 could be updated in a Java update, earlier?
>> Apart from the assertion 'will not fix', accurate floating point
>> is a massive requirement.  It isn't very possible to do within-range
>> float or double multiplies, divides, powers, roots, or even things
>> in other classes like obtaining the distances between two points
>> (in Java2D and Java3D).
>>
>> -Could there be a BigDecimal version of StrictMath
>> being put in to the standard libraries, under Java's own umbrella,
>> and not as someone else's separate library?
>>

The answer to this question hasn't changed since I answered it yesterday 
[1] or from when the same question was asked and answered by via a web 
bug a month ago. [2]

If the same question is asked again tomorrow in this or another venue 
the answer will be the same and I will not respond again explicitly.

-Joe

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050357.html

[2] https://bugs.openjdk.java.net/browse/JDK-8190947

From david.holmes at oracle.com  Thu Dec  7 02:54:59 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 7 Dec 2017 12:54:59 +1000
Subject: hotspot-dev Digest, Vol 128, Issue 13
In-Reply-To: <SL2P216MB058869F14201818789256E729A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
References: <mailman.39087.1512610965.26058.hotspot-dev@openjdk.java.net>
 <SL2P216MB058869F14201818789256E729A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
Message-ID: <8ed2c779-5105-834c-c993-41c3ecacf506@oracle.com>

"A Z" you already basically asked this in your "Java SE Maths questions" 
thread. Please don't create multiple threads on the same issue - and 
please never use the subject "hotspot-dev Digest, Vol XXX, Issue NN" - 
if replying to a digest please add the correct subject.

Thank you.
David

On 7/12/2017 12:04 PM, A Z wrote:
> These are Java SE questions.
> 
> -Is it likely that JEP 306 could be updated in a Java update, earlier?
> Apart from the assertion 'will not fix', accurate floating point
> is a massive requirement.  It isn't very possible to do within-range
> float or double multiplies, divides, powers, roots, or even things
> in other classes like obtaining the distances between two points
> (in Java2D and Java3D).
> 
> -Could there be a BigDecimal version of StrictMath
> being put in to the standard libraries, under Java's own umbrella,
> and not as someone else's separate library?
> 
> 
> 'Consider the square root function on the interval [1, 2), that is the
> half-open region that includes 1 but does not include 2. This
> corresponds to the floating-point numbers with an exponent of 0. There
> are 2^52 floating-point values with this exponent. Mathematically,
> sqrt(1) = 1 and sqrt(2) ~= 1.414... Therefore, in floating-point, for
> values 1.0 <= x < 2.0, the result of sqrt(x) also has an exponent of 0.
> Now we see that there are 2^52 floating-point values with an exponent of
> 0 and taking a square root of those values will only yield about 0.414 *
> 2^52 distinct answers. Therefore, we see that using a fixed
> floating-point precision, the square root function on [1.0, 2.0)
> *cannot* be inverted losslessly since only a minority of the input
> elements have distinct answers.'
> 
> It is the case, however, that if the policy is taken, even slightly beyond the range of a decimal value,
> e.g. that if the precision is 64, you can rationally aim to get the obverse and inverse of
> a value in a function call if you round HALF_UP by means of considering the decimal
> in precision 65, which is what I'm trying to suggest.  Some extra logic at the boundary zone,
> to facilitate
> 
> (pow(sqrt(3),2) == 3) //true
> 

From coleen.phillimore at oracle.com  Thu Dec  7 04:27:35 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 6 Dec 2017 23:27:35 -0500
Subject: RFR (M) 8186903: Remove j-types from Atomic
In-Reply-To: <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com>
References: <eb7efe57-e17b-4050-e837-691817829f23@oracle.com>
 <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com>
 <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com>
Message-ID: <b02e1d4c-7e0f-1cd5-c282-bd68d671d11c@oracle.com>

resending.

On 12/6/17 11:00 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 12/6/17 9:41 PM, David Holmes wrote:
>> Hi Coleen,
>>
>> On 7/12/2017 7:59 AM, coleen.phillimore at oracle.com wrote:
>>> Summary: Change parameter types from jlong, jint, jbyte to int64_t, 
>>> int32_t and int8_t respectively
>>
>> That's fine. But you also made a bunch of changes to rename the "ptr" 
>> variants to "long", and in the process changed intptr_t to int64_t. 
>> The change ptr->long isn't really accurate. And intptr_t and int64_t 
>> are different sizes on 32-bit! So this change seems problematic and 
>> out of scope by your own description. That said I thought we had/were 
>> getting rid of the "ptr" variants ??
>
> Yes, I did rename atomic_add_ptr_entry to atomic_add_long_entry. This 
> is to match the other names which are currently empty, "long" and 
> "byte".?? This was a last vestige of the ptr variants.?? It's only 
> used on 64 bit windows, so changing it to intptr_t to int64_t is 
> correct.?? For some reason, there isn't a long variant on 32 bits.? 
> Possibly because we don't add jlong values in the vm?
> ent
> So this renaming makes it consistent with the other names, which then 
> can all be changed at once, when nice names are agreed upon.
>>
>>> Leave renaming functions for later change.
>>>
>>> Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on 
>>> windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero 
>>> product mode (fails building fastdebug for some other reason).
>>>
>>> Other platforms: could you please test this patch?
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186903
>>>
>>> This change is for JDK 11.
>>
>> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp
>>
>> Return type should be int32_t not int
>>
>> src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp
>>
>> -? static intptr_t? (*atomic_xchg_long_func)???? (jlong, volatile 
>> jlong*);
>> -? static intptr_t? atomic_xchg_long_bootstrap?? (jlong, volatile 
>> jlong*);
>>
>> Wow - that looks like a bug! Only returns 32-bits on 32-bit!
>
> This one also is only used on 64 bit.? I have to confess I don't 
> follow all the paths of the atomics and their various translations 
> down to the platform levels.?? I'm not sure how windows 32 bit calls 
> atomic_add or xchg for 64 bit values (or if it is not implemented).
>>
>> Everything else seems fine.
>>
>
> Thanks for the eagle eye review.
> Coleen
>> Thanks,
>> David
>>
>>> Thanks,
>>> Coleen
>


From david.holmes at oracle.com  Thu Dec  7 05:00:54 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 7 Dec 2017 15:00:54 +1000
Subject: JNI ReleasePrimitiveArrayCritical with mode JNI_COMMIT shouldn't
 end critical region
In-Reply-To: <CAP-5=fWZacKq7cjXfJ_+TcOsH-FAA9eKGzZ-L62kMHOmcqUyjg@mail.gmail.com>
References: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>
 <3d676bb0-f7d3-ec40-cfb8-6a905f79a434@oracle.com>
 <CAP-5=fXv4inQiVpk5Ey1Qhy_N+hSmGuciXcZN_k-1U0+pDKqAA@mail.gmail.com>
 <b72ab75b-84fd-2ec2-3b62-6e720052231e@oracle.com>
 <CAP-5=fWZacKq7cjXfJ_+TcOsH-FAA9eKGzZ-L62kMHOmcqUyjg@mail.gmail.com>
Message-ID: <788e54e9-7019-eb59-e9d6-bf0ed538e9d9@oracle.com>

On 7/12/2017 2:55 PM, Ian Rogers wrote:
> Thanks, fwiw Jikes RVM agrees that all critical releases end the 
> critical region:
> https://github.com/JikesRVM/JikesRVM/blob/master/rvm/src/org/jikesrvm/jni/JNIFunctions.java#L5936
> 
> As does Cacao:
> http://mips.complang.tuwien.ac.at/hg/cacao/file/2b4c9b6c245d/src/native/jni.cpp#l3208
> 
> Kaffe (with a non-moving GC) treats the release in the same way as 
> Release<Primitive>ArrayElements:
> https://github.com/kaffe/kaffe/blob/master/kaffe/kaffevm/jni/jni-arrays.c#L404
> which is the same as how it is handled on Android.
> 
> HotSpot has managed to put a foot in both camps, ending the critical 
> always (a la Jikes RVM and Cacao) but honoring commit behavior (and 
> leaking) when in -Xcheck:jni.

So ... I should file a bug for the leak in the checked version and apply 
your suggested patch to always pass mode 0?

Thanks,
David


> Thanks,
> Ian
> 
> On Wed, Dec 6, 2017 at 5:25 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Ian,
> 
>     On 7/12/2017 4:48 AM, Ian Rogers wrote:
> 
>         Thanks David, I think we may have differing opinions on clarity
>         :-) In the case of -Xcheck:jni and with HotSpot a copy is always
>         made, and so
> 
> 
>     Ah I see. I was considering only the "real" functionality.
> 
>     The fact the checked version of getPrimitiveArrayCritical creates a
>     copy seems to be treated as an internal detail as it does not AFAICS
>     report that a copy was in fact made - the passed in isCopy pointer
>     will be set false by the real getPrimitiveArrayCritical.
> 
>         perhaps the attached patch causes the implementation to match
>         the spec.
> 
> 
>     The whole logic surrounding the management of the copy seems
>     somewhat suspect to me. As you note with your patch
>     check_wrapped_array_release honours the mode, which in the checked
>     case allows, AFAICS, the internally made copy to "leak". So ignoring
>     the passed in mode and always passing 0 to
>     check_wrapped_array_release seems more correct.
> 
>         Given that commit doesn't free a copy, is it intended behavior
>         that in HotSpot it ends a critical region? ie In a VM that
>         allowed copies you could imagine, Get, Commit, Release and as
>         spec-ed the critical region ends at the commit if not a copy,
>         and at the release if it is. Perhaps the simplest thing is to
>         remove the notion of commit here.
> 
> 
>     I honestly do not know what this API is really trying to achieve in
>     that regard. I don't know the intended usage of "commit" mode. Why
>     would you not free the copied buffer? The spec unhelpfully only states:
> 
>     "The other options give the programmer more control over memory
>     management and should be used with extreme care."
> 
>     And if you don't free it what can you do with it? For
>     Get*ArrayElements it clearly states
> 
>     "The result is valid until the corresponding
>     Release<PrimitiveType>ArrayElements() function is called."
> 
>     so once any Release* is done, regardless of mode, it would seem the
>     array (copy or not) is no longer valid and should not be accessed
>     again. So I don't see any expectation that you can call Release*
>     multiple times and so in terms of the critical variants I expect the
>     critical section to end when Release is called - regardless of mode.
> 
>     David
> 
>         Thanks,
>         Ian
> 
> 
>         On Tue, Dec 5, 2017 at 4:37 PM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
> 
>          ? ? Hi Ian,
> 
>          ? ? On 6/12/2017 9:15 AM, Ian Rogers wrote:
> 
>          ? ? ? ? From:
>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical>
>                 
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical>>
> 
> 
>          ? ? You need to see the updated spec:
> 
>         https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical>
>             
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical>>
> 
>          ? ? That spec makes it clear:
> 
>          ? ? "mode: the release mode (see Primitive Array Release Modes): 0,
>          ? ? JNI_COMMIT or JNI_ABORT. Ignored if carray was a not copy."
> 
>          ? ? In hotspot getCriticalArrayPrimitive never returns a copy
>         so the
>          ? ? mode is always ignored, as per the existing comment.
> 
>          ? ? David
>          ? ? -----
> 
> 
>          ? ? ? ? "The semantics of these two functions are very similar
>         to the
>          ? ? ? ? existing
>          ? ? ? ? Get/Release<primitivetype>ArrayElements functions. "
> 
>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines>
>                 
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines>>
> 
>          ? ? ? ? "JNI_COMMIT copy back the content but do not free the
>         elems buffer"
> 
>          ? ? ? ? Consider the pattern of:
>          ? ? ? ? GetPrimitiveArrayCritical(...)
>          ? ? ? ? ReleasePrimitiveArrayCritical(..., JNI_COMMIT)
>          ? ? ? ? ReleasePrimitiveArrayCritical(..., 0)
> 
>          ? ? ? ? where the first release is to just achieve a copy back.
>         For example,
>          ? ? ? ? jniCheck.cpp will copy back but not free a copy in the
>         case of
>          ? ? ? ? JNI_COMMIT
>          ? ? ? ? for a critical. The implementation of
>          ? ? ? ? ReleasePrimitiveArrayCritical ignores
>          ? ? ? ? all arguments and so it ends the critical region even
>         in the
>          ? ? ? ? event of a
>          ? ? ? ? commit.
> 
>          ? ? ? ? The attached patch makes ReleasePrimitiveArrayCritical
>         consider
>          ? ? ? ? the mode
>          ? ? ? ? argument when releasing the GCLocker.
> 
>          ? ? ? ? Thanks,
>          ? ? ? ? Ian
> 
> 
> 

From irogers at google.com  Wed Dec  6 18:48:15 2017
From: irogers at google.com (Ian Rogers)
Date: Wed, 6 Dec 2017 10:48:15 -0800
Subject: JNI ReleasePrimitiveArrayCritical with mode JNI_COMMIT shouldn't
 end critical region
In-Reply-To: <3d676bb0-f7d3-ec40-cfb8-6a905f79a434@oracle.com>
References: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>
 <3d676bb0-f7d3-ec40-cfb8-6a905f79a434@oracle.com>
Message-ID: <CAP-5=fXv4inQiVpk5Ey1Qhy_N+hSmGuciXcZN_k-1U0+pDKqAA@mail.gmail.com>

Thanks David, I think we may have differing opinions on clarity :-) In the
case of -Xcheck:jni and with HotSpot a copy is always made, and so perhaps
the attached patch causes the implementation to match the spec. Given that
commit doesn't free a copy, is it intended behavior that in HotSpot it ends
a critical region? ie In a VM that allowed copies you could imagine, Get,
Commit, Release and as spec-ed the critical region ends at the commit if
not a copy, and at the release if it is. Perhaps the simplest thing is to
remove the notion of commit here.

Thanks,
Ian

On Tue, Dec 5, 2017 at 4:37 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Ian,
>
> On 6/12/2017 9:15 AM, Ian Rogers wrote:
>
>> From:
>> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimiti
>> veArrayCritical
>>
>
> You need to see the updated spec:
>
> https://docs.oracle.com/javase/9/docs/specs/jni/functions.
> html#getprimitivearraycritical-releaseprimitivearraycritical
>
> That spec makes it clear:
>
> "mode: the release mode (see Primitive Array Release Modes): 0, JNI_COMMIT
> or JNI_ABORT. Ignored if carray was a not copy."
>
> In hotspot getCriticalArrayPrimitive never returns a copy so the mode is
> always ignored, as per the existing comment.
>
> David
> -----
>
>
> "The semantics of these two functions are very similar to the existing
>> Get/Release<primitivetype>ArrayElements functions. "
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>>
>> "JNI_COMMIT copy back the content but do not free the elems buffer"
>>
>> Consider the pattern of:
>> GetPrimitiveArrayCritical(...)
>> ReleasePrimitiveArrayCritical(..., JNI_COMMIT)
>> ReleasePrimitiveArrayCritical(..., 0)
>>
>> where the first release is to just achieve a copy back. For example,
>> jniCheck.cpp will copy back but not free a copy in the case of JNI_COMMIT
>> for a critical. The implementation of ReleasePrimitiveArrayCritical
>> ignores
>> all arguments and so it ends the critical region even in the event of a
>> commit.
>>
>> The attached patch makes ReleasePrimitiveArrayCritical consider the mode
>> argument when releasing the GCLocker.
>>
>> Thanks,
>> Ian
>>
>>

From irogers at google.com  Thu Dec  7 04:55:04 2017
From: irogers at google.com (Ian Rogers)
Date: Wed, 6 Dec 2017 20:55:04 -0800
Subject: JNI ReleasePrimitiveArrayCritical with mode JNI_COMMIT shouldn't
 end critical region
In-Reply-To: <b72ab75b-84fd-2ec2-3b62-6e720052231e@oracle.com>
References: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>
 <3d676bb0-f7d3-ec40-cfb8-6a905f79a434@oracle.com>
 <CAP-5=fXv4inQiVpk5Ey1Qhy_N+hSmGuciXcZN_k-1U0+pDKqAA@mail.gmail.com>
 <b72ab75b-84fd-2ec2-3b62-6e720052231e@oracle.com>
Message-ID: <CAP-5=fWZacKq7cjXfJ_+TcOsH-FAA9eKGzZ-L62kMHOmcqUyjg@mail.gmail.com>

Thanks, fwiw Jikes RVM agrees that all critical releases end the critical
region:
https://github.com/JikesRVM/JikesRVM/blob/master/rvm/src/org/jikesrvm/jni/JNIFunctions.java#L5936

As does Cacao:
http://mips.complang.tuwien.ac.at/hg/cacao/file/2b4c9b6c245d/src/native/jni.cpp#l3208

Kaffe (with a non-moving GC) treats the release in the same way as
Release<Primitive>ArrayElements:
https://github.com/kaffe/kaffe/blob/master/kaffe/kaffevm/jni/jni-arrays.c#L404
which is the same as how it is handled on Android.

HotSpot has managed to put a foot in both camps, ending the critical always
(a la Jikes RVM and Cacao) but honoring commit behavior (and leaking) when
in -Xcheck:jni.

Thanks,
Ian

On Wed, Dec 6, 2017 at 5:25 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Ian,
>
> On 7/12/2017 4:48 AM, Ian Rogers wrote:
>
>> Thanks David, I think we may have differing opinions on clarity :-) In
>> the case of -Xcheck:jni and with HotSpot a copy is always made, and so
>>
>
> Ah I see. I was considering only the "real" functionality.
>
> The fact the checked version of getPrimitiveArrayCritical creates a copy
> seems to be treated as an internal detail as it does not AFAICS report that
> a copy was in fact made - the passed in isCopy pointer will be set false by
> the real getPrimitiveArrayCritical.
>
> perhaps the attached patch causes the implementation to match the spec.
>>
>
> The whole logic surrounding the management of the copy seems somewhat
> suspect to me. As you note with your patch check_wrapped_array_release
> honours the mode, which in the checked case allows, AFAICS, the internally
> made copy to "leak". So ignoring the passed in mode and always passing 0 to
> check_wrapped_array_release seems more correct.
>
> Given that commit doesn't free a copy, is it intended behavior that in
>> HotSpot it ends a critical region? ie In a VM that allowed copies you could
>> imagine, Get, Commit, Release and as spec-ed the critical region ends at
>> the commit if not a copy, and at the release if it is. Perhaps the simplest
>> thing is to remove the notion of commit here.
>>
>
> I honestly do not know what this API is really trying to achieve in that
> regard. I don't know the intended usage of "commit" mode. Why would you not
> free the copied buffer? The spec unhelpfully only states:
>
> "The other options give the programmer more control over memory management
> and should be used with extreme care."
>
> And if you don't free it what can you do with it? For Get*ArrayElements it
> clearly states
>
> "The result is valid until the corresponding Release<PrimitiveType>ArrayElements()
> function is called."
>
> so once any Release* is done, regardless of mode, it would seem the array
> (copy or not) is no longer valid and should not be accessed again. So I
> don't see any expectation that you can call Release* multiple times and so
> in terms of the critical variants I expect the critical section to end when
> Release is called - regardless of mode.
>
> David
>
> Thanks,
>> Ian
>>
>>
>> On Tue, Dec 5, 2017 at 4:37 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Ian,
>>
>>     On 6/12/2017 9:15 AM, Ian Rogers wrote:
>>
>>         From:
>>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimiti
>> veArrayCritical
>>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimiti
>> veArrayCritical>
>>
>>
>>     You need to see the updated spec:
>>
>>     https://docs.oracle.com/javase/9/docs/specs/jni/functions.
>> html#getprimitivearraycritical-releaseprimitivearraycritical
>>     <https://docs.oracle.com/javase/9/docs/specs/jni/functions.
>> html#getprimitivearraycritical-releaseprimitivearraycritical>
>>
>>     That spec makes it clear:
>>
>>     "mode: the release mode (see Primitive Array Release Modes): 0,
>>     JNI_COMMIT or JNI_ABORT. Ignored if carray was a not copy."
>>
>>     In hotspot getCriticalArrayPrimitive never returns a copy so the
>>     mode is always ignored, as per the existing comment.
>>
>>     David
>>     -----
>>
>>
>>         "The semantics of these two functions are very similar to the
>>         existing
>>         Get/Release<primitivetype>ArrayElements functions. "
>>
>>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#Release_PrimitiveType_ArrayElements_routines>
>>
>>         "JNI_COMMIT copy back the content but do not free the elems
>> buffer"
>>
>>         Consider the pattern of:
>>         GetPrimitiveArrayCritical(...)
>>         ReleasePrimitiveArrayCritical(..., JNI_COMMIT)
>>         ReleasePrimitiveArrayCritical(..., 0)
>>
>>         where the first release is to just achieve a copy back. For
>> example,
>>         jniCheck.cpp will copy back but not free a copy in the case of
>>         JNI_COMMIT
>>         for a critical. The implementation of
>>         ReleasePrimitiveArrayCritical ignores
>>         all arguments and so it ends the critical region even in the
>>         event of a
>>         commit.
>>
>>         The attached patch makes ReleasePrimitiveArrayCritical consider
>>         the mode
>>         argument when releasing the GCLocker.
>>
>>         Thanks,
>>         Ian
>>
>>
>>

From dalibor.topic at oracle.com  Thu Dec  7 08:39:18 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 7 Dec 2017 09:39:18 +0100
Subject: hotspot-dev Digest, Vol 128, Issue 13
In-Reply-To: <SL2P216MB058869F14201818789256E729A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
References: <mailman.39087.1512610965.26058.hotspot-dev@openjdk.java.net>
 <SL2P216MB058869F14201818789256E729A330@SL2P216MB0588.KORP216.PROD.OUTLOOK.COM>
Message-ID: <9282282c-42a0-ee56-35e6-c7070f6130ca@oracle.com>



On 07.12.2017 03:04, A Z wrote:
> These are Java SE questions.
> 
> -Is it likely that JEP 306 could be updated in a Java update, earlier?

No.

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 muthusamy.chinnathambi at oracle.com  Thu Dec  7 09:05:24 2017
From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi)
Date: Thu, 7 Dec 2017 01:05:24 -0800 (PST)
Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization
 queries the wrong chunk freelist
In-Reply-To: <8db8fcaa-7a7f-4cd2-034f-4af05bbec7bd@oracle.com>
References: <811da80f-e107-4d0c-903b-c109b592176e@default>
 <CAA-vtUx0QjH4QCHTNDCq1JA+-+OzMO6M1+pjOvSJ7H0g1YgzXQ@mail.gmail.com>
 <6e7c7f30-599d-4558-8c84-0360f0535cf4@default>
 <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default>
 <d55656db-f114-400c-895f-3e7878cde3fa@default>
 <CAA-vtUxYmBnr7qH+ut__D7-5roUE9OD7OmQ6yZi+xse9SrHeEQ@mail.gmail.com>
 <1c305b2e-ae87-4161-b094-c5407e9f389e@default>
 <CAA-vtUztTsFCtHUchuHRtgSw_pbxCu9qK85gZF-Y72GsSa1WzA@mail.gmail.com>
 <94651bf0-3eaa-406a-89b3-361c8408ce19@default>
 <6862edf2-71eb-b600-d49f-7e0f765e772b@oracle.com>
 <ab4920cf-9b5b-41e3-87c4-617a63c05e33@default>
 <8db8fcaa-7a7f-4cd2-034f-4af05bbec7bd@oracle.com>
Message-ID: <cee06043-4f18-4dbd-af61-0a10ffade2e3@default>


Thanks a lot Stefan and Thomas.

Regards,
Muthusamy C

-----Original Message-----
From: Stefan Karlsson 
Sent: Wednesday, December 6, 2017 5:47 PM
To: Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com>; Thomas St?fe <thomas.stuefe at gmail.com>; Ioi Lam <ioi.lam at oracle.com>
Cc: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; Per Liden <per.liden at oracle.com>; Stephen Fitch <stephen.fitch at oracle.com>
Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist



On 2017-12-06 12:54, Muthusamy Chinnathambi wrote:
> Hi Stefan,
> 
> Thanks for the review
> 
>> 1) Can you make sure that the unit test gets hooked into
>> execute_internal_vm_test in:
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/b0f7174de2c5/src/share/vm/prims/jni.cpp
> 
>> And test it with:
>> -XX:+ExecuteInternalVMTests
> Yes. Please find the updated webrev at http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.02/  .
> Tested with  -XX:+ExecuteInternalVMTests as well.

Thanks, that looks good to me.

StefanK

> 
>> 2) report_insufficient_metaspace has been removed in later JDKs. Ioi, is
>> this addition of report_insufficient_metaspace OK?
> I think yes.  JDK9 still has this, although seem to have been removed in 10.
> 
>> The backport of metaspace.cpp and metaspace.hpp looks fine but I haven't
>> tracked all changes to the metaspace files for 8u-dev so a second pair
>> of eyes would be good.
> Agreed.
> Thomas St?fe had reviewed it, although he had the concern of execution of the test case.
> The updated webrev should address it.
> 
> Regards,
> Muthusamy C
> 
> 
> -----Original Message-----
> From: Stefan Karlsson
> Sent: Tuesday, December 5, 2017 4:53 PM
> To: Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com>; Thomas St?fe <thomas.stuefe at gmail.com>; Ioi Lam <ioi.lam at oracle.com>
> Cc: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; Per Liden <per.liden at oracle.com>; Stephen Fitch <stephen.fitch at oracle.com>
> Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist
> 
> Hi Muthusamy,
> 
> The backport of metaspace.cpp and metaspace.hpp looks fine but I haven't
> tracked all changes to the metaspace files for 8u-dev so a second pair
> of eyes would be good.
> 
> Two things:
> 
> 1) Can you make sure that the unit test gets hooked into
> execute_internal_vm_test in:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/b0f7174de2c5/src/share/vm/prims/jni.cpp
> 
> And test it with:
> -XX:+ExecuteInternalVMTests
> 
> 
> 2) report_insufficient_metaspace has been removed in later JDKs. Ioi, is
> this addition of report_insufficient_metaspace OK?
> 
> Thanks,
> StefanK
> 
> 
> On 2017-11-17 09:59, Muthusamy Chinnathambi wrote:
>> Hi Thomas,
>>
>> Thanks for the review.
>>
>>> . I also would prefer that the gtests you omitted should be part of the
>> change (I think before there were gtests, these kind of tests were
>> implemented as file-local static test functions and called I think via
>> whitebox.cpp ? But I wait what others say.
>>
>> Yes, the test is part of
>> https://bugs.openjdk.java.net/browse/JDK-8169931 . I would be
>> backporting this as well, just that I didn?t want to pollute the current BP.
>>
>> Regards,
>>
>> Muthusamy C
>>
>> *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> *Sent:* Friday, November 17, 2017 2:21 PM
>> *To:* Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com>
>> *Cc:* HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>; Per
>> Liden <per.liden at oracle.com>; Stefan Karlsson
>> <stefan.karlsson at oracle.com>; Stephen Fitch <stephen.fitch at oracle.com>
>> *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace
>> initialization queries the wrong chunk freelist
>>
>> Hi Muthusamy,
>>
>>   From the look of it updated webrev looks fine, but I do not have the
>> time to build and check on jdk8u. I also would prefer that the gtests
>> you omitted should be part of the change (I think before there were
>> gtests, these kind of tests were implemented as file-local static test
>> functions and called I think via whitebox.cpp ? But I wait what others say.
>>
>> Someone from Oracle should confirm this patch. Note that Mikael left
>> Oracle, I took him off the reply list because mail bounce.
>>
>> Kind Regards, Thomas
>>
>> On Thu, Nov 16, 2017 at 10:08 AM, Muthusamy Chinnathambi
>> <muthusamy.chinnathambi at oracle.com
>> <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
>>
>>      Hi Thomas,
>>
>>      Thanks for the review.
>>
>>       > But are there gtests already in jdk8u? I thought gtests came with
>>      jdk9?
>>
>>       > http://openjdk.java.net/jeps/281
>>
>>       > If not, how does
>>      http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html
>>      run or even compile?
>>
>>      Yes, you are right. "test_spaceManager.cpp" should not have been
>>      included here.
>>
>>      Please find the updated webrev at
>>      http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.01/? .
>>
>>      Regards,
>>
>>      Muthusamy C
>>
>>      *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com
>>      <mailto:thomas.stuefe at gmail.com>]
>>      *Sent:* Wednesday, November 15, 2017 6:30 PM
>>      *To:* Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com
>>      <mailto:muthusamy.chinnathambi at oracle.com>>
>>      *Cc:* HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>>      <mailto:hotspot-dev at openjdk.java.net>>; Mikael Gerdin
>>      <mikael.gerdin at oracle.com <mailto:mikael.gerdin at oracle.com>>; Per
>>      Liden <per.liden at oracle.com <mailto:per.liden at oracle.com>>; Stefan
>>      Karlsson <stefan.karlsson at oracle.com
>>      <mailto:stefan.karlsson at oracle.com>>; Stephen Fitch
>>      <stephen.fitch at oracle.com <mailto:stephen.fitch at oracle.com>>
>>      *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace
>>      initialization queries the wrong chunk freelist
>>
>>      Hi Muthusamy,
>>
>>      Looks okay. But are there gtests already in jdk8u? I thought gtests
>>      came with jdk9?
>>
>>      http://openjdk.java.net/jeps/281
>>
>>      If not, how does
>>      http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html
>>      run or even compile?
>>
>>      Thanks, Thomas
>>
>>      On Wed, Nov 15, 2017 at 11:19 AM, Muthusamy Chinnathambi
>>      <muthusamy.chinnathambi at oracle.com
>>      <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
>>
>>          Hi,
>>
>>          Could someone please review this backport.
>>
>>          Regards,
>>          Muthusamy C
>>
>>          -----Original Message-----
>>          From: Muthusamy Chinnathambi
>>
>>          Sent: Friday, November 10, 2017 3:27 PM
>>          To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>>          <mailto:hotspot-dev at openjdk.java.net>>
>>          Cc: Mikael Gerdin <mikael.gerdin at oracle.com
>>          <mailto:mikael.gerdin at oracle.com>>
>>          Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace
>>          initialization queries the wrong chunk freelist
>>
>>          Hi,
>>
>>          Can someone please review this.
>>
>>          Thanks!
>>          Muthusamy C
>>
>>          -----Original Message-----
>>          From: Muthusamy Chinnathambi
>>          Sent: Wednesday, November 8, 2017 11:24 AM
>>          To: Thomas St?fe <thomas.stuefe at gmail.com
>>          <mailto:thomas.stuefe at gmail.com>>
>>          Cc: Mikael Gerdin <mikael.gerdin at oracle.com
>>          <mailto:mikael.gerdin at oracle.com>>; HotSpot Open Source
>>          Developers <hotspot-dev at openjdk.java.net
>>          <mailto:hotspot-dev at openjdk.java.net>>
>>          Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace
>>          initialization queries the wrong chunk freelist
>>
>>          Hi Thomas,
>>
>>
>>
>>           > ?the webrev link seems to be dead.
>>
>>          Sorry for the trouble.
>>
>>          Please find the corrected link below
>>
>>          http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/
>>
>>
>>
>>          Somehow the line following the link got appended to the previous
>>          one leading to a dead link.
>>
>>
>>
>>          Regards,
>>
>>          Muthusamy C
>>
>>
>>
>>          From: Thomas St?fe [mailto:thomas.stuefe at gmail.com
>>          <mailto:thomas.stuefe at gmail.com>]
>>          Sent: Tuesday, November 7, 2017 8:12 PM
>>          To: Muthusamy Chinnathambi <muthusamy.chinnathambi at oracle.com
>>          <mailto:muthusamy.chinnathambi at oracle.com>>
>>          Cc: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net
>>          <mailto:hotspot-dev at openjdk.java.net>>; Mikael Gerdin
>>          <mikael.gerdin at oracle.com <mailto:mikael.gerdin at oracle.com>>
>>          Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace
>>          initialization queries the wrong chunk freelist
>>
>>
>>
>>          Hi Muthusamy,
>>
>>
>>
>>          the webrev link seems to be dead.
>>
>>
>>
>>          ..Thomas
>>
>>
>>
>>          On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi
>>          <HYPERLINK "mailto:muthusamy.chinnathambi at oracle.com
>>          <mailto:muthusamy.chinnathambi at oracle.com>"muthusamy.chinnathambi at oracle.com
>>          <mailto:muthusamy.chinnathambi at oracle.com>> wrote:
>>
>>          Hi,
>>
>>          Please review the backport of bug: "JDK-8170395: Metaspace
>>          initialization queries the wrong chunk freelist" to jdk8u-dev
>>
>>          Please note that this is not a clean backport due to new entries
>>          in debug.cpp and copyright changes.
>>
>>
>>          Webrev: HYPERLINK
>>          "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/
>>          jdk9
>>          <http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9> bug:
>>          https://bugs.openjdk.java.net/browse/JDK-8170395
>>          Original patch pushed to jdk9:
>>          http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a
>>
>>          Test:? Had run jtreg and jprt hotspot testsets.
>>
>>          Regards,
>>          Muthusamy C
>>

From goetz.lindenmaier at sap.com  Thu Dec  7 10:59:12 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 7 Dec 2017 10:59:12 +0000
Subject: RFR(M): 8189102: All tools should support -?, -h and --help
In-Reply-To: <c27028f9f5844c3c818885f88c75f84b@sap.com>
References: <c27028f9f5844c3c818885f88c75f84b@sap.com>
Message-ID: <8aa25976d496465fac00a4ae3628e533@sap.com>

Hi,

I prepared a fifth webrev for this change.  Please review.

It incorporates the changes requested by the CSR reviewers 
(not to remove docuemtation of '-help' where is was documented
before) and the changes proposed by Kumar:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.05/

See also the information in the webrev  itself, there are also patch files
with the incremental builds.

This change contains fixes for some langtool tests.
I ran the following test suites on it:
hotspot, jdk, langtools, nashorn, jaxp, most of them on 
all the platforms we build.

Best regards,
  Goetz.




> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Mittwoch, 11. Oktober 2017 22:07
> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> Subject: RFR(M): 8189102: All tools should support -?, -h and --help
> 
> Hi
> 
> The tools in jdk should all show the same behavior wrt. help flags.
> This change normalizes the help flags of a row of the tools in the jdk.
> Java accepts -?, -h and --help, thus I changed the tools to support
> these, too.  Some tools exited with '1' after displaying the help message,
> I turned this to '0'.
> 
> Maybe this is not the right mailing list for this, please advise.
> 
> Please review this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.01/
> 
> In detail, this fixes the help message of the following tools:
> jar          -? -h --help;  added -?.
> jarsigner    -? -h --help;  added --help. -help accepted but not documented.
> javac        -?    --help;  added -?. Removed -help. -h is taken for other purpose
> javadoc      -? -h --help;  added -h -?. Removed -help
> javap        -? -h --help;  added -h. -help accepted but no more documented.
> jcmd         -? -h --help;  added -? --help. -help accepted but no more
> documented. Changed return value to '0'
> jdb          -? -h --help;  added -? -h --help. -help accepted but no more
> documented.
> jdeprscan    -? -h --help;  added -?
> jinfo        -? -h --help;  added -? --help. -help accepted but no more
> documented.
> jjs             -h --help;  Replaced -help by --help. Adding more not straight
> forward.
> jps          -? -h --help;  added -? --help. -help accepted but no more
> documented.
> jshell       -? -h --help;  added -?
> jstat        -? -h --help;  added -h --help. -help accepted but no more
> documented.
> 
> Best regards,
>   Goetz.

From vladimir.kozlov at oracle.com  Thu Dec  7 17:54:28 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 7 Dec 2017 09:54:28 -0800
Subject: RFR(M): 8189102: All tools should support -?, -h and --help
In-Reply-To: <8aa25976d496465fac00a4ae3628e533@sap.com>
References: <c27028f9f5844c3c818885f88c75f84b@sap.com>
 <8aa25976d496465fac00a4ae3628e533@sap.com>
Message-ID: <1f66eda1-ccd2-4bb4-f75b-a2353cb1a5a9@oracle.com>

jaotc change is good.

Thanks,
Vladimir

On 12/7/17 2:59 AM, Lindenmaier, Goetz wrote:
> Hi,
> 
> I prepared a fifth webrev for this change.  Please review.
> 
> It incorporates the changes requested by the CSR reviewers
> (not to remove docuemtation of '-help' where is was documented
> before) and the changes proposed by Kumar:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.05/
> 
> See also the information in the webrev  itself, there are also patch files
> with the incremental builds.
> 
> This change contains fixes for some langtool tests.
> I ran the following test suites on it:
> hotspot, jdk, langtools, nashorn, jaxp, most of them on
> all the platforms we build.
> 
> Best regards,
>    Goetz.
> 
> 
> 
> 
>> -----Original Message-----
>> From: Lindenmaier, Goetz
>> Sent: Mittwoch, 11. Oktober 2017 22:07
>> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
>> Subject: RFR(M): 8189102: All tools should support -?, -h and --help
>>
>> Hi
>>
>> The tools in jdk should all show the same behavior wrt. help flags.
>> This change normalizes the help flags of a row of the tools in the jdk.
>> Java accepts -?, -h and --help, thus I changed the tools to support
>> these, too.  Some tools exited with '1' after displaying the help message,
>> I turned this to '0'.
>>
>> Maybe this is not the right mailing list for this, please advise.
>>
>> Please review this change. I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.01/
>>
>> In detail, this fixes the help message of the following tools:
>> jar          -? -h --help;  added -?.
>> jarsigner    -? -h --help;  added --help. -help accepted but not documented.
>> javac        -?    --help;  added -?. Removed -help. -h is taken for other purpose
>> javadoc      -? -h --help;  added -h -?. Removed -help
>> javap        -? -h --help;  added -h. -help accepted but no more documented.
>> jcmd         -? -h --help;  added -? --help. -help accepted but no more
>> documented. Changed return value to '0'
>> jdb          -? -h --help;  added -? -h --help. -help accepted but no more
>> documented.
>> jdeprscan    -? -h --help;  added -?
>> jinfo        -? -h --help;  added -? --help. -help accepted but no more
>> documented.
>> jjs             -h --help;  Replaced -help by --help. Adding more not straight
>> forward.
>> jps          -? -h --help;  added -? --help. -help accepted but no more
>> documented.
>> jshell       -? -h --help;  added -?
>> jstat        -? -h --help;  added -h --help. -help accepted but no more
>> documented.
>>
>> Best regards,
>>    Goetz.

From jesper.wilhelmsson at oracle.com  Thu Dec  7 17:56:55 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 7 Dec 2017 18:56:55 +0100
Subject: Fwd: JDK 10 enters Rampdown Phase One in one week
References: <20171207155844.A8FCA110E83@eggemoggin.niobe.net>
Message-ID: <E5619ED0-22B5-4BBA-90AC-7439AF791CD2@oracle.com>

Hi HotSpot developers!

FYI, Mark sent out the announcement below around RDP1. I'm happy to highlight that this announcement states that all main JDK repositories (which includes jdk/hs) will enter RDP1 at the same date, December 14th.

We have agreed on a process to allow pushes made to the jdk/hs repository all the way up to December 14th to get integrated to the JDK 10 stabilization repository. This gives you another week to fix those last critical P4-P5 bugs.

The general recommendation is still not to push more RFEs or P4-P5 bug fixes though, as there are more than enough higher priority bugs to work on to stabilize JDK 10.

Thanks,
/Jesper

> Begin forwarded message:
> 
> From: mark.reinhold at oracle.com
> Subject: JDK 10 enters Rampdown Phase One in one week
> Date: 7 December 2017 at 16:58:44 CET
> To: jdk-dev at openjdk.java.net
> 
> JDK 10 will enter Rampdown Phase One in one week, on Thursday, 14
> December.  Changes intended for JDK 10 should be in the main-line
> repository (http://hg.openjdk.java.net/jdk/jdk), or one of the two
> repositories that feed it (jdk/hs or jdk/client), by 16:00 UTC on
> that day [1].
> 
> After next week's build (jdk-10+36) is promoted we'll open a jdk/jdk10
> repository, initialized from that tag in the main line, to host the
> remaining stabilization work for JDK 10.  This will include any last
> changes that trickle in from jdk/hs and jdk/client, most likely early
> the following week.  Further JDK 10 EA builds will be done from this
> repository.
> 
> We'll semi-automatically merge changes pushed to JDK 10 into the
> main-line jdk/jdk repository, as we did for the transition from JDK 9
> to JDK 10.  This means that:
> 
>  - If you make a change in JDK 10 then you needn't do any extra
>    work to get it into the main line, though if a merge conflict
>    arises then you might be asked to help resolve it.
> 
>  - If you need to make a change in both JDK 10 and the main line
>    then just push it to JDK 10, and wait for the automatic merge
>    to complete.
> 
> Changes pushed into the main-line repositories (jdk/{jdk,client,hs})
> after the above deadline will be destined for JDK 11 unless they're
> back-ported.  When back-ports turn out to be necessary then they'll be
> easier to do than in the past: Duplicate bugids are permitted in the
> new repository layout, so a change can be pushed to both code lines
> using the same bugid if needed.
> 
> The Rampdown Phase One process will be similar to that of JDK 9 [2].
> I'll post a detailed proposal for that shortly.
> 
> - Mark
> 
> 
> [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+10+Rampdown+Phase+One&iso=20171214T16
> [2] http://openjdk.java.net/projects/jdk9/rdp-1


From jcbeyler at google.com  Fri Dec  8 05:49:46 2017
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 7 Dec 2017 21:49:46 -0800
Subject: TLAB Refills for x86
In-Reply-To: <c3304685625d485c96f1ae3cc4c0a430@sap.com>
References: <c3304685625d485c96f1ae3cc4c0a430@sap.com>
Message-ID: <CAF9BGByvGg-GWcq01MAShPPj9phbUWSB6FQgYzdzjYZKrxVyrQ@mail.gmail.com>

Hi all,

I added a reword of the comment (I could also remove it so let me know):
http://cr.openjdk.java.net/~rasbold/8191027/webrev.03/

Let me know if it is better!

Thanks,
Jc

On Tue, Dec 5, 2017 at 4:59 AM, Doerr, Martin <martin.doerr at sap.com> wrote:

> Hi Robbin,
>
> ok. Thanks for the explanation.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Robbin Ehn [mailto:robbin.ehn at oracle.com]
> Sent: Dienstag, 5. Dezember 2017 13:52
> To: Doerr, Martin <martin.doerr at sap.com>; Thomas Schatzl <
> thomas.schatzl at oracle.com>; JC Beyler <jcbeyler at google.com>;
> hotspot-dev at openjdk.java.net
> Subject: Re: TLAB Refills for x86
>
> Hi Martin,
>
> On 2017-12-05 13:12, Doerr, Martin wrote:
> > Hi,
> >
> > the interpreter change looks good to me (except the comment change).
> > I've taken a look at C1 and C2 compilers.
> > C2 already does it as desired: It either uses TLAB or shared eden
> allocation (if supported).
> >
> > Unfortunately, the C1 implementation in c1_Runtime1_x86/sparc still
> contains a path "try_eden" when TLAB allocation fails. (Also see
> MacroAssembler::tlab_refill). I think this should be adapted as well. Would
> you agree?
>
> The flag FastTLABRefill will be obsoleted in JDK 11 and we can then start
> removing (after Dec 14) the functionality.
> In 10 we turned FastTLABRefill off by default and deprecated it.
> (FastTLABRefill was only actually on when using non-G1 and for C1 only)
> (https://bugs.openjdk.java.net/browse/JDK-8190925)
> This will be handled in a separate enhancement 'removing dead code'.
>
> This (interpreter tlab refills) will not make 10, instead targeted for 11.
> So in 11 we are aiming for a consistence behavior in all (not looked at
> gral) 'compilers'.
>
> Thanks!
>
> /Robbin
>
> >
> > Best regards,
> > Martin
> >
> >
> > -----Original Message-----
> > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Thomas Schatzl
> > Sent: Dienstag, 5. Dezember 2017 12:07
> > To: JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
> > Subject: Re: TLAB Refills for x86
> >
> > Hi,
> >
> > On Thu, 2017-11-30 at 13:09 -0800, JC Beyler wrote:
> >> Hi all,
> >>
> >> The TLAB and the inline contiguous allocations handling are different
> >> for
> >> each architecture. On certain architectures, TLAB is never actually
> >> never
> >> refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
> >>
> >> The idea behind the implementation for x86 is to separate TLAB usage
> >> to
> >> contiguous allocations in eden space.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191027
> >> WebRev: http://cr.openjdk.java.net/~rasbold/8191027/webrev.02/
> >>
> >> Does anyone see any issues with this webrev?
> >
> > I only see a slight issue with the new comment on how it works: the
> > first time I read it, it seemed to me that step 1+2 are inclusive, not
> > exclusive as is implemented (there is step 4 which explains that it is
> > exclusive retroactively). But maybe it's just me.
> >
> > Looks good otherwise.
> >
> > Thomas
> >
>

From david.holmes at oracle.com  Fri Dec  8 05:40:20 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 8 Dec 2017 15:40:20 +1000
Subject: JNI ReleasePrimitiveArrayCritical with mode JNI_COMMIT shouldn't
 end critical region
In-Reply-To: <CAP-5=fUH4cyO3ZTQOTkG7CZo65pz0u5xJOZmsYTMbdFj5FTfFg@mail.gmail.com>
References: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>
 <3d676bb0-f7d3-ec40-cfb8-6a905f79a434@oracle.com>
 <CAP-5=fXv4inQiVpk5Ey1Qhy_N+hSmGuciXcZN_k-1U0+pDKqAA@mail.gmail.com>
 <b72ab75b-84fd-2ec2-3b62-6e720052231e@oracle.com>
 <CAP-5=fWZacKq7cjXfJ_+TcOsH-FAA9eKGzZ-L62kMHOmcqUyjg@mail.gmail.com>
 <788e54e9-7019-eb59-e9d6-bf0ed538e9d9@oracle.com>
 <CAP-5=fUH4cyO3ZTQOTkG7CZo65pz0u5xJOZmsYTMbdFj5FTfFg@mail.gmail.com>
Message-ID: <f4c50d9e-4d7f-84e1-15ee-757f99740aca@oracle.com>

Filed: https://bugs.openjdk.java.net/browse/JDK-8193234

David

On 8/12/2017 2:58 AM, Ian Rogers wrote:
> On Wed, Dec 6, 2017 at 9:00 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 7/12/2017 2:55 PM, Ian Rogers wrote:
> 
>         Thanks, fwiw Jikes RVM agrees that all critical releases end the
>         critical region:
>         https://github.com/JikesRVM/JikesRVM/blob/master/rvm/src/org/jikesrvm/jni/JNIFunctions.java#L5936
>         <https://github.com/JikesRVM/JikesRVM/blob/master/rvm/src/org/jikesrvm/jni/JNIFunctions.java#L5936>
> 
>         As does Cacao:
>         http://mips.complang.tuwien.ac.at/hg/cacao/file/2b4c9b6c245d/src/native/jni.cpp#l3208
>         <http://mips.complang.tuwien.ac.at/hg/cacao/file/2b4c9b6c245d/src/native/jni.cpp#l3208>
> 
>         Kaffe (with a non-moving GC) treats the release in the same way
>         as Release<Primitive>ArrayElements:
>         https://github.com/kaffe/kaffe/blob/master/kaffe/kaffevm/jni/jni-arrays.c#L404
>         <https://github.com/kaffe/kaffe/blob/master/kaffe/kaffevm/jni/jni-arrays.c#L404>
>         which is the same as how it is handled on Android.
> 
>         HotSpot has managed to put a foot in both camps, ending the
>         critical always (a la Jikes RVM and Cacao) but honoring commit
>         behavior (and leaking) when in -Xcheck:jni.
> 
> 
>     So ... I should file a bug for the leak in the checked version and
>     apply your suggested patch to always pass mode 0?
> 
>     Thanks,
>     David
> 
> 
> Sounds good to me. I would have filed the bug rather than starting this 
> thread if I had a user/bug account :-)
> 
> Thanks,
> Ian
> 
>         Thanks,
>         Ian
> 
> 
>         On Wed, Dec 6, 2017 at 5:25 PM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
> 
>          ? ? Hi Ian,
> 
>          ? ? On 7/12/2017 4:48 AM, Ian Rogers wrote:
> 
>          ? ? ? ? Thanks David, I think we may have differing opinions on
>         clarity
>          ? ? ? ? :-) In the case of -Xcheck:jni and with HotSpot a copy
>         is always
>          ? ? ? ? made, and so
> 
> 
>          ? ? Ah I see. I was considering only the "real" functionality.
> 
>          ? ? The fact the checked version of getPrimitiveArrayCritical
>         creates a
>          ? ? copy seems to be treated as an internal detail as it does
>         not AFAICS
>          ? ? report that a copy was in fact made - the passed in isCopy
>         pointer
>          ? ? will be set false by the real getPrimitiveArrayCritical.
> 
>          ? ? ? ? perhaps the attached patch causes the implementation to
>         match
>          ? ? ? ? the spec.
> 
> 
>          ? ? The whole logic surrounding the management of the copy seems
>          ? ? somewhat suspect to me. As you note with your patch
>          ? ? check_wrapped_array_release honours the mode, which in the
>         checked
>          ? ? case allows, AFAICS, the internally made copy to "leak". So
>         ignoring
>          ? ? the passed in mode and always passing 0 to
>          ? ? check_wrapped_array_release seems more correct.
> 
>          ? ? ? ? Given that commit doesn't free a copy, is it intended
>         behavior
>          ? ? ? ? that in HotSpot it ends a critical region? ie In a VM that
>          ? ? ? ? allowed copies you could imagine, Get, Commit, Release
>         and as
>          ? ? ? ? spec-ed the critical region ends at the commit if not a
>         copy,
>          ? ? ? ? and at the release if it is. Perhaps the simplest thing
>         is to
>          ? ? ? ? remove the notion of commit here.
> 
> 
>          ? ? I honestly do not know what this API is really trying to
>         achieve in
>          ? ? that regard. I don't know the intended usage of "commit"
>         mode. Why
>          ? ? would you not free the copied buffer? The spec unhelpfully
>         only states:
> 
>          ? ? "The other options give the programmer more control over memory
>          ? ? management and should be used with extreme care."
> 
>          ? ? And if you don't free it what can you do with it? For
>          ? ? Get*ArrayElements it clearly states
> 
>          ? ? "The result is valid until the corresponding
>          ? ? Release<PrimitiveType>ArrayElements() function is called."
> 
>          ? ? so once any Release* is done, regardless of mode, it would
>         seem the
>          ? ? array (copy or not) is no longer valid and should not be
>         accessed
>          ? ? again. So I don't see any expectation that you can call
>         Release*
>          ? ? multiple times and so in terms of the critical variants I
>         expect the
>          ? ? critical section to end when Release is called - regardless
>         of mode.
> 
>          ? ? David
> 
>          ? ? ? ? Thanks,
>          ? ? ? ? Ian
> 
> 
>          ? ? ? ? On Tue, Dec 5, 2017 at 4:37 PM, David Holmes
>          ? ? ? ? <david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>
>          ? ? ? ? <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
> 
>          ? ? ? ? <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>>> wrote:
> 
>          ? ? ? ? ?? ? Hi Ian,
> 
>          ? ? ? ? ?? ? On 6/12/2017 9:15 AM, Ian Rogers wrote:
> 
>          ? ? ? ? ?? ? ? ? From:
>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical>
>                 
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical>>
>                                 
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical>
>                 
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimitiveArrayCritical>>>
> 
> 
>          ? ? ? ? ?? ? You need to see the updated spec:
> 
>         https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical>
>                 
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical>>
>                             
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical>
>                 
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical
>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getprimitivearraycritical-releaseprimitivearraycritical>>>
> 
>          ? ? ? ? ?? ? That spec makes it clear:
> 
>          ? ? ? ? ?? ? "mode: the release mode (see Primitive Array
>         Release Modes): 0,
>          ? ? ? ? ?? ? JNI_COMMIT or JNI_ABORT. Ignored if carray was a
>         not copy."
> 
>          ? ? ? ? ?? ? In hotspot getCriticalArrayPrimitive never returns
>         a copy
>          ? ? ? ? so the
>          ? ? ? ? ?? ? mode is always ignored, as per the existing comment.
> 
>          ? ? ? ? ?? ? David
>          ? ? ? ? ?? ? -----
> 
> 
>          ? ? ? ? ?? ? ? ? "The semantics of these two functions are very
>         similar
>          ? ? ? ? to the
>          ? ? ? ? ?? ? ? ? existing
>          ? ? ? ? ?? ? ? ? Get/Release<primitivetype>ArrayElements
>         functions. "
> 
>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines>
>                 
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines>>
>                                 
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines>
>                 
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Release_PrimitiveType_ArrayElements_routines>>>
> 
>          ? ? ? ? ?? ? ? ? "JNI_COMMIT copy back the content but do not
>         free the
>          ? ? ? ? elems buffer"
> 
>          ? ? ? ? ?? ? ? ? Consider the pattern of:
>          ? ? ? ? ?? ? ? ? GetPrimitiveArrayCritical(...)
>          ? ? ? ? ?? ? ? ? ReleasePrimitiveArrayCritical(..., JNI_COMMIT)
>          ? ? ? ? ?? ? ? ? ReleasePrimitiveArrayCritical(..., 0)
> 
>          ? ? ? ? ?? ? ? ? where the first release is to just achieve a
>         copy back.
>          ? ? ? ? For example,
>          ? ? ? ? ?? ? ? ? jniCheck.cpp will copy back but not free a
>         copy in the
>          ? ? ? ? case of
>          ? ? ? ? ?? ? ? ? JNI_COMMIT
>          ? ? ? ? ?? ? ? ? for a critical. The implementation of
>          ? ? ? ? ?? ? ? ? ReleasePrimitiveArrayCritical ignores
>          ? ? ? ? ?? ? ? ? all arguments and so it ends the critical
>         region even
>          ? ? ? ? in the
>          ? ? ? ? ?? ? ? ? event of a
>          ? ? ? ? ?? ? ? ? commit.
> 
>          ? ? ? ? ?? ? ? ? The attached patch makes
>         ReleasePrimitiveArrayCritical
>          ? ? ? ? consider
>          ? ? ? ? ?? ? ? ? the mode
>          ? ? ? ? ?? ? ? ? argument when releasing the GCLocker.
> 
>          ? ? ? ? ?? ? ? ? Thanks,
>          ? ? ? ? ?? ? ? ? Ian
> 
> 
> 
> 

From jcbeyler at google.com  Fri Dec  8 05:52:18 2017
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 7 Dec 2017 21:52:18 -0800
Subject: RFR 8191989: TLAB Refills for Sparc
In-Reply-To: <1512472098.2454.23.camel@oracle.com>
References: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>
 <1512472098.2454.23.camel@oracle.com>
Message-ID: <CAF9BGBwL-e+PNO5DjFa8xFVJcEESViryBqj6wK=NOdkW+UOpEw@mail.gmail.com>

Hi Thomas,

I fixed it here:
http://cr.openjdk.java.net/~rasbold/8191989/webrev.02/

Let me know if it is better, I did the same for x86.

Thanks!
Jc

On Tue, Dec 5, 2017 at 3:08 AM, Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> Hi,
>
> On Thu, 2017-11-30 at 16:58 -0800, JC Beyler wrote:
> > Hi all,
> >
> > The TLAB and the inline contiguous allocations handling are different
> > for
> > each architecture. On certain architectures, TLAB is never actually
> > never
> > refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
> >
> > The idea behind the implementation for Sparc is to do two things:
> >   - separate TLAB usage to contiguous allocations in eden space.
> >   - remove the code that augments the TLAB waste limit since that is
> > already done in the common code slow path
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8191989
> > WebRev: *http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/
> > <http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/>*
> >
> > Does anyone see any issues with this webrev?
>
>   same comment as the x86 change, otherwise looks good.
>
> Thanks,
>   Thomas
>

From martin.doerr at sap.com  Fri Dec  8 16:17:03 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 8 Dec 2017 16:17:03 +0000
Subject: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
 handshakes
Message-ID: <de1b75906439447eb24eaf15a2be805f@sap.com>

Hi,

I've implemented Thread-local handshakes on PPC64 and s390.

We may improve it by using SIGTRAP-based polling on these 2 platforms in the future (which requires changes in shared code).
For now, I just implemented it like on the other platforms without further improvements.

Webrev is here:
http://cr.openjdk.java.net/~mdoerr/8193257_PPC64_s390_Thread-local_hs/webrev.00/

Please review.

Best regards,
Martin


From aph at redhat.com  Fri Dec  8 17:50:19 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Dec 2017 17:50:19 +0000
Subject: RFR: 8193260: AArch64: JVMCI: Implement trampoline calls
Message-ID: <338e82df-fb2b-47ba-2c75-15e530be5aa4@redhat.com>

AArch64 call instructions only have a 26-bit range, so if the code
cache is greater than 128 megabytes (and it is by default)
compilations will fail with out-of-range branches.

C1 and C2 solve this by generating trampolines for Java calls. The
Aarch64 JVMCI CodeInstaller doesn't ganerate trampolines, and we
should fix it so that it does.

Note that this webrev includes the necessary Graal changes.  Graal is
maintained separately, so these are only included FYI: they will have
to be reviewed after these JVMCI changes are in HotSpot.

Also note that this includes changes to shared and x86 code, so it'll
need a sponsor.

http://cr.openjdk.java.net/~aph/8193260-1/

-- 
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 stuart.monteith at linaro.org  Fri Dec  8 19:07:55 2017
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Fri, 8 Dec 2017 19:07:55 +0000
Subject: RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV
Message-ID: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>

Hello,
   The Aarch64 backend decompresses klass pointers using XOR if the
size of the compressed classes space is less then the base address.
However, in JDK 10  CompressedClassSpaceSize doesn't represent the
range of the compressed shared classes area, which is set to 4GB.

   https://bugs.openjdk.java.net/browse/JDK-8193266
   http://cr.openjdk.java.net/~smonteith/8193266/webrev/

I've speculatively put up a patch which deals with the issue on
Aarch64. While I understand the problem with the generated aarch64
code, I don't believe understand the CDS code sufficiently at this
point to determine if there is a bug within the CDS code regarding the
CompressedClassSpaceSize parameter.

Thanks,
    Stuart

From aph at redhat.com  Sat Dec  9 11:37:15 2017
From: aph at redhat.com (Andrew Haley)
Date: Sat, 9 Dec 2017 11:37:15 +0000
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
Message-ID: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>

Hi,

On 08/12/17 19:07, Stuart Monteith wrote:

>    The Aarch64 backend decompresses klass pointers using XOR if the
> size of the compressed classes space is less then the base address.
> However, in JDK 10  CompressedClassSpaceSize doesn't represent the
> range of the compressed shared classes area, which is set to 4GB.
> 
>    https://bugs.openjdk.java.net/browse/JDK-8193266
>    http://cr.openjdk.java.net/~smonteith/8193266/webrev/
> 
> I've speculatively put up a patch which deals with the issue on
> Aarch64. While I understand the problem with the generated aarch64
> code, I don't believe understand the CDS code sufficiently at this
> point to determine if there is a bug within the CDS code regarding the
> CompressedClassSpaceSize parameter.

Good catch!

Hmm.  This sort-of papers over the problem, in that it disables XOR-
encoding of class metadata.  I would have thought it makes more sense
to set narrow_klass_base high enough so that this does not happen.  We
really want narrow_klass_shift to be zero if we can, which should be
OK if the shared klasses are in a 4G range.

I think that I see the logic of your patch, but I think it's a very
complicated way of saying

  if (narrow_klass_base() > 1ul << 32 << narrow_klass_shift())

Also, beware of putting any more complexity into
use_XOR_for_compressed_class_base because it's executed very often.
We should perhaps do it once, when we allocate the metaspace.

-- 
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  Sat Dec  9 19:02:19 2017
From: aph at redhat.com (Andrew Haley)
Date: Sat, 9 Dec 2017 19:02:19 +0000
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
 <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
Message-ID: <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>

On 09/12/17 11:37, Andrew Haley wrote:
> Hmm.  This sort-of papers over the problem, in that it disables XOR-
> encoding of class metadata.  I would have thought it makes more sense
> to set narrow_klass_base high enough so that this does not happen.  We
> really want narrow_klass_shift to be zero if we can, which should be
> OK if the shared klasses are in a 4G range.

And I now see that in the very odd code in question the shift is set
to 3, regardless of the fact that it's not necessary.  Something to
do with AOT, which I guess always does the shift.  I'd prefer
AArch64 always to set the shift to zero, and we could then search
for a suitable base.  We never need a shift for compressed classes,
given that 4G seems to be hard-wired as a maximum size.

We could establish the convention that the shift is always zero
on AArch64, and then this problem would go away completely.

-- 
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  Sun Dec 10 09:46:33 2017
From: aph at redhat.com (Andrew Haley)
Date: Sun, 10 Dec 2017 09:46:33 +0000
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
 <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
 <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>
Message-ID: <d8348c30-f509-c94e-9c9e-1d397973b758@redhat.com>

On 09/12/17 19:02, Andrew Haley wrote:

> We could establish the convention that the shift is always zero
> on AArch64, and then this problem would go away completely.

Ahh, I just realized that this too is too simple, because we don't
know where the metaspace is going to be, so we have to generate code
which can run wherever the metaspace is.  It's tricky.

-- 
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 thomas.schatzl at oracle.com  Mon Dec 11 11:06:17 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 11 Dec 2017 12:06:17 +0100
Subject: TLAB Refills for x86
In-Reply-To: <CAF9BGByvGg-GWcq01MAShPPj9phbUWSB6FQgYzdzjYZKrxVyrQ@mail.gmail.com>
References: <c3304685625d485c96f1ae3cc4c0a430@sap.com>
 <CAF9BGByvGg-GWcq01MAShPPj9phbUWSB6FQgYzdzjYZKrxVyrQ@mail.gmail.com>
Message-ID: <1512990377.2882.9.camel@oracle.com>

Hi,

On Thu, 2017-12-07 at 21:49 -0800, JC Beyler wrote:
> Hi all,
> 
> I added a reword of the comment (I could also remove it so let me
> know):
> http://cr.openjdk.java.net/~rasbold/8191027/webrev.03/
> 
> Let me know if it is better!

  my suggestion:

3872   // Allocate the instance:
3873   // 1) If TLAB is enabled:
3874   //  a) Try to allocate in the TLAB
3875   //  b) If fails, go to the slow path.
3876   //    Else If inline contiguous allocations are enabled:
3878   //  i) Try to allocate in eden
3879   //  ii) If fails due to heap end, go to slow path.
3880   // 2) If TLAB is enabled OR inline contiguous is enabled:
3881   //  a) Initialize the allocation
3882   //  b) Exit.
3883   // 3) Go to slow path.
3884 

Same idea for the SPARC change.

Thanks,
  Thomas


From stuart.monteith at linaro.org  Mon Dec 11 13:43:33 2017
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Mon, 11 Dec 2017 13:43:33 +0000
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <d8348c30-f509-c94e-9c9e-1d397973b758@redhat.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
 <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
 <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>
 <d8348c30-f509-c94e-9c9e-1d397973b758@redhat.com>
Message-ID: <CAEGA6kac5=5ydKLgBjh+Z53To4owm63J4ppLV12DQAwhe+nnuw@mail.gmail.com>

I've copied and pasted the calculation for UnscaledClassSpaceMax in
use_XOR_for_compressed_class_base to match the variable of the same
name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces  -
I did this for ease of reference while we decide what to do.

I guess you're referring to this piece of code:


As far as I can tell, the parameter CompressedClassSpaceSize is ignored.

On 10 December 2017 at 09:46, Andrew Haley <aph at redhat.com> wrote:
> On 09/12/17 19:02, Andrew Haley wrote:
>
>> We could establish the convention that the shift is always zero
>> on AArch64, and then this problem would go away completely.
>
> Ahh, I just realized that this too is too simple, because we don't
> know where the metaspace is going to be, so we have to generate code
> which can run wherever the metaspace is.  It's tricky.
>
> --
> 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  Mon Dec 11 13:54:54 2017
From: aph at redhat.com (Andrew Haley)
Date: Mon, 11 Dec 2017 13:54:54 +0000
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <CAEGA6kac5=5ydKLgBjh+Z53To4owm63J4ppLV12DQAwhe+nnuw@mail.gmail.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
 <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
 <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>
 <d8348c30-f509-c94e-9c9e-1d397973b758@redhat.com>
 <CAEGA6kac5=5ydKLgBjh+Z53To4owm63J4ppLV12DQAwhe+nnuw@mail.gmail.com>
Message-ID: <b3927395-4c7e-c3f1-4788-0bbbc8956292@redhat.com>

On 11/12/17 13:43, Stuart Monteith wrote:
> I've copied and pasted the calculation for UnscaledClassSpaceMax in
> use_XOR_for_compressed_class_base to match the variable of the same
> name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces  -
> I did this for ease of reference while we decide what to do.

Yes, I get that.  I don't want to pessimize the "normal" use of OpenJDK
AArch64 for the sake of this weird case.  I guess that as long as no-
one explicitly sets the base of the metaspace below 32 bits it doesn't
matter anyway.

-- 
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 coleen.phillimore at oracle.com  Mon Dec 11 22:09:26 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 11 Dec 2017 17:09:26 -0500
Subject: RFR (S) 8193053: jvm crash by G1CMBitMapClosure::do_addr
Message-ID: <3792a294-8276-b29f-6cfd-cb5a7e75f475@oracle.com>

Summary: We were adding an unloaded mirror to the SATB collection set in 
remove_handle.

open webrev at http://cr.openjdk.java.net/~coleenp/8193053.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8193053

This fix is somewhat minimal because it's late in the jdk 10 release 
cycle but improved function name is welcome.

Tested with failing jck tests for several hours (usual failure in first 
run).? Also ran mach5 tier1-5 (still in progress but almost done).

Thanks,
Coleen

From goetz.lindenmaier at sap.com  Tue Dec 12 08:26:47 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 12 Dec 2017 08:26:47 +0000
Subject: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
 handshakes
In-Reply-To: <de1b75906439447eb24eaf15a2be805f@sap.com>
References: <de1b75906439447eb24eaf15a2be805f@sap.com>
Message-ID: <65ba0690f70a431296c8a704ca88fd23@sap.com>

Hi Martin, 

I had a look at your change.

I see you enabled it per default?

macroAssembler_ppc/s390.cpp: 
MacroAssembler::safepoint_poll()
Could you add some comment that says what this is doing?
As it's not doing a safepoint_poll ... its just preparing it, right?
Maybe also "slow_target" should be "do_safepoint".
  
templateInterpreterGenerator_ppc.cpp:
Why do you change memory ordering from release() to lwsync()?

sharedRuntime_ppc/s390.cpp
If I understand right you skip the safepoint instruction.
Why that? Could you please document that this differs 
from the other platforms here?

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin
> Sent: Freitag, 8. Dezember 2017 17:17
> To: hotspot-dev developers (hotspot-dev at openjdk.java.net) <hotspot-
> dev at openjdk.java.net>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Schmidt, Lutz <lutz.schmidt at sap.com>
> Subject: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
> handshakes
> 
> Hi,
> 
> 
> 
> I've implemented Thread-local handshakes on PPC64 and s390.
> 
> 
> 
> We may improve it by using SIGTRAP-based polling on these 2 platforms in
> the future (which requires changes in shared code).
> 
> For now, I just implemented it like on the other platforms without further
> improvements.
> 
> 
> 
> Webrev is here:
> 
> http://cr.openjdk.java.net/~mdoerr/8193257_PPC64_s390_Thread-
> local_hs/webrev.00/
> 
> 
> 
> Please review.
> 
> 
> 
> Best regards,
> 
> Martin
> 
> 


From martin.doerr at sap.com  Tue Dec 12 10:07:50 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 12 Dec 2017 10:07:50 +0000
Subject: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
 handshakes
In-Reply-To: <65ba0690f70a431296c8a704ca88fd23@sap.com>
References: <de1b75906439447eb24eaf15a2be805f@sap.com>
 <65ba0690f70a431296c8a704ca88fd23@sap.com>
Message-ID: <49fe36780e5d4abf99745199479a75a7@sap.com>

Hi G?tz,

thanks reviewing. Please see my answers inline.

Best regards,
Martin


> I see you enabled it per default?
Yes. I have tried to keep the implementation as close to the other platforms as possible. x86, SPARC and aarch64 have it enabled by default, too.

> macroAssembler_ppc/s390.cpp: 
> MacroAssembler::safepoint_poll()
> Could you add some comment that says what this is doing?
> As it's not doing a safepoint_poll ... its just preparing it, right?
> Maybe also "slow_target" should be "do_safepoint".
I agree with that the label name "do_safepoint" would be more comprehensible, but I'd prefer to use the same name as x86, SPARC and aarch64.
What the function safepoint_poll does is it simply performs the poll by checking the poll bit + conditional branch to the safepoint code. Would you like to see a comment like "Perform poll and branch if safepoint requested"?

> templateInterpreterGenerator_ppc.cpp:
> Why do you change memory ordering from release() to lwsync()?
This is not a functional change. release() emits an lwsync() instruction. I have changed it to emphasize that we're using it for acquire and release in one instruction. release() hides that we use it for acquire, too.

> sharedRuntime_ppc/s390.cpp
> If I understand right you skip the safepoint instruction.
> Why that? Could you please document that this differs 
> from the other platforms here?
The s390 code does exactly the same thing as on the other platforms. It adjusts to PC to point to the instruction following the poll instruction. This is part of the new concept which needs to be implemented on all platforms supporting local handshakes. The difference to PPC for example is that s390 has different instruction sizes (2, 4 and 6 bytes) and I implemented it in a way that it works with any poll instruction regardless of its size.
Would you like to see a comment like "Support poll instruction with any size"?


From goetz.lindenmaier at sap.com  Tue Dec 12 10:20:46 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 12 Dec 2017 10:20:46 +0000
Subject: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
 handshakes
In-Reply-To: <49fe36780e5d4abf99745199479a75a7@sap.com>
References: <de1b75906439447eb24eaf15a2be805f@sap.com>
 <65ba0690f70a431296c8a704ca88fd23@sap.com>
 <49fe36780e5d4abf99745199479a75a7@sap.com>
Message-ID: <76d784d3d6dd4b60a09f0c93a04e1dfe@sap.com>

Hi, 

I would prefer
"Check whether safepoint is requested and if so branch to code suspending the thread."
The word 'poll' isn't very precise to describe what is happening here.

Other stuff all fine. Reviewed. No new webrev needed.

Best regards,
  Goetz. 

> -----Original Message-----
> From: Doerr, Martin
> Sent: Dienstag, 12. Dezember 2017 11:08
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
> developers (hotspot-dev at openjdk.java.net) <hotspot-
> dev at openjdk.java.net>; Schmidt, Lutz <lutz.schmidt at sap.com>
> Subject: RE: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
> handshakes
> 
> Hi G?tz,
> 
> thanks reviewing. Please see my answers inline.
> 
> Best regards,
> Martin
> 
> 
> > I see you enabled it per default?
> Yes. I have tried to keep the implementation as close to the other platforms
> as possible. x86, SPARC and aarch64 have it enabled by default, too.
> 
> > macroAssembler_ppc/s390.cpp:
> > MacroAssembler::safepoint_poll()
> > Could you add some comment that says what this is doing?
> > As it's not doing a safepoint_poll ... its just preparing it, right?
> > Maybe also "slow_target" should be "do_safepoint".
> I agree with that the label name "do_safepoint" would be more
> comprehensible, but I'd prefer to use the same name as x86, SPARC and
> aarch64.
> What the function safepoint_poll does is it simply performs the poll by
> checking the poll bit + conditional branch to the safepoint code. Would you
> like to see a comment like "Perform poll and branch if safepoint requested"?
> 
> > templateInterpreterGenerator_ppc.cpp:
> > Why do you change memory ordering from release() to lwsync()?
> This is not a functional change. release() emits an lwsync() instruction. I have
> changed it to emphasize that we're using it for acquire and release in one
> instruction. release() hides that we use it for acquire, too.
> 
> > sharedRuntime_ppc/s390.cpp
> > If I understand right you skip the safepoint instruction.
> > Why that? Could you please document that this differs
> > from the other platforms here?
> The s390 code does exactly the same thing as on the other platforms. It
> adjusts to PC to point to the instruction following the poll instruction. This is
> part of the new concept which needs to be implemented on all platforms
> supporting local handshakes. The difference to PPC for example is that s390
> has different instruction sizes (2, 4 and 6 bytes) and I implemented it in a way
> that it works with any poll instruction regardless of its size.
> Would you like to see a comment like "Support poll instruction with any
> size"?


From adinn at redhat.com  Tue Dec 12 15:27:18 2017
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 12 Dec 2017 15:27:18 +0000
Subject: RFR: 8193260: AArch64: JVMCI: Implement trampoline calls
In-Reply-To: <338e82df-fb2b-47ba-2c75-15e530be5aa4@redhat.com>
References: <338e82df-fb2b-47ba-2c75-15e530be5aa4@redhat.com>
Message-ID: <22e19f80-9c62-084c-0c52-efb86fb1ddab@redhat.com>

On 08/12/17 17:50, Andrew Haley wrote:
> AArch64 call instructions only have a 26-bit range, so if the code
> cache is greater than 128 megabytes (and it is by default)
> compilations will fail with out-of-range branches.
> 
> C1 and C2 solve this by generating trampolines for Java calls. The
> Aarch64 JVMCI CodeInstaller doesn't ganerate trampolines, and we
> should fix it so that it does.
> 
> Note that this webrev includes the necessary Graal changes.  Graal is
> maintained separately, so these are only included FYI: they will have
> to be reviewed after these JVMCI changes are in HotSpot.
> 
> Also note that this includes changes to shared and x86 code, so it'll
> need a sponsor.
> 
> http://cr.openjdk.java.net/~aph/8193260-1/
This looks ok by eyeball and OpenJDK builds and runs ok for non-Graal
runs on AArch64. So, on those grounds it is reviewed.

I also patched and built a latest checkout Graal tree in order to test
Graal, pointed it at my jdkdev/hs build (aka, for now, jdk10) using
--jdkhome /path/to/jdkdev/hs/build/... and then tried to run a few things.

This was fine when running Hello World which did nto need to load Graal
compiler code. However, it barfed when I tried running netbeans
apparently because of having to eat compiler class files with version 54
(jdk10). So, building Graal with jdk10 doesn't actually work yet:

    Caused by: java.lang.UnsupportedClassVersionError: Unsupported class
file version: 54.0
    at
jdk.internal.vm.compiler/org.graalvm.compiler.replacements.classfile.Classfile.<init>(Classfile.java:69)
    at
jdk.internal.vm.compiler/org.graalvm.compiler.replacements.classfile.ClassfileBytecodeProvider.getClassfile(ClassfileBytecodeProvider.java:129)

I fixed this by tweaking the offending class above, Classfile, to allow
bytecode versions up to 54 and it then successfully ran netbeans (the
relevant diff is included below).

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

---
a/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java
+++
b/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java
@@ -47,7 +47,7 @@ public class Classfile {
     private final List<ClassfileBytecode> codeAttributes;

     private static final int MAJOR_VERSION_JAVA7 = 51;
-    private static final int MAJOR_VERSION_JAVA9 = 53;
+    private static final int MAJOR_VERSION_JAVA10 = 54;
     private static final int MAGIC = 0xCAFEBABE;

     /**
@@ -65,7 +65,7 @@ public class Classfile {

         int minor = stream.readUnsignedShort();
         int major = stream.readUnsignedShort();
-        if (major < MAJOR_VERSION_JAVA7 || major > MAJOR_VERSION_JAVA9) {
+        if (major < MAJOR_VERSION_JAVA7 || major > MAJOR_VERSION_JAVA10) {
             throw new UnsupportedClassVersionError("Unsupported class
file version: " + major + "." + minor);
         }

From yumin.qi at gmail.com  Wed Dec 13 05:18:13 2017
From: yumin.qi at gmail.com (yumin qi)
Date: Tue, 12 Dec 2017 21:18:13 -0800
Subject: Question: Restriction on non-empty directory on cass path
Message-ID: <CAOEheN6y7mG+okW2L=CPce1a8Y7HA1MnMcgbpCPLXOscEBvyxg@mail.gmail.com>

Hi,

  The question is for CDS. When dump CDS using (tried with Ioi's AppCDS
patch)
  -Xshare:dump -XX:+UseAppCDS  -cp somedir:somedir/somefile.jar

   if somedir does not contain any classes file, but other non class files,
it will fail here:

ClassLoaderExt::add_class_path_entry(...):

         tty->print_cr("Error: non-empty directory '%s'", path);
         exit_with_path_failure("Cannot have non-empty directory in
boot/ext/app classpaths", NULL);

   Why not just skip adding such class path entry? Will it fail on share if
those entries skipped?
   Is this a design behavior?
   User some time append such directories to class path, and will confuse
on such failure on CDS since it won't fail on non-CDS way.

    Any inputs really appreciated.

  Thanks
  Yumin

From ioi.lam at oracle.com  Wed Dec 13 05:28:04 2017
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 12 Dec 2017 21:28:04 -0800
Subject: Question: Restriction on non-empty directory on cass path
In-Reply-To: <CAOEheN6y7mG+okW2L=CPce1a8Y7HA1MnMcgbpCPLXOscEBvyxg@mail.gmail.com>
References: <CAOEheN6y7mG+okW2L=CPce1a8Y7HA1MnMcgbpCPLXOscEBvyxg@mail.gmail.com>
Message-ID: <9112476e-e336-3e04-9a85-76d7b30cace5@oracle.com>

This was a design decision. CDS require any directories on the classpath 
to be empty (I think we really should discourage directories to be use 
in the classpath). The reason is that it's difficult to check whether 
the any class files have been added/modified/removed -- if we don't do 
such checks, then the program will load different classes depending on 
whether CDS is enabled.

What's the reason for your users to append directories to the classpath?

Thanks

- Ioi


On 12/12/17 9:18 PM, yumin qi wrote:
> Hi,
>
> ? The question is for CDS. When dump CDS using (tried with Ioi's 
> AppCDS patch)
> ? -Xshare:dump -XX:+UseAppCDS? -cp somedir:somedir/somefile.jar
>
> ? ?if somedir does not contain any classes file, but other non class 
> files, it will fail here:
>
> ClassLoaderExt::add_class_path_entry(...):
> ? ? ? ? ?tty->print_cr("Error: non-empty directory '%s'", path);
> ? ? ? ? ?exit_with_path_failure("Cannot have non-empty directory in 
> boot/ext/app classpaths", NULL);
>
> ? ?Why not just skip adding such class path entry? Will it fail on 
> share if those entries skipped?
> ? ?Is this a design behavior?
> ? ?User some time append such directories to class path, and will 
> confuse on such failure on CDS since it won't fail on non-CDS way.
> ? ? Any inputs really appreciated.
>
> ? Thanks
> ? Yumin


From yumin.qi at gmail.com  Wed Dec 13 05:33:46 2017
From: yumin.qi at gmail.com (yumin qi)
Date: Tue, 12 Dec 2017 21:33:46 -0800
Subject: Question: Restriction on non-empty directory on cass path
In-Reply-To: <9112476e-e336-3e04-9a85-76d7b30cace5@oracle.com>
References: <CAOEheN6y7mG+okW2L=CPce1a8Y7HA1MnMcgbpCPLXOscEBvyxg@mail.gmail.com>
 <9112476e-e336-3e04-9a85-76d7b30cace5@oracle.com>
Message-ID: <CAOEheN7oE4avRC43TQ9pK-Bgyn3ixNsKS8F0rohd4wckWUk9sQ@mail.gmail.com>

Ioi,
  The user has script to run their apps,  the script is large and setting
is little awkward. When use AppCDS, they modified the existing script and
failed here.
  So the solution is remove all such directories from class path.

Thanks
Yumin

On Tue, Dec 12, 2017 at 9:28 PM, Ioi Lam <ioi.lam at oracle.com> wrote:

> This was a design decision. CDS require any directories on the classpath
> to be empty (I think we really should discourage directories to be use in
> the classpath). The reason is that it's difficult to check whether the any
> class files have been added/modified/removed -- if we don't do such checks,
> then the program will load different classes depending on whether CDS is
> enabled.
>
> What's the reason for your users to append directories to the classpath?
>
> Thanks
>
> - Ioi
>
>
>
> On 12/12/17 9:18 PM, yumin qi wrote:
>
>> Hi,
>>
>>   The question is for CDS. When dump CDS using (tried with Ioi's AppCDS
>> patch)
>>   -Xshare:dump -XX:+UseAppCDS  -cp somedir:somedir/somefile.jar
>>
>>    if somedir does not contain any classes file, but other non class
>> files, it will fail here:
>>
>> ClassLoaderExt::add_class_path_entry(...):
>>          tty->print_cr("Error: non-empty directory '%s'", path);
>>          exit_with_path_failure("Cannot have non-empty directory in
>> boot/ext/app classpaths", NULL);
>>
>>    Why not just skip adding such class path entry? Will it fail on share
>> if those entries skipped?
>>    Is this a design behavior?
>>    User some time append such directories to class path, and will confuse
>> on such failure on CDS since it won't fail on non-CDS way.
>>     Any inputs really appreciated.
>>
>>   Thanks
>>   Yumin
>>
>
>

From kim.barrett at oracle.com  Wed Dec 13 05:50:05 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 13 Dec 2017 00:50:05 -0500
Subject: RFR (S) 8193053: jvm crash by G1CMBitMapClosure::do_addr
In-Reply-To: <3792a294-8276-b29f-6cfd-cb5a7e75f475@oracle.com>
References: <3792a294-8276-b29f-6cfd-cb5a7e75f475@oracle.com>
Message-ID: <077DEF32-1CD3-4A5F-B728-0C9A319E5C8E@oracle.com>

> On Dec 11, 2017, at 5:09 PM, coleen.phillimore at oracle.com wrote:
> 
> Summary: We were adding an unloaded mirror to the SATB collection set in remove_handle.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8193053.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8193053
> 
> This fix is somewhat minimal because it's late in the jdk 10 release cycle but improved function name is welcome.
> 
> Tested with failing jck tests for several hours (usual failure in first run).  Also ran mach5 tier1-5 (still in progress but almost done).
> 
> Thanks,
> Coleen

Change looks okay.



From vladimir.kozlov at oracle.com  Wed Dec 13 08:16:39 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 Dec 2017 00:16:39 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <85ed009a-5c31-80fb-b8ae-1f889843e6e7@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
 <c3cca6dc-14f2-855a-e2be-fa60c0ad9ac8@oracle.com>
 <85ed009a-5c31-80fb-b8ae-1f889843e6e7@oracle.com>
Message-ID: <7dc8336c-7024-e02a-accf-d8fc2a92d5bf@oracle.com>

After several rounds of testing (which found different types of failures 
with Graal as JIT compiler) I decided to limit these changes for cases 
when --limit-modules is used:

http://cr.openjdk.java.net/~kvn/8191788/webrev.01/

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

Thanks,
Vladimir

On 11/29/17 3:19 PM, Vladimir Kozlov wrote:
> Yes, it was my limited understanding what --limit-modules is. We should 
> not add modules "under cover" when --limit-modules is used. User should 
> known all required modules *explicitly* to create correct image with 
> jlink based on result of runs with --limit-modules flag.
> 
> Since it is limited set of tests which use --limit-modules (11 in 
> hotspot, 23 in jdk and few in closed) I will exclude these tests from 
> running with Graal as JIT by adding @require to them:
> 
>  ?@requires !vm.graal.enabled
> 
> We may revisit this later in a future when Graal become default JIT 
> compiler (it should be supported on platforms at that time).
> 
> Thanks,
> Vladimir
> 
> On 11/29/17 2:44 PM, mandy chung wrote:
>> Vladimir and I discussed this offline. java --limit-modules should 
>> have the same set of observable modules as running on an image that is 
>> created with jlink.? When running with -XX:+UseJVMCICompiler on a 
>> runtime image with just java.base, it will fail in the same way as 
>> running with java --limit-modules java.base -XX:+UseJVMCICompiler. 
>> These tests are written to run on a runtime image with java.base only 
>> should be updated to get it run with -XX:+UseJVMCICompiler.? I will 
>> take a look and see how we can refactor the tests to support such 
>> testing configuration.?? In the meantime, Vladimir suggests to exclude 
>> these tests when running with -XX:+UseJVMCICompiler (specifying 
>> @requires).
>>
>> Mandy

From gnormington at pivotal.io  Wed Dec 13 09:13:57 2017
From: gnormington at pivotal.io (Glyn Normington)
Date: Wed, 13 Dec 2017 09:13:57 +0000
Subject: Additional JEPS 8182070 requirement: avoiding container OOM
In-Reply-To: <CAA-6JZrGWai5z57e+U7f92K3eb0VVp9xj0MwQ1Zi9ms5OKh3vw@mail.gmail.com>
References: <CAA-6JZrGWai5z57e+U7f92K3eb0VVp9xj0MwQ1Zi9ms5OKh3vw@mail.gmail.com>
Message-ID: <CAA-6JZot6rBg1Eynehk9EQvQFF2cNpZFX4Bat_FE9nm0BzMAxw@mail.gmail.com>

I wonder if someone involved in JEPS 8182070 (Container aware Java) would
care to comment on the additional requirement described below?

On Mon, Nov 13, 2017 at 9:30 AM, Glyn Normington <gnormington at pivotal.io>
wrote:

> I would like to mention an additional requirement for JEPS 8182070 (
> http://openjdk.java.net/jeps/8182070): avoid the JVM hitting container
> OOM by strictly bounding the amount of (physical) memory that the JVM
> consumes. This may be implicit in the document, but I think it should be
> made an explicit goal.
>
> If a java application hits container OOM, no detailed diagnostics, such as
> those associated with an OutOfMemoryError or a JVMTI resource exhaustion
> event, are presented to the user, so the user finds it very difficult to
> know how to fix the problem.
>
> The Cloud Foundry OSS project has done quite a bit of work on this problem
> and provides a couple of utilities which help when running a JVM in a
> container:
>
> * Java memory calculator ([1], [2]) to determine JVM memory settings,
> * jvmkill JVMTI agent ([3]) to report detailed diagnostics on a resource
> exhaustion event.
>
> Regards,
> Glyn
>
> [1] https://github.com/cloudfoundry/java-buildpack-memory-calculator
>
> [2] Design doc: https://docs.google.com/document/d/
> 1vlXBiwRIjwiVcbvUGYMrxx2Aw1RVAtxq3iuZ3UK2vXA/edit#heading=h.uy41ishpv9zc
>
> [3] https://github.com/cloudfoundry/jvmkill
>



-- 
Regards,
Glyn

From gnormington at pivotal.io  Wed Dec 13 09:39:33 2017
From: gnormington at pivotal.io (Glyn Normington)
Date: Wed, 13 Dec 2017 09:39:33 +0000
Subject: Excessive "GC" memory area size [was: Re: Determining "GC" memory
 area size]
Message-ID: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>

On the basis of the reply below, we have been thinking of estimating the
size of the "GC" memory area as a little more than (1/32) * heapSize.
However, running `java -version` with a 350m heap results in "GC" memory as
reported by NMT of over 17% of the heap size, so this estimate is way out.

If the analysis below is accurate, then given the number of GC threads is
10 (ParallelGCThreads=8, ConcGCThreads=2), can there be many more
taskqueues than GC threads?

Or is there another explanation for the additional "GC" size?

Thanks,
Glyn

[1] https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe

On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu <zgu at redhat.com> wrote:

> Hi Glyn,
>
>
>> Can anyone here tell me how the GC memory area size is determined? If
>> there
>> is documentation, so much the better as we'd prefer not to depend on code
>> details that might flux arbitrarily.
>>
>>
> GC memory is mainly data structures used by GC runtime. It can be varied
> by collector used, size of the Java heap, the number of GC threads and etc.
> and, of course, the application itself.
>
> Some are *fixed* costs, which can be estimated. E.g. two marking bitmaps
> used by G1, each costs 1/64 of heap size (assuming default object
> alignment).
>
> Some are *semi-fixed*, e.g. taskqueue's fixed cost is about 1M for each
> queue on 64-bits VM, but it can overflow. And the number of task queues is
> proportional to the number of GC threads.
>
> Then there are factors from application itself,  such as object mutation
> rate, inter-generation/region references, etc.
>
>
> I don't see a single formula for estimating GC memory size. If you are
> using G1, the biggest overhead comes from 2 bitmaps (1/32 * heap size).
>
> Thanks,
>
> -Zhengyu
>
>
>
>


-- 
Regards,
Glyn

From coleen.phillimore at oracle.com  Wed Dec 13 12:05:27 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 13 Dec 2017 07:05:27 -0500
Subject: RFR (S) 8193053: jvm crash by G1CMBitMapClosure::do_addr
In-Reply-To: <077DEF32-1CD3-4A5F-B728-0C9A319E5C8E@oracle.com>
References: <3792a294-8276-b29f-6cfd-cb5a7e75f475@oracle.com>
 <077DEF32-1CD3-4A5F-B728-0C9A319E5C8E@oracle.com>
Message-ID: <14b61878-406e-9823-78b6-4e1dbd178f6c@oracle.com>

Thanks Kim!
Coleen

On 12/13/17 12:50 AM, Kim Barrett wrote:
>> On Dec 11, 2017, at 5:09 PM, coleen.phillimore at oracle.com wrote:
>>
>> Summary: We were adding an unloaded mirror to the SATB collection set in remove_handle.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8193053.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8193053
>>
>> This fix is somewhat minimal because it's late in the jdk 10 release cycle but improved function name is welcome.
>>
>> Tested with failing jck tests for several hours (usual failure in first run).  Also ran mach5 tier1-5 (still in progress but almost done).
>>
>> Thanks,
>> Coleen
> Change looks okay.
>
>


From zgu at redhat.com  Wed Dec 13 12:27:46 2017
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 13 Dec 2017 07:27:46 -0500
Subject: Excessive "GC" memory area size [was: Re: Determining "GC" memory
 area size]
In-Reply-To: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>
References: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>
Message-ID: <0cd04045-ef97-16bf-874a-6703d6222578@redhat.com>

Hi Glyn,

You can run NMT with detail tracking (-XX:NativeMemoryTracking=detail) 
then use jcmd (jcmd <pid> VM.native_memory detail) to find out all 
allocations for GC.

For example:

[0x00007f9fba000000 - 0x00007f9fbc000000] reserved 32768KB for *GC* from
     [0x00007fa0130260ef] G1CMMarkStack::resize(unsigned long)+0x8f
     [0x00007fa01302cf62] 
G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*, 
G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
     [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
     [0x00007fa013ca26af] universe_init()+0x6f

         [0x00007f9fba000000 - 0x00007f9fbc000000] committed 32768KB from
             [0x00007fa01302610d] G1CMMarkStack::resize(unsigned long)+0xad
             [0x00007fa01302cf62] 
G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*, 
G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
             [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
             [0x00007fa013ca26af] universe_init()+0x6f


[0x00007fa012ac5395] ArrayAllocator<unsigned long>::allocate(unsigned 
long, MemoryType)+0x245
[0x00007fa012ac5448] unsigned long* 
BitMap::reallocate<CHeapBitMapAllocator>(CHeapBitMapAllocator const&, 
unsigned long*, unsigned long, unsigned long)+0x38
[0x00007fa012ac509f] CHeapBitMap::initialize(unsigned long)+0x6f
[0x00007fa013093b9c] 
G1PageBasedVirtualSpace::G1PageBasedVirtualSpace(ReservedSpace, unsigned 
long, unsigned long)+0x13c
                              (malloc=129KB *type=GC* #6)

Thanks,

-Zhengyu



On 12/13/2017 04:39 AM, Glyn Normington wrote:
> On the basis of the reply below, we have been thinking of estimating the
> size of the "GC" memory area as a little more than (1/32) * heapSize.
> However, running `java -version` with a 350m heap results in "GC" memory as
> reported by NMT of over 17% of the heap size, so this estimate is way out.
> 
> If the analysis below is accurate, then given the number of GC threads is
> 10 (ParallelGCThreads=8, ConcGCThreads=2), can there be many more
> taskqueues than GC threads?
> 
> Or is there another explanation for the additional "GC" size?
> 
> Thanks,
> Glyn
> 
> [1] https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
> 
> On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu <zgu at redhat.com> wrote:
> 
>> Hi Glyn,
>>
>>
>>> Can anyone here tell me how the GC memory area size is determined? If
>>> there
>>> is documentation, so much the better as we'd prefer not to depend on code
>>> details that might flux arbitrarily.
>>>
>>>
>> GC memory is mainly data structures used by GC runtime. It can be varied
>> by collector used, size of the Java heap, the number of GC threads and etc.
>> and, of course, the application itself.
>>
>> Some are *fixed* costs, which can be estimated. E.g. two marking bitmaps
>> used by G1, each costs 1/64 of heap size (assuming default object
>> alignment).
>>
>> Some are *semi-fixed*, e.g. taskqueue's fixed cost is about 1M for each
>> queue on 64-bits VM, but it can overflow. And the number of task queues is
>> proportional to the number of GC threads.
>>
>> Then there are factors from application itself,  such as object mutation
>> rate, inter-generation/region references, etc.
>>
>>
>> I don't see a single formula for estimating GC memory size. If you are
>> using G1, the biggest overhead comes from 2 bitmaps (1/32 * heap size).
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>
>>
> 
> 

From gnormington at pivotal.io  Wed Dec 13 14:35:00 2017
From: gnormington at pivotal.io (Glyn Normington)
Date: Wed, 13 Dec 2017 14:35:00 +0000
Subject: Excessive "GC" memory area size [was: Re: Determining "GC" memory
 area size]
In-Reply-To: <0cd04045-ef97-16bf-874a-6703d6222578@redhat.com>
References: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>
 <0cd04045-ef97-16bf-874a-6703d6222578@redhat.com>
Message-ID: <CAA-6JZpAkm-Tm4wkFkpD8jVk2+eq20GFFxEj6nKwazik8dNHhQ@mail.gmail.com>

Thanks Zhengyu! That got me quite a bit further.

The NMT virtual memory map showed the mmap portion of GC space consisting
of:
* the two marking bitmaps you mentioned previously, each 1/64 of heap size.
* a mark stack of 32 MB which is 8* MarkStackSize (but which could grow to
8* MarkStackSizeMax or 128 MB).
* three 700 KB areas, although I'm not sure what these are used for or how
to predict their total size.

This leaves the malloc portion of GC space "17615KB #2312" which I think
was due 2312 calls to malloc. Again, not sure what these are used for or
how to predict their total size except that I presume they include the task
queues you mentioned previously.

Outstanding questions:
1. Is the mmap space which consumed three 700 KB areas above fixed,
proportional to heap size, or what?
2. How many task queues are there for a given number of GC threads?
3. Task queues can overflow, so what is the maximum space each one can
occupy?
4. Of the malloc space not consumed by task queues, how much is fixed and
how much proportional to heap size, number of GC threads, etc.?

The aim is to calculate a reasonable estimate of an upper bound for GC
space consumption.

Raw data for anyone who's interested:
https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6

Regards,
Glyn

On Wed, Dec 13, 2017 at 12:27 PM, Zhengyu Gu <zgu at redhat.com> wrote:

> Hi Glyn,
>
> You can run NMT with detail tracking (-XX:NativeMemoryTracking=detail)
> then use jcmd (jcmd <pid> VM.native_memory detail) to find out all
> allocations for GC.
>
> For example:
>
> [0x00007f9fba000000 - 0x00007f9fbc000000] reserved 32768KB for *GC* from
>     [0x00007fa0130260ef] G1CMMarkStack::resize(unsigned long)+0x8f
>     [0x00007fa01302cf62] G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
> G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>     [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
>     [0x00007fa013ca26af] universe_init()+0x6f
>
>         [0x00007f9fba000000 - 0x00007f9fbc000000] committed 32768KB from
>             [0x00007fa01302610d] G1CMMarkStack::resize(unsigned long)+0xad
>             [0x00007fa01302cf62] G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
> G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>             [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
>             [0x00007fa013ca26af] universe_init()+0x6f
>
>
> [0x00007fa012ac5395] ArrayAllocator<unsigned long>::allocate(unsigned
> long, MemoryType)+0x245
> [0x00007fa012ac5448] unsigned long* BitMap::reallocate<CHeapBitMap
> Allocator>(CHeapBitMapAllocator const&, unsigned long*, unsigned long,
> unsigned long)+0x38
> [0x00007fa012ac509f] CHeapBitMap::initialize(unsigned long)+0x6f
> [0x00007fa013093b9c] G1PageBasedVirtualSpace::G1Pag
> eBasedVirtualSpace(ReservedSpace, unsigned long, unsigned long)+0x13c
>                              (malloc=129KB *type=GC* #6)
>
> Thanks,
>
> -Zhengyu
>
>
>
>
> On 12/13/2017 04:39 AM, Glyn Normington wrote:
>
>> On the basis of the reply below, we have been thinking of estimating the
>> size of the "GC" memory area as a little more than (1/32) * heapSize.
>> However, running `java -version` with a 350m heap results in "GC" memory
>> as
>> reported by NMT of over 17% of the heap size, so this estimate is way out.
>>
>> If the analysis below is accurate, then given the number of GC threads is
>> 10 (ParallelGCThreads=8, ConcGCThreads=2), can there be many more
>> taskqueues than GC threads?
>>
>> Or is there another explanation for the additional "GC" size?
>>
>> Thanks,
>> Glyn
>>
>> [1] https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>>
>> On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu <zgu at redhat.com> wrote:
>>
>> Hi Glyn,
>>>
>>>
>>> Can anyone here tell me how the GC memory area size is determined? If
>>>> there
>>>> is documentation, so much the better as we'd prefer not to depend on
>>>> code
>>>> details that might flux arbitrarily.
>>>>
>>>>
>>>> GC memory is mainly data structures used by GC runtime. It can be varied
>>> by collector used, size of the Java heap, the number of GC threads and
>>> etc.
>>> and, of course, the application itself.
>>>
>>> Some are *fixed* costs, which can be estimated. E.g. two marking bitmaps
>>> used by G1, each costs 1/64 of heap size (assuming default object
>>> alignment).
>>>
>>> Some are *semi-fixed*, e.g. taskqueue's fixed cost is about 1M for each
>>> queue on 64-bits VM, but it can overflow. And the number of task queues
>>> is
>>> proportional to the number of GC threads.
>>>
>>> Then there are factors from application itself,  such as object mutation
>>> rate, inter-generation/region references, etc.
>>>
>>>
>>> I don't see a single formula for estimating GC memory size. If you are
>>> using G1, the biggest overhead comes from 2 bitmaps (1/32 * heap size).
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>
>>>
>>>
>>
>>


-- 
Regards,
Glyn

From bob.vandette at oracle.com  Wed Dec 13 14:58:38 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 13 Dec 2017 09:58:38 -0500
Subject: Additional JEPS 8182070 requirement: avoiding container OOM
In-Reply-To: <CAA-6JZot6rBg1Eynehk9EQvQFF2cNpZFX4Bat_FE9nm0BzMAxw@mail.gmail.com>
References: <CAA-6JZrGWai5z57e+U7f92K3eb0VVp9xj0MwQ1Zi9ms5OKh3vw@mail.gmail.com>
 <CAA-6JZot6rBg1Eynehk9EQvQFF2cNpZFX4Bat_FE9nm0BzMAxw@mail.gmail.com>
Message-ID: <4F9A9BCE-AE0A-4C2D-979E-F4D8482EC5C0@oracle.com>

Hi Glyn,

The JEP you mention is going to be updated in a week or so to refocus it?s goals
on monitoring of the JVM running in containers.  This is due to the fact that I was
able to split out the work of dynamically configuring the VM based on container
settings and integrate this work into JDK 10.  This work was integrated under jira issue
https://bugs.openjdk.java.net/browse/JDK-8146115 <https://bugs.openjdk.java.net/browse/JDK-8146115>.

Although this change does not completely address your requirement, it should help.
This change causes the JVM to correctly configure the number of threads and memory
allocations based on the resources configured in the container.  This change also
introduces a new JVM option (-XX:ActiveProcessorCount=xx) which allows the user
to specify how many processors the JVM should use.  We will now honor cpu shares, quotas
in addition to cpusets for determining the number of threads that the JVM will use.

Prior to this change, I also added https://bugs.openjdk.java.net/browse/JDK-8186315 <https://bugs.openjdk.java.net/browse/JDK-8186315>.
This change allows the user to specify the percentage of container memory that
should be used by the Java Heap.  This allows the users to reserve memory outside
of the Java heap for other classes of memory allocations (C-Heap for example).

Both of these changes have been integrated into JDK 10 and are available in the
latest early access release of Linux x64 (http://jdk.java.net/10/ <http://jdk.java.net/10/>).

I will talk to the Hotspot runtime folks about your requirement but other than these 
options, have you considered configuring your containers to use some swap space
in addition to memory configurations so that temporary spikes in memory consumption 
won?t cause an OOM ?  There are also ways of disabling the OOM killer in containers.
If we get a failed memory allocation, we will try to deliver a Java OutOfMemory
exception which would at least allow you to figure out what went wrong.  I haven?t looked 
into this yet but it is something worth considering.

Bob.



> On Dec 13, 2017, at 4:13 AM, Glyn Normington <gnormington at pivotal.io> wrote:
> 
> I wonder if someone involved in JEPS 8182070 (Container aware Java) would
> care to comment on the additional requirement described below?
> 
> On Mon, Nov 13, 2017 at 9:30 AM, Glyn Normington <gnormington at pivotal.io>
> wrote:
> 
>> I would like to mention an additional requirement for JEPS 8182070 (
>> http://openjdk.java.net/jeps/8182070): avoid the JVM hitting container
>> OOM by strictly bounding the amount of (physical) memory that the JVM
>> consumes. This may be implicit in the document, but I think it should be
>> made an explicit goal.
>> 
>> If a java application hits container OOM, no detailed diagnostics, such as
>> those associated with an OutOfMemoryError or a JVMTI resource exhaustion
>> event, are presented to the user, so the user finds it very difficult to
>> know how to fix the problem.
>> 
>> The Cloud Foundry OSS project has done quite a bit of work on this problem
>> and provides a couple of utilities which help when running a JVM in a
>> container:
>> 
>> * Java memory calculator ([1], [2]) to determine JVM memory settings,
>> * jvmkill JVMTI agent ([3]) to report detailed diagnostics on a resource
>> exhaustion event.
>> 
>> Regards,
>> Glyn
>> 
>> [1] https://github.com/cloudfoundry/java-buildpack-memory-calculator
>> 
>> [2] Design doc: https://docs.google.com/document/d/
>> 1vlXBiwRIjwiVcbvUGYMrxx2Aw1RVAtxq3iuZ3UK2vXA/edit#heading=h.uy41ishpv9zc
>> 
>> [3] https://github.com/cloudfoundry/jvmkill
>> 
> 
> 
> 
> -- 
> Regards,
> Glyn


From zgu at redhat.com  Wed Dec 13 15:16:10 2017
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 13 Dec 2017 10:16:10 -0500
Subject: Excessive "GC" memory area size [was: Re: Determining "GC" memory
 area size]
In-Reply-To: <CAA-6JZpAkm-Tm4wkFkpD8jVk2+eq20GFFxEj6nKwazik8dNHhQ@mail.gmail.com>
References: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>
 <0cd04045-ef97-16bf-874a-6703d6222578@redhat.com>
 <CAA-6JZpAkm-Tm4wkFkpD8jVk2+eq20GFFxEj6nKwazik8dNHhQ@mail.gmail.com>
Message-ID: <83f18360-5dab-7780-3f28-db5abfed19e7@redhat.com>

Hi Glyn,

On 12/13/2017 09:35 AM, Glyn Normington wrote:
> Thanks Zhengyu! That got me quite a bit further.
> 
> The NMT virtual memory map showed the mmap portion of GC space 
> consisting of:
> * the two marking bitmaps you mentioned previously, each 1/64 of heap size.
> * a mark stack of 32 MB which is 8* MarkStackSize (but which could grow 
> to 8* MarkStackSizeMax or 128 MB).
> * three 700 KB areas, although I'm not sure what these are used for or 
> how to predict their total size.
> 
> This leaves the malloc portion of GC space "17615KB #2312" which I think 
> was due 2312 calls to malloc. Again, not sure what these are used for or 
> how to predict their total size except that I presume they include the 
> task queues you mentioned previously.

Can you try on JDK10? it has enhancement [1] which can show what memory 
allocation is for, on each allocation site.


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

Thanks,

-Zhengyu

> 
> Outstanding questions:
> 1. Is the mmap space which consumed three 700 KB areas above fixed, 
> proportional to heap size, or what?
> 2. How many task queues are there for a given number of GC threads?
> 3. Task queues can overflow, so what is the maximum space each one can 
> occupy?
> 4. Of the malloc space not consumed by task queues, how much is fixed 
> and how much proportional to heap size, number of GC threads, etc.?
> 
> The aim is to calculate a reasonable estimate of an upper bound for GC 
> space consumption.
> 
> Raw data for anyone who's interested: 
> https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6
> 
> Regards,
> Glyn
> 
> On Wed, Dec 13, 2017 at 12:27 PM, Zhengyu Gu <zgu at redhat.com 
> <mailto:zgu at redhat.com>> wrote:
> 
>     Hi Glyn,
> 
>     You can run NMT with detail tracking
>     (-XX:NativeMemoryTracking=detail) then use jcmd (jcmd <pid>
>     VM.native_memory detail) to find out all allocations for GC.
> 
>     For example:
> 
>     [0x00007f9fba000000 - 0x00007f9fbc000000] reserved 32768KB for *GC* from
>          [0x00007fa0130260ef] G1CMMarkStack::resize(unsigned long)+0x8f
>          [0x00007fa01302cf62]
>     G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>     G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>          [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
>          [0x00007fa013ca26af] universe_init()+0x6f
> 
>              [0x00007f9fba000000 - 0x00007f9fbc000000] committed 32768KB
>     from
>                  [0x00007fa01302610d] G1CMMarkStack::resize(unsigned
>     long)+0xad
>                  [0x00007fa01302cf62]
>     G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>     G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>                  [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
>                  [0x00007fa013ca26af] universe_init()+0x6f
> 
> 
>     [0x00007fa012ac5395] ArrayAllocator<unsigned
>     long>::allocate(unsigned long, MemoryType)+0x245
>     [0x00007fa012ac5448] unsigned long*
>     BitMap::reallocate<CHeapBitMapAllocator>(CHeapBitMapAllocator
>     const&, unsigned long*, unsigned long, unsigned long)+0x38
>     [0x00007fa012ac509f] CHeapBitMap::initialize(unsigned long)+0x6f
>     [0x00007fa013093b9c]
>     G1PageBasedVirtualSpace::G1PageBasedVirtualSpace(ReservedSpace,
>     unsigned long, unsigned long)+0x13c
>                                   (malloc=129KB *type=GC* #6)
> 
>     Thanks,
> 
>     -Zhengyu
> 
> 
> 
> 
>     On 12/13/2017 04:39 AM, Glyn Normington wrote:
> 
>         On the basis of the reply below, we have been thinking of
>         estimating the
>         size of the "GC" memory area as a little more than (1/32) *
>         heapSize.
>         However, running `java -version` with a 350m heap results in
>         "GC" memory as
>         reported by NMT of over 17% of the heap size, so this estimate
>         is way out.
> 
>         If the analysis below is accurate, then given the number of GC
>         threads is
>         10 (ParallelGCThreads=8, ConcGCThreads=2), can there be many more
>         taskqueues than GC threads?
> 
>         Or is there another explanation for the additional "GC" size?
> 
>         Thanks,
>         Glyn
> 
>         [1]
>         https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>
> 
>         On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu <zgu at redhat.com
>         <mailto:zgu at redhat.com>> wrote:
> 
>             Hi Glyn,
> 
> 
>                 Can anyone here tell me how the GC memory area size is
>                 determined? If
>                 there
>                 is documentation, so much the better as we'd prefer not
>                 to depend on code
>                 details that might flux arbitrarily.
> 
> 
>             GC memory is mainly data structures used by GC runtime. It
>             can be varied
>             by collector used, size of the Java heap, the number of GC
>             threads and etc.
>             and, of course, the application itself.
> 
>             Some are *fixed* costs, which can be estimated. E.g. two
>             marking bitmaps
>             used by G1, each costs 1/64 of heap size (assuming default
>             object
>             alignment).
> 
>             Some are *semi-fixed*, e.g. taskqueue's fixed cost is about
>             1M for each
>             queue on 64-bits VM, but it can overflow. And the number of
>             task queues is
>             proportional to the number of GC threads.
> 
>             Then there are factors from application itself,  such as
>             object mutation
>             rate, inter-generation/region references, etc.
> 
> 
>             I don't see a single formula for estimating GC memory size.
>             If you are
>             using G1, the biggest overhead comes from 2 bitmaps (1/32 *
>             heap size).
> 
>             Thanks,
> 
>             -Zhengyu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Regards,
> Glyn

From stuart.monteith at linaro.org  Wed Dec 13 15:56:21 2017
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Wed, 13 Dec 2017 15:56:21 +0000
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <b3927395-4c7e-c3f1-4788-0bbbc8956292@redhat.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
 <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
 <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>
 <d8348c30-f509-c94e-9c9e-1d397973b758@redhat.com>
 <CAEGA6kac5=5ydKLgBjh+Z53To4owm63J4ppLV12DQAwhe+nnuw@mail.gmail.com>
 <b3927395-4c7e-c3f1-4788-0bbbc8956292@redhat.com>
Message-ID: <CAEGA6kaLEXvURu8ScwKb-rpSwLWOrKksvkRfKL8wsKb2_cq+tQ@mail.gmail.com>

Hello,
   Here's most latest patch:

http://cr.openjdk.java.net/~smonteith/8193266/webrev-2/

Things to note:
   I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp
and metaspaceShared.cpp
MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is
the same value as UnscaledOopHeapMax. Perhaps that should be used
instead of UnscaledClassSpaceMax in all three places.
   I'm using the constant in MacroAssembler_aarch64.hpp in the
MacroAssembler constructor instead of CompressedClassSpaceSize.
   The calculation has changed - "1u" has changed to "1ul" as the
address "0x100000000" is not representable as a 32 bit value.
   The test has changed from ">" to ">=" as the greatest offset for
4GB is "0xffffffff", and so 0x100000000 and upwards are all acceptable
for XORing offsets to.

The intention is to prevent bad code from being generated if the
compressed class addresses range changes.

BR,
   Stuart

On 11 December 2017 at 13:54, Andrew Haley <aph at redhat.com> wrote:
> On 11/12/17 13:43, Stuart Monteith wrote:
>> I've copied and pasted the calculation for UnscaledClassSpaceMax in
>> use_XOR_for_compressed_class_base to match the variable of the same
>> name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces  -
>> I did this for ease of reference while we decide what to do.
>
> Yes, I get that.  I don't want to pessimize the "normal" use of OpenJDK
> AArch64 for the sake of this weird case.  I guess that as long as no-
> one explicitly sets the base of the metaspace below 32 bits it doesn't
> matter anyway.
>
> --
> 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 gnormington at pivotal.io  Wed Dec 13 16:01:24 2017
From: gnormington at pivotal.io (Glyn Normington)
Date: Wed, 13 Dec 2017 16:01:24 +0000
Subject: Additional JEPS 8182070 requirement: avoiding container OOM
In-Reply-To: <4F9A9BCE-AE0A-4C2D-979E-F4D8482EC5C0@oracle.com>
References: <CAA-6JZrGWai5z57e+U7f92K3eb0VVp9xj0MwQ1Zi9ms5OKh3vw@mail.gmail.com>
 <CAA-6JZot6rBg1Eynehk9EQvQFF2cNpZFX4Bat_FE9nm0BzMAxw@mail.gmail.com>
 <4F9A9BCE-AE0A-4C2D-979E-F4D8482EC5C0@oracle.com>
Message-ID: <CAA-6JZpa0LSxz_Sd=h+un=VT=nhLgK_xRt7mciiQXtKL8XUsQg@mail.gmail.com>

Hi Bob

Thanks very much for that information. Some comments inline. This one could
be relevant to the refocussed JEP: the JVM should monitor its approach to
the container memory limit and trigger "out of memory" processing at some
threshold close to the limit.

Regards,
Glyn

On Wed, Dec 13, 2017 at 2:58 PM, Bob Vandette <bob.vandette at oracle.com>
wrote:

> Hi Glyn,
>
> The JEP you mention is going to be updated in a week or so to refocus it?s
> goals
> on monitoring of the JVM running in containers.  This is due to the fact
> that I was
> able to split out the work of dynamically configuring the VM based on
> container
> settings and integrate this work into JDK 10.  This work was integrated
> under jira issue
> https://bugs.openjdk.java.net/browse/JDK-8146115.
>
> Although this change does not completely address your requirement, it
> should help.
> This change causes the JVM to correctly configure the number of threads
> and memory
> allocations based on the resources configured in the container.  This
> change also
> introduces a new JVM option (-XX:ActiveProcessorCount=xx) which allows
> the user
> to specify how many processors the JVM should use.  We will now honor cpu
> shares, quotas
> in addition to cpusets for determining the number of threads that the JVM
> will use.
>

Yes, that does sound like a useful set of changes.


>
> Prior to this change, I also added https://bugs.openjdk.jav
> a.net/browse/JDK-8186315.
> This change allows the user to specify the percentage of container memory
> that
> should be used by the Java Heap.  This allows the users to reserve memory
> outside
> of the Java heap for other classes of memory allocations (C-Heap for
> example).
>
> Both of these changes have been integrated into JDK 10 and are available
> in the
> latest early access release of Linux x64 (http://jdk.java.net/10/).
>

How interesting! The previous version of our Java memory calculator allowed
the heap size to be specified as a proportion of container memory, but we
could only guess at a default proportion and users found it quite hard to
know what value to use when they needed to increase or decrease heap size.

The current version adopts a different approach: we try to calculate JVM
memory consumption (apart from heap) from the JVM options and then subtract
that value from the container memory to get the maximum heap size. This
approach suffers from the difficulty of predicting the memory consumption
of the JVM with any accuracy (see my recent thread entitled 'Excessive "GC"
memory area size'). The up-side of the new approach is that the user can
override the behaviour using standard JVM options rather than proportions.


>
> I will talk to the Hotspot runtime folks about your requirement
>

Thanks very much.


> but other than these
> options, have you considered configuring your containers to use some swap
> space
> in addition to memory configurations so that temporary spikes in memory
> consumption
> won?t cause an OOM ?
>

We talked about this but we need to bound the amount of swap space because
our environment is a PaaS and we can't allow users to consume more than
their fair share of system resources. If we did enable a bounded swap
space, I think we'd hit the same issue when the RAM+swap limit was exceeded.


> There are also ways of disabling the OOM killer in containers.
>

We actually tried that. We started the container with the OOM killer
disabled and when the container hit OOM, we gathered diagnostics and
re-enabled the OOM killer to terminate the container. The main issue with
that is the container-level diagnostics (number of committed pages of RAM
etc.) don't tell the Java programmer what JVM options need changing to
avoid the problem in future.

A more sophisticated approach along those lines would be to disable the OOM
killer and when the container *nears* its limit somehow trigger the JVM to
do "out of memory" processing. Then our JVMTI agent would be driven and
produce plenty of diagnostics suitable for a Java programmer. This is a bit
speculative though as it requires fairly deep changes to the container
configuration as well as solving the problem of how to trigger the JVM to
do its "out of memory" processing. Maybe a more practical solution there is
for the JVM itself to monitor its approach to the container memory limit
and trigger "out of memory" processing at some threshold close to the
limit. This could be relevant to the JEP.


> If we get a failed memory allocation, we will try to deliver a Java
> OutOfMemory
> exception which would at least allow you to figure out what went wrong.  I
> haven?t looked
> into this yet but it is something worth considering.
>

Yeah, OutOfMemory exceptions provide some useful information, although we
found it was insufficiently detailed which is why we wrote a JVMTI agent to
dump out detailed diagnostics.


>
> Bob.
>
>
>
> On Dec 13, 2017, at 4:13 AM, Glyn Normington <gnormington at pivotal.io>
> wrote:
>
> I wonder if someone involved in JEPS 8182070 (Container aware Java) would
> care to comment on the additional requirement described below?
>
> On Mon, Nov 13, 2017 at 9:30 AM, Glyn Normington <gnormington at pivotal.io>
> wrote:
>
> I would like to mention an additional requirement for JEPS 8182070 (
> http://openjdk.java.net/jeps/8182070): avoid the JVM hitting container
> OOM by strictly bounding the amount of (physical) memory that the JVM
> consumes. This may be implicit in the document, but I think it should be
> made an explicit goal.
>
> If a java application hits container OOM, no detailed diagnostics, such as
> those associated with an OutOfMemoryError or a JVMTI resource exhaustion
> event, are presented to the user, so the user finds it very difficult to
> know how to fix the problem.
>
> The Cloud Foundry OSS project has done quite a bit of work on this problem
> and provides a couple of utilities which help when running a JVM in a
> container:
>
> * Java memory calculator ([1], [2]) to determine JVM memory settings,
> * jvmkill JVMTI agent ([3]) to report detailed diagnostics on a resource
> exhaustion event.
>
> Regards,
> Glyn
>
> [1] https://github.com/cloudfoundry/java-buildpack-memory-calculator
>
> [2] Design doc: https://docs.google.com/document/d/
> 1vlXBiwRIjwiVcbvUGYMrxx2Aw1RVAtxq3iuZ3UK2vXA/edit#heading=h.uy41ishpv9zc
>
> [3] https://github.com/cloudfoundry/jvmkill
>
>
>
>
> --
> Regards,
> Glyn
>
>
>


-- 
Regards,
Glyn

From gnormington at pivotal.io  Wed Dec 13 16:38:28 2017
From: gnormington at pivotal.io (Glyn Normington)
Date: Wed, 13 Dec 2017 16:38:28 +0000
Subject: Excessive "GC" memory area size [was: Re: Determining "GC" memory
 area size]
In-Reply-To: <83f18360-5dab-7780-3f28-db5abfed19e7@redhat.com>
References: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>
 <0cd04045-ef97-16bf-874a-6703d6222578@redhat.com>
 <CAA-6JZpAkm-Tm4wkFkpD8jVk2+eq20GFFxEj6nKwazik8dNHhQ@mail.gmail.com>
 <83f18360-5dab-7780-3f28-db5abfed19e7@redhat.com>
Message-ID: <CAA-6JZpXF3LLYrg6npEHOcZx_a6K5=C7Z6jsASgxGaHWa-Ukdg@mail.gmail.com>

Hi Zhengyu

Thanks again for a great suggestion. JDK 10 gave more insights such as this
one showing a task queue-related malloc of 8 MB:

0x000000010d128e58]
_ZN20MallocArrayAllocatorI16G1TaskQueueEntryE8allocateEm10MemoryType+0x5c
[0x000000010d12372e]
_ZN16G1ConcurrentMarkC2EP15G1CollectedHeapP21G1RegionToSpaceMapperS3_+0x8e4
[0x000000010d1198af] _ZN15G1CollectedHeap10initializeEv+0x561
[0x000000010d559029] _ZN8Universe15initialize_heapEv+0x4f
                             (malloc=8192KB type=GC #8)

The malloc details don't seem to add up to the total, so maybe some
allocation sites got missed, but it's definitely better than with JDK 8.

Regards,
Glyn


On Wed, Dec 13, 2017 at 3:16 PM, Zhengyu Gu <zgu at redhat.com> wrote:

> Hi Glyn,
>
> On 12/13/2017 09:35 AM, Glyn Normington wrote:
>
>> Thanks Zhengyu! That got me quite a bit further.
>>
>> The NMT virtual memory map showed the mmap portion of GC space consisting
>> of:
>> * the two marking bitmaps you mentioned previously, each 1/64 of heap
>> size.
>> * a mark stack of 32 MB which is 8* MarkStackSize (but which could grow
>> to 8* MarkStackSizeMax or 128 MB).
>> * three 700 KB areas, although I'm not sure what these are used for or
>> how to predict their total size.
>>
>> This leaves the malloc portion of GC space "17615KB #2312" which I think
>> was due 2312 calls to malloc. Again, not sure what these are used for or
>> how to predict their total size except that I presume they include the task
>> queues you mentioned previously.
>>
>
> Can you try on JDK10? it has enhancement [1] which can show what memory
> allocation is for, on each allocation site.
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8139673
>
> Thanks,
>
> -Zhengyu
>
>
>> Outstanding questions:
>> 1. Is the mmap space which consumed three 700 KB areas above fixed,
>> proportional to heap size, or what?
>> 2. How many task queues are there for a given number of GC threads?
>> 3. Task queues can overflow, so what is the maximum space each one can
>> occupy?
>> 4. Of the malloc space not consumed by task queues, how much is fixed and
>> how much proportional to heap size, number of GC threads, etc.?
>>
>> The aim is to calculate a reasonable estimate of an upper bound for GC
>> space consumption.
>>
>> Raw data for anyone who's interested: https://gist.github.com/glyn/a
>> 3bd944eb2943f4f5a98b5ac712efeb6
>>
>> Regards,
>> Glyn
>>
>> On Wed, Dec 13, 2017 at 12:27 PM, Zhengyu Gu <zgu at redhat.com <mailto:
>> zgu at redhat.com>> wrote:
>>
>>     Hi Glyn,
>>
>>     You can run NMT with detail tracking
>>     (-XX:NativeMemoryTracking=detail) then use jcmd (jcmd <pid>
>>     VM.native_memory detail) to find out all allocations for GC.
>>
>>     For example:
>>
>>     [0x00007f9fba000000 - 0x00007f9fbc000000] reserved 32768KB for *GC*
>> from
>>          [0x00007fa0130260ef] G1CMMarkStack::resize(unsigned long)+0x8f
>>          [0x00007fa01302cf62]
>>     G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>>     G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>>          [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
>>          [0x00007fa013ca26af] universe_init()+0x6f
>>
>>              [0x00007f9fba000000 - 0x00007f9fbc000000] committed 32768KB
>>     from
>>                  [0x00007fa01302610d] G1CMMarkStack::resize(unsigned
>>     long)+0xad
>>                  [0x00007fa01302cf62]
>>     G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>>     G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>>                  [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
>>                  [0x00007fa013ca26af] universe_init()+0x6f
>>
>>
>>     [0x00007fa012ac5395] ArrayAllocator<unsigned
>>     long>::allocate(unsigned long, MemoryType)+0x245
>>     [0x00007fa012ac5448] unsigned long*
>>     BitMap::reallocate<CHeapBitMapAllocator>(CHeapBitMapAllocator
>>     const&, unsigned long*, unsigned long, unsigned long)+0x38
>>     [0x00007fa012ac509f] CHeapBitMap::initialize(unsigned long)+0x6f
>>     [0x00007fa013093b9c]
>>     G1PageBasedVirtualSpace::G1PageBasedVirtualSpace(ReservedSpace,
>>     unsigned long, unsigned long)+0x13c
>>                                   (malloc=129KB *type=GC* #6)
>>
>>     Thanks,
>>
>>     -Zhengyu
>>
>>
>>
>>
>>     On 12/13/2017 04:39 AM, Glyn Normington wrote:
>>
>>         On the basis of the reply below, we have been thinking of
>>         estimating the
>>         size of the "GC" memory area as a little more than (1/32) *
>>         heapSize.
>>         However, running `java -version` with a 350m heap results in
>>         "GC" memory as
>>         reported by NMT of over 17% of the heap size, so this estimate
>>         is way out.
>>
>>         If the analysis below is accurate, then given the number of GC
>>         threads is
>>         10 (ParallelGCThreads=8, ConcGCThreads=2), can there be many more
>>         taskqueues than GC threads?
>>
>>         Or is there another explanation for the additional "GC" size?
>>
>>         Thanks,
>>         Glyn
>>
>>         [1]
>>         https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>
>>
>>         On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu <zgu at redhat.com
>>         <mailto:zgu at redhat.com>> wrote:
>>
>>             Hi Glyn,
>>
>>
>>                 Can anyone here tell me how the GC memory area size is
>>                 determined? If
>>                 there
>>                 is documentation, so much the better as we'd prefer not
>>                 to depend on code
>>                 details that might flux arbitrarily.
>>
>>
>>             GC memory is mainly data structures used by GC runtime. It
>>             can be varied
>>             by collector used, size of the Java heap, the number of GC
>>             threads and etc.
>>             and, of course, the application itself.
>>
>>             Some are *fixed* costs, which can be estimated. E.g. two
>>             marking bitmaps
>>             used by G1, each costs 1/64 of heap size (assuming default
>>             object
>>             alignment).
>>
>>             Some are *semi-fixed*, e.g. taskqueue's fixed cost is about
>>             1M for each
>>             queue on 64-bits VM, but it can overflow. And the number of
>>             task queues is
>>             proportional to the number of GC threads.
>>
>>             Then there are factors from application itself,  such as
>>             object mutation
>>             rate, inter-generation/region references, etc.
>>
>>
>>             I don't see a single formula for estimating GC memory size.
>>             If you are
>>             using G1, the biggest overhead comes from 2 bitmaps (1/32 *
>>             heap size).
>>
>>             Thanks,
>>
>>             -Zhengyu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Regards,
>> Glyn
>>
>


-- 
Regards,
Glyn

From mandy.chung at oracle.com  Wed Dec 13 16:47:43 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 13 Dec 2017 08:47:43 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <7dc8336c-7024-e02a-accf-d8fc2a92d5bf@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
 <c3cca6dc-14f2-855a-e2be-fa60c0ad9ac8@oracle.com>
 <85ed009a-5c31-80fb-b8ae-1f889843e6e7@oracle.com>
 <7dc8336c-7024-e02a-accf-d8fc2a92d5bf@oracle.com>
Message-ID: <b75992eb-5ff6-bf12-a695-581712eb956a@oracle.com>



On 12/13/17 12:16 AM, Vladimir Kozlov wrote:
> After several rounds of testing (which found different types of 
> failures with Graal as JIT compiler) I decided to limit these changes 
> for cases when --limit-modules is used:
>
> http://cr.openjdk.java.net/~kvn/8191788/webrev.01/

Looks okay.

Since the number of tests with --limit-modules is small, filtering them 
out when running with Graal as JIT compiler is a reasonable approach for 
JDK 10.?? At some point, we may revisit this and possibly a test library 
to deal with similar use case - tests with limited modules when running 
with additional VM flags requiring observable modules.? I will create an 
issue for it.

Mandy

From bob.vandette at oracle.com  Wed Dec 13 16:51:44 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 13 Dec 2017 11:51:44 -0500
Subject: Additional JEPS 8182070 requirement: avoiding container OOM
In-Reply-To: <CAA-6JZpa0LSxz_Sd=h+un=VT=nhLgK_xRt7mciiQXtKL8XUsQg@mail.gmail.com>
References: <CAA-6JZrGWai5z57e+U7f92K3eb0VVp9xj0MwQ1Zi9ms5OKh3vw@mail.gmail.com>
 <CAA-6JZot6rBg1Eynehk9EQvQFF2cNpZFX4Bat_FE9nm0BzMAxw@mail.gmail.com>
 <4F9A9BCE-AE0A-4C2D-979E-F4D8482EC5C0@oracle.com>
 <CAA-6JZpa0LSxz_Sd=h+un=VT=nhLgK_xRt7mciiQXtKL8XUsQg@mail.gmail.com>
Message-ID: <5250BF60-FE77-45C6-B650-476AB5837A2C@oracle.com>


> On Dec 13, 2017, at 11:01 AM, Glyn Normington <gnormington at pivotal.io> wrote:
> 
> Hi Bob
> 
> Thanks very much for that information. Some comments inline. This one could be relevant to the refocussed JEP: the JVM should monitor its approach to the container memory limit and trigger "out of memory" processing at some threshold close to the limit.

Memory allocations in hotspot are difficult to track since there are many different allocators 
and we don?t control them all.  Thread stacks get dynamically allocated upon use, the C++ runtime allocates 
memory for native code and third party JNI library could be calling malloc.  These are all in addition
to the allocators we do control - Java Heap and internal Memory Arenas for runtime metadata.

One possible solution is to at least attempt threshold checking during allocations we
do control and to do OOM processing at that time.  This wouldn?t catch every case but could
increase the robustness of the Java runtime.  With the change I introduced in JDK-8146155,
we now at least have a way of finding out how much free memory is available in the container.

Bob.

> 
> Regards,
> Glyn
> 
> On Wed, Dec 13, 2017 at 2:58 PM, Bob Vandette <bob.vandette at oracle.com <mailto:bob.vandette at oracle.com>> wrote:
> Hi Glyn,
> 
> The JEP you mention is going to be updated in a week or so to refocus it?s goals
> on monitoring of the JVM running in containers.  This is due to the fact that I was
> able to split out the work of dynamically configuring the VM based on container
> settings and integrate this work into JDK 10.  This work was integrated under jira issue
> https://bugs.openjdk.java.net/browse/JDK-8146115 <https://bugs.openjdk.java.net/browse/JDK-8146115>.
> 
> Although this change does not completely address your requirement, it should help.
> This change causes the JVM to correctly configure the number of threads and memory
> allocations based on the resources configured in the container.  This change also
> introduces a new JVM option (-XX:ActiveProcessorCount=xx) which allows the user
> to specify how many processors the JVM should use.  We will now honor cpu shares, quotas
> in addition to cpusets for determining the number of threads that the JVM will use.
> 
> Yes, that does sound like a useful set of changes.
>  
> 
> Prior to this change, I also added https://bugs.openjdk.java.net/browse/JDK-8186315 <https://bugs.openjdk.java.net/browse/JDK-8186315>.
> This change allows the user to specify the percentage of container memory that
> should be used by the Java Heap.  This allows the users to reserve memory outside
> of the Java heap for other classes of memory allocations (C-Heap for example).
> 
> Both of these changes have been integrated into JDK 10 and are available in the
> latest early access release of Linux x64 (http://jdk.java.net/10/ <http://jdk.java.net/10/>).
> 
> How interesting! The previous version of our Java memory calculator allowed the heap size to be specified as a proportion of container memory, but we could only guess at a default proportion and users found it quite hard to know what value to use when they needed to increase or decrease heap size.
> 
> The current version adopts a different approach: we try to calculate JVM memory consumption (apart from heap) from the JVM options and then subtract that value from the container memory to get the maximum heap size. This approach suffers from the difficulty of predicting the memory consumption of the JVM with any accuracy (see my recent thread entitled 'Excessive "GC" memory area size'). The up-side of the new approach is that the user can override the behaviour using standard JVM options rather than proportions.
>  
> 
> I will talk to the Hotspot runtime folks about your requirement
> 
> Thanks very much.
>  
> but other than these 
> options, have you considered configuring your containers to use some swap space
> in addition to memory configurations so that temporary spikes in memory consumption 
> won?t cause an OOM ?
> 
> We talked about this but we need to bound the amount of swap space because our environment is a PaaS and we can't allow users to consume more than their fair share of system resources. If we did enable a bounded swap space, I think we'd hit the same issue when the RAM+swap limit was exceeded.
>  
> There are also ways of disabling the OOM killer in containers.
> 
> We actually tried that. We started the container with the OOM killer disabled and when the container hit OOM, we gathered diagnostics and re-enabled the OOM killer to terminate the container. The main issue with that is the container-level diagnostics (number of committed pages of RAM etc.) don't tell the Java programmer what JVM options need changing to avoid the problem in future.
> 
> A more sophisticated approach along those lines would be to disable the OOM killer and when the container *nears* its limit somehow trigger the JVM to do "out of memory" processing. Then our JVMTI agent would be driven and produce plenty of diagnostics suitable for a Java programmer. This is a bit speculative though as it requires fairly deep changes to the container configuration as well as solving the problem of how to trigger the JVM to do its "out of memory" processing. Maybe a more practical solution there is for the JVM itself to monitor its approach to the container memory limit and trigger "out of memory" processing at some threshold close to the limit. This could be relevant to the JEP.
>  
> If we get a failed memory allocation, we will try to deliver a Java OutOfMemory
> exception which would at least allow you to figure out what went wrong.  I haven?t looked 
> into this yet but it is something worth considering.
> 
> Yeah, OutOfMemory exceptions provide some useful information, although we found it was insufficiently detailed which is why we wrote a JVMTI agent to dump out detailed diagnostics.
>  
> 
> Bob.
> 
> 
> 
>> On Dec 13, 2017, at 4:13 AM, Glyn Normington <gnormington at pivotal.io <mailto:gnormington at pivotal.io>> wrote:
>> 
>> I wonder if someone involved in JEPS 8182070 (Container aware Java) would
>> care to comment on the additional requirement described below?
>> 
>> On Mon, Nov 13, 2017 at 9:30 AM, Glyn Normington <gnormington at pivotal.io <mailto:gnormington at pivotal.io>>
>> wrote:
>> 
>>> I would like to mention an additional requirement for JEPS 8182070 (
>>> http://openjdk.java.net/jeps/8182070 <http://openjdk.java.net/jeps/8182070>): avoid the JVM hitting container
>>> OOM by strictly bounding the amount of (physical) memory that the JVM
>>> consumes. This may be implicit in the document, but I think it should be
>>> made an explicit goal.
>>> 
>>> If a java application hits container OOM, no detailed diagnostics, such as
>>> those associated with an OutOfMemoryError or a JVMTI resource exhaustion
>>> event, are presented to the user, so the user finds it very difficult to
>>> know how to fix the problem.
>>> 
>>> The Cloud Foundry OSS project has done quite a bit of work on this problem
>>> and provides a couple of utilities which help when running a JVM in a
>>> container:
>>> 
>>> * Java memory calculator ([1], [2]) to determine JVM memory settings,
>>> * jvmkill JVMTI agent ([3]) to report detailed diagnostics on a resource
>>> exhaustion event.
>>> 
>>> Regards,
>>> Glyn
>>> 
>>> [1] https://github.com/cloudfoundry/java-buildpack-memory-calculator <https://github.com/cloudfoundry/java-buildpack-memory-calculator>
>>> 
>>> [2] Design doc: https://docs.google.com/document/d/ <https://docs.google.com/document/d/>
>>> 1vlXBiwRIjwiVcbvUGYMrxx2Aw1RVAtxq3iuZ3UK2vXA/edit#heading=h.uy41ishpv9zc
>>> 
>>> [3] https://github.com/cloudfoundry/jvmkill <https://github.com/cloudfoundry/jvmkill>
>>> 
>> 
>> 
>> 
>> -- 
>> Regards,
>> Glyn
> 
> 
> 
> 
> -- 
> Regards,
> Glyn


From vladimir.kozlov at oracle.com  Wed Dec 13 16:55:12 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 Dec 2017 08:55:12 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <b75992eb-5ff6-bf12-a695-581712eb956a@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
 <c3cca6dc-14f2-855a-e2be-fa60c0ad9ac8@oracle.com>
 <85ed009a-5c31-80fb-b8ae-1f889843e6e7@oracle.com>
 <7dc8336c-7024-e02a-accf-d8fc2a92d5bf@oracle.com>
 <b75992eb-5ff6-bf12-a695-581712eb956a@oracle.com>
Message-ID: <bf986033-6e92-a7a4-4109-7901aa7c3621@oracle.com>

Thank you, Mandy

Vladimir

On 12/13/17 8:47 AM, mandy chung wrote:
> 
> 
> On 12/13/17 12:16 AM, Vladimir Kozlov wrote:
>> After several rounds of testing (which found different types of 
>> failures with Graal as JIT compiler) I decided to limit these changes 
>> for cases when --limit-modules is used:
>>
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.01/
> 
> Looks okay.
> 
> Since the number of tests with --limit-modules is small, filtering them 
> out when running with Graal as JIT compiler is a reasonable approach for 
> JDK 10.?? At some point, we may revisit this and possibly a test library 
> to deal with similar use case - tests with limited modules when running 
> with additional VM flags requiring observable modules.? I will create an 
> issue for it.
> 
> Mandy

From Alan.Bateman at oracle.com  Wed Dec 13 16:58:30 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 13 Dec 2017 16:58:30 +0000
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <b75992eb-5ff6-bf12-a695-581712eb956a@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
 <c3cca6dc-14f2-855a-e2be-fa60c0ad9ac8@oracle.com>
 <85ed009a-5c31-80fb-b8ae-1f889843e6e7@oracle.com>
 <7dc8336c-7024-e02a-accf-d8fc2a92d5bf@oracle.com>
 <b75992eb-5ff6-bf12-a695-581712eb956a@oracle.com>
Message-ID: <64006fa7-a538-6c9a-9237-04ca31afde5a@oracle.com>



On 13/12/2017 16:47, mandy chung wrote:
>
>
> On 12/13/17 12:16 AM, Vladimir Kozlov wrote:
>> After several rounds of testing (which found different types of 
>> failures with Graal as JIT compiler) I decided to limit these changes 
>> for cases when --limit-modules is used:
>>
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.01/
>
> Looks okay.
>
> Since the number of tests with --limit-modules is small, filtering 
> them out when running with Graal as JIT compiler is a reasonable 
> approach for JDK 10.?? At some point, we may revisit this and possibly 
> a test library to deal with similar use case - tests with limited 
> modules when running with additional VM flags requiring observable 
> modules.? I will create an issue for it.
I looked at the webrev too, looks good and much better than modifying 
the VM to augment the list specified to --limit-modules.

-Alan

From vladimir.kozlov at oracle.com  Wed Dec 13 16:59:41 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 Dec 2017 08:59:41 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <64006fa7-a538-6c9a-9237-04ca31afde5a@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
 <c3cca6dc-14f2-855a-e2be-fa60c0ad9ac8@oracle.com>
 <85ed009a-5c31-80fb-b8ae-1f889843e6e7@oracle.com>
 <7dc8336c-7024-e02a-accf-d8fc2a92d5bf@oracle.com>
 <b75992eb-5ff6-bf12-a695-581712eb956a@oracle.com>
 <64006fa7-a538-6c9a-9237-04ca31afde5a@oracle.com>
Message-ID: <15c22fd0-2dd6-d4af-e7ea-3448d3e34fe0@oracle.com>

Thank you, Alan

Vladimir

On 12/13/17 8:58 AM, Alan Bateman wrote:
> 
> 
> On 13/12/2017 16:47, mandy chung wrote:
>>
>>
>> On 12/13/17 12:16 AM, Vladimir Kozlov wrote:
>>> After several rounds of testing (which found different types of 
>>> failures with Graal as JIT compiler) I decided to limit these changes 
>>> for cases when --limit-modules is used:
>>>
>>> http://cr.openjdk.java.net/~kvn/8191788/webrev.01/
>>
>> Looks okay.
>>
>> Since the number of tests with --limit-modules is small, filtering 
>> them out when running with Graal as JIT compiler is a reasonable 
>> approach for JDK 10.?? At some point, we may revisit this and possibly 
>> a test library to deal with similar use case - tests with limited 
>> modules when running with additional VM flags requiring observable 
>> modules.? I will create an issue for it.
> I looked at the webrev too, looks good and much better than modifying 
> the VM to augment the list specified to --limit-modules.
> 
> -Alan

From gnormington at pivotal.io  Wed Dec 13 17:00:58 2017
From: gnormington at pivotal.io (Glyn Normington)
Date: Wed, 13 Dec 2017 17:00:58 +0000
Subject: Additional JEPS 8182070 requirement: avoiding container OOM
In-Reply-To: <5250BF60-FE77-45C6-B650-476AB5837A2C@oracle.com>
References: <CAA-6JZrGWai5z57e+U7f92K3eb0VVp9xj0MwQ1Zi9ms5OKh3vw@mail.gmail.com>
 <CAA-6JZot6rBg1Eynehk9EQvQFF2cNpZFX4Bat_FE9nm0BzMAxw@mail.gmail.com>
 <4F9A9BCE-AE0A-4C2D-979E-F4D8482EC5C0@oracle.com>
 <CAA-6JZpa0LSxz_Sd=h+un=VT=nhLgK_xRt7mciiQXtKL8XUsQg@mail.gmail.com>
 <5250BF60-FE77-45C6-B650-476AB5837A2C@oracle.com>
Message-ID: <CAA-6JZoeZXRx4xBKj-fGfUmZWu=mryUp=ujU56tYsSgEoHYByA@mail.gmail.com>

On Wed, Dec 13, 2017 at 4:51 PM, Bob Vandette <bob.vandette at oracle.com>
wrote:

>
> On Dec 13, 2017, at 11:01 AM, Glyn Normington <gnormington at pivotal.io>
> wrote:
>
> Hi Bob
>
> Thanks very much for that information. Some comments inline. This one
> could be relevant to the refocussed JEP: the JVM should monitor its
> approach to the container memory limit and trigger "out of memory"
> processing at some threshold close to the limit.
>
>
> Memory allocations in hotspot are difficult to track since there are many
> different allocators
> and we don?t control them all.  Thread stacks get dynamically allocated
> upon use, the C++ runtime allocates
> memory for native code and third party JNI library could be calling
> malloc.  These are all in addition
> to the allocators we do control - Java Heap and internal Memory Arenas for
> runtime metadata.
>
> One possible solution is to at least attempt threshold checking during
> allocations we
> do control and to do OOM processing at that time.  This wouldn?t catch
> every case but could
> increase the robustness of the Java runtime.  With the change I introduced
> in JDK-8146155,
> we now at least have a way of finding out how much free memory is
> available in the container.
>

Another solution you might like to mull over is for the JVM to poll the
memory cgroup value memory.usage_in_bytes (assuming the memory cgroup is
mounted read-only inside the container) and trigger "out of memory" on some
threshold.


>
> Bob.
>
>
> Regards,
> Glyn
>
> On Wed, Dec 13, 2017 at 2:58 PM, Bob Vandette <bob.vandette at oracle.com>
> wrote:
>
>> Hi Glyn,
>>
>> The JEP you mention is going to be updated in a week or so to refocus
>> it?s goals
>> on monitoring of the JVM running in containers.  This is due to the fact
>> that I was
>> able to split out the work of dynamically configuring the VM based on
>> container
>> settings and integrate this work into JDK 10.  This work was integrated
>> under jira issue
>> https://bugs.openjdk.java.net/browse/JDK-8146115.
>>
>> Although this change does not completely address your requirement, it
>> should help.
>> This change causes the JVM to correctly configure the number of threads
>> and memory
>> allocations based on the resources configured in the container.  This
>> change also
>> introduces a new JVM option (-XX:ActiveProcessorCount=xx) which allows
>> the user
>> to specify how many processors the JVM should use.  We will now honor cpu
>> shares, quotas
>> in addition to cpusets for determining the number of threads that the JVM
>> will use.
>>
>
> Yes, that does sound like a useful set of changes.
>
>
>>
>> Prior to this change, I also added https://bugs.openjdk.jav
>> a.net/browse/JDK-8186315.
>> This change allows the user to specify the percentage of container memory
>> that
>> should be used by the Java Heap.  This allows the users to reserve memory
>> outside
>> of the Java heap for other classes of memory allocations (C-Heap for
>> example).
>>
>> Both of these changes have been integrated into JDK 10 and are available
>> in the
>> latest early access release of Linux x64 (http://jdk.java.net/10/).
>>
>
> How interesting! The previous version of our Java memory calculator
> allowed the heap size to be specified as a proportion of container memory,
> but we could only guess at a default proportion and users found it quite
> hard to know what value to use when they needed to increase or decrease
> heap size.
>
> The current version adopts a different approach: we try to calculate JVM
> memory consumption (apart from heap) from the JVM options and then subtract
> that value from the container memory to get the maximum heap size. This
> approach suffers from the difficulty of predicting the memory consumption
> of the JVM with any accuracy (see my recent thread entitled 'Excessive "GC"
> memory area size'). The up-side of the new approach is that the user can
> override the behaviour using standard JVM options rather than proportions.
>
>
>>
>> I will talk to the Hotspot runtime folks about your requirement
>>
>
> Thanks very much.
>
>
>> but other than these
>> options, have you considered configuring your containers to use some swap
>> space
>> in addition to memory configurations so that temporary spikes in memory
>> consumption
>> won?t cause an OOM ?
>>
>
> We talked about this but we need to bound the amount of swap space because
> our environment is a PaaS and we can't allow users to consume more than
> their fair share of system resources. If we did enable a bounded swap
> space, I think we'd hit the same issue when the RAM+swap limit was exceeded.
>
>
>> There are also ways of disabling the OOM killer in containers.
>>
>
> We actually tried that. We started the container with the OOM killer
> disabled and when the container hit OOM, we gathered diagnostics and
> re-enabled the OOM killer to terminate the container. The main issue with
> that is the container-level diagnostics (number of committed pages of RAM
> etc.) don't tell the Java programmer what JVM options need changing to
> avoid the problem in future.
>
> A more sophisticated approach along those lines would be to disable the
> OOM killer and when the container *nears* its limit somehow trigger the JVM
> to do "out of memory" processing. Then our JVMTI agent would be driven and
> produce plenty of diagnostics suitable for a Java programmer. This is a bit
> speculative though as it requires fairly deep changes to the container
> configuration as well as solving the problem of how to trigger the JVM to
> do its "out of memory" processing. Maybe a more practical solution there is
> for the JVM itself to monitor its approach to the container memory limit
> and trigger "out of memory" processing at some threshold close to the
> limit. This could be relevant to the JEP.
>
>
>> If we get a failed memory allocation, we will try to deliver a Java
>> OutOfMemory
>> exception which would at least allow you to figure out what went wrong.
>> I haven?t looked
>> into this yet but it is something worth considering.
>>
>
> Yeah, OutOfMemory exceptions provide some useful information, although we
> found it was insufficiently detailed which is why we wrote a JVMTI agent to
> dump out detailed diagnostics.
>
>
>>
>> Bob.
>>
>>
>>
>> On Dec 13, 2017, at 4:13 AM, Glyn Normington <gnormington at pivotal.io>
>> wrote:
>>
>> I wonder if someone involved in JEPS 8182070 (Container aware Java) would
>> care to comment on the additional requirement described below?
>>
>> On Mon, Nov 13, 2017 at 9:30 AM, Glyn Normington <gnormington at pivotal.io>
>> wrote:
>>
>> I would like to mention an additional requirement for JEPS 8182070 (
>> http://openjdk.java.net/jeps/8182070): avoid the JVM hitting container
>> OOM by strictly bounding the amount of (physical) memory that the JVM
>> consumes. This may be implicit in the document, but I think it should be
>> made an explicit goal.
>>
>> If a java application hits container OOM, no detailed diagnostics, such as
>> those associated with an OutOfMemoryError or a JVMTI resource exhaustion
>> event, are presented to the user, so the user finds it very difficult to
>> know how to fix the problem.
>>
>> The Cloud Foundry OSS project has done quite a bit of work on this problem
>> and provides a couple of utilities which help when running a JVM in a
>> container:
>>
>> * Java memory calculator ([1], [2]) to determine JVM memory settings,
>> * jvmkill JVMTI agent ([3]) to report detailed diagnostics on a resource
>> exhaustion event.
>>
>> Regards,
>> Glyn
>>
>> [1] https://github.com/cloudfoundry/java-buildpack-memory-calculator
>>
>> [2] Design doc: https://docs.google.com/document/d/
>> 1vlXBiwRIjwiVcbvUGYMrxx2Aw1RVAtxq3iuZ3UK2vXA/edit#heading=h.uy41ishpv9zc
>>
>> [3] https://github.com/cloudfoundry/jvmkill
>>
>>
>>
>>
>> --
>> Regards,
>> Glyn
>>
>>
>>
>
>
> --
> Regards,
> Glyn
>
>
>


-- 
Regards,
Glyn

From zgu at redhat.com  Wed Dec 13 17:18:41 2017
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 13 Dec 2017 12:18:41 -0500
Subject: Excessive "GC" memory area size [was: Re: Determining "GC" memory
 area size]
In-Reply-To: <CAA-6JZpXF3LLYrg6npEHOcZx_a6K5=C7Z6jsASgxGaHWa-Ukdg@mail.gmail.com>
References: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>
 <0cd04045-ef97-16bf-874a-6703d6222578@redhat.com>
 <CAA-6JZpAkm-Tm4wkFkpD8jVk2+eq20GFFxEj6nKwazik8dNHhQ@mail.gmail.com>
 <83f18360-5dab-7780-3f28-db5abfed19e7@redhat.com>
 <CAA-6JZpXF3LLYrg6npEHOcZx_a6K5=C7Z6jsASgxGaHWa-Ukdg@mail.gmail.com>
Message-ID: <b23e3c7f-8a23-036c-69d1-ff2be6cf2a6f@redhat.com>

Hi Glyn,

On 12/13/2017 11:38 AM, Glyn Normington wrote:
> Hi Zhengyu
> 
> Thanks again for a great suggestion. JDK 10 gave more insights such as 
> this one showing a task queue-related malloc of 8 MB:
> 
> 0x000000010d128e58] 
> _ZN20MallocArrayAllocatorI16G1TaskQueueEntryE8allocateEm10MemoryType+0x5c
> [0x000000010d12372e] 
> _ZN16G1ConcurrentMarkC2EP15G1CollectedHeapP21G1RegionToSpaceMapperS3_+0x8e4
> [0x000000010d1198af] _ZN15G1CollectedHeap10initializeEv+0x561
> [0x000000010d559029] _ZN8Universe15initialize_heapEv+0x4f
>                               (malloc=8192KB type=GC #8)
> 
> The malloc details don't seem to add up to the total, so maybe some 
> allocation sites got missed, but it's definitely better than with JDK 8.

Detail tracking does discard allocation sites with small enough 
allocation, e.g. < 1K when scale = KB. But I will be surprised if the 
disparity is significant.

Thanks,

-Zhengyu



> 
> Regards,
> Glyn
> 
> 
> On Wed, Dec 13, 2017 at 3:16 PM, Zhengyu Gu <zgu at redhat.com 
> <mailto:zgu at redhat.com>> wrote:
> 
>     Hi Glyn,
> 
>     On 12/13/2017 09:35 AM, Glyn Normington wrote:
> 
>         Thanks Zhengyu! That got me quite a bit further.
> 
>         The NMT virtual memory map showed the mmap portion of GC space
>         consisting of:
>         * the two marking bitmaps you mentioned previously, each 1/64 of
>         heap size.
>         * a mark stack of 32 MB which is 8* MarkStackSize (but which
>         could grow to 8* MarkStackSizeMax or 128 MB).
>         * three 700 KB areas, although I'm not sure what these are used
>         for or how to predict their total size.
> 
>         This leaves the malloc portion of GC space "17615KB #2312" which
>         I think was due 2312 calls to malloc. Again, not sure what these
>         are used for or how to predict their total size except that I
>         presume they include the task queues you mentioned previously.
> 
> 
>     Can you try on JDK10? it has enhancement [1] which can show what
>     memory allocation is for, on each allocation site.
> 
> 
>     [1] https://bugs.openjdk.java.net/browse/JDK-8139673
>     <https://bugs.openjdk.java.net/browse/JDK-8139673>
> 
>     Thanks,
> 
>     -Zhengyu
> 
> 
>         Outstanding questions:
>         1. Is the mmap space which consumed three 700 KB areas above
>         fixed, proportional to heap size, or what?
>         2. How many task queues are there for a given number of GC threads?
>         3. Task queues can overflow, so what is the maximum space each
>         one can occupy?
>         4. Of the malloc space not consumed by task queues, how much is
>         fixed and how much proportional to heap size, number of GC
>         threads, etc.?
> 
>         The aim is to calculate a reasonable estimate of an upper bound
>         for GC space consumption.
> 
>         Raw data for anyone who's interested:
>         https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6
>         <https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6>
> 
>         Regards,
>         Glyn
> 
>         On Wed, Dec 13, 2017 at 12:27 PM, Zhengyu Gu <zgu at redhat.com
>         <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>         <mailto:zgu at redhat.com>>> wrote:
> 
>              Hi Glyn,
> 
>              You can run NMT with detail tracking
>              (-XX:NativeMemoryTracking=detail) then use jcmd (jcmd <pid>
>              VM.native_memory detail) to find out all allocations for GC.
> 
>              For example:
> 
>              [0x00007f9fba000000 - 0x00007f9fbc000000] reserved 32768KB
>         for *GC* from
>                   [0x00007fa0130260ef] G1CMMarkStack::resize(unsigned
>         long)+0x8f
>                   [0x00007fa01302cf62]
>              G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>              G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>                   [0x00007fa01300e94b] G1CollectedHeap::initialize()+0x62b
>                   [0x00007fa013ca26af] universe_init()+0x6f
> 
>                       [0x00007f9fba000000 - 0x00007f9fbc000000]
>         committed 32768KB
>              from
>                           [0x00007fa01302610d]
>         G1CMMarkStack::resize(unsigned
>              long)+0xad
>                           [0x00007fa01302cf62]
>              G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>              G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>                           [0x00007fa01300e94b]
>         G1CollectedHeap::initialize()+0x62b
>                           [0x00007fa013ca26af] universe_init()+0x6f
> 
> 
>              [0x00007fa012ac5395] ArrayAllocator<unsigned
>              long>::allocate(unsigned long, MemoryType)+0x245
>              [0x00007fa012ac5448] unsigned long*
>              BitMap::reallocate<CHeapBitMapAllocator>(CHeapBitMapAllocator
>              const&, unsigned long*, unsigned long, unsigned long)+0x38
>              [0x00007fa012ac509f] CHeapBitMap::initialize(unsigned
>         long)+0x6f
>              [0x00007fa013093b9c]
>              G1PageBasedVirtualSpace::G1PageBasedVirtualSpace(ReservedSpace,
>              unsigned long, unsigned long)+0x13c
>                                            (malloc=129KB *type=GC* #6)
> 
>              Thanks,
> 
>              -Zhengyu
> 
> 
> 
> 
>              On 12/13/2017 04:39 AM, Glyn Normington wrote:
> 
>                  On the basis of the reply below, we have been thinking of
>                  estimating the
>                  size of the "GC" memory area as a little more than (1/32) *
>                  heapSize.
>                  However, running `java -version` with a 350m heap
>         results in
>                  "GC" memory as
>                  reported by NMT of over 17% of the heap size, so this
>         estimate
>                  is way out.
> 
>                  If the analysis below is accurate, then given the
>         number of GC
>                  threads is
>                  10 (ParallelGCThreads=8, ConcGCThreads=2), can there be
>         many more
>                  taskqueues than GC threads?
> 
>                  Or is there another explanation for the additional "GC"
>         size?
> 
>                  Thanks,
>                  Glyn
> 
>                  [1]
>         https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>
>                 
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>>
> 
>                  On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu
>         <zgu at redhat.com <mailto:zgu at redhat.com>
>                  <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>> wrote:
> 
>                      Hi Glyn,
> 
> 
>                          Can anyone here tell me how the GC memory area
>         size is
>                          determined? If
>                          there
>                          is documentation, so much the better as we'd
>         prefer not
>                          to depend on code
>                          details that might flux arbitrarily.
> 
> 
>                      GC memory is mainly data structures used by GC
>         runtime. It
>                      can be varied
>                      by collector used, size of the Java heap, the
>         number of GC
>                      threads and etc.
>                      and, of course, the application itself.
> 
>                      Some are *fixed* costs, which can be estimated.
>         E.g. two
>                      marking bitmaps
>                      used by G1, each costs 1/64 of heap size (assuming
>         default
>                      object
>                      alignment).
> 
>                      Some are *semi-fixed*, e.g. taskqueue's fixed cost
>         is about
>                      1M for each
>                      queue on 64-bits VM, but it can overflow. And the
>         number of
>                      task queues is
>                      proportional to the number of GC threads.
> 
>                      Then there are factors from application itself, 
>         such as
>                      object mutation
>                      rate, inter-generation/region references, etc.
> 
> 
>                      I don't see a single formula for estimating GC
>         memory size.
>                      If you are
>                      using G1, the biggest overhead comes from 2 bitmaps
>         (1/32 *
>                      heap size).
> 
>                      Thanks,
> 
>                      -Zhengyu
> 
> 
> 
> 
> 
> 
> 
> 
> 
>         -- 
>         Regards,
>         Glyn
> 
> 
> 
> 
> -- 
> Regards,
> Glyn

From bob.vandette at oracle.com  Wed Dec 13 17:34:03 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 13 Dec 2017 12:34:03 -0500
Subject: Additional JEPS 8182070 requirement: avoiding container OOM
In-Reply-To: <CAA-6JZoeZXRx4xBKj-fGfUmZWu=mryUp=ujU56tYsSgEoHYByA@mail.gmail.com>
References: <CAA-6JZrGWai5z57e+U7f92K3eb0VVp9xj0MwQ1Zi9ms5OKh3vw@mail.gmail.com>
 <CAA-6JZot6rBg1Eynehk9EQvQFF2cNpZFX4Bat_FE9nm0BzMAxw@mail.gmail.com>
 <4F9A9BCE-AE0A-4C2D-979E-F4D8482EC5C0@oracle.com>
 <CAA-6JZpa0LSxz_Sd=h+un=VT=nhLgK_xRt7mciiQXtKL8XUsQg@mail.gmail.com>
 <5250BF60-FE77-45C6-B650-476AB5837A2C@oracle.com>
 <CAA-6JZoeZXRx4xBKj-fGfUmZWu=mryUp=ujU56tYsSgEoHYByA@mail.gmail.com>
Message-ID: <2B711894-FF97-4B0F-8D8A-41E9E2ECFFC6@oracle.com>


> On Dec 13, 2017, at 12:00 PM, Glyn Normington <gnormington at pivotal.io> wrote:
> 
> On Wed, Dec 13, 2017 at 4:51 PM, Bob Vandette <bob.vandette at oracle.com <mailto:bob.vandette at oracle.com>> wrote:
> 
>> On Dec 13, 2017, at 11:01 AM, Glyn Normington <gnormington at pivotal.io <mailto:gnormington at pivotal.io>> wrote:
>> 
>> Hi Bob
>> 
>> Thanks very much for that information. Some comments inline. This one could be relevant to the refocussed JEP: the JVM should monitor its approach to the container memory limit and trigger "out of memory" processing at some threshold close to the limit.
> 
> Memory allocations in hotspot are difficult to track since there are many different allocators 
> and we don?t control them all.  Thread stacks get dynamically allocated upon use, the C++ runtime allocates 
> memory for native code and third party JNI library could be calling malloc.  These are all in addition
> to the allocators we do control - Java Heap and internal Memory Arenas for runtime metadata.
> 
> One possible solution is to at least attempt threshold checking during allocations we
> do control and to do OOM processing at that time.  This wouldn?t catch every case but could
> increase the robustness of the Java runtime.  With the change I introduced in JDK-8146155,
> we now at least have a way of finding out how much free memory is available in the container.
> 
> Another solution you might like to mull over is for the JVM to poll the memory cgroup value memory.usage_in_bytes (assuming the memory cgroup is mounted read-only inside the container) and trigger "out of memory" on some threshold.

That is exactly what I was referring to in "we now at least have a way of finding out how much free memory is available in the container."

I added several cgroup access functions inside hotspot (http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp>)
including these two.

/* memory_usage_in_bytes <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l456>
 * <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l457>
 * Return the amount of used memory for this process. <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l458>
 * <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l459>
 * return: <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l460>
 *    memory usage in bytes or <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l461>
 *    -1 for unlimited <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l462>
 *    OSCONTAINER_ERROR for not supported <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l463>
 */ <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l464>
jlong OSContainer::memory_usage_in_bytes() { <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l465>
  GET_CONTAINER_INFO(jlong, memory, "/memory.usage_in_bytes", <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l466>
                     "Memory Usage is: " JLONG_FORMAT, JLONG_FORMAT, memusage); <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l467>
  return memusage; <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l468>
} <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l469>
 <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l470>
/* memory_max_usage_in_bytes <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l471>
 * <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l472>
 * Return the maximum amount of used memory for this process. <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l473>
 * <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l474>
 * return: <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l475>
 *    max memory usage in bytes or <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l476>
 *    OSCONTAINER_ERROR for not supported <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l477>
 */ <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l478>
jlong OSContainer::memory_max_usage_in_bytes() { <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l479>
  GET_CONTAINER_INFO(jlong, memory, "/memory.max_usage_in_bytes", <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l480>
                     "Maximum Memory Usage is: " JLONG_FORMAT, JLONG_FORMAT, memmaxusage); <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l481>
  return memmaxusage; <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l482>
}

Bob.

>  
> 
> Bob.
> 
>> 
>> Regards,
>> Glyn
>> 
>> On Wed, Dec 13, 2017 at 2:58 PM, Bob Vandette <bob.vandette at oracle.com <mailto:bob.vandette at oracle.com>> wrote:
>> Hi Glyn,
>> 
>> The JEP you mention is going to be updated in a week or so to refocus it?s goals
>> on monitoring of the JVM running in containers.  This is due to the fact that I was
>> able to split out the work of dynamically configuring the VM based on container
>> settings and integrate this work into JDK 10.  This work was integrated under jira issue
>> https://bugs.openjdk.java.net/browse/JDK-8146115 <https://bugs.openjdk.java.net/browse/JDK-8146115>.
>> 
>> Although this change does not completely address your requirement, it should help.
>> This change causes the JVM to correctly configure the number of threads and memory
>> allocations based on the resources configured in the container.  This change also
>> introduces a new JVM option (-XX:ActiveProcessorCount=xx) which allows the user
>> to specify how many processors the JVM should use.  We will now honor cpu shares, quotas
>> in addition to cpusets for determining the number of threads that the JVM will use.
>> 
>> Yes, that does sound like a useful set of changes.
>>  
>> 
>> Prior to this change, I also added https://bugs.openjdk.java.net/browse/JDK-8186315 <https://bugs.openjdk.java.net/browse/JDK-8186315>.
>> This change allows the user to specify the percentage of container memory that
>> should be used by the Java Heap.  This allows the users to reserve memory outside
>> of the Java heap for other classes of memory allocations (C-Heap for example).
>> 
>> Both of these changes have been integrated into JDK 10 and are available in the
>> latest early access release of Linux x64 (http://jdk.java.net/10/ <http://jdk.java.net/10/>).
>> 
>> How interesting! The previous version of our Java memory calculator allowed the heap size to be specified as a proportion of container memory, but we could only guess at a default proportion and users found it quite hard to know what value to use when they needed to increase or decrease heap size.
>> 
>> The current version adopts a different approach: we try to calculate JVM memory consumption (apart from heap) from the JVM options and then subtract that value from the container memory to get the maximum heap size. This approach suffers from the difficulty of predicting the memory consumption of the JVM with any accuracy (see my recent thread entitled 'Excessive "GC" memory area size'). The up-side of the new approach is that the user can override the behaviour using standard JVM options rather than proportions.
>>  
>> 
>> I will talk to the Hotspot runtime folks about your requirement
>> 
>> Thanks very much.
>>  
>> but other than these 
>> options, have you considered configuring your containers to use some swap space
>> in addition to memory configurations so that temporary spikes in memory consumption 
>> won?t cause an OOM ?
>> 
>> We talked about this but we need to bound the amount of swap space because our environment is a PaaS and we can't allow users to consume more than their fair share of system resources. If we did enable a bounded swap space, I think we'd hit the same issue when the RAM+swap limit was exceeded.
>>  
>> There are also ways of disabling the OOM killer in containers.
>> 
>> We actually tried that. We started the container with the OOM killer disabled and when the container hit OOM, we gathered diagnostics and re-enabled the OOM killer to terminate the container. The main issue with that is the container-level diagnostics (number of committed pages of RAM etc.) don't tell the Java programmer what JVM options need changing to avoid the problem in future.
>> 
>> A more sophisticated approach along those lines would be to disable the OOM killer and when the container *nears* its limit somehow trigger the JVM to do "out of memory" processing. Then our JVMTI agent would be driven and produce plenty of diagnostics suitable for a Java programmer. This is a bit speculative though as it requires fairly deep changes to the container configuration as well as solving the problem of how to trigger the JVM to do its "out of memory" processing. Maybe a more practical solution there is for the JVM itself to monitor its approach to the container memory limit and trigger "out of memory" processing at some threshold close to the limit. This could be relevant to the JEP.
>>  
>> If we get a failed memory allocation, we will try to deliver a Java OutOfMemory
>> exception which would at least allow you to figure out what went wrong.  I haven?t looked 
>> into this yet but it is something worth considering.
>> 
>> Yeah, OutOfMemory exceptions provide some useful information, although we found it was insufficiently detailed which is why we wrote a JVMTI agent to dump out detailed diagnostics.
>>  
>> 
>> Bob.
>> 
>> 
>> 
>>> On Dec 13, 2017, at 4:13 AM, Glyn Normington <gnormington at pivotal.io <mailto:gnormington at pivotal.io>> wrote:
>>> 
>>> I wonder if someone involved in JEPS 8182070 (Container aware Java) would
>>> care to comment on the additional requirement described below?
>>> 
>>> On Mon, Nov 13, 2017 at 9:30 AM, Glyn Normington <gnormington at pivotal.io <mailto:gnormington at pivotal.io>>
>>> wrote:
>>> 
>>>> I would like to mention an additional requirement for JEPS 8182070 (
>>>> http://openjdk.java.net/jeps/8182070 <http://openjdk.java.net/jeps/8182070>): avoid the JVM hitting container
>>>> OOM by strictly bounding the amount of (physical) memory that the JVM
>>>> consumes. This may be implicit in the document, but I think it should be
>>>> made an explicit goal.
>>>> 
>>>> If a java application hits container OOM, no detailed diagnostics, such as
>>>> those associated with an OutOfMemoryError or a JVMTI resource exhaustion
>>>> event, are presented to the user, so the user finds it very difficult to
>>>> know how to fix the problem.
>>>> 
>>>> The Cloud Foundry OSS project has done quite a bit of work on this problem
>>>> and provides a couple of utilities which help when running a JVM in a
>>>> container:
>>>> 
>>>> * Java memory calculator ([1], [2]) to determine JVM memory settings,
>>>> * jvmkill JVMTI agent ([3]) to report detailed diagnostics on a resource
>>>> exhaustion event.
>>>> 
>>>> Regards,
>>>> Glyn
>>>> 
>>>> [1] https://github.com/cloudfoundry/java-buildpack-memory-calculator <https://github.com/cloudfoundry/java-buildpack-memory-calculator>
>>>> 
>>>> [2] Design doc: https://docs.google.com/document/d/ <https://docs.google.com/document/d/>
>>>> 1vlXBiwRIjwiVcbvUGYMrxx2Aw1RVAtxq3iuZ3UK2vXA/edit#heading=h.uy41ishpv9zc
>>>> 
>>>> [3] https://github.com/cloudfoundry/jvmkill <https://github.com/cloudfoundry/jvmkill>
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Regards,
>>> Glyn
>> 
>> 
>> 
>> 
>> -- 
>> Regards,
>> Glyn
> 
> 
> 
> 
> -- 
> Regards,
> Glyn


From irogers at google.com  Thu Dec  7 16:58:49 2017
From: irogers at google.com (Ian Rogers)
Date: Thu, 7 Dec 2017 08:58:49 -0800
Subject: JNI ReleasePrimitiveArrayCritical with mode JNI_COMMIT shouldn't
 end critical region
In-Reply-To: <788e54e9-7019-eb59-e9d6-bf0ed538e9d9@oracle.com>
References: <CAP-5=fUaZuihHT1yY+QM-SXcqAQMaxTAb8SL3x=byG_5KRuRng@mail.gmail.com>
 <3d676bb0-f7d3-ec40-cfb8-6a905f79a434@oracle.com>
 <CAP-5=fXv4inQiVpk5Ey1Qhy_N+hSmGuciXcZN_k-1U0+pDKqAA@mail.gmail.com>
 <b72ab75b-84fd-2ec2-3b62-6e720052231e@oracle.com>
 <CAP-5=fWZacKq7cjXfJ_+TcOsH-FAA9eKGzZ-L62kMHOmcqUyjg@mail.gmail.com>
 <788e54e9-7019-eb59-e9d6-bf0ed538e9d9@oracle.com>
Message-ID: <CAP-5=fUH4cyO3ZTQOTkG7CZo65pz0u5xJOZmsYTMbdFj5FTfFg@mail.gmail.com>

On Wed, Dec 6, 2017 at 9:00 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 7/12/2017 2:55 PM, Ian Rogers wrote:
>
>> Thanks, fwiw Jikes RVM agrees that all critical releases end the critical
>> region:
>> https://github.com/JikesRVM/JikesRVM/blob/master/rvm/src/org
>> /jikesrvm/jni/JNIFunctions.java#L5936
>>
>> As does Cacao:
>> http://mips.complang.tuwien.ac.at/hg/cacao/file/2b4c9b6c245d
>> /src/native/jni.cpp#l3208
>>
>> Kaffe (with a non-moving GC) treats the release in the same way as
>> Release<Primitive>ArrayElements:
>> https://github.com/kaffe/kaffe/blob/master/kaffe/kaffevm/
>> jni/jni-arrays.c#L404
>> which is the same as how it is handled on Android.
>>
>> HotSpot has managed to put a foot in both camps, ending the critical
>> always (a la Jikes RVM and Cacao) but honoring commit behavior (and
>> leaking) when in -Xcheck:jni.
>>
>
> So ... I should file a bug for the leak in the checked version and apply
> your suggested patch to always pass mode 0?
>
> Thanks,
> David
>

Sounds good to me. I would have filed the bug rather than starting this
thread if I had a user/bug account :-)

Thanks,
Ian


> Thanks,
>> Ian
>>
>>
>> On Wed, Dec 6, 2017 at 5:25 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Ian,
>>
>>     On 7/12/2017 4:48 AM, Ian Rogers wrote:
>>
>>         Thanks David, I think we may have differing opinions on clarity
>>         :-) In the case of -Xcheck:jni and with HotSpot a copy is always
>>         made, and so
>>
>>
>>     Ah I see. I was considering only the "real" functionality.
>>
>>     The fact the checked version of getPrimitiveArrayCritical creates a
>>     copy seems to be treated as an internal detail as it does not AFAICS
>>     report that a copy was in fact made - the passed in isCopy pointer
>>     will be set false by the real getPrimitiveArrayCritical.
>>
>>         perhaps the attached patch causes the implementation to match
>>         the spec.
>>
>>
>>     The whole logic surrounding the management of the copy seems
>>     somewhat suspect to me. As you note with your patch
>>     check_wrapped_array_release honours the mode, which in the checked
>>     case allows, AFAICS, the internally made copy to "leak". So ignoring
>>     the passed in mode and always passing 0 to
>>     check_wrapped_array_release seems more correct.
>>
>>         Given that commit doesn't free a copy, is it intended behavior
>>         that in HotSpot it ends a critical region? ie In a VM that
>>         allowed copies you could imagine, Get, Commit, Release and as
>>         spec-ed the critical region ends at the commit if not a copy,
>>         and at the release if it is. Perhaps the simplest thing is to
>>         remove the notion of commit here.
>>
>>
>>     I honestly do not know what this API is really trying to achieve in
>>     that regard. I don't know the intended usage of "commit" mode. Why
>>     would you not free the copied buffer? The spec unhelpfully only
>> states:
>>
>>     "The other options give the programmer more control over memory
>>     management and should be used with extreme care."
>>
>>     And if you don't free it what can you do with it? For
>>     Get*ArrayElements it clearly states
>>
>>     "The result is valid until the corresponding
>>     Release<PrimitiveType>ArrayElements() function is called."
>>
>>     so once any Release* is done, regardless of mode, it would seem the
>>     array (copy or not) is no longer valid and should not be accessed
>>     again. So I don't see any expectation that you can call Release*
>>     multiple times and so in terms of the critical variants I expect the
>>     critical section to end when Release is called - regardless of mode.
>>
>>     David
>>
>>         Thanks,
>>         Ian
>>
>>
>>         On Tue, Dec 5, 2017 at 4:37 PM, David Holmes
>>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>         <mailto:david.holmes at oracle.com
>>
>>         <mailto:david.holmes at oracle.com>>> wrote:
>>
>>              Hi Ian,
>>
>>              On 6/12/2017 9:15 AM, Ian Rogers wrote:
>>
>>                  From:
>>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimiti
>> veArrayCritical
>>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimiti
>> veArrayCritical>
>>                         <https://docs.oracle.com/javas
>> e/8/docs/technotes/guides/jni/spec/functions.html#GetPrimiti
>> veArrayCritical_ReleasePrimitiveArrayCritical
>>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#GetPrimitiveArrayCritical_ReleasePrimiti
>> veArrayCritical>>
>>
>>
>>              You need to see the updated spec:
>>
>>         https://docs.oracle.com/javase/9/docs/specs/jni/functions.
>> html#getprimitivearraycritical-releaseprimitivearraycritical
>>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.
>> html#getprimitivearraycritical-releaseprimitivearraycritical>
>>                     <https://docs.oracle.com/javas
>> e/9/docs/specs/jni/functions.html#getprimitivearraycritical
>> -releaseprimitivearraycritical
>>         <https://docs.oracle.com/javase/9/docs/specs/jni/functions.
>> html#getprimitivearraycritical-releaseprimitivearraycritical>>
>>
>>              That spec makes it clear:
>>
>>              "mode: the release mode (see Primitive Array Release Modes):
>> 0,
>>              JNI_COMMIT or JNI_ABORT. Ignored if carray was a not copy."
>>
>>              In hotspot getCriticalArrayPrimitive never returns a copy
>>         so the
>>              mode is always ignored, as per the existing comment.
>>
>>              David
>>              -----
>>
>>
>>                  "The semantics of these two functions are very similar
>>         to the
>>                  existing
>>                  Get/Release<primitivetype>ArrayElements functions. "
>>
>>         https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#Release_PrimitiveType_ArrayElements_routines
>>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#Release_PrimitiveType_ArrayElements_routines>
>>                         <https://docs.oracle.com/javas
>> e/8/docs/technotes/guides/jni/spec/functions.html#Release_
>> PrimitiveType_ArrayElements_routines
>>         <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/
>> spec/functions.html#Release_PrimitiveType_ArrayElements_routines>>
>>
>>                  "JNI_COMMIT copy back the content but do not free the
>>         elems buffer"
>>
>>                  Consider the pattern of:
>>                  GetPrimitiveArrayCritical(...)
>>                  ReleasePrimitiveArrayCritical(..., JNI_COMMIT)
>>                  ReleasePrimitiveArrayCritical(..., 0)
>>
>>                  where the first release is to just achieve a copy back.
>>         For example,
>>                  jniCheck.cpp will copy back but not free a copy in the
>>         case of
>>                  JNI_COMMIT
>>                  for a critical. The implementation of
>>                  ReleasePrimitiveArrayCritical ignores
>>                  all arguments and so it ends the critical region even
>>         in the
>>                  event of a
>>                  commit.
>>
>>                  The attached patch makes ReleasePrimitiveArrayCritical
>>         consider
>>                  the mode
>>                  argument when releasing the GCLocker.
>>
>>                  Thanks,
>>                  Ian
>>
>>
>>
>>

From gnormington at pivotal.io  Thu Dec 14 09:12:03 2017
From: gnormington at pivotal.io (Glyn Normington)
Date: Thu, 14 Dec 2017 09:12:03 +0000
Subject: Additional JEPS 8182070 requirement: avoiding container OOM
In-Reply-To: <2B711894-FF97-4B0F-8D8A-41E9E2ECFFC6@oracle.com>
References: <CAA-6JZrGWai5z57e+U7f92K3eb0VVp9xj0MwQ1Zi9ms5OKh3vw@mail.gmail.com>
 <CAA-6JZot6rBg1Eynehk9EQvQFF2cNpZFX4Bat_FE9nm0BzMAxw@mail.gmail.com>
 <4F9A9BCE-AE0A-4C2D-979E-F4D8482EC5C0@oracle.com>
 <CAA-6JZpa0LSxz_Sd=h+un=VT=nhLgK_xRt7mciiQXtKL8XUsQg@mail.gmail.com>
 <5250BF60-FE77-45C6-B650-476AB5837A2C@oracle.com>
 <CAA-6JZoeZXRx4xBKj-fGfUmZWu=mryUp=ujU56tYsSgEoHYByA@mail.gmail.com>
 <2B711894-FF97-4B0F-8D8A-41E9E2ECFFC6@oracle.com>
Message-ID: <CAA-6JZohTzW9BkOSiadVqReDWy4zm+bh4P1gw5nweCk8DkbFfQ@mail.gmail.com>

On Wed, Dec 13, 2017 at 5:34 PM, Bob Vandette <bob.vandette at oracle.com>
wrote:

>
> On Dec 13, 2017, at 12:00 PM, Glyn Normington <gnormington at pivotal.io>
> wrote:
>
> On Wed, Dec 13, 2017 at 4:51 PM, Bob Vandette <bob.vandette at oracle.com>
> wrote:
>
>>
>> On Dec 13, 2017, at 11:01 AM, Glyn Normington <gnormington at pivotal.io>
>> wrote:
>>
>> Hi Bob
>>
>> Thanks very much for that information. Some comments inline. This one
>> could be relevant to the refocussed JEP: the JVM should monitor its
>> approach to the container memory limit and trigger "out of memory"
>> processing at some threshold close to the limit.
>>
>>
>> Memory allocations in hotspot are difficult to track since there are many
>> different allocators
>> and we don?t control them all.  Thread stacks get dynamically allocated
>> upon use, the C++ runtime allocates
>> memory for native code and third party JNI library could be calling
>> malloc.  These are all in addition
>> to the allocators we do control - Java Heap and internal Memory Arenas
>> for runtime metadata.
>>
>> One possible solution is to at least attempt threshold checking during
>> allocations we
>> do control and to do OOM processing at that time.  This wouldn?t catch
>> every case but could
>> increase the robustness of the Java runtime.  With the change I
>> introduced in JDK-8146155,
>> we now at least have a way of finding out how much free memory is
>> available in the container.
>>
>
> Another solution you might like to mull over is for the JVM to poll the
> memory cgroup value memory.usage_in_bytes (assuming the memory cgroup is
> mounted read-only inside the container) and trigger "out of memory" on some
> threshold.
>
>
> That is exactly what I was referring to in "we now at least have a way of
> finding out how much free memory is available in the container."
>

Ah, thanks for clarifying. That's great.


>
> I added several cgroup access functions inside hotspot (
> http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/
> hotspot/os/linux/osContainer_linux.cpp)
> including these two.
>
> /* memory_usage_in_bytes <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l456> * <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l457> * Return the amount of used memory for this process. <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l458> * <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l459> * return: <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l460> *    memory usage in bytes or <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l461> *    -1 for unlimited <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l462> *    OSCONTAINER_ERROR for not supported <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l463> */ <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l464>jlong OSContainer::memory_usage_in_bytes() { <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l465>  GET_CONTAINER_INFO(jlong, memory, "/memory.usage_in_bytes", <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l466>                     "Memory Usage is: " JLONG_FORMAT, JLONG_FORMAT, memusage); <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l467>  return memusage; <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l468>} <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l469> <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l470>/* memory_max_usage_in_bytes <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l471> * <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l472> * Return the maximum amount of used memory for this process. <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l473> * <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l474> * return: <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l475> *    max memory usage in bytes or <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l476> *    OSCONTAINER_ERROR for not supported <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l477> */ <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l478>jlong OSContainer::memory_max_usage_in_bytes() { <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l479>  GET_CONTAINER_INFO(jlong, memory, "/memory.max_usage_in_bytes", <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l480>                     "Maximum Memory Usage is: " JLONG_FORMAT, JLONG_FORMAT, memmaxusage); <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l481>  return memmaxusage; <http://hg.openjdk.java.net/jdk/jdk/file/a559b7cd1dea/src/hotspot/os/linux/osContainer_linux.cpp#l482>}
>
>
> Bob.
>
>
>
>>
>> Bob.
>>
>>
>> Regards,
>> Glyn
>>
>> On Wed, Dec 13, 2017 at 2:58 PM, Bob Vandette <bob.vandette at oracle.com>
>> wrote:
>>
>>> Hi Glyn,
>>>
>>> The JEP you mention is going to be updated in a week or so to refocus
>>> it?s goals
>>> on monitoring of the JVM running in containers.  This is due to the fact
>>> that I was
>>> able to split out the work of dynamically configuring the VM based on
>>> container
>>> settings and integrate this work into JDK 10.  This work was integrated
>>> under jira issue
>>> https://bugs.openjdk.java.net/browse/JDK-8146115.
>>>
>>> Although this change does not completely address your requirement, it
>>> should help.
>>> This change causes the JVM to correctly configure the number of threads
>>> and memory
>>> allocations based on the resources configured in the container.  This
>>> change also
>>> introduces a new JVM option (-XX:ActiveProcessorCount=xx) which allows
>>> the user
>>> to specify how many processors the JVM should use.  We will now honor
>>> cpu shares, quotas
>>> in addition to cpusets for determining the number of threads that the
>>> JVM will use.
>>>
>>
>> Yes, that does sound like a useful set of changes.
>>
>>
>>>
>>> Prior to this change, I also added https://bugs.openjdk.jav
>>> a.net/browse/JDK-8186315.
>>> This change allows the user to specify the percentage of container
>>> memory that
>>> should be used by the Java Heap.  This allows the users to reserve
>>> memory outside
>>> of the Java heap for other classes of memory allocations (C-Heap for
>>> example).
>>>
>>> Both of these changes have been integrated into JDK 10 and are available
>>> in the
>>> latest early access release of Linux x64 (http://jdk.java.net/10/).
>>>
>>
>> How interesting! The previous version of our Java memory calculator
>> allowed the heap size to be specified as a proportion of container memory,
>> but we could only guess at a default proportion and users found it quite
>> hard to know what value to use when they needed to increase or decrease
>> heap size.
>>
>> The current version adopts a different approach: we try to calculate JVM
>> memory consumption (apart from heap) from the JVM options and then subtract
>> that value from the container memory to get the maximum heap size. This
>> approach suffers from the difficulty of predicting the memory consumption
>> of the JVM with any accuracy (see my recent thread entitled 'Excessive "GC"
>> memory area size'). The up-side of the new approach is that the user can
>> override the behaviour using standard JVM options rather than proportions.
>>
>>
>>>
>>> I will talk to the Hotspot runtime folks about your requirement
>>>
>>
>> Thanks very much.
>>
>>
>>> but other than these
>>> options, have you considered configuring your containers to use some
>>> swap space
>>> in addition to memory configurations so that temporary spikes in memory
>>> consumption
>>> won?t cause an OOM ?
>>>
>>
>> We talked about this but we need to bound the amount of swap space
>> because our environment is a PaaS and we can't allow users to consume more
>> than their fair share of system resources. If we did enable a bounded swap
>> space, I think we'd hit the same issue when the RAM+swap limit was exceeded.
>>
>>
>>> There are also ways of disabling the OOM killer in containers.
>>>
>>
>> We actually tried that. We started the container with the OOM killer
>> disabled and when the container hit OOM, we gathered diagnostics and
>> re-enabled the OOM killer to terminate the container. The main issue with
>> that is the container-level diagnostics (number of committed pages of RAM
>> etc.) don't tell the Java programmer what JVM options need changing to
>> avoid the problem in future.
>>
>> A more sophisticated approach along those lines would be to disable the
>> OOM killer and when the container *nears* its limit somehow trigger the JVM
>> to do "out of memory" processing. Then our JVMTI agent would be driven and
>> produce plenty of diagnostics suitable for a Java programmer. This is a bit
>> speculative though as it requires fairly deep changes to the container
>> configuration as well as solving the problem of how to trigger the JVM to
>> do its "out of memory" processing. Maybe a more practical solution there is
>> for the JVM itself to monitor its approach to the container memory limit
>> and trigger "out of memory" processing at some threshold close to the
>> limit. This could be relevant to the JEP.
>>
>>
>>> If we get a failed memory allocation, we will try to deliver a Java
>>> OutOfMemory
>>> exception which would at least allow you to figure out what went wrong.
>>> I haven?t looked
>>> into this yet but it is something worth considering.
>>>
>>
>> Yeah, OutOfMemory exceptions provide some useful information, although we
>> found it was insufficiently detailed which is why we wrote a JVMTI agent to
>> dump out detailed diagnostics.
>>
>>
>>>
>>> Bob.
>>>
>>>
>>>
>>> On Dec 13, 2017, at 4:13 AM, Glyn Normington <gnormington at pivotal.io>
>>> wrote:
>>>
>>> I wonder if someone involved in JEPS 8182070 (Container aware Java) would
>>> care to comment on the additional requirement described below?
>>>
>>> On Mon, Nov 13, 2017 at 9:30 AM, Glyn Normington <gnormington at pivotal.io
>>> >
>>> wrote:
>>>
>>> I would like to mention an additional requirement for JEPS 8182070 (
>>> http://openjdk.java.net/jeps/8182070): avoid the JVM hitting container
>>> OOM by strictly bounding the amount of (physical) memory that the JVM
>>> consumes. This may be implicit in the document, but I think it should be
>>> made an explicit goal.
>>>
>>> If a java application hits container OOM, no detailed diagnostics, such
>>> as
>>> those associated with an OutOfMemoryError or a JVMTI resource exhaustion
>>> event, are presented to the user, so the user finds it very difficult to
>>> know how to fix the problem.
>>>
>>> The Cloud Foundry OSS project has done quite a bit of work on this
>>> problem
>>> and provides a couple of utilities which help when running a JVM in a
>>> container:
>>>
>>> * Java memory calculator ([1], [2]) to determine JVM memory settings,
>>> * jvmkill JVMTI agent ([3]) to report detailed diagnostics on a resource
>>> exhaustion event.
>>>
>>> Regards,
>>> Glyn
>>>
>>> [1] https://github.com/cloudfoundry/java-buildpack-memory-calculator
>>>
>>> [2] Design doc: https://docs.google.com/document/d/
>>> 1vlXBiwRIjwiVcbvUGYMrxx2Aw1RVAtxq3iuZ3UK2vXA/edit#heading=h.uy41ishpv9zc
>>>
>>> [3] https://github.com/cloudfoundry/jvmkill
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Glyn
>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Glyn
>>
>>
>>
>
>
> --
> Regards,
> Glyn
>
>
>


-- 
Regards,
Glyn

From gnormington at pivotal.io  Thu Dec 14 11:19:02 2017
From: gnormington at pivotal.io (Glyn Normington)
Date: Thu, 14 Dec 2017 11:19:02 +0000
Subject: Excessive "GC" memory area size [was: Re: Determining "GC" memory
 area size]
In-Reply-To: <b23e3c7f-8a23-036c-69d1-ff2be6cf2a6f@redhat.com>
References: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>
 <0cd04045-ef97-16bf-874a-6703d6222578@redhat.com>
 <CAA-6JZpAkm-Tm4wkFkpD8jVk2+eq20GFFxEj6nKwazik8dNHhQ@mail.gmail.com>
 <83f18360-5dab-7780-3f28-db5abfed19e7@redhat.com>
 <CAA-6JZpXF3LLYrg6npEHOcZx_a6K5=C7Z6jsASgxGaHWa-Ukdg@mail.gmail.com>
 <b23e3c7f-8a23-036c-69d1-ff2be6cf2a6f@redhat.com>
Message-ID: <CAA-6JZou9MBU2buQgrUK44cBV7dAn6bGvjjhihUkL-kYaJaV=Q@mail.gmail.com>

On Wed, Dec 13, 2017 at 5:18 PM, Zhengyu Gu <zgu at redhat.com> wrote:

> Hi Glyn,
>
> On 12/13/2017 11:38 AM, Glyn Normington wrote:
>
>> Hi Zhengyu
>>
>> Thanks again for a great suggestion. JDK 10 gave more insights such as
>> this one showing a task queue-related malloc of 8 MB:
>>
>> 0x000000010d128e58] _ZN20MallocArrayAllocatorI16G1
>> TaskQueueEntryE8allocateEm10MemoryType+0x5c
>> [0x000000010d12372e] _ZN16G1ConcurrentMarkC2EP15G1C
>> ollectedHeapP21G1RegionToSpaceMapperS3_+0x8e4
>> [0x000000010d1198af] _ZN15G1CollectedHeap10initializeEv+0x561
>> [0x000000010d559029] _ZN8Universe15initialize_heapEv+0x4f
>>                               (malloc=8192KB type=GC #8)
>>
>> The malloc details don't seem to add up to the total, so maybe some
>> allocation sites got missed, but it's definitely better than with JDK 8.
>>
>
> Detail tracking does discard allocation sites with small enough
> allocation, e.g. < 1K when scale = KB. But I will be surprised if the
> disparity is significant.
>

You're right. The malloc details add up to 17524 KB which is almost equal
to the reported total of 17544 KB.

There was another large malloc, which I guess might also be task
queue-related:

[0x000000010d11dbc4]
_ZN20MallocArrayAllocatorI8StarTaskE8allocateEm10MemoryType+0x5c
[0x000000010d119124] _ZN15G1CollectedHeapC2EP17G1CollectorPolicy+0x82c
[0x000000010d11274a]
_ZN11GCArguments23create_heap_with_policyI15G1CollectedHeap17G1CollectorPolicyEEP13CollectedHeapv+0x44
[0x000000010d559019] _ZN8Universe15initialize_heapEv+0x3f
                             (malloc=8192KB type=GC #8)



>
> Thanks,
>
> -Zhengyu
>
>
>
>
>> Regards,
>> Glyn
>>
>>
>> On Wed, Dec 13, 2017 at 3:16 PM, Zhengyu Gu <zgu at redhat.com <mailto:
>> zgu at redhat.com>> wrote:
>>
>>     Hi Glyn,
>>
>>     On 12/13/2017 09:35 AM, Glyn Normington wrote:
>>
>>         Thanks Zhengyu! That got me quite a bit further.
>>
>>         The NMT virtual memory map showed the mmap portion of GC space
>>         consisting of:
>>         * the two marking bitmaps you mentioned previously, each 1/64 of
>>         heap size.
>>         * a mark stack of 32 MB which is 8* MarkStackSize (but which
>>         could grow to 8* MarkStackSizeMax or 128 MB).
>>         * three 700 KB areas, although I'm not sure what these are used
>>         for or how to predict their total size.
>>
>>         This leaves the malloc portion of GC space "17615KB #2312" which
>>         I think was due 2312 calls to malloc. Again, not sure what these
>>         are used for or how to predict their total size except that I
>>         presume they include the task queues you mentioned previously.
>>
>>
>>     Can you try on JDK10? it has enhancement [1] which can show what
>>     memory allocation is for, on each allocation site.
>>
>>
>>     [1] https://bugs.openjdk.java.net/browse/JDK-8139673
>>     <https://bugs.openjdk.java.net/browse/JDK-8139673>
>>
>>     Thanks,
>>
>>     -Zhengyu
>>
>>
>>         Outstanding questions:
>>         1. Is the mmap space which consumed three 700 KB areas above
>>         fixed, proportional to heap size, or what?
>>         2. How many task queues are there for a given number of GC
>> threads?
>>         3. Task queues can overflow, so what is the maximum space each
>>         one can occupy?
>>         4. Of the malloc space not consumed by task queues, how much is
>>         fixed and how much proportional to heap size, number of GC
>>         threads, etc.?
>>
>>         The aim is to calculate a reasonable estimate of an upper bound
>>         for GC space consumption.
>>
>>         Raw data for anyone who's interested:
>>         https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6
>>         <https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6>
>>
>>         Regards,
>>         Glyn
>>
>>         On Wed, Dec 13, 2017 at 12:27 PM, Zhengyu Gu <zgu at redhat.com
>>         <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>>
>>         <mailto:zgu at redhat.com>>> wrote:
>>
>>              Hi Glyn,
>>
>>              You can run NMT with detail tracking
>>              (-XX:NativeMemoryTracking=detail) then use jcmd (jcmd <pid>
>>              VM.native_memory detail) to find out all allocations for GC.
>>
>>              For example:
>>
>>              [0x00007f9fba000000 - 0x00007f9fbc000000] reserved 32768KB
>>         for *GC* from
>>                   [0x00007fa0130260ef] G1CMMarkStack::resize(unsigned
>>         long)+0x8f
>>                   [0x00007fa01302cf62]
>>              G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>>              G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>>                   [0x00007fa01300e94b] G1CollectedHeap::initialize()+
>> 0x62b
>>                   [0x00007fa013ca26af] universe_init()+0x6f
>>
>>                       [0x00007f9fba000000 - 0x00007f9fbc000000]
>>         committed 32768KB
>>              from
>>                           [0x00007fa01302610d]
>>         G1CMMarkStack::resize(unsigned
>>              long)+0xad
>>                           [0x00007fa01302cf62]
>>              G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>>              G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>>                           [0x00007fa01300e94b]
>>         G1CollectedHeap::initialize()+0x62b
>>                           [0x00007fa013ca26af] universe_init()+0x6f
>>
>>
>>              [0x00007fa012ac5395] ArrayAllocator<unsigned
>>              long>::allocate(unsigned long, MemoryType)+0x245
>>              [0x00007fa012ac5448] unsigned long*
>>              BitMap::reallocate<CHeapBitMapAllocator>(CHeapBitMapAllocat
>> or
>>              const&, unsigned long*, unsigned long, unsigned long)+0x38
>>              [0x00007fa012ac509f] CHeapBitMap::initialize(unsigned
>>         long)+0x6f
>>              [0x00007fa013093b9c]
>>              G1PageBasedVirtualSpace::G1PageBasedVirtualSpace(ReservedSp
>> ace,
>>              unsigned long, unsigned long)+0x13c
>>                                            (malloc=129KB *type=GC* #6)
>>
>>              Thanks,
>>
>>              -Zhengyu
>>
>>
>>
>>
>>              On 12/13/2017 04:39 AM, Glyn Normington wrote:
>>
>>                  On the basis of the reply below, we have been thinking of
>>                  estimating the
>>                  size of the "GC" memory area as a little more than
>> (1/32) *
>>                  heapSize.
>>                  However, running `java -version` with a 350m heap
>>         results in
>>                  "GC" memory as
>>                  reported by NMT of over 17% of the heap size, so this
>>         estimate
>>                  is way out.
>>
>>                  If the analysis below is accurate, then given the
>>         number of GC
>>                  threads is
>>                  10 (ParallelGCThreads=8, ConcGCThreads=2), can there be
>>         many more
>>                  taskqueues than GC threads?
>>
>>                  Or is there another explanation for the additional "GC"
>>         size?
>>
>>                  Thanks,
>>                  Glyn
>>
>>                  [1]
>>         https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>
>>                         <https://gist.github.com/glyn/
>> f10b7dea77994ad0f5589a416fbc77fe
>>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>>
>>
>>                  On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu
>>         <zgu at redhat.com <mailto:zgu at redhat.com>
>>                  <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>> wrote:
>>
>>                      Hi Glyn,
>>
>>
>>                          Can anyone here tell me how the GC memory area
>>         size is
>>                          determined? If
>>                          there
>>                          is documentation, so much the better as we'd
>>         prefer not
>>                          to depend on code
>>                          details that might flux arbitrarily.
>>
>>
>>                      GC memory is mainly data structures used by GC
>>         runtime. It
>>                      can be varied
>>                      by collector used, size of the Java heap, the
>>         number of GC
>>                      threads and etc.
>>                      and, of course, the application itself.
>>
>>                      Some are *fixed* costs, which can be estimated.
>>         E.g. two
>>                      marking bitmaps
>>                      used by G1, each costs 1/64 of heap size (assuming
>>         default
>>                      object
>>                      alignment).
>>
>>                      Some are *semi-fixed*, e.g. taskqueue's fixed cost
>>         is about
>>                      1M for each
>>                      queue on 64-bits VM, but it can overflow. And the
>>         number of
>>                      task queues is
>>                      proportional to the number of GC threads.
>>
>>                      Then there are factors from application itself,
>>    such as
>>                      object mutation
>>                      rate, inter-generation/region references, etc.
>>
>>
>>                      I don't see a single formula for estimating GC
>>         memory size.
>>                      If you are
>>                      using G1, the biggest overhead comes from 2 bitmaps
>>         (1/32 *
>>                      heap size).
>>
>>                      Thanks,
>>
>>                      -Zhengyu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>         --         Regards,
>>         Glyn
>>
>>
>>
>>
>> --
>> Regards,
>> Glyn
>>
>


-- 
Regards,
Glyn

From lutz.schmidt at sap.com  Thu Dec 14 11:48:41 2017
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Thu, 14 Dec 2017 11:48:41 +0000
Subject: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
 handshakes
In-Reply-To: <76d784d3d6dd4b60a09f0c93a04e1dfe@sap.com>
References: <de1b75906439447eb24eaf15a2be805f@sap.com>
 <65ba0690f70a431296c8a704ca88fd23@sap.com>
 <49fe36780e5d4abf99745199479a75a7@sap.com>
 <76d784d3d6dd4b60a09f0c93a04e1dfe@sap.com>
Message-ID: <A14859E1-F0A8-409B-86AD-0686AB7EA1D2@sap.com>

Hi Martin, 

Your change looks good. I?d like to point out just two little details:
 - sharedRuntime_ppc.cpp, around line 236:
   Your comment talks about saving r31, but in fact you are saving r31 and r30.
 - macroAssembler_s390.hpp, around line 440:
   Your comment suggests instr_size(size, pc) actually updates the pc, but it does not.

If you agree, please just update the comments before you push. No new webrev required. 
 
Thanks for implementing this feature.

Lutz

 

On 12.12.2017, 11:20, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:

    Hi, 
    
    I would prefer
    "Check whether safepoint is requested and if so branch to code suspending the thread."
    The word 'poll' isn't very precise to describe what is happening here.
    
    Other stuff all fine. Reviewed. No new webrev needed.
    
    Best regards,
      Goetz. 
    
    > -----Original Message-----
    > From: Doerr, Martin
    > Sent: Dienstag, 12. Dezember 2017 11:08
    > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
    > developers (hotspot-dev at openjdk.java.net) <hotspot-
    > dev at openjdk.java.net>; Schmidt, Lutz <lutz.schmidt at sap.com>
    > Subject: RE: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
    > handshakes
    > 
    > Hi G?tz,
    > 
    > thanks reviewing. Please see my answers inline.
    > 
    > Best regards,
    > Martin
    > 
    > 
    > > I see you enabled it per default?
    > Yes. I have tried to keep the implementation as close to the other platforms
    > as possible. x86, SPARC and aarch64 have it enabled by default, too.
    > 
    > > macroAssembler_ppc/s390.cpp:
    > > MacroAssembler::safepoint_poll()
    > > Could you add some comment that says what this is doing?
    > > As it's not doing a safepoint_poll ... its just preparing it, right?
    > > Maybe also "slow_target" should be "do_safepoint".
    > I agree with that the label name "do_safepoint" would be more
    > comprehensible, but I'd prefer to use the same name as x86, SPARC and
    > aarch64.
    > What the function safepoint_poll does is it simply performs the poll by
    > checking the poll bit + conditional branch to the safepoint code. Would you
    > like to see a comment like "Perform poll and branch if safepoint requested"?
    > 
    > > templateInterpreterGenerator_ppc.cpp:
    > > Why do you change memory ordering from release() to lwsync()?
    > This is not a functional change. release() emits an lwsync() instruction. I have
    > changed it to emphasize that we're using it for acquire and release in one
    > instruction. release() hides that we use it for acquire, too.
    > 
    > > sharedRuntime_ppc/s390.cpp
    > > If I understand right you skip the safepoint instruction.
    > > Why that? Could you please document that this differs
    > > from the other platforms here?
    > The s390 code does exactly the same thing as on the other platforms. It
    > adjusts to PC to point to the instruction following the poll instruction. This is
    > part of the new concept which needs to be implemented on all platforms
    > supporting local handshakes. The difference to PPC for example is that s390
    > has different instruction sizes (2, 4 and 6 bytes) and I implemented it in a way
    > that it works with any poll instruction regardless of its size.
    > Would you like to see a comment like "Support poll instruction with any
    > size"?
    
    


From martin.doerr at sap.com  Thu Dec 14 12:09:27 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 14 Dec 2017 12:09:27 +0000
Subject: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
 handshakes
In-Reply-To: <A14859E1-F0A8-409B-86AD-0686AB7EA1D2@sap.com>
References: <de1b75906439447eb24eaf15a2be805f@sap.com>
 <65ba0690f70a431296c8a704ca88fd23@sap.com>
 <49fe36780e5d4abf99745199479a75a7@sap.com>
 <76d784d3d6dd4b60a09f0c93a04e1dfe@sap.com>
 <A14859E1-F0A8-409B-86AD-0686AB7EA1D2@sap.com>
Message-ID: <0cc149a3e1174f84b77a2eaececf98a1@sap.com>

Hi Lutz and G?tz,

thanks for reviewing. I have pushed the change with the proposed comment changes to jdk/jdk.

Best regards,
Martin


-----Original Message-----
From: Schmidt, Lutz 
Sent: Donnerstag, 14. Dezember 2017 12:49
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Doerr, Martin <martin.doerr at sap.com>; hotspot-dev developers (hotspot-dev at openjdk.java.net) <hotspot-dev at openjdk.java.net>
Subject: Re: RFR(L): 8193257: PPC64, s390 implementation for Thread-local handshakes

Hi Martin, 

Your change looks good. I?d like to point out just two little details:
 - sharedRuntime_ppc.cpp, around line 236:
   Your comment talks about saving r31, but in fact you are saving r31 and r30.
 - macroAssembler_s390.hpp, around line 440:
   Your comment suggests instr_size(size, pc) actually updates the pc, but it does not.

If you agree, please just update the comments before you push. No new webrev required. 
 
Thanks for implementing this feature.

Lutz

 

On 12.12.2017, 11:20, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com> wrote:

    Hi, 
    
    I would prefer
    "Check whether safepoint is requested and if so branch to code suspending the thread."
    The word 'poll' isn't very precise to describe what is happening here.
    
    Other stuff all fine. Reviewed. No new webrev needed.
    
    Best regards,
      Goetz. 
    
    > -----Original Message-----
    > From: Doerr, Martin
    > Sent: Dienstag, 12. Dezember 2017 11:08
    > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
    > developers (hotspot-dev at openjdk.java.net) <hotspot-
    > dev at openjdk.java.net>; Schmidt, Lutz <lutz.schmidt at sap.com>
    > Subject: RE: RFR(L): 8193257: PPC64, s390 implementation for Thread-local
    > handshakes
    > 
    > Hi G?tz,
    > 
    > thanks reviewing. Please see my answers inline.
    > 
    > Best regards,
    > Martin
    > 
    > 
    > > I see you enabled it per default?
    > Yes. I have tried to keep the implementation as close to the other platforms
    > as possible. x86, SPARC and aarch64 have it enabled by default, too.
    > 
    > > macroAssembler_ppc/s390.cpp:
    > > MacroAssembler::safepoint_poll()
    > > Could you add some comment that says what this is doing?
    > > As it's not doing a safepoint_poll ... its just preparing it, right?
    > > Maybe also "slow_target" should be "do_safepoint".
    > I agree with that the label name "do_safepoint" would be more
    > comprehensible, but I'd prefer to use the same name as x86, SPARC and
    > aarch64.
    > What the function safepoint_poll does is it simply performs the poll by
    > checking the poll bit + conditional branch to the safepoint code. Would you
    > like to see a comment like "Perform poll and branch if safepoint requested"?
    > 
    > > templateInterpreterGenerator_ppc.cpp:
    > > Why do you change memory ordering from release() to lwsync()?
    > This is not a functional change. release() emits an lwsync() instruction. I have
    > changed it to emphasize that we're using it for acquire and release in one
    > instruction. release() hides that we use it for acquire, too.
    > 
    > > sharedRuntime_ppc/s390.cpp
    > > If I understand right you skip the safepoint instruction.
    > > Why that? Could you please document that this differs
    > > from the other platforms here?
    > The s390 code does exactly the same thing as on the other platforms. It
    > adjusts to PC to point to the instruction following the poll instruction. This is
    > part of the new concept which needs to be implemented on all platforms
    > supporting local handshakes. The difference to PPC for example is that s390
    > has different instruction sizes (2, 4 and 6 bytes) and I implemented it in a way
    > that it works with any poll instruction regardless of its size.
    > Would you like to see a comment like "Support poll instruction with any
    > size"?
    
    


From doug.simon at oracle.com  Thu Dec 14 13:20:14 2017
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 14 Dec 2017 14:20:14 +0100
Subject: How to determine cause of class loading
Message-ID: <2B16E216-73AF-4CC0-8DB9-7C2CD549EC1E@oracle.com>

Quite often I find myself wanting to know why a given class is loaded. That is, I want to see a stack trace. As far as I can tell, there is no support for this in HotSpot which is why we hacked in support for a -XX:+TraceClassLoadingStack to graal-jvmci-8[1]. Is there a good reason a similar flag should not be added to main line HotSpot?

-Doug

[1] https://github.com/graalvm/graal-jvmci-8/commit/25de3259d10b8606e318ceecbdf0195d3b1f196f

From Alan.Bateman at oracle.com  Thu Dec 14 13:30:08 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 14 Dec 2017 13:30:08 +0000
Subject: How to determine cause of class loading
In-Reply-To: <2B16E216-73AF-4CC0-8DB9-7C2CD549EC1E@oracle.com>
References: <2B16E216-73AF-4CC0-8DB9-7C2CD549EC1E@oracle.com>
Message-ID: <8ee7e5cc-3138-9ec8-7f41-9f233ced8408@oracle.com>



On 14/12/2017 13:20, Doug Simon wrote:
> Quite often I find myself wanting to know why a given class is loaded. That is, I want to see a stack trace. As far as I can tell, there is no support for this in HotSpot which is why we hacked in support for a -XX:+TraceClassLoadingStack to graal-jvmci-8[1]. Is there a good reason a similar flag should not be added to main line HotSpot?
>
I've needed to do this a few times, I've usually resorted to adding an 
initializer to the class to dump the stack when it runs.

If something like this is added then it could be useful to specify a 
pattern or even a list class names to avoid a stack trace for every 
class. That might help with interference too when there is a lot of 
class loading going on in different threads.

-Alan

From zgu at redhat.com  Thu Dec 14 13:39:59 2017
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 14 Dec 2017 08:39:59 -0500
Subject: Excessive "GC" memory area size [was: Re: Determining "GC" memory
 area size]
In-Reply-To: <CAA-6JZou9MBU2buQgrUK44cBV7dAn6bGvjjhihUkL-kYaJaV=Q@mail.gmail.com>
References: <CAA-6JZoV6xxFezL4NSXf0+mGJXFVKOR222qzr3Pkxc4X2E8GHQ@mail.gmail.com>
 <0cd04045-ef97-16bf-874a-6703d6222578@redhat.com>
 <CAA-6JZpAkm-Tm4wkFkpD8jVk2+eq20GFFxEj6nKwazik8dNHhQ@mail.gmail.com>
 <83f18360-5dab-7780-3f28-db5abfed19e7@redhat.com>
 <CAA-6JZpXF3LLYrg6npEHOcZx_a6K5=C7Z6jsASgxGaHWa-Ukdg@mail.gmail.com>
 <b23e3c7f-8a23-036c-69d1-ff2be6cf2a6f@redhat.com>
 <CAA-6JZou9MBU2buQgrUK44cBV7dAn6bGvjjhihUkL-kYaJaV=Q@mail.gmail.com>
Message-ID: <8d16faf5-73be-6788-6807-9f878c4ef4a1@redhat.com>



On 12/14/2017 06:19 AM, Glyn Normington wrote:
> On Wed, Dec 13, 2017 at 5:18 PM, Zhengyu Gu <zgu at redhat.com 
> <mailto:zgu at redhat.com>> wrote:
> 
>     Hi Glyn,
> 
>     On 12/13/2017 11:38 AM, Glyn Normington wrote:
> 
>         Hi Zhengyu
> 
>         Thanks again for a great suggestion. JDK 10 gave more insights
>         such as this one showing a task queue-related malloc of 8 MB:
> 
>         0x000000010d128e58]
>         _ZN20MallocArrayAllocatorI16G1TaskQueueEntryE8allocateEm10MemoryType+0x5c
>         [0x000000010d12372e]
>         _ZN16G1ConcurrentMarkC2EP15G1CollectedHeapP21G1RegionToSpaceMapperS3_+0x8e4
>         [0x000000010d1198af] _ZN15G1CollectedHeap10initializeEv+0x561
>         [0x000000010d559029] _ZN8Universe15initialize_heapEv+0x4f
>                                        (malloc=8192KB type=GC #8)
> 
>         The malloc details don't seem to add up to the total, so maybe
>         some allocation sites got missed, but it's definitely better
>         than with JDK 8.
> 
> 
>     Detail tracking does discard allocation sites with small enough
>     allocation, e.g. < 1K when scale = KB. But I will be surprised if
>     the disparity is significant.
> 
> 
> You're right. The malloc details add up to 17524 KB which is almost 
> equal to the reported total of 17544 KB.
> 
> There was another large malloc, which I guess might also be task 
> queue-related:
> 
> [0x000000010d11dbc4] 
> _ZN20MallocArrayAllocatorI8StarTaskE8allocateEm10MemoryType+0x5c
> [0x000000010d119124] _ZN15G1CollectedHeapC2EP17G1CollectorPolicy+0x82c
> [0x000000010d11274a] 
> _ZN11GCArguments23create_heap_with_policyI15G1CollectedHeap17G1CollectorPolicyEEP13CollectedHeapv+0x44
> [0x000000010d559019] _ZN8Universe15initialize_heapEv+0x3f
>                               (malloc=8192KB type=GC #8)
> 
> 
Yes, looks like creation of task queues.


-Zhengyu

>     Thanks,
> 
>     -Zhengyu
> 
> 
> 
> 
>         Regards,
>         Glyn
> 
> 
>         On Wed, Dec 13, 2017 at 3:16 PM, Zhengyu Gu <zgu at redhat.com
>         <mailto:zgu at redhat.com> <mailto:zgu at redhat.com
>         <mailto:zgu at redhat.com>>> wrote:
> 
>              Hi Glyn,
> 
>              On 12/13/2017 09:35 AM, Glyn Normington wrote:
> 
>                  Thanks Zhengyu! That got me quite a bit further.
> 
>                  The NMT virtual memory map showed the mmap portion of
>         GC space
>                  consisting of:
>                  * the two marking bitmaps you mentioned previously,
>         each 1/64 of
>                  heap size.
>                  * a mark stack of 32 MB which is 8* MarkStackSize (but
>         which
>                  could grow to 8* MarkStackSizeMax or 128 MB).
>                  * three 700 KB areas, although I'm not sure what these
>         are used
>                  for or how to predict their total size.
> 
>                  This leaves the malloc portion of GC space "17615KB
>         #2312" which
>                  I think was due 2312 calls to malloc. Again, not sure
>         what these
>                  are used for or how to predict their total size except
>         that I
>                  presume they include the task queues you mentioned
>         previously.
> 
> 
>              Can you try on JDK10? it has enhancement [1] which can show
>         what
>              memory allocation is for, on each allocation site.
> 
> 
>              [1] https://bugs.openjdk.java.net/browse/JDK-8139673
>         <https://bugs.openjdk.java.net/browse/JDK-8139673>
>              <https://bugs.openjdk.java.net/browse/JDK-8139673
>         <https://bugs.openjdk.java.net/browse/JDK-8139673>>
> 
>              Thanks,
> 
>              -Zhengyu
> 
> 
>                  Outstanding questions:
>                  1. Is the mmap space which consumed three 700 KB areas
>         above
>                  fixed, proportional to heap size, or what?
>                  2. How many task queues are there for a given number of
>         GC threads?
>                  3. Task queues can overflow, so what is the maximum
>         space each
>                  one can occupy?
>                  4. Of the malloc space not consumed by task queues, how
>         much is
>                  fixed and how much proportional to heap size, number of GC
>                  threads, etc.?
> 
>                  The aim is to calculate a reasonable estimate of an
>         upper bound
>                  for GC space consumption.
> 
>                  Raw data for anyone who's interested:
>         https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6
>         <https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6>
>                 
>         <https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6
>         <https://gist.github.com/glyn/a3bd944eb2943f4f5a98b5ac712efeb6>>
> 
>                  Regards,
>                  Glyn
> 
>                  On Wed, Dec 13, 2017 at 12:27 PM, Zhengyu Gu
>         <zgu at redhat.com <mailto:zgu at redhat.com>
>                  <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>         <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
> 
>                  <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>> wrote:
> 
>                       Hi Glyn,
> 
>                       You can run NMT with detail tracking
>                       (-XX:NativeMemoryTracking=detail) then use jcmd
>         (jcmd <pid>
>                       VM.native_memory detail) to find out all
>         allocations for GC.
> 
>                       For example:
> 
>                       [0x00007f9fba000000 - 0x00007f9fbc000000] reserved
>         32768KB
>                  for *GC* from
>                            [0x00007fa0130260ef]
>         G1CMMarkStack::resize(unsigned
>                  long)+0x8f
>                            [0x00007fa01302cf62]
>                       G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>                       G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>                            [0x00007fa01300e94b]
>         G1CollectedHeap::initialize()+0x62b
>                            [0x00007fa013ca26af] universe_init()+0x6f
> 
>                                [0x00007f9fba000000 - 0x00007f9fbc000000]
>                  committed 32768KB
>                       from
>                                    [0x00007fa01302610d]
>                  G1CMMarkStack::resize(unsigned
>                       long)+0xad
>                                    [0x00007fa01302cf62]
>                       G1ConcurrentMark::G1ConcurrentMark(G1CollectedHeap*,
>                       G1RegionToSpaceMapper*, G1RegionToSpaceMapper*)+0x782
>                                    [0x00007fa01300e94b]
>                  G1CollectedHeap::initialize()+0x62b
>                                    [0x00007fa013ca26af] universe_init()+0x6f
> 
> 
>                       [0x00007fa012ac5395] ArrayAllocator<unsigned
>                       long>::allocate(unsigned long, MemoryType)+0x245
>                       [0x00007fa012ac5448] unsigned long*
>                     
>           BitMap::reallocate<CHeapBitMapAllocator>(CHeapBitMapAllocator
>                       const&, unsigned long*, unsigned long, unsigned
>         long)+0x38
>                       [0x00007fa012ac509f] CHeapBitMap::initialize(unsigned
>                  long)+0x6f
>                       [0x00007fa013093b9c]
>                     
>           G1PageBasedVirtualSpace::G1PageBasedVirtualSpace(ReservedSpace,
>                       unsigned long, unsigned long)+0x13c
>                                                     (malloc=129KB
>         *type=GC* #6)
> 
>                       Thanks,
> 
>                       -Zhengyu
> 
> 
> 
> 
>                       On 12/13/2017 04:39 AM, Glyn Normington wrote:
> 
>                           On the basis of the reply below, we have been
>         thinking of
>                           estimating the
>                           size of the "GC" memory area as a little more
>         than (1/32) *
>                           heapSize.
>                           However, running `java -version` with a 350m heap
>                  results in
>                           "GC" memory as
>                           reported by NMT of over 17% of the heap size,
>         so this
>                  estimate
>                           is way out.
> 
>                           If the analysis below is accurate, then given the
>                  number of GC
>                           threads is
>                           10 (ParallelGCThreads=8, ConcGCThreads=2), can
>         there be
>                  many more
>                           taskqueues than GC threads?
> 
>                           Or is there another explanation for the
>         additional "GC"
>                  size?
> 
>                           Thanks,
>                           Glyn
> 
>                           [1]
>         https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>
>                 
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>>
>                                 
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>
>                 
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe
>         <https://gist.github.com/glyn/f10b7dea77994ad0f5589a416fbc77fe>>>
> 
>                           On Fri, Nov 10, 2017 at 7:05 PM, Zhengyu Gu
>                  <zgu at redhat.com <mailto:zgu at redhat.com>
>         <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>
>                           <mailto:zgu at redhat.com <mailto:zgu at redhat.com>
>         <mailto:zgu at redhat.com <mailto:zgu at redhat.com>>>> wrote:
> 
>                               Hi Glyn,
> 
> 
>                                   Can anyone here tell me how the GC
>         memory area
>                  size is
>                                   determined? If
>                                   there
>                                   is documentation, so much the better
>         as we'd
>                  prefer not
>                                   to depend on code
>                                   details that might flux arbitrarily.
> 
> 
>                               GC memory is mainly data structures used by GC
>                  runtime. It
>                               can be varied
>                               by collector used, size of the Java heap, the
>                  number of GC
>                               threads and etc.
>                               and, of course, the application itself.
> 
>                               Some are *fixed* costs, which can be
>         estimated.
>                  E.g. two
>                               marking bitmaps
>                               used by G1, each costs 1/64 of heap size
>         (assuming
>                  default
>                               object
>                               alignment).
> 
>                               Some are *semi-fixed*, e.g. taskqueue's
>         fixed cost
>                  is about
>                               1M for each
>                               queue on 64-bits VM, but it can overflow.
>         And the
>                  number of
>                               task queues is
>                               proportional to the number of GC threads.
> 
>                               Then there are factors from application
>         itself,         such as
>                               object mutation
>                               rate, inter-generation/region references, etc.
> 
> 
>                               I don't see a single formula for estimating GC
>                  memory size.
>                               If you are
>                               using G1, the biggest overhead comes from
>         2 bitmaps
>                  (1/32 *
>                               heap size).
> 
>                               Thanks,
> 
>                               -Zhengyu
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                  --         Regards,
>                  Glyn
> 
> 
> 
> 
>         -- 
>         Regards,
>         Glyn
> 
> 
> 
> 
> -- 
> Regards,
> Glyn

From doug.simon at oracle.com  Thu Dec 14 13:39:38 2017
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 14 Dec 2017 14:39:38 +0100
Subject: How to determine cause of class loading
In-Reply-To: <8ee7e5cc-3138-9ec8-7f41-9f233ced8408@oracle.com>
References: <2B16E216-73AF-4CC0-8DB9-7C2CD549EC1E@oracle.com>
 <8ee7e5cc-3138-9ec8-7f41-9f233ced8408@oracle.com>
Message-ID: <454BA6CA-FB48-4E62-8C62-2B0F9C46DAD4@oracle.com>

That's enough input for me to open an issue ;-)

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

-Doug

> On 14 Dec 2017, at 14:30, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 14/12/2017 13:20, Doug Simon wrote:
>> Quite often I find myself wanting to know why a given class is loaded. That is, I want to see a stack trace. As far as I can tell, there is no support for this in HotSpot which is why we hacked in support for a -XX:+TraceClassLoadingStack to graal-jvmci-8[1]. Is there a good reason a similar flag should not be added to main line HotSpot?
>> 
> I've needed to do this a few times, I've usually resorted to adding an initializer to the class to dump the stack when it runs.
> 
> If something like this is added then it could be useful to specify a pattern or even a list class names to avoid a stack trace for every class. That might help with interference too when there is a lot of class loading going on in different threads.
> 
> -Alan


From jcbeyler at google.com  Thu Dec 14 16:04:35 2017
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 14 Dec 2017 08:04:35 -0800
Subject: TLAB Refills for x86
In-Reply-To: <1512990377.2882.9.camel@oracle.com>
References: <c3304685625d485c96f1ae3cc4c0a430@sap.com>
 <CAF9BGByvGg-GWcq01MAShPPj9phbUWSB6FQgYzdzjYZKrxVyrQ@mail.gmail.com>
 <1512990377.2882.9.camel@oracle.com>
Message-ID: <CAF9BGBys5p+Hc5QMMakQCuEPenXMx7CMQ6=p9nSaEGezyEeuow@mail.gmail.com>

Hi Thomas,

Done here:
http://cr.openjdk.java.net/~rasbold/8191027/webrev.04/

Let me know what you think,
Jc

On Mon, Dec 11, 2017 at 3:06 AM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> Hi,
>
> On Thu, 2017-12-07 at 21:49 -0800, JC Beyler wrote:
>> Hi all,
>>
>> I added a reword of the comment (I could also remove it so let me
>> know):
>> http://cr.openjdk.java.net/~rasbold/8191027/webrev.03/
>>
>> Let me know if it is better!
>
>   my suggestion:
>
> 3872   // Allocate the instance:
> 3873   // 1) If TLAB is enabled:
> 3874   //  a) Try to allocate in the TLAB
> 3875   //  b) If fails, go to the slow path.
> 3876   //    Else If inline contiguous allocations are enabled:
> 3878   //  i) Try to allocate in eden
> 3879   //  ii) If fails due to heap end, go to slow path.
> 3880   // 2) If TLAB is enabled OR inline contiguous is enabled:
> 3881   //  a) Initialize the allocation
> 3882   //  b) Exit.
> 3883   // 3) Go to slow path.
> 3884
>
> Same idea for the SPARC change.
>
> Thanks,
>   Thomas
>

From jcbeyler at google.com  Thu Dec 14 16:05:19 2017
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 14 Dec 2017 08:05:19 -0800
Subject: RFR 8191989: TLAB Refills for Sparc
In-Reply-To: <CAF9BGBwL-e+PNO5DjFa8xFVJcEESViryBqj6wK=NOdkW+UOpEw@mail.gmail.com>
References: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>
 <1512472098.2454.23.camel@oracle.com>
 <CAF9BGBwL-e+PNO5DjFa8xFVJcEESViryBqj6wK=NOdkW+UOpEw@mail.gmail.com>
Message-ID: <CAF9BGBy5-ZggYX+PStaTY=NbY6fnn5-STxEwbNgk5WpCHggyKw@mail.gmail.com>

Hi Thomas,

I did the same change for sparc here (compared to x86):
http://cr.openjdk.java.net/~rasbold/8191989/webrev.03/

Let me know what you think,
Jc

On Thu, Dec 7, 2017 at 9:52 PM, JC Beyler <jcbeyler at google.com> wrote:
> Hi Thomas,
>
> I fixed it here:
> http://cr.openjdk.java.net/~rasbold/8191989/webrev.02/
>
> Let me know if it is better, I did the same for x86.
>
> Thanks!
> Jc
>
> On Tue, Dec 5, 2017 at 3:08 AM, Thomas Schatzl <thomas.schatzl at oracle.com>
> wrote:
>>
>> Hi,
>>
>> On Thu, 2017-11-30 at 16:58 -0800, JC Beyler wrote:
>> > Hi all,
>> >
>> > The TLAB and the inline contiguous allocations handling are different
>> > for
>> > each architecture. On certain architectures, TLAB is never actually
>> > never
>> > refilled (ref:  https://bugs.openjdk.java.net/browse/JDK-8190862).
>> >
>> > The idea behind the implementation for Sparc is to do two things:
>> >   - separate TLAB usage to contiguous allocations in eden space.
>> >   - remove the code that augments the TLAB waste limit since that is
>> > already done in the common code slow path
>> >
>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8191989
>> > WebRev: *http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/
>> > <http://cr.openjdk.java.net/~rasbold/8191989/webrev.01/>*
>> >
>> > Does anyone see any issues with this webrev?
>>
>>   same comment as the x86 change, otherwise looks good.
>>
>> Thanks,
>>   Thomas
>
>

From jcbeyler at google.com  Thu Dec 14 16:08:37 2017
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 14 Dec 2017 08:08:37 -0800
Subject: RFR 8191985: Tlab refills for ARM
Message-ID: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>

Hi all,

The TLAB and the inline contiguous allocations handling are different
for each architecture. On certain architectures, TLAB is never
actually never refilled (ref:
https://bugs.openjdk.java.net/browse/JDK-8190862).

The idea behind the implementation for Arm is the same as for
Sparc/X86/Aarch64 and is to do one thing:
  - separate TLAB usage to contiguous allocations in eden space.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191985
WebRev: http://cr.openjdk.java.net/~rasbold/8191985/webrev.03/

Does anyone see any issues with this webrev? Could someone test/verify
it please?

Thanks for your help,
Jc

From thomas.schatzl at oracle.com  Thu Dec 14 16:08:21 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Dec 2017 17:08:21 +0100
Subject: TLAB Refills for x86
In-Reply-To: <CAF9BGBys5p+Hc5QMMakQCuEPenXMx7CMQ6=p9nSaEGezyEeuow@mail.gmail.com>
References: <c3304685625d485c96f1ae3cc4c0a430@sap.com>
 <CAF9BGByvGg-GWcq01MAShPPj9phbUWSB6FQgYzdzjYZKrxVyrQ@mail.gmail.com>
 <1512990377.2882.9.camel@oracle.com>
 <CAF9BGBys5p+Hc5QMMakQCuEPenXMx7CMQ6=p9nSaEGezyEeuow@mail.gmail.com>
Message-ID: <1513267701.2416.2.camel@oracle.com>

Hi,

On Thu, 2017-12-14 at 08:04 -0800, JC Beyler wrote:
> Hi Thomas,
> 
> Done here:
> http://cr.openjdk.java.net/~rasbold/8191027/webrev.04/
> 
> Let me know what you think,
> Jc


I only looked at the comment, which looks good now :)

Thanks,
  Thomas

From jcbeyler at google.com  Thu Dec 14 16:09:52 2017
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 14 Dec 2017 08:09:52 -0800
Subject: RFR 8191986: TLAB refills for Aarch64
Message-ID: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>

Hi all,

The TLAB and the inline contiguous allocations handling are different
for each architecture. On certain architectures, TLAB is never
actually never refilled (ref:
https://bugs.openjdk.java.net/browse/JDK-8190862).

The idea behind the implementation for Aarch64 is the same as for
Sparc/X86/Arm and is to do one thing:
  - separate TLAB usage to contiguous allocations in eden space.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191986
WebRev: http://cr.openjdk.java.net/~rasbold/8191986/webrev.02/

Does anyone see any issues with this webrev? Could someone test/verify
it please?

Thanks for your help,
Jc

From jcbeyler at google.com  Thu Dec 14 16:10:45 2017
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 14 Dec 2017 08:10:45 -0800
Subject: TLAB Refills for x86
In-Reply-To: <1513267701.2416.2.camel@oracle.com>
References: <c3304685625d485c96f1ae3cc4c0a430@sap.com>
 <CAF9BGByvGg-GWcq01MAShPPj9phbUWSB6FQgYzdzjYZKrxVyrQ@mail.gmail.com>
 <1512990377.2882.9.camel@oracle.com>
 <CAF9BGBys5p+Hc5QMMakQCuEPenXMx7CMQ6=p9nSaEGezyEeuow@mail.gmail.com>
 <1513267701.2416.2.camel@oracle.com>
Message-ID: <CAF9BGBwo0K5t=KS4a7-XGUs_RCtmgMgH85JrVsBJKzqh-bUDZQ@mail.gmail.com>

Thanks :)

Forgot to say that I removed the numbering, the indentation seemed
enough and the numbering did make it look confusing... even to me ;-)
Jc

On Thu, Dec 14, 2017 at 8:08 AM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> Hi,
>
> On Thu, 2017-12-14 at 08:04 -0800, JC Beyler wrote:
>> Hi Thomas,
>>
>> Done here:
>> http://cr.openjdk.java.net/~rasbold/8191027/webrev.04/
>>
>> Let me know what you think,
>> Jc
>
>
> I only looked at the comment, which looks good now :)
>
> Thanks,
>   Thomas

From thomas.schatzl at oracle.com  Thu Dec 14 16:15:42 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Dec 2017 17:15:42 +0100
Subject: TLAB Refills for x86
In-Reply-To: <CAF9BGBwo0K5t=KS4a7-XGUs_RCtmgMgH85JrVsBJKzqh-bUDZQ@mail.gmail.com>
References: <c3304685625d485c96f1ae3cc4c0a430@sap.com>
 <CAF9BGByvGg-GWcq01MAShPPj9phbUWSB6FQgYzdzjYZKrxVyrQ@mail.gmail.com>
 <1512990377.2882.9.camel@oracle.com>
 <CAF9BGBys5p+Hc5QMMakQCuEPenXMx7CMQ6=p9nSaEGezyEeuow@mail.gmail.com>
 <1513267701.2416.2.camel@oracle.com>
 <CAF9BGBwo0K5t=KS4a7-XGUs_RCtmgMgH85JrVsBJKzqh-bUDZQ@mail.gmail.com>
Message-ID: <1513268142.2416.4.camel@oracle.com>

Hi,

On Thu, 2017-12-14 at 08:10 -0800, JC Beyler wrote:
> Thanks :)
> 
> Forgot to say that I removed the numbering, the indentation seemed
> enough and the numbering did make it look confusing... even to me ;-)

 I did notice that :) I agree.

Thomas


From thomas.schatzl at oracle.com  Thu Dec 14 16:07:48 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 14 Dec 2017 17:07:48 +0100
Subject: RFR 8191989: TLAB Refills for Sparc
In-Reply-To: <CAF9BGBy5-ZggYX+PStaTY=NbY6fnn5-STxEwbNgk5WpCHggyKw@mail.gmail.com>
References: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>
 <1512472098.2454.23.camel@oracle.com>
 <CAF9BGBwL-e+PNO5DjFa8xFVJcEESViryBqj6wK=NOdkW+UOpEw@mail.gmail.com>
 <CAF9BGBy5-ZggYX+PStaTY=NbY6fnn5-STxEwbNgk5WpCHggyKw@mail.gmail.com>
Message-ID: <1513267668.2416.1.camel@oracle.com>

Hi,

On Thu, 2017-12-14 at 08:05 -0800, JC Beyler wrote:
> Hi Thomas,
> 
> I did the same change for sparc here (compared to x86):
> http://cr.openjdk.java.net/~rasbold/8191989/webrev.03/

I only looked at the comment, which looks good now :)

Thanks,
  Thomas

From dmitry.samersoff at bell-sw.com  Fri Dec 15 14:54:49 2017
From: dmitry.samersoff at bell-sw.com (Dmitry Samersov)
Date: Fri, 15 Dec 2017 17:54:49 +0300
Subject: RFR 8191986: TLAB refills for Aarch64
In-Reply-To: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>
References: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>
Message-ID: <57ccf60c-cfb9-d6c4-2b9b-4d1a840a290c@bell-sw.com>

JC Beyler,

I'll test the fix.

-Dmitry

On 14.12.2017 19:09, JC Beyler wrote:
> Hi all,
> 
> The TLAB and the inline contiguous allocations handling are different
> for each architecture. On certain architectures, TLAB is never
> actually never refilled (ref:
> https://bugs.openjdk.java.net/browse/JDK-8190862).
> 
> The idea behind the implementation for Aarch64 is the same as for
> Sparc/X86/Arm and is to do one thing:
>   - separate TLAB usage to contiguous allocations in eden space.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191986
> WebRev: http://cr.openjdk.java.net/~rasbold/8191986/webrev.02/
> 
> Does anyone see any issues with this webrev? Could someone test/verify
> it please?
> 
> Thanks for your help,
> Jc
> 



From adinn at redhat.com  Fri Dec 15 14:58:40 2017
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 15 Dec 2017 14:58:40 +0000
Subject: RFR 8191986: TLAB refills for Aarch64
In-Reply-To: <57ccf60c-cfb9-d6c4-2b9b-4d1a840a290c@bell-sw.com>
References: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>
 <57ccf60c-cfb9-d6c4-2b9b-4d1a840a290c@bell-sw.com>
Message-ID: <3d01c3d3-fbf6-1ae3-61c8-840a394133c5@redhat.com>

On 15/12/17 14:54, Dmitry Samersov wrote:
> JC Beyler,
> 
> I'll test the fix.
No need -- I have already done so and it is fine.

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 thomas.schatzl at oracle.com  Fri Dec 15 15:05:33 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 15 Dec 2017 16:05:33 +0100
Subject: RFR 8191986: TLAB refills for Aarch64
In-Reply-To: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>
References: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>
Message-ID: <1513350333.2466.12.camel@oracle.com>

Hi,

On Thu, 2017-12-14 at 08:09 -0800, JC Beyler wrote:
> Hi all,
> 
> The TLAB and the inline contiguous allocations handling are different
> for each architecture. On certain architectures, TLAB is never
> actually never refilled (ref:
> https://bugs.openjdk.java.net/browse/JDK-8190862).
> 
> The idea behind the implementation for Aarch64 is the same as for
> Sparc/X86/Arm and is to do one thing:
>   - separate TLAB usage to contiguous allocations in eden space.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191986
> WebRev: http://cr.openjdk.java.net/~rasbold/8191986/webrev.02/
> 
> Does anyone see any issues with this webrev? Could someone
> test/verify
> it please?


  looks good to me.

Thomas


From dmitry.samersoff at bell-sw.com  Fri Dec 15 15:19:24 2017
From: dmitry.samersoff at bell-sw.com (Dmitry Samersov)
Date: Fri, 15 Dec 2017 18:19:24 +0300
Subject: RFR 8191986: TLAB refills for Aarch64
In-Reply-To: <3d01c3d3-fbf6-1ae3-61c8-840a394133c5@redhat.com>
References: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>
 <57ccf60c-cfb9-d6c4-2b9b-4d1a840a290c@bell-sw.com>
 <3d01c3d3-fbf6-1ae3-61c8-840a394133c5@redhat.com>
Message-ID: <04ada3f4-6fab-5323-d60b-74cda30862c4@bell-sw.com>

Andrew,

> No need -- I have already done so and it is fine.

Thank you.

The fix looks good to me as well.

-Dmitry


On 15.12.2017 17:58, Andrew Dinn wrote:
> On 15/12/17 14:54, Dmitry Samersov wrote:
>> JC Beyler,
>>
>> I'll test the fix.
> No need -- I have already done so and it is fine.
> 
> 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 jcbeyler at google.com  Fri Dec 15 15:52:21 2017
From: jcbeyler at google.com (JC Beyler)
Date: Fri, 15 Dec 2017 07:52:21 -0800
Subject: RFR 8191986: TLAB refills for Aarch64
In-Reply-To: <04ada3f4-6fab-5323-d60b-74cda30862c4@bell-sw.com>
References: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>
 <57ccf60c-cfb9-d6c4-2b9b-4d1a840a290c@bell-sw.com>
 <3d01c3d3-fbf6-1ae3-61c8-840a394133c5@redhat.com>
 <04ada3f4-6fab-5323-d60b-74cda30862c4@bell-sw.com>
Message-ID: <CAF9BGBzRE54D96UYE9h59u26U7bqWtSkcWjiHo9--C+vRXeokg@mail.gmail.com>

Thanks all for testing it :)
Jc

On Fri, Dec 15, 2017 at 7:19 AM, Dmitry Samersov
<dmitry.samersoff at bell-sw.com> wrote:
> Andrew,
>
>> No need -- I have already done so and it is fine.
>
> Thank you.
>
> The fix looks good to me as well.
>
> -Dmitry
>
>
> On 15.12.2017 17:58, Andrew Dinn wrote:
>> On 15/12/17 14:54, Dmitry Samersov wrote:
>>> JC Beyler,
>>>
>>> I'll test the fix.
>> No need -- I have already done so and it is fine.
>>
>> 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 dms at samersoff.net  Mon Dec 18 08:05:43 2017
From: dms at samersoff.net (Dmitry Samersoff)
Date: Mon, 18 Dec 2017 11:05:43 +0300
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <CAEGA6kaLEXvURu8ScwKb-rpSwLWOrKksvkRfKL8wsKb2_cq+tQ@mail.gmail.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
 <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
 <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>
 <d8348c30-f509-c94e-9c9e-1d397973b758@redhat.com>
 <CAEGA6kac5=5ydKLgBjh+Z53To4owm63J4ppLV12DQAwhe+nnuw@mail.gmail.com>
 <b3927395-4c7e-c3f1-4788-0bbbc8956292@redhat.com>
 <CAEGA6kaLEXvURu8ScwKb-rpSwLWOrKksvkRfKL8wsKb2_cq+tQ@mail.gmail.com>
Message-ID: <d942b674-3c6e-0837-d6f4-938793189e66@samersoff.net>

Stuart,

I can confirm that the patch works in our environment.

-Dmitry

On 13.12.2017 18:56, Stuart Monteith wrote:
> Hello,
>    Here's most latest patch:
> 
> http://cr.openjdk.java.net/~smonteith/8193266/webrev-2/
> 
> Things to note:
>    I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp
> and metaspaceShared.cpp
> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is
> the same value as UnscaledOopHeapMax. Perhaps that should be used
> instead of UnscaledClassSpaceMax in all three places.
>    I'm using the constant in MacroAssembler_aarch64.hpp in the
> MacroAssembler constructor instead of CompressedClassSpaceSize.
>    The calculation has changed - "1u" has changed to "1ul" as the
> address "0x100000000" is not representable as a 32 bit value.
>    The test has changed from ">" to ">=" as the greatest offset for
> 4GB is "0xffffffff", and so 0x100000000 and upwards are all acceptable
> for XORing offsets to.
> 
> The intention is to prevent bad code from being generated if the
> compressed class addresses range changes.
> 
> BR,
>    Stuart
> 
> On 11 December 2017 at 13:54, Andrew Haley <aph at redhat.com> wrote:
>> On 11/12/17 13:43, Stuart Monteith wrote:
>>> I've copied and pasted the calculation for UnscaledClassSpaceMax in
>>> use_XOR_for_compressed_class_base to match the variable of the same
>>> name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces  -
>>> I did this for ease of reference while we decide what to do.
>>
>> Yes, I get that.  I don't want to pessimize the "normal" use of OpenJDK
>> AArch64 for the sake of this weird case.  I guess that as long as no-
>> one explicitly sets the base of the metaspace below 32 bits it doesn't
>> matter anyway.
>>
>> --
>> 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  Mon Dec 18 09:15:53 2017
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Dec 2017 09:15:53 +0000
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <CAEGA6kaLEXvURu8ScwKb-rpSwLWOrKksvkRfKL8wsKb2_cq+tQ@mail.gmail.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
 <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
 <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>
 <d8348c30-f509-c94e-9c9e-1d397973b758@redhat.com>
 <CAEGA6kac5=5ydKLgBjh+Z53To4owm63J4ppLV12DQAwhe+nnuw@mail.gmail.com>
 <b3927395-4c7e-c3f1-4788-0bbbc8956292@redhat.com>
 <CAEGA6kaLEXvURu8ScwKb-rpSwLWOrKksvkRfKL8wsKb2_cq+tQ@mail.gmail.com>
Message-ID: <20e812bc-d132-9863-815b-345283f9517e@redhat.com>

On 13/12/17 15:56, Stuart Monteith wrote:
>    I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp
> and metaspaceShared.cpp
> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is
> the same value as UnscaledOopHeapMax. Perhaps that should be used
> instead of UnscaledClassSpaceMax in all three places.
>    I'm using the constant in MacroAssembler_aarch64.hpp in the
> MacroAssembler constructor instead of CompressedClassSpaceSize.

I don't thing that really helps.  We don't need a global constant
which is the worst possible case for UnscaledClassSpaceMax because
we already know what that is: it's 2**32.

We need to know how much space is in use.

-- 
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 muthusamy.chinnathambi at oracle.com  Mon Dec 18 09:35:39 2017
From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi)
Date: Mon, 18 Dec 2017 01:35:39 -0800 (PST)
Subject: [8u] RFR for backport of JDK-8169931: 8k class metaspace chunks
 misallocated from 4k chunk freelist
Message-ID: <14de408c-48f8-462d-8652-9c4b210f0129@default>

Hi,
		 
Please review the backport of bug: "JDK-8169931: 8k class metaspace chunks misallocated from 4k chunk freelist" to jdk8u-dev

Please note that this is not a clean backport due to new entries in jni.cpp.


Webrev:  http://cr.openjdk.java.net/~mchinnathamb/JDK-8169931/webrev.01/ 
jdk9 bug:  https://bugs.openjdk.java.net/browse/JDK-8169931 
Original patch pushed to jdk9:  http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8d26435a4c69 

Test:  Had run jtreg, jprt hotspot testset and with -XX:+ExecuteInternalVMTests.

Regards,
Muthusamy C

From stuart.monteith at linaro.org  Mon Dec 18 13:41:36 2017
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Mon, 18 Dec 2017 13:41:36 +0000
Subject: [aarch64-port-dev ] RFR: 8193266: AArch64:
 TestOptionsWithRanges.java SIGSEGV
In-Reply-To: <20e812bc-d132-9863-815b-345283f9517e@redhat.com>
References: <CAEGA6kZMsWyPHskBBDHVHNVRQKzCY5VDfpxPCRLs8gdJ3uohZQ@mail.gmail.com>
 <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com>
 <d4a9532e-0fee-5b58-9163-34488117227d@redhat.com>
 <d8348c30-f509-c94e-9c9e-1d397973b758@redhat.com>
 <CAEGA6kac5=5ydKLgBjh+Z53To4owm63J4ppLV12DQAwhe+nnuw@mail.gmail.com>
 <b3927395-4c7e-c3f1-4788-0bbbc8956292@redhat.com>
 <CAEGA6kaLEXvURu8ScwKb-rpSwLWOrKksvkRfKL8wsKb2_cq+tQ@mail.gmail.com>
 <20e812bc-d132-9863-815b-345283f9517e@redhat.com>
Message-ID: <CAEGA6kZ3_wMoaz8NzQou0Y=NjuAvCZ6ZxqMEjN4VbV3h=p=c-g@mail.gmail.com>

Ok, the constant was just an attempt at reducing the likelihood of the
backend generating bad addresses if the range changes. We have a
testcase that might trip if the future changes.

We'll need the 4GB limit during dumping the shared metaspace. During
runtime, we'll need the maximum size of the compressed metaspace. I
suppose that's the intention behind using CompressedClassSpaceSize.
I've just been checking to see if that still holds.

BR,
   Stuart


On 18 December 2017 at 09:15, Andrew Haley <aph at redhat.com> wrote:
> On 13/12/17 15:56, Stuart Monteith wrote:
>>    I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp
>> and metaspaceShared.cpp
>> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is
>> the same value as UnscaledOopHeapMax. Perhaps that should be used
>> instead of UnscaledClassSpaceMax in all three places.
>>    I'm using the constant in MacroAssembler_aarch64.hpp in the
>> MacroAssembler constructor instead of CompressedClassSpaceSize.
>
> I don't thing that really helps.  We don't need a global constant
> which is the worst possible case for UnscaledClassSpaceMax because
> we already know what that is: it's 2**32.
>
> We need to know how much space is in use.
>
> --
> 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 paul.sandoz at oracle.com  Tue Dec 19 01:42:49 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 18 Dec 2017 17:42:49 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <5A386C66.6090505@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
 <5A386C66.6090505@oracle.com>
Message-ID: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>

Looks good to me.

I am including HS dev for the class file version changes:

  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/>
  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/>

We can push the above patches under the following issue rather that merge into Joe's patch:

  https://bugs.openjdk.java.net/browse/JDK-8191913 <https://bugs.openjdk.java.net/browse/JDK-8191913>

Hopefully by the next release we can merge together and with less changes required.

Paul.

> On 18 Dec 2017, at 17:33, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> A follow-up on defining a final field RELEASE_CURRENT  as an alias for the latest SourceVersion constant to allow easier updating of annotations using SourceVersion constants. Somewht surprisingly, this is not legal Java code; an annotation must use an enum constant directly and not a constant expression which evaluates to an enum constant.
> 
> This rules is given in JLS 9.7.1 Normal Annotations:
> 
>> T [ the element type] is not an array type, and the type of V [the element value] is assignment compatible (?5.2) with T, and:
>> 
>>    If T is a primitive type or String, then V is a constant expression (?15.28).
>>    If T is Class or an invocation of Class (?4.5), then V is a class literal (?15.8.2).
>>    If T is an enum type (?8.9), then V is an enum constant (?8.9.1).
>>    V is not null.
> https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1
> 
> The wording goes back to JLS 3rd edition which introduced enums and annotations.
> 
> Formally, the constant expression concept in JLS 15.28 only applies to primitive types and Strings. Presumably, it would not be too difficult to expand this concept to include class literals and enum constants.
> 
> In any case, in the mean time the suggested idiom will not work and the changes of RELEASE_9 => RELEASE_10 will need to stay.
> 
> Updated webrev with a minor merge:
> 
>    http://cr.openjdk.java.net/~darcy/8173382.3/
> 
> Cheers,
> 
> -Joe
> 


From joe.darcy at oracle.com  Tue Dec 19 01:49:42 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 18 Dec 2017 17:49:42 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target
 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
 <5A386C66.6090505@oracle.com>
 <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
Message-ID: <5A387036.2080008@oracle.com>

Thanks Paul.

I'm doing final checks and preparations of fixes to

     JDK-8173382: Add -source 11 and -target 11 to javac
     JDK-8193291: Add SourceVersion.RELEASE_11

and expect to push shortly.

Cheers,

-Joe

On 12/18/2017 5:42 PM, Paul Sandoz wrote:
> Looks good to me.
>
> I am including HS dev for the class file version changes:
>
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk/JDK-8173382-classfile-version/webrev/>
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/>
>
> We can push the above patches under the following issue rather that 
> merge into Joe's patch:
>
> https://bugs.openjdk.java.net/browse/JDK-8191913
>
> Hopefully by the next release we can merge together and with less 
> changes required.
>
> Paul.
>
>> On 18 Dec 2017, at 17:33, Joseph D. Darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>> Hello,
>>
>> A follow-up on defining a final field RELEASE_CURRENT  as an alias 
>> for the latest SourceVersion constant to allow easier updating of 
>> annotations using SourceVersion constants. Somewht surprisingly, this 
>> is not legal Java code; an annotation must use an enum constant 
>> directly and not a constant expression which evaluates to an enum 
>> constant.
>>
>> This rules is given in JLS 9.7.1 Normal Annotations:
>>
>>> T [ the element type] is not an array type, and the type of V [the 
>>> element value] is assignment compatible (?5.2) with T, and:
>>>
>>>    If T is a primitive type or String, then V is a constant 
>>> expression (?15.28).
>>>    If T is Class or an invocation of Class (?4.5), then V is a class 
>>> literal (?15.8.2).
>>>    If T is an enum type (?8.9), then V is an enum constant (?8.9.1).
>>>    V is not null.
>> https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1
>>
>> The wording goes back to JLS 3rd edition which introduced enums and 
>> annotations.
>>
>> Formally, the constant expression concept in JLS 15.28 only applies 
>> to primitive types and Strings. Presumably, it would not be too 
>> difficult to expand this concept to include class literals and enum 
>> constants.
>>
>> In any case, in the mean time the suggested idiom will not work and 
>> the changes of RELEASE_9 => RELEASE_10 will need to stay.
>>
>> Updated webrev with a minor merge:
>>
>>    http://cr.openjdk.java.net/~darcy/8173382.3/
>>
>> Cheers,
>>
>> -Joe
>>
>


From david.holmes at oracle.com  Tue Dec 19 01:52:01 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Dec 2017 11:52:01 +1000
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
 <5A386C66.6090505@oracle.com>
 <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
Message-ID: <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com>

On 19/12/2017 11:42 AM, Paul Sandoz wrote:
> Looks good to me.
> 
> I am including HS dev for the class file version changes:
> 
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/
> 
> We can push the above patches under the following issue rather that 
> merge into Joe's patch:
> 
> https://bugs.openjdk.java.net/browse/JDK-8191913
> 
> Hopefully by the next release we can merge together and with less 
> changes required.

Changes seem okay, but I'm still a little concerned about using 
classfile version 55 before we actually bump the JDK version to 11.

And it still isn't clear to me who will be doing the actual version 
update and when?

Thanks,
David

> Paul.
> 
>> On 18 Dec 2017, at 17:33, Joseph D. Darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>> Hello,
>>
>> A follow-up on defining a final field RELEASE_CURRENT ?as an alias for 
>> the latest SourceVersion constant to allow easier updating of 
>> annotations using SourceVersion constants. Somewht surprisingly, this 
>> is not legal Java code; an annotation must use an enum constant 
>> directly and not a constant expression which evaluates to an enum 
>> constant.
>>
>> This rules is given in JLS 9.7.1 Normal Annotations:
>>
>>> T [ the element type] is not an array type, and the type of V [the 
>>> element value] is assignment compatible (?5.2) with T, and:
>>>
>>> ???If T is a primitive type or String, then V is a constant 
>>> expression (?15.28).
>>> ???If T is Class or an invocation of Class (?4.5), then V is a class 
>>> literal (?15.8.2).
>>> ???If T is an enum type (?8.9), then V is an enum constant (?8.9.1).
>>> ???V is not null.
>> https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1
>>
>> The wording goes back to JLS 3rd edition which introduced enums and 
>> annotations.
>>
>> Formally, the constant expression concept in JLS 15.28 only applies to 
>> primitive types and Strings. Presumably, it would not be too difficult 
>> to expand this concept to include class literals and enum constants.
>>
>> In any case, in the mean time the suggested idiom will not work and 
>> the changes of RELEASE_9 => RELEASE_10 will need to stay.
>>
>> Updated webrev with a minor merge:
>>
>> ???http://cr.openjdk.java.net/~darcy/8173382.3/
>>
>> Cheers,
>>
>> -Joe
>>
> 

From paul.sandoz at oracle.com  Tue Dec 19 02:34:01 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 18 Dec 2017 18:34:01 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
 <5A386C66.6090505@oracle.com>
 <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
 <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com>
Message-ID: <C08EF385-D3AC-45A0-8E66-8965DAE1AED7@oracle.com>



> On 18 Dec 2017, at 17:52, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 19/12/2017 11:42 AM, Paul Sandoz wrote:
>> Looks good to me.
>> I am including HS dev for the class file version changes:
>> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/
>> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/
>> We can push the above patches under the following issue rather that merge into Joe's patch:
>> https://bugs.openjdk.java.net/browse/JDK-8191913
>> Hopefully by the next release we can merge together and with less changes required.
> 
> Changes seem okay, but I'm still a little concerned about using classfile version 55 before we actually bump the JDK version to 11.
> 

Thanks, jdk and hs 1 to 4 tier testing showed no issues.


> And it still isn't clear to me who will be doing the actual version update and when?
> 

Unsure, we are still working out the steps, hopefully it would follow on fairly quickly.

Plus there are quite a few follow on actions we can do to make this simpler for next time (especially for hardcoded values in build scripts and tests).

Paul.

From robbin.ehn at oracle.com  Tue Dec 19 10:24:50 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 19 Dec 2017 11:24:50 +0100
Subject: RFR 8191985: Tlab refills for ARM
In-Reply-To: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
References: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
Message-ID: <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>

Hi JC,

We do not longer have the ability to build and test arm32. And none seem to be picking this port up.
Only eyeballing this to looks good!

/Robbin

On 2017-12-14 17:08, JC Beyler wrote:
> Hi all,
> 
> The TLAB and the inline contiguous allocations handling are different
> for each architecture. On certain architectures, TLAB is never
> actually never refilled (ref:
> https://bugs.openjdk.java.net/browse/JDK-8190862).
> 
> The idea behind the implementation for Arm is the same as for
> Sparc/X86/Aarch64 and is to do one thing:
>    - separate TLAB usage to contiguous allocations in eden space.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191985
> WebRev: http://cr.openjdk.java.net/~rasbold/8191985/webrev.03/
> 
> Does anyone see any issues with this webrev? Could someone test/verify
> it please?
> 
> Thanks for your help,
> Jc
> 

From Alan.Bateman at oracle.com  Tue Dec 19 11:06:01 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Dec 2017 11:06:01 +0000
Subject: Thread.single_step field, anything using it?
Message-ID: <e13f3404-2988-9cd7-7a2e-13f09ea666ff@oracle.com>

I've been going through the fields in java.lang.Thread and I'm wondering 
if this field can be removed:

 ??? /* Whether or not to single_step this thread. */
 ??? private boolean???? single_step;

This field was used in the original Classic VM (pre-OpenJDK history). It 
doesn't appear to be used in the HotSpot VM.

Does anyone know of any reason to keep it? Are there other VMs using it 
by any chance?

-Alan




From matthias.baesken at sap.com  Tue Dec 19 16:37:24 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 19 Dec 2017 16:37:24 +0000
Subject: nmethod::print_calls(outputStream* st) still needed ?
Message-ID: <8cec0e778d564aa6bcec2b9c372cb5de@sap.com>

Hello,    nmethod::print_calls   from

  src<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/>/hotspot<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/>/share<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/>/code<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/code/>/nmethod.cpp<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/code/nmethod.cpp>     and
  src<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/>/hotspot<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/>/share<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/>/code<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/code/>/nmethod.hpp<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/code/nmethod.cpp>

seems to be not referenced any more.
Should it be removed ?

(I was   looking into this when I   searched for  the  potential need of  additional   ResourceMarks  when   CompiledIC_at<http://ld8443:8080/source/s?defs=CompiledIC_at&project=openjdk-jdk-jdk>  is  used
    Which is done  in  nmethod::print_calls   .  )


Thanks, Matthias

From vladimir.kozlov at oracle.com  Tue Dec 19 17:55:03 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 19 Dec 2017 09:55:03 -0800
Subject: nmethod::print_calls(outputStream* st) still needed ?
In-Reply-To: <8cec0e778d564aa6bcec2b9c372cb5de@sap.com>
References: <8cec0e778d564aa6bcec2b9c372cb5de@sap.com>
Message-ID: <ef8a2252-7d10-bbc6-1f23-5322b22fe1ef@oracle.com>

Long-long ago it was called from nmethod::print_nmethod() but we lost it 
there. It is seems the call was removed because it was noisy.
I think it still can be used when debugging CompiledIC.

Regards,
Vladimir

On 12/19/17 8:37 AM, Baesken, Matthias wrote:
> Hello,    nmethod::print_calls   from
> 
>    src<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/>/hotspot<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/>/share<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/>/code<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/code/>/nmethod.cpp<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/code/nmethod.cpp>     and
>    src<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/>/hotspot<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/>/share<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/>/code<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/code/>/nmethod.hpp<http://ld8443:8080/source/xref/openjdk-jdk-jdk/src/hotspot/share/code/nmethod.cpp>
> 
> seems to be not referenced any more.
> Should it be removed ?
> 
> (I was   looking into this when I   searched for  the  potential need of  additional   ResourceMarks  when   CompiledIC_at<http://ld8443:8080/source/s?defs=CompiledIC_at&project=openjdk-jdk-jdk>  is  used
>      Which is done  in  nmethod::print_calls   .  )
> 
> 
> Thanks, Matthias
> 

From glaubitz at physik.fu-berlin.de  Tue Dec 19 20:53:44 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 19 Dec 2017 21:53:44 +0100
Subject: RFR: 8192123: Zero should use compiler built-ins for atomics on
 linux-arm
In-Reply-To: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de>
References: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de>
Message-ID: <ea78f0fc-9573-d5ef-6b7a-438c9f108699@physik.fu-berlin.de>

Hi!

On 11/29/2017 03:08 PM, John Paul Adrian Glaubitz wrote:
> Like it has already been done for linux-m68k in JDK-8187227, Zero should also be
> patched on linux-arm to use compiler built-ins for the atomic functions in
> hotspot/os_cpu/linux_zero/assembler_linux_zero.cpp.

Since the development phase for OpenJDK 11 has started now, I would like
to ask for this change to be reviewed and hopefully approved again.

I have just successfully tested a rebased version of this patch on Debian
armel and it builds fine:

/usr/bin/printf  -- "----- Build times -------\nStart %s\nEnd   %s\n%s\n%s\n-------------------------\n" "`/bin/cat /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/make-support/build-times/build_time_start_TOTAL_human_readable`" "`/bin/cat /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/make-support/build-times/build_time_end_TOTAL_human_readable`" "`/bin/ls /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/make-support/build-times/build_time_diff_* | /bin/grep -v _TOTAL | /usr/bin/xargs /bin/cat | /usr/bin/sort -k 2`" "`/bin/cat /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/make-support/build-times/build_time_diff_TOTAL`" > >(/usr/bin/tee -a /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/build.log) 2> >(/usr/bin/tee -a /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/build.log >&2) && wait
----- Build times -------
Start 2017-12-19 11:02:55
End   2017-12-19 20:47:43

09:44:48 TOTAL
-------------------------
if test -f /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/make-support/exit-with-error ; then \
     exit 1 ; \
   fi
/usr/bin/printf "Finished building target 'images' in configuration 'linux-arm-normal-zero-release'\n" > >(/usr/bin/tee -a /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/build.log) 2> >(/usr/bin/tee -a /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/build.log >&2) && wait
Finished building target 'images' in configuration 'linux-arm-normal-zero-release'
make[1]: Leaving directory '/home/glaubitz/openjdk/hs'

Changeset can be found in [1].

Also, could maybe someone assist me in committing this change myself
as I am now officially a JDK committer :-).

Thanks,

Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8192123/webrev.00/

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From david.holmes at oracle.com  Tue Dec 19 22:27:29 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Dec 2017 08:27:29 +1000
Subject: Trivial RFR: 8193840: Add compiler/c2/Test8007294.java to the problem
 list
Message-ID: <c6f3555c-e4b5-45fa-b0e4-0d6d58002c78@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8193840
webrev: http://cr.openjdk.java.net/~dholmes/8193840/webrev/


--- old/test/hotspot/jtreg/ProblemList.txt	2017-12-19 17:25:19.263976578 
-0500
+++ new/test/hotspot/jtreg/ProblemList.txt	2017-12-19 17:25:17.091852524 
-0500
@@ -51,6 +51,7 @@
  compiler/tiered/LevelTransitionTest.java 8067651 generic-all
  compiler/types/correctness/CorrectnessTest.java 8066173 generic-all
  compiler/types/correctness/OffTest.java 8066173 generic-all
+compiler/c2/Test8007294.java 8192992 generic-all

  # aot test intermittently failing in jprt 8175791
  compiler/aot/DeoptimizationTest.java 8175791 windows-all

Thanks,
David

From coleen.phillimore at oracle.com  Tue Dec 19 22:29:30 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 19 Dec 2017 17:29:30 -0500
Subject: Trivial RFR: 8193840: Add compiler/c2/Test8007294.java to the
 problem list
In-Reply-To: <c6f3555c-e4b5-45fa-b0e4-0d6d58002c78@oracle.com>
References: <c6f3555c-e4b5-45fa-b0e4-0d6d58002c78@oracle.com>
Message-ID: <db366e39-a0b1-f207-b62f-fd022a079689@oracle.com>

Looks good.? Thanks!
Coleen

On 12/19/17 5:27 PM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193840
> webrev: http://cr.openjdk.java.net/~dholmes/8193840/webrev/
>
>
> --- old/test/hotspot/jtreg/ProblemList.txt??? 2017-12-19 
> 17:25:19.263976578 -0500
> +++ new/test/hotspot/jtreg/ProblemList.txt??? 2017-12-19 
> 17:25:17.091852524 -0500
> @@ -51,6 +51,7 @@
> ?compiler/tiered/LevelTransitionTest.java 8067651 generic-all
> ?compiler/types/correctness/CorrectnessTest.java 8066173 generic-all
> ?compiler/types/correctness/OffTest.java 8066173 generic-all
> +compiler/c2/Test8007294.java 8192992 generic-all
>
> ?# aot test intermittently failing in jprt 8175791
> ?compiler/aot/DeoptimizationTest.java 8175791 windows-all
>
> Thanks,
> David


From david.holmes at oracle.com  Tue Dec 19 22:32:11 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Dec 2017 08:32:11 +1000
Subject: Trivial RFR: 8193840: Add compiler/c2/Test8007294.java to the
 problem list
In-Reply-To: <db366e39-a0b1-f207-b62f-fd022a079689@oracle.com>
References: <c6f3555c-e4b5-45fa-b0e4-0d6d58002c78@oracle.com>
 <db366e39-a0b1-f207-b62f-fd022a079689@oracle.com>
Message-ID: <87b65f3c-de55-32ab-2098-6fd5877cad76@oracle.com>

Thanks Coleen.

David

On 20/12/2017 8:29 AM, coleen.phillimore at oracle.com wrote:
> Looks good.? Thanks!
> Coleen
> 
> On 12/19/17 5:27 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193840
>> webrev: http://cr.openjdk.java.net/~dholmes/8193840/webrev/
>>
>>
>> --- old/test/hotspot/jtreg/ProblemList.txt??? 2017-12-19 
>> 17:25:19.263976578 -0500
>> +++ new/test/hotspot/jtreg/ProblemList.txt??? 2017-12-19 
>> 17:25:17.091852524 -0500
>> @@ -51,6 +51,7 @@
>> ?compiler/tiered/LevelTransitionTest.java 8067651 generic-all
>> ?compiler/types/correctness/CorrectnessTest.java 8066173 generic-all
>> ?compiler/types/correctness/OffTest.java 8066173 generic-all
>> +compiler/c2/Test8007294.java 8192992 generic-all
>>
>> ?# aot test intermittently failing in jprt 8175791
>> ?compiler/aot/DeoptimizationTest.java 8175791 windows-all
>>
>> Thanks,
>> David
> 

From gerald.thornbrugh at oracle.com  Tue Dec 19 22:36:02 2017
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Tue, 19 Dec 2017 15:36:02 -0700
Subject: Trivial RFR: 8193840: Add compiler/c2/Test8007294.java to the
 problem list
In-Reply-To: <c6f3555c-e4b5-45fa-b0e4-0d6d58002c78@oracle.com>
References: <c6f3555c-e4b5-45fa-b0e4-0d6d58002c78@oracle.com>
Message-ID: <1694fa86-6944-bcbb-c8a0-d8385dd12dee@oracle.com>

Hi David,

Your change looks good.

Jerry

> Bug: https://bugs.openjdk.java.net/browse/JDK-8193840
> webrev: http://cr.openjdk.java.net/~dholmes/8193840/webrev/
>
>
> --- old/test/hotspot/jtreg/ProblemList.txt??? 2017-12-19 
> 17:25:19.263976578 -0500
> +++ new/test/hotspot/jtreg/ProblemList.txt??? 2017-12-19 
> 17:25:17.091852524 -0500
> @@ -51,6 +51,7 @@
> ?compiler/tiered/LevelTransitionTest.java 8067651 generic-all
> ?compiler/types/correctness/CorrectnessTest.java 8066173 generic-all
> ?compiler/types/correctness/OffTest.java 8066173 generic-all
> +compiler/c2/Test8007294.java 8192992 generic-all
>
> ?# aot test intermittently failing in jprt 8175791
> ?compiler/aot/DeoptimizationTest.java 8175791 windows-all
>
> Thanks,
> David


From david.holmes at oracle.com  Tue Dec 19 22:56:03 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Dec 2017 08:56:03 +1000
Subject: Trivial RFR: 8193840: Add compiler/c2/Test8007294.java to the
 problem list
In-Reply-To: <1694fa86-6944-bcbb-c8a0-d8385dd12dee@oracle.com>
References: <c6f3555c-e4b5-45fa-b0e4-0d6d58002c78@oracle.com>
 <1694fa86-6944-bcbb-c8a0-d8385dd12dee@oracle.com>
Message-ID: <d1aeb5a3-7e6c-fc1b-1730-01e5b8bed13e@oracle.com>

Thanks Jerry!

But already pushed under trivial rules.

David

On 20/12/2017 8:36 AM, Gerald Thornbrugh wrote:
> Hi David,
> 
> Your change looks good.
> 
> Jerry
> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193840
>> webrev: http://cr.openjdk.java.net/~dholmes/8193840/webrev/
>>
>>
>> --- old/test/hotspot/jtreg/ProblemList.txt??? 2017-12-19 
>> 17:25:19.263976578 -0500
>> +++ new/test/hotspot/jtreg/ProblemList.txt??? 2017-12-19 
>> 17:25:17.091852524 -0500
>> @@ -51,6 +51,7 @@
>> ?compiler/tiered/LevelTransitionTest.java 8067651 generic-all
>> ?compiler/types/correctness/CorrectnessTest.java 8066173 generic-all
>> ?compiler/types/correctness/OffTest.java 8066173 generic-all
>> +compiler/c2/Test8007294.java 8192992 generic-all
>>
>> ?# aot test intermittently failing in jprt 8175791
>> ?compiler/aot/DeoptimizationTest.java 8175791 windows-all
>>
>> Thanks,
>> David
> 

From jcbeyler at google.com  Wed Dec 20 04:39:45 2017
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 19 Dec 2017 20:39:45 -0800
Subject: RFR 8191985: Tlab refills for ARM
In-Reply-To: <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>
References: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
 <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>
Message-ID: <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>

Hi all,

Thanks Robbin for the eye-balling.

I did update the webrev to here:
http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.01/

Let me know what you think,
Jc

On Tue, Dec 19, 2017 at 2:24 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
> Hi JC,
>
> We do not longer have the ability to build and test arm32. And none seem to
> be picking this port up.
> Only eyeballing this to looks good!
>
> /Robbin
>
>
> On 2017-12-14 17:08, JC Beyler wrote:
>>
>> Hi all,
>>
>> The TLAB and the inline contiguous allocations handling are different
>> for each architecture. On certain architectures, TLAB is never
>> actually never refilled (ref:
>> https://bugs.openjdk.java.net/browse/JDK-8190862).
>>
>> The idea behind the implementation for Arm is the same as for
>> Sparc/X86/Aarch64 and is to do one thing:
>>    - separate TLAB usage to contiguous allocations in eden space.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191985
>> WebRev: http://cr.openjdk.java.net/~rasbold/8191985/webrev.03/
>>
>> Does anyone see any issues with this webrev? Could someone test/verify
>> it please?
>>
>> Thanks for your help,
>> Jc
>>
>

From jcbeyler at google.com  Wed Dec 20 04:42:34 2017
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 19 Dec 2017 20:42:34 -0800
Subject: RFR 8191986: TLAB refills for Aarch64
In-Reply-To: <CAF9BGBzRE54D96UYE9h59u26U7bqWtSkcWjiHo9--C+vRXeokg@mail.gmail.com>
References: <CAF9BGBzHQWYiAmHLkuXhMyu_Dugbwb6vxVcXPaD5DEdwshTJgg@mail.gmail.com>
 <57ccf60c-cfb9-d6c4-2b9b-4d1a840a290c@bell-sw.com>
 <3d01c3d3-fbf6-1ae3-61c8-840a394133c5@redhat.com>
 <04ada3f4-6fab-5323-d60b-74cda30862c4@bell-sw.com>
 <CAF9BGBzRE54D96UYE9h59u26U7bqWtSkcWjiHo9--C+vRXeokg@mail.gmail.com>
Message-ID: <CAF9BGByvCpnV7GjN_wT_0hsVr0d2MC6S8EpyLa=4f79tPr4WLg@mail.gmail.com>

Hi,

I moved the webrev to here:
http://cr.openjdk.java.net/~jcbeyler/8191986/webrev.01/

Let me know if there are any issues there,
Jc


On Fri, Dec 15, 2017 at 7:52 AM, JC Beyler <jcbeyler at google.com> wrote:
> Thanks all for testing it :)
> Jc
>
> On Fri, Dec 15, 2017 at 7:19 AM, Dmitry Samersov
> <dmitry.samersoff at bell-sw.com> wrote:
>> Andrew,
>>
>>> No need -- I have already done so and it is fine.
>>
>> Thank you.
>>
>> The fix looks good to me as well.
>>
>> -Dmitry
>>
>>
>> On 15.12.2017 17:58, Andrew Dinn wrote:
>>> On 15/12/17 14:54, Dmitry Samersov wrote:
>>>> JC Beyler,
>>>>
>>>> I'll test the fix.
>>> No need -- I have already done so and it is fine.
>>>
>>> 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 jcbeyler at google.com  Wed Dec 20 04:43:29 2017
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 19 Dec 2017 20:43:29 -0800
Subject: TLAB Refills for x86
In-Reply-To: <1513268142.2416.4.camel@oracle.com>
References: <c3304685625d485c96f1ae3cc4c0a430@sap.com>
 <CAF9BGByvGg-GWcq01MAShPPj9phbUWSB6FQgYzdzjYZKrxVyrQ@mail.gmail.com>
 <1512990377.2882.9.camel@oracle.com>
 <CAF9BGBys5p+Hc5QMMakQCuEPenXMx7CMQ6=p9nSaEGezyEeuow@mail.gmail.com>
 <1513267701.2416.2.camel@oracle.com>
 <CAF9BGBwo0K5t=KS4a7-XGUs_RCtmgMgH85JrVsBJKzqh-bUDZQ@mail.gmail.com>
 <1513268142.2416.4.camel@oracle.com>
Message-ID: <CAF9BGBxEz=iHFC86PTxHFAnjit17NSxFVSfP=2QJGS1G7khTYA@mail.gmail.com>

Hi all,

I moved the webrev to here:
http://cr.openjdk.java.net/~jcbeyler/8191027/webrev.01/

Let me know if there are any issues,
Jc

On Thu, Dec 14, 2017 at 8:15 AM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> Hi,
>
> On Thu, 2017-12-14 at 08:10 -0800, JC Beyler wrote:
>> Thanks :)
>>
>> Forgot to say that I removed the numbering, the indentation seemed
>> enough and the numbering did make it look confusing... even to me ;-)
>
>  I did notice that :) I agree.
>
> Thomas
>

From jcbeyler at google.com  Wed Dec 20 04:44:16 2017
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 19 Dec 2017 20:44:16 -0800
Subject: RFR 8191989: TLAB Refills for Sparc
In-Reply-To: <1513267668.2416.1.camel@oracle.com>
References: <CAF9BGBzGJrx9eoy8KOe7zXRCX3gQNR-OmbyVs-K8kxi_r=qJtg@mail.gmail.com>
 <1512472098.2454.23.camel@oracle.com>
 <CAF9BGBwL-e+PNO5DjFa8xFVJcEESViryBqj6wK=NOdkW+UOpEw@mail.gmail.com>
 <CAF9BGBy5-ZggYX+PStaTY=NbY6fnn5-STxEwbNgk5WpCHggyKw@mail.gmail.com>
 <1513267668.2416.1.camel@oracle.com>
Message-ID: <CAF9BGBxTYFwGSUg7gUSPaUsBrVkZGfprVbFajuPpxSXW1JFD=A@mail.gmail.com>

Hi,

I updated the webrev to here:
http://cr.openjdk.java.net/~jcbeyler/8191989/webrev.02/

Let me know if there is anything wrong with it :)

Thanks,
Jc

On Thu, Dec 14, 2017 at 8:07 AM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> Hi,
>
> On Thu, 2017-12-14 at 08:05 -0800, JC Beyler wrote:
>> Hi Thomas,
>>
>> I did the same change for sparc here (compared to x86):
>> http://cr.openjdk.java.net/~rasbold/8191989/webrev.03/
>
> I only looked at the comment, which looks good now :)
>
> Thanks,
>   Thomas

From robbin.ehn at oracle.com  Wed Dec 20 07:58:53 2017
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 20 Dec 2017 08:58:53 +0100
Subject: RFR 8191985: Tlab refills for ARM
In-Reply-To: <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>
References: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
 <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>
 <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>
Message-ID: <b429ff80-c8f3-992f-10f1-cdd3b3480e2f@oracle.com>

Hi JC,

Looks good to me.

Can someone else please eyeball this?

/Robbin

On 2017-12-20 05:39, JC Beyler wrote:
> Hi all,
> 
> Thanks Robbin for the eye-balling.
> 
> I did update the webrev to here:
> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.01/
> 
> Let me know what you think,
> Jc
> 
> On Tue, Dec 19, 2017 at 2:24 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>> Hi JC,
>>
>> We do not longer have the ability to build and test arm32. And none seem to
>> be picking this port up.
>> Only eyeballing this to looks good!
>>
>> /Robbin
>>
>>
>> On 2017-12-14 17:08, JC Beyler wrote:
>>>
>>> Hi all,
>>>
>>> The TLAB and the inline contiguous allocations handling are different
>>> for each architecture. On certain architectures, TLAB is never
>>> actually never refilled (ref:
>>> https://bugs.openjdk.java.net/browse/JDK-8190862).
>>>
>>> The idea behind the implementation for Arm is the same as for
>>> Sparc/X86/Aarch64 and is to do one thing:
>>>     - separate TLAB usage to contiguous allocations in eden space.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191985
>>> WebRev: http://cr.openjdk.java.net/~rasbold/8191985/webrev.03/
>>>
>>> Does anyone see any issues with this webrev? Could someone test/verify
>>> it please?
>>>
>>> Thanks for your help,
>>> Jc
>>>
>>

From david.holmes at oracle.com  Wed Dec 20 10:22:36 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Dec 2017 20:22:36 +1000
Subject: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11 for
 JDK 11 and 12 support
Message-ID: <7b8e93f8-e465-ec13-215b-f33c16d29d02@oracle.com>

Before we can update to JDK version 11, jtreg needs to be updated to 
recognize that release value - which is happening in jtreg 4.2 b11. So 
we then need to ensure that jtreg 4.2 b11 is used by updating the 
requiredVersion in each of the TEST.ROOT files, and in the jib 
configuiration.

bug: https://bugs.openjdk.java.net/browse/JDK-8193838
webrev: http://cr.openjdk.java.net/~dholmes/8193838/webrev/

Testing - TBD once b11 is promoted
  - local build using jib
  - hs/jdk tier1 and tier2

Thanks,
David

From Alan.Bateman at oracle.com  Wed Dec 20 10:32:36 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Dec 2017 10:32:36 +0000
Subject: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11
 for JDK 11 and 12 support
In-Reply-To: <7b8e93f8-e465-ec13-215b-f33c16d29d02@oracle.com>
References: <7b8e93f8-e465-ec13-215b-f33c16d29d02@oracle.com>
Message-ID: <7a8316ea-5979-d30b-54fc-b96bffaef2cc@oracle.com>



On 20/12/2017 10:22, David Holmes wrote:
> Before we can update to JDK version 11, jtreg needs to be updated to 
> recognize that release value - which is happening in jtreg 4.2 b11. So 
> we then need to ensure that jtreg 4.2 b11 is used by updating the 
> requiredVersion in each of the TEST.ROOT files, and in the jib 
> configuiration.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8193838
> webrev: http://cr.openjdk.java.net/~dholmes/8193838/webrev/
Looks fine.

From serguei.spitsyn at oracle.com  Wed Dec 20 10:41:47 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 20 Dec 2017 02:41:47 -0800
Subject: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11
 for JDK 11 and 12 support
In-Reply-To: <7b8e93f8-e465-ec13-215b-f33c16d29d02@oracle.com>
References: <7b8e93f8-e465-ec13-215b-f33c16d29d02@oracle.com>
Message-ID: <933a8584-e101-facd-a7ee-21583b546707@oracle.com>

David,

It looks good.

Thanks,
Serguei


On 12/20/17 02:22, David Holmes wrote:
> Before we can update to JDK version 11, jtreg needs to be updated to 
> recognize that release value - which is happening in jtreg 4.2 b11. So 
> we then need to ensure that jtreg 4.2 b11 is used by updating the 
> requiredVersion in each of the TEST.ROOT files, and in the jib 
> configuiration.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8193838
> webrev: http://cr.openjdk.java.net/~dholmes/8193838/webrev/
>
> Testing - TBD once b11 is promoted
> ?- local build using jib
> ?- hs/jdk tier1 and tier2
>
> Thanks,
> David


From david.holmes at oracle.com  Wed Dec 20 12:40:37 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Dec 2017 22:40:37 +1000
Subject: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11
 for JDK 11 and 12 support
In-Reply-To: <7a8316ea-5979-d30b-54fc-b96bffaef2cc@oracle.com>
References: <7b8e93f8-e465-ec13-215b-f33c16d29d02@oracle.com>
 <7a8316ea-5979-d30b-54fc-b96bffaef2cc@oracle.com>
Message-ID: <f83dd131-5d81-d0a4-b531-91f7a1c68dbe@oracle.com>

Thanks Alan.

David

On 20/12/2017 8:32 PM, Alan Bateman wrote:
> 
> 
> On 20/12/2017 10:22, David Holmes wrote:
>> Before we can update to JDK version 11, jtreg needs to be updated to 
>> recognize that release value - which is happening in jtreg 4.2 b11. So 
>> we then need to ensure that jtreg 4.2 b11 is used by updating the 
>> requiredVersion in each of the TEST.ROOT files, and in the jib 
>> configuiration.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8193838
>> webrev: http://cr.openjdk.java.net/~dholmes/8193838/webrev/
> Looks fine.

From david.holmes at oracle.com  Wed Dec 20 12:40:56 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 20 Dec 2017 22:40:56 +1000
Subject: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11
 for JDK 11 and 12 support
In-Reply-To: <933a8584-e101-facd-a7ee-21583b546707@oracle.com>
References: <7b8e93f8-e465-ec13-215b-f33c16d29d02@oracle.com>
 <933a8584-e101-facd-a7ee-21583b546707@oracle.com>
Message-ID: <6c438b05-1e97-f4da-b364-560af7939aaf@oracle.com>

Thanks Serguei!

David

On 20/12/2017 8:41 PM, serguei.spitsyn at oracle.com wrote:
> David,
> 
> It looks good.
> 
> Thanks,
> Serguei
> 
> 
> On 12/20/17 02:22, David Holmes wrote:
>> Before we can update to JDK version 11, jtreg needs to be updated to 
>> recognize that release value - which is happening in jtreg 4.2 b11. So 
>> we then need to ensure that jtreg 4.2 b11 is used by updating the 
>> requiredVersion in each of the TEST.ROOT files, and in the jib 
>> configuiration.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8193838
>> webrev: http://cr.openjdk.java.net/~dholmes/8193838/webrev/
>>
>> Testing - TBD once b11 is promoted
>> ?- local build using jib
>> ?- hs/jdk tier1 and tier2
>>
>> Thanks,
>> David
> 

From edward.nevill at gmail.com  Wed Dec 20 13:21:15 2017
From: edward.nevill at gmail.com (Edward Nevill)
Date: Wed, 20 Dec 2017 13:21:15 +0000
Subject: RFR 8191985: Tlab refills for ARM
In-Reply-To: <b429ff80-c8f3-992f-10f1-cdd3b3480e2f@oracle.com>
References: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
 <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>
 <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>
 <b429ff80-c8f3-992f-10f1-cdd3b3480e2f@oracle.com>
Message-ID: <1513776075.2757.7.camel@gmail.com>

Hi Robin,

I have eyeballed this, comparing it against the x86 version, and it looks good to me.

I'll try to build and test this, but it will probably be sometime between Christmas and New Year.

Just to confirm, the repo I should be patching and building is the following?

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

Thanks,
Ed.

On Wed, 2017-12-20 at 08:58 +0100, Robbin Ehn wrote:
> Hi JC,
> 
> Looks good to me.
> 
> Can someone else please eyeball this?
> 
> /Robbin
> 
On 2017-12-20 05:39, JC Beyler wrote:
> 
> Hi all,
> 
> Thanks Robbin for the eye-balling.
> 
> I did update the webrev to here:
> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.01/
> 
> Let me know what you think,
> Jc
> 
> > > > 

From dmitry.samersoff at bell-sw.com  Wed Dec 20 13:27:30 2017
From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff)
Date: Wed, 20 Dec 2017 16:27:30 +0300
Subject: RFR 8191985: Tlab refills for ARM
In-Reply-To: <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>
References: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
 <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>
 <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>
Message-ID: <768e6810-8b01-6f09-8464-e37c0d8ae4ee@bell-sw.com>

JC Beyler,

Looks good to me.

But I didn't test it.

-Dmitry

On 12/20/2017 07:39 AM, JC Beyler wrote:
> Hi all,
> 
> Thanks Robbin for the eye-balling.
> 
> I did update the webrev to here:
> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.01/
> 
> Let me know what you think,
> Jc
> 
> On Tue, Dec 19, 2017 at 2:24 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>> Hi JC,
>>
>> We do not longer have the ability to build and test arm32. And none seem to
>> be picking this port up.
>> Only eyeballing this to looks good!
>>
>> /Robbin
>>
>>
>> On 2017-12-14 17:08, JC Beyler wrote:
>>>
>>> Hi all,
>>>
>>> The TLAB and the inline contiguous allocations handling are different
>>> for each architecture. On certain architectures, TLAB is never
>>> actually never refilled (ref:
>>> https://bugs.openjdk.java.net/browse/JDK-8190862).
>>>
>>> The idea behind the implementation for Arm is the same as for
>>> Sparc/X86/Aarch64 and is to do one thing:
>>>    - separate TLAB usage to contiguous allocations in eden space.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191985
>>> WebRev: http://cr.openjdk.java.net/~rasbold/8191985/webrev.03/
>>>
>>> Does anyone see any issues with this webrev? Could someone test/verify
>>> it please?
>>>
>>> Thanks for your help,
>>> Jc
>>>
>>


From daniel.daugherty at oracle.com  Wed Dec 20 13:50:33 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 20 Dec 2017 08:50:33 -0500
Subject: RFR 8191985: Tlab refills for ARM
In-Reply-To: <1513776075.2757.7.camel@gmail.com>
References: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
 <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>
 <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>
 <b429ff80-c8f3-992f-10f1-cdd3b3480e2f@oracle.com>
 <1513776075.2757.7.camel@gmail.com>
Message-ID: <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com>

On 12/20/17 8:21 AM, Edward Nevill wrote:
> Hi Robin,
>
> I have eyeballed this, comparing it against the x86 version, and it looks good to me.
>
> I'll try to build and test this, but it will probably be sometime between Christmas and New Year.
>
> Just to confirm, the repo I should be patching and building is the following?
>
> http://hg.openjdk.java.net/jdk/jdk

The webrev shows this line:

 > Compare against:??? http://hg.openjdk.java.net/jdk10/hs

but that repo is stale with the creation of:

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

and

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

I recommend HotSpot changes be made relative to

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

Dan

>
> Thanks,
> Ed.
>
> On Wed, 2017-12-20 at 08:58 +0100, Robbin Ehn wrote:
>> Hi JC,
>>
>> Looks good to me.
>>
>> Can someone else please eyeball this?
>>
>> /Robbin
>>
> On 2017-12-20 05:39, JC Beyler wrote:
>> Hi all,
>>
>> Thanks Robbin for the eye-balling.
>>
>> I did update the webrev to here:
>> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.01/
>>
>> Let me know what you think,
>> Jc
>>


From jcbeyler at google.com  Wed Dec 20 17:06:15 2017
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 20 Dec 2017 09:06:15 -0800
Subject: RFR 8191985: Tlab refills for ARM
In-Reply-To: <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com>
References: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
 <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>
 <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>
 <b429ff80-c8f3-992f-10f1-cdd3b3480e2f@oracle.com>
 <1513776075.2757.7.camel@gmail.com>
 <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com>
Message-ID: <CAF9BGBzeMOokcQB_JHdw4FAzGYjBJLStnEkjDQFfkWDF-X9xeQ@mail.gmail.com>

Hi all,

Thanks for taking a look at the webrev!

Here is the change relative to jdk/hs:
http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/

Let me know what you think, hopefully I didn't make a mistake when
making the webrev :)
Jc


On Wed, Dec 20, 2017 at 5:50 AM, Daniel D. Daugherty
<daniel.daugherty at oracle.com> wrote:
> On 12/20/17 8:21 AM, Edward Nevill wrote:
>>
>> Hi Robin,
>>
>> I have eyeballed this, comparing it against the x86 version, and it looks
>> good to me.
>>
>> I'll try to build and test this, but it will probably be sometime between
>> Christmas and New Year.
>>
>> Just to confirm, the repo I should be patching and building is the
>> following?
>>
>> http://hg.openjdk.java.net/jdk/jdk
>
>
> The webrev shows this line:
>
>> Compare against:    http://hg.openjdk.java.net/jdk10/hs
>
> but that repo is stale with the creation of:
>
> http://hg.openjdk.java.net/jdk/jdk
>
> and
>
> http://hg.openjdk.java.net/jdk/hs
>
> I recommend HotSpot changes be made relative to
>
> http://hg.openjdk.java.net/jdk/hs
>
> Dan
>
>
>>
>> Thanks,
>> Ed.
>>
>> On Wed, 2017-12-20 at 08:58 +0100, Robbin Ehn wrote:
>>>
>>> Hi JC,
>>>
>>> Looks good to me.
>>>
>>> Can someone else please eyeball this?
>>>
>>> /Robbin
>>>
>> On 2017-12-20 05:39, JC Beyler wrote:
>>>
>>> Hi all,
>>>
>>> Thanks Robbin for the eye-balling.
>>>
>>> I did update the webrev to here:
>>> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.01/
>>>
>>> Let me know what you think,
>>> Jc
>>>
>

From jcbeyler at google.com  Wed Dec 20 20:30:24 2017
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 20 Dec 2017 12:30:24 -0800
Subject: RFR 8191987: TLAB Refills for PPC64
Message-ID: <CAF9BGBycs9OZ6FfO7ViDc8k44risA_bFV2njPteDLzgAX30n6g@mail.gmail.com>

Hi all,

The TLAB and the inline contiguous allocations handling are different
for each architecture. On certain architectures, TLAB is never
actually never refilled (ref:
https://bugs.openjdk.java.net/browse/JDK-8190862).

The PPC patch really only removes the code that augments the TLAB
waste limit since that is already done in the common code slow path.

Due to a double jump, there is an additional change to have code from
SkipIfEqualZero available so that we don't have to manually generate
that code in the template code.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191987
WebRev: http://cr.openjdk.java.net/~rasbold/8191987/webrev.03/

Let me know what you think and if someone could test/verify it, that
would be great.

Thanks for your help,
Jc

From jcbeyler at google.com  Wed Dec 20 20:33:30 2017
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 20 Dec 2017 12:33:30 -0800
Subject: RFR 8191988: TLAB Refills for S390
Message-ID: <CAF9BGBxoT6a8CijL_c9oK-gRLWYgczFjOhzatfuiyXC9Jm5y_Q@mail.gmail.com>

Hi all,

The TLAB and the inline contiguous allocations handling are different
for each architecture. On certain architectures, TLAB is never
actually never refilled (ref:
https://bugs.openjdk.java.net/browse/JDK-8190862).

The S390 patch is a cleanup code webrev, it used to set the
allow_shared_alloc variable to false and then left code there. This
cleans it up and simplifies that code path.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191988
WebRev: http://cr.openjdk.java.net/~rasbold/8191988/webrev.02/

Let me know what you think and if someone could test/verify it, that
would be great.

Thanks for your help,
Jc

From glaubitz at physik.fu-berlin.de  Wed Dec 20 20:49:29 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 20 Dec 2017 21:49:29 +0100
Subject: RFR 8191988: TLAB Refills for S390
In-Reply-To: <CAF9BGBxoT6a8CijL_c9oK-gRLWYgczFjOhzatfuiyXC9Jm5y_Q@mail.gmail.com>
References: <CAF9BGBxoT6a8CijL_c9oK-gRLWYgczFjOhzatfuiyXC9Jm5y_Q@mail.gmail.com>
Message-ID: <ffb3c0ff-4b68-0da7-9090-06a85d92542f@physik.fu-berlin.de>

Hi JC!

On 12/20/2017 09:33 PM, JC Beyler wrote:
> WebRev: http://cr.openjdk.java.net/~rasbold/8191988/webrev.02/

This URL 404s. Did you mean: http://cr.openjdk.java.net/~rasbold/8191988/webrev.01/ ?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From jcbeyler at google.com  Wed Dec 20 21:03:56 2017
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 20 Dec 2017 13:03:56 -0800
Subject: RFR 8191988: TLAB Refills for S390
In-Reply-To: <ffb3c0ff-4b68-0da7-9090-06a85d92542f@physik.fu-berlin.de>
References: <CAF9BGBxoT6a8CijL_c9oK-gRLWYgczFjOhzatfuiyXC9Jm5y_Q@mail.gmail.com>
 <ffb3c0ff-4b68-0da7-9090-06a85d92542f@physik.fu-berlin.de>
Message-ID: <CAF9BGByzfKU8yM_bdO3zP8aj-Q6rWXbp4nU_z1QbFzs=GgndnQ@mail.gmail.com>

Sorry, I went too fast:

WebRev: http://cr.openjdk.java.net/~jcbeyler/8191988/webrev.02/

Thanks!
Jc

2017-12-20 12:49 GMT-08:00 John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de>:
> Hi JC!
>
> On 12/20/2017 09:33 PM, JC Beyler wrote:
>> WebRev: http://cr.openjdk.java.net/~rasbold/8191988/webrev.02/
>
> This URL 404s. Did you mean: http://cr.openjdk.java.net/~rasbold/8191988/webrev.01/ ?
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From jcbeyler at google.com  Wed Dec 20 21:04:18 2017
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 20 Dec 2017 13:04:18 -0800
Subject: RFR 8191987: TLAB Refills for PPC64
In-Reply-To: <CAF9BGBycs9OZ6FfO7ViDc8k44risA_bFV2njPteDLzgAX30n6g@mail.gmail.com>
References: <CAF9BGBycs9OZ6FfO7ViDc8k44risA_bFV2njPteDLzgAX30n6g@mail.gmail.com>
Message-ID: <CAF9BGBwWCTs6VhwGFGBJfkE8txd+n0d3xesnisMHaKEqK6Yp=A@mail.gmail.com>

Please see the updated webrev :)


WebRev: http://cr.openjdk.java.net/~jcbeyler/8191987/webrev.03/

On Wed, Dec 20, 2017 at 12:30 PM, JC Beyler <jcbeyler at google.com> wrote:
> Hi all,
>
> The TLAB and the inline contiguous allocations handling are different
> for each architecture. On certain architectures, TLAB is never
> actually never refilled (ref:
> https://bugs.openjdk.java.net/browse/JDK-8190862).
>
> The PPC patch really only removes the code that augments the TLAB
> waste limit since that is already done in the common code slow path.
>
> Due to a double jump, there is an additional change to have code from
> SkipIfEqualZero available so that we don't have to manually generate
> that code in the template code.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191987
> WebRev: http://cr.openjdk.java.net/~rasbold/8191987/webrev.03/
>
> Let me know what you think and if someone could test/verify it, that
> would be great.
>
> Thanks for your help,
> Jc

From erik.joelsson at oracle.com  Thu Dec 21 10:15:11 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 21 Dec 2017 11:15:11 +0100
Subject: Another question, if I may?
In-Reply-To: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com>
References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com>
Message-ID: <bfc85d29-6ab7-c598-8ac1-4ac8643edda1@oracle.com>

Adding hotspot-dev.

/Erik


On 2017-12-21 10:43, Ted Neward wrote:
> What?s the steps necessary to add a new -XX flag? I?d assumed (naively) that all that was required was to add it to the list of macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets kicked back out with the ?Unrecognized flag; did you mean??? error.
>
>   
>
> Is there something I?m missing? Does the flag need to be registered someplace else as well?
>
>   
>
> Ted Neward
>
> Author, Speaker, Mentor
>
> http://www.newardassociates.com
>
> t: @tedneward | m: (425) 647-4526
>


From david.holmes at oracle.com  Thu Dec 21 12:20:47 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 21 Dec 2017 22:20:47 +1000
Subject: Another question, if I may?
In-Reply-To: <bfc85d29-6ab7-c598-8ac1-4ac8643edda1@oracle.com>
References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com>
 <bfc85d29-6ab7-c598-8ac1-4ac8643edda1@oracle.com>
Message-ID: <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com>

On 21/12/2017 8:15 PM, Erik Joelsson wrote:
> Adding hotspot-dev.
> 
> /Erik
> 
> 
> On 2017-12-21 10:43, Ted Neward wrote:
>> What?s the steps necessary to add a new -XX flag? I?d assumed 
>> (naively) that all that was required was to add it to the list of 
>> macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag 

Yes that should suffice.

>> (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets 
>> kicked back out with the ?Unrecognized flag; did you mean??? error.

Why would "make hotspot" be using your new flag? Are you trying to apply 
your flag to the newly built VM during the build process? I'm not even 
sure if "make hotspot" would use the new VM. I always do a full build: 
make images

David

>>
>>
>> Is there something I?m missing? Does the flag need to be registered 
>> someplace else as well?
>>
>>
>> Ted Neward
>>
>> Author, Speaker, Mentor
>>
>> http://www.newardassociates.com
>>
>> t: @tedneward | m: (425) 647-4526
>>
> 

From martin.doerr at sap.com  Thu Dec 21 15:04:50 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 21 Dec 2017 15:04:50 +0000
Subject: RFR 8191988: TLAB Refills for S390
In-Reply-To: <CAF9BGByzfKU8yM_bdO3zP8aj-Q6rWXbp4nU_z1QbFzs=GgndnQ@mail.gmail.com>
References: <CAF9BGBxoT6a8CijL_c9oK-gRLWYgczFjOhzatfuiyXC9Jm5y_Q@mail.gmail.com>
 <ffb3c0ff-4b68-0da7-9090-06a85d92542f@physik.fu-berlin.de>
 <CAF9BGByzfKU8yM_bdO3zP8aj-Q6rWXbp4nU_z1QbFzs=GgndnQ@mail.gmail.com>
Message-ID: <84f8d984974f41688a7a83a70a471ff9@sap.com>

Hi Jc,

reviewed. Looks good.
I can push it together with the PPC change.
 
Thanks and best regards,
Martin


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of JC Beyler
Sent: Mittwoch, 20. Dezember 2017 22:04
To: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
Cc: hotspot-dev at openjdk.java.net
Subject: Re: RFR 8191988: TLAB Refills for S390

Sorry, I went too fast:

WebRev: http://cr.openjdk.java.net/~jcbeyler/8191988/webrev.02/

Thanks!
Jc

2017-12-20 12:49 GMT-08:00 John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de>:
> Hi JC!
>
> On 12/20/2017 09:33 PM, JC Beyler wrote:
>> WebRev: http://cr.openjdk.java.net/~rasbold/8191988/webrev.02/
>
> This URL 404s. Did you mean: http://cr.openjdk.java.net/~rasbold/8191988/webrev.01/ ?
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From martin.doerr at sap.com  Thu Dec 21 15:06:38 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 21 Dec 2017 15:06:38 +0000
Subject: RFR 8191987: TLAB Refills for PPC64
In-Reply-To: <CAF9BGBwWCTs6VhwGFGBJfkE8txd+n0d3xesnisMHaKEqK6Yp=A@mail.gmail.com>
References: <CAF9BGBycs9OZ6FfO7ViDc8k44risA_bFV2njPteDLzgAX30n6g@mail.gmail.com>
 <CAF9BGBwWCTs6VhwGFGBJfkE8txd+n0d3xesnisMHaKEqK6Yp=A@mail.gmail.com>
Message-ID: <9de49afc59c645ae9e22726b0ce29c3d@sap.com>

Hi Jc,

excellent. I didn't really like the usage of SkipIfEqualZero in the current code. I prefer your version.
I can push it after we got a 2nd review.

Thanks and best regards,
Martin


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of JC Beyler
Sent: Mittwoch, 20. Dezember 2017 22:04
To: hotspot-dev at openjdk.java.net
Subject: Re: RFR 8191987: TLAB Refills for PPC64

Please see the updated webrev :)


WebRev: http://cr.openjdk.java.net/~jcbeyler/8191987/webrev.03/

On Wed, Dec 20, 2017 at 12:30 PM, JC Beyler <jcbeyler at google.com> wrote:
> Hi all,
>
> The TLAB and the inline contiguous allocations handling are different
> for each architecture. On certain architectures, TLAB is never
> actually never refilled (ref:
> https://bugs.openjdk.java.net/browse/JDK-8190862).
>
> The PPC patch really only removes the code that augments the TLAB
> waste limit since that is already done in the common code slow path.
>
> Due to a double jump, there is an additional change to have code from
> SkipIfEqualZero available so that we don't have to manually generate
> that code in the template code.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191987
> WebRev: http://cr.openjdk.java.net/~rasbold/8191987/webrev.03/
>
> Let me know what you think and if someone could test/verify it, that
> would be great.
>
> Thanks for your help,
> Jc

From goetz.lindenmaier at sap.com  Thu Dec 21 15:27:41 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 21 Dec 2017 15:27:41 +0000
Subject: RFR 8191988: TLAB Refills for S390
In-Reply-To: <84f8d984974f41688a7a83a70a471ff9@sap.com>
References: <CAF9BGBxoT6a8CijL_c9oK-gRLWYgczFjOhzatfuiyXC9Jm5y_Q@mail.gmail.com>
 <ffb3c0ff-4b68-0da7-9090-06a85d92542f@physik.fu-berlin.de>
 <CAF9BGByzfKU8yM_bdO3zP8aj-Q6rWXbp4nU_z1QbFzs=GgndnQ@mail.gmail.com>
 <84f8d984974f41688a7a83a70a471ff9@sap.com>
Message-ID: <3f87572dabd74455ab328fcf978dd453@sap.com>

Hi, 

thanks for doing this, especially as it fixes compiler/memoryinitialization/ZeroTLABTest.java.
Therefore this one might be a candidate to push to 10.

Looks good.

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Doerr, Martin
> Sent: Donnerstag, 21. Dezember 2017 16:05
> To: JC Beyler <jcbeyler at google.com>; John Paul Adrian Glaubitz
> <glaubitz at physik.fu-berlin.de>
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: RFR 8191988: TLAB Refills for S390
> 
> Hi Jc,
> 
> reviewed. Looks good.
> I can push it together with the PPC change.
> 
> Thanks and best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of JC Beyler
> Sent: Mittwoch, 20. Dezember 2017 22:04
> To: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR 8191988: TLAB Refills for S390
> 
> Sorry, I went too fast:
> 
> WebRev: http://cr.openjdk.java.net/~jcbeyler/8191988/webrev.02/
> 
> Thanks!
> Jc
> 
> 2017-12-20 12:49 GMT-08:00 John Paul Adrian Glaubitz
> <glaubitz at physik.fu-berlin.de>:
> > Hi JC!
> >
> > On 12/20/2017 09:33 PM, JC Beyler wrote:
> >> WebRev: http://cr.openjdk.java.net/~rasbold/8191988/webrev.02/
> >
> > This URL 404s. Did you mean:
> http://cr.openjdk.java.net/~rasbold/8191988/webrev.01/ ?
> >
> > Adrian
> >
> > --
> >  .''`.  John Paul Adrian Glaubitz
> > : :' :  Debian Developer - glaubitz at debian.org
> > `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> >   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From goetz.lindenmaier at sap.com  Thu Dec 21 15:31:38 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 21 Dec 2017 15:31:38 +0000
Subject: RFR 8191987: TLAB Refills for PPC64
In-Reply-To: <9de49afc59c645ae9e22726b0ce29c3d@sap.com>
References: <CAF9BGBycs9OZ6FfO7ViDc8k44risA_bFV2njPteDLzgAX30n6g@mail.gmail.com>
 <CAF9BGBwWCTs6VhwGFGBJfkE8txd+n0d3xesnisMHaKEqK6Yp=A@mail.gmail.com>
 <9de49afc59c645ae9e22726b0ce29c3d@sap.com>
Message-ID: <04d220f336d14f1e8d1653711f89726d@sap.com>

Looks good, thanks for the cleanup.

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Doerr, Martin
> Sent: Donnerstag, 21. Dezember 2017 16:07
> To: JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
> Subject: RE: RFR 8191987: TLAB Refills for PPC64
> 
> Hi Jc,
> 
> excellent. I didn't really like the usage of SkipIfEqualZero in the current code.
> I prefer your version.
> I can push it after we got a 2nd review.
> 
> Thanks and best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of JC Beyler
> Sent: Mittwoch, 20. Dezember 2017 22:04
> To: hotspot-dev at openjdk.java.net
> Subject: Re: RFR 8191987: TLAB Refills for PPC64
> 
> Please see the updated webrev :)
> 
> 
> WebRev: http://cr.openjdk.java.net/~jcbeyler/8191987/webrev.03/
> 
> On Wed, Dec 20, 2017 at 12:30 PM, JC Beyler <jcbeyler at google.com> wrote:
> > Hi all,
> >
> > The TLAB and the inline contiguous allocations handling are different
> > for each architecture. On certain architectures, TLAB is never
> > actually never refilled (ref:
> > https://bugs.openjdk.java.net/browse/JDK-8190862).
> >
> > The PPC patch really only removes the code that augments the TLAB
> > waste limit since that is already done in the common code slow path.
> >
> > Due to a double jump, there is an additional change to have code from
> > SkipIfEqualZero available so that we don't have to manually generate
> > that code in the template code.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8191987
> > WebRev: http://cr.openjdk.java.net/~rasbold/8191987/webrev.03/
> >
> > Let me know what you think and if someone could test/verify it, that
> > would be great.
> >
> > Thanks for your help,
> > Jc

From glaubitz at physik.fu-berlin.de  Thu Dec 21 16:24:41 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 21 Dec 2017 17:24:41 +0100
Subject: RFR: 8192123: Zero should use compiler built-ins for atomics on
 linux-arm
In-Reply-To: <707713f8-2d2b-f85e-ba8e-d32ee4a16615@redhat.com>
References: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de>
 <707713f8-2d2b-f85e-ba8e-d32ee4a16615@redhat.com>
Message-ID: <0968a94e-d99c-7401-e149-a18b5b57f41b@physik.fu-berlin.de>

Hi Andrew!

On 11/29/2017 04:04 PM, Andrew Haley wrote:
> Hmm.  This doesn't fix a bug, and there's a non-zero probability of
> introducing one.  I guess it should be OK, but this is a combination
> of performance improvement (possibly) and cleanup.

Can you have another look at the change before I can push my commit?

See: http://cr.openjdk.java.net/~glaubitz/8192123/webrev.00/

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From ted at tedneward.com  Thu Dec 21 22:49:06 2017
From: ted at tedneward.com (Ted Neward)
Date: Thu, 21 Dec 2017 14:49:06 -0800
Subject: Another question, if I may?
In-Reply-To: <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com>
References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com>
 <bfc85d29-6ab7-c598-8ac1-4ac8643edda1@oracle.com>
 <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com>
Message-ID: <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com>

What I mean is, I do a "make hotspot", and the resulting change doesn't seem to be recognized when I run the code--doing a "java -XX:+PrintTedMessage -version" yields the "Unrecognized flag" error. (I added a simple fprintf() to part of the JVM startup code to print out the message, just to prove the flag was recognized and parsed.) Does that make more sense? I'm not trying to use the new VM as part of the build process--just add a flag to a VM that I can trigger when I run "java -version".

I would've thought that "make hotspot" would compile the flag into the libjvm.so, and then drop the newly-built libjvm into the image directory, so that I wouldn't have to do a full build. Presumably, then, "make images" checks dependencies and doesn't build stuff that isn't affected by the change? (Otherwise, that would seem like a TON of build time for a fairly minimal change.)

Ted Neward
Author, Speaker, Mentor
http://www.newardassociates.com
t: @tedneward | m: (425) 647-4526

?On 12/21/17, 4:20 AM, "David Holmes" <david.holmes at oracle.com> wrote:

    On 21/12/2017 8:15 PM, Erik Joelsson wrote:
    > Adding hotspot-dev.
    > 
    > /Erik
    > 
    > 
    > On 2017-12-21 10:43, Ted Neward wrote:
    >> What?s the steps necessary to add a new -XX flag? I?d assumed 
    >> (naively) that all that was required was to add it to the list of 
    >> macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag 
    
    Yes that should suffice.
    
    >> (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets 
    >> kicked back out with the ?Unrecognized flag; did you mean??? error.
    
    Why would "make hotspot" be using your new flag? Are you trying to apply 
    your flag to the newly built VM during the build process? I'm not even 
    sure if "make hotspot" would use the new VM. I always do a full build: 
    make images
    
    David
    
    >>
    >>
    >> Is there something I?m missing? Does the flag need to be registered 
    >> someplace else as well?
    >>
    >>
    >> Ted Neward
    >>
    >> Author, Speaker, Mentor
    >>
    >> http://www.newardassociates.com
    >>
    >> t: @tedneward | m: (425) 647-4526
    >>
    > 
    



From david.holmes at oracle.com  Fri Dec 22 00:06:34 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Dec 2017 10:06:34 +1000
Subject: Another question, if I may?
In-Reply-To: <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com>
References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com>
 <bfc85d29-6ab7-c598-8ac1-4ac8643edda1@oracle.com>
 <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com>
 <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com>
Message-ID: <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com>

On 22/12/2017 8:49 AM, Ted Neward wrote:
> What I mean is, I do a "make hotspot", and the resulting change doesn't seem to be recognized when I run the code--doing a "java -XX:+PrintTedMessage -version" yields the "Unrecognized flag" error. (I added a simple fprintf() to part of the JVM startup code to print out the message, just to prove the flag was recognized and parsed.) Does that make more sense? I'm not trying to use the new VM as part of the build process--just add a flag to a VM that I can trigger when I run "java -version".
> 
> I would've thought that "make hotspot" would compile the flag into the libjvm.so, and then drop the newly-built libjvm into the image directory, so that I wouldn't have to do a full build. Presumably, then, "make images" checks dependencies and doesn't build stuff that isn't affected by the change? (Otherwise, that would seem like a TON of build time for a fairly minimal change.)

"make hotspot" won't update the image, you need to "make images" for that.

Assuming you're building 9+ then when you change libjvm.so the module 
needs to be rebuilt etc.

Or you can work from the exploded build the contents of e.g.

  build/linux-x64-debug/jdk/

though you still need a full build to prime that. But after that "make 
hotspot" should suffice. (Erik correct me if I'm wrong here please.)

BTW there are three preexisting diagnostic flags that can be used to 
avoid adding your own: UseNewCode, UseNewCode2, UseNewCode3

HTH,
David

> Ted Neward
> Author, Speaker, Mentor
> http://www.newardassociates.com
> t: @tedneward | m: (425) 647-4526
> 
> ?On 12/21/17, 4:20 AM, "David Holmes" <david.holmes at oracle.com> wrote:
> 
>      On 21/12/2017 8:15 PM, Erik Joelsson wrote:
>      > Adding hotspot-dev.
>      >
>      > /Erik
>      >
>      >
>      > On 2017-12-21 10:43, Ted Neward wrote:
>      >> What?s the steps necessary to add a new -XX flag? I?d assumed
>      >> (naively) that all that was required was to add it to the list of
>      >> macro?ed flags in hotspot/share/runtime/globals.hpp, but my new flag
>      
>      Yes that should suffice.
>      
>      >> (?PrintTedMessage?) isn?t recognized when I ?make hotspot?; it gets
>      >> kicked back out with the ?Unrecognized flag; did you mean??? error.
>      
>      Why would "make hotspot" be using your new flag? Are you trying to apply
>      your flag to the newly built VM during the build process? I'm not even
>      sure if "make hotspot" would use the new VM. I always do a full build:
>      make images
>      
>      David
>      
>      >>
>      >>
>      >> Is there something I?m missing? Does the flag need to be registered
>      >> someplace else as well?
>      >>
>      >>
>      >> Ted Neward
>      >>
>      >> Author, Speaker, Mentor
>      >>
>      >> http://www.newardassociates.com
>      >>
>      >> t: @tedneward | m: (425) 647-4526
>      >>
>      >
>      
> 
> 

From david.buck at oracle.com  Fri Dec 22 06:19:37 2017
From: david.buck at oracle.com (David Buck)
Date: Fri, 22 Dec 2017 15:19:37 +0900
Subject: [8u] RFR(S) 8044107 : Add Diagnostic Command to list all ClassLoaders
Message-ID: <30338e73-69c2-98c8-ac11-f3ed3913ec28@oracle.com>

Hi!

Please review this very simple serviceability backport to 8u. The only 
difference between the JDK 9 changeset and the JDK 8 changeset is that 
the ClassLoaderDataGraph::cld_do function was already backported to JDK 
8 in the fix for 8049421 [0]. So the changes for adding 
classLoaderData.hpp|cpp are already in JDK 8 line-for-line exactly the 
same as they are in JDK 9.

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

JDK 9 changeset:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/56a35b09e0d4

JDK 9 code review thread
May 2014: 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/014072.html
June 2014: 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014127.html

JDK 8 webrev for review:
http://cr.openjdk.java.net/~dbuck/8044107_jdk8_ver00/

Testing:
JPRT (hotspot testset)
jtreg test included in changeset
manually confirmed new diagnostic command works as expected

Cheers,
-Buck

[0] http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/2c6ef90f030a

From david.holmes at oracle.com  Fri Dec 22 08:10:51 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 22 Dec 2017 18:10:51 +1000
Subject: [8u] RFR(S) 8044107 : Add Diagnostic Command to list all
 ClassLoaders
In-Reply-To: <30338e73-69c2-98c8-ac11-f3ed3913ec28@oracle.com>
References: <30338e73-69c2-98c8-ac11-f3ed3913ec28@oracle.com>
Message-ID: <c6c43000-9e5c-e767-f3f9-43554cf0bb73@oracle.com>

This looks like an accurate backport to me.

Thanks,
David

On 22/12/2017 4:19 PM, David Buck wrote:
> Hi!
> 
> Please review this very simple serviceability backport to 8u. The only 
> difference between the JDK 9 changeset and the JDK 8 changeset is that 
> the ClassLoaderDataGraph::cld_do function was already backported to JDK 
> 8 in the fix for 8049421 [0]. So the changes for adding 
> classLoaderData.hpp|cpp are already in JDK 8 line-for-line exactly the 
> same as they are in JDK 9.
> 
> bug report:
> https://bugs.openjdk.java.net/browse/JDK-8044107
> 
> JDK 9 changeset:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/56a35b09e0d4
> 
> JDK 9 code review thread
> May 2014: 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/014072.html
> June 2014: 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014127.html
> 
> JDK 8 webrev for review:
> http://cr.openjdk.java.net/~dbuck/8044107_jdk8_ver00/
> 
> Testing:
> JPRT (hotspot testset)
> jtreg test included in changeset
> manually confirmed new diagnostic command works as expected
> 
> Cheers,
> -Buck
> 
> [0] http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/2c6ef90f030a

From erik.joelsson at oracle.com  Fri Dec 22 08:32:03 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 22 Dec 2017 09:32:03 +0100
Subject: Another question, if I may?
In-Reply-To: <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com>
References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com>
 <bfc85d29-6ab7-c598-8ac1-4ac8643edda1@oracle.com>
 <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com>
 <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com>
 <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com>
Message-ID: <385762d8-6714-29d9-0082-0316ddb2f0ff@oracle.com>



On 2017-12-22 01:06, David Holmes wrote:
>
> "make hotspot" won't update the image, you need to "make images" for 
> that.
>
> Assuming you're building 9+ then when you change libjvm.so the module 
> needs to be rebuilt etc.
>
> Or you can work from the exploded build the contents of e.g.
>
> ?build/linux-x64-debug/jdk/
>
> though you still need a full build to prime that. But after that "make 
> hotspot" should suffice. (Erik correct me if I'm wrong here please.)
This is correct. Using the exploded image as described is the shortcut 
we have. The actual images are always built using jmod/jlink and yes, 
that requires quite a bit of extra build time.

If you are in JDK 8, you need to run "make jdk" to get the exploded 
image updated with the new libjvm.so.

/Erik

From martin.doerr at sap.com  Fri Dec 22 11:01:06 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 22 Dec 2017 11:01:06 +0000
Subject: RFR 8191988: TLAB Refills for S390
In-Reply-To: <3f87572dabd74455ab328fcf978dd453@sap.com>
References: <CAF9BGBxoT6a8CijL_c9oK-gRLWYgczFjOhzatfuiyXC9Jm5y_Q@mail.gmail.com>
 <ffb3c0ff-4b68-0da7-9090-06a85d92542f@physik.fu-berlin.de>
 <CAF9BGByzfKU8yM_bdO3zP8aj-Q6rWXbp4nU_z1QbFzs=GgndnQ@mail.gmail.com>
 <84f8d984974f41688a7a83a70a471ff9@sap.com>
 <3f87572dabd74455ab328fcf978dd453@sap.com>
Message-ID: <25a44ab234604b8aa58d9cc84549a2ee@sap.com>

Hi all,

I have changed priority to P3 and pushed it to jdk10 because it fixes ZeroTLAB. It will get merged into hs, later.

Thanks everyone and best regards,
Martin


-----Original Message-----
From: Lindenmaier, Goetz 
Sent: Donnerstag, 21. Dezember 2017 16:28
To: Doerr, Martin <martin.doerr at sap.com>; JC Beyler <jcbeyler at google.com>; John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
Cc: hotspot-dev at openjdk.java.net
Subject: RE: RFR 8191988: TLAB Refills for S390

Hi, 

thanks for doing this, especially as it fixes compiler/memoryinitialization/ZeroTLABTest.java.
Therefore this one might be a candidate to push to 10.

Looks good.

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Doerr, Martin
> Sent: Donnerstag, 21. Dezember 2017 16:05
> To: JC Beyler <jcbeyler at google.com>; John Paul Adrian Glaubitz
> <glaubitz at physik.fu-berlin.de>
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: RFR 8191988: TLAB Refills for S390
> 
> Hi Jc,
> 
> reviewed. Looks good.
> I can push it together with the PPC change.
> 
> Thanks and best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of JC Beyler
> Sent: Mittwoch, 20. Dezember 2017 22:04
> To: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR 8191988: TLAB Refills for S390
> 
> Sorry, I went too fast:
> 
> WebRev: http://cr.openjdk.java.net/~jcbeyler/8191988/webrev.02/
> 
> Thanks!
> Jc
> 
> 2017-12-20 12:49 GMT-08:00 John Paul Adrian Glaubitz
> <glaubitz at physik.fu-berlin.de>:
> > Hi JC!
> >
> > On 12/20/2017 09:33 PM, JC Beyler wrote:
> >> WebRev: http://cr.openjdk.java.net/~rasbold/8191988/webrev.02/
> >
> > This URL 404s. Did you mean:
> http://cr.openjdk.java.net/~rasbold/8191988/webrev.01/ ?
> >
> > Adrian
> >
> > --
> >  .''`.  John Paul Adrian Glaubitz
> > : :' :  Debian Developer - glaubitz at debian.org
> > `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> >   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From martin.doerr at sap.com  Fri Dec 22 11:03:04 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 22 Dec 2017 11:03:04 +0000
Subject: RFR 8191987: TLAB Refills for PPC64
In-Reply-To: <04d220f336d14f1e8d1653711f89726d@sap.com>
References: <CAF9BGBycs9OZ6FfO7ViDc8k44risA_bFV2njPteDLzgAX30n6g@mail.gmail.com>
 <CAF9BGBwWCTs6VhwGFGBJfkE8txd+n0d3xesnisMHaKEqK6Yp=A@mail.gmail.com>
 <9de49afc59c645ae9e22726b0ce29c3d@sap.com>
 <04d220f336d14f1e8d1653711f89726d@sap.com>
Message-ID: <05098ecd21624ed58d0cfe4b5ed674bc@sap.com>

Hi all,

pushed to jdk/hs.

Thanks everyone and best regards,
Martin


-----Original Message-----
From: Lindenmaier, Goetz 
Sent: Donnerstag, 21. Dezember 2017 16:32
To: Doerr, Martin <martin.doerr at sap.com>; JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
Subject: RE: RFR 8191987: TLAB Refills for PPC64

Looks good, thanks for the cleanup.

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Doerr, Martin
> Sent: Donnerstag, 21. Dezember 2017 16:07
> To: JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
> Subject: RE: RFR 8191987: TLAB Refills for PPC64
> 
> Hi Jc,
> 
> excellent. I didn't really like the usage of SkipIfEqualZero in the current code.
> I prefer your version.
> I can push it after we got a 2nd review.
> 
> Thanks and best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of JC Beyler
> Sent: Mittwoch, 20. Dezember 2017 22:04
> To: hotspot-dev at openjdk.java.net
> Subject: Re: RFR 8191987: TLAB Refills for PPC64
> 
> Please see the updated webrev :)
> 
> 
> WebRev: http://cr.openjdk.java.net/~jcbeyler/8191987/webrev.03/
> 
> On Wed, Dec 20, 2017 at 12:30 PM, JC Beyler <jcbeyler at google.com> wrote:
> > Hi all,
> >
> > The TLAB and the inline contiguous allocations handling are different
> > for each architecture. On certain architectures, TLAB is never
> > actually never refilled (ref:
> > https://bugs.openjdk.java.net/browse/JDK-8190862).
> >
> > The PPC patch really only removes the code that augments the TLAB
> > waste limit since that is already done in the common code slow path.
> >
> > Due to a double jump, there is an additional change to have code from
> > SkipIfEqualZero available so that we don't have to manually generate
> > that code in the template code.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8191987
> > WebRev: http://cr.openjdk.java.net/~rasbold/8191987/webrev.03/
> >
> > Let me know what you think and if someone could test/verify it, that
> > would be great.
> >
> > Thanks for your help,
> > Jc

From aph at redhat.com  Fri Dec 22 14:46:35 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 Dec 2017 14:46:35 +0000
Subject: RFR: 8192123: Zero should use compiler built-ins for atomics on
 linux-arm
In-Reply-To: <6991e542-cf59-0930-dd34-fec9ae61727d@oracle.com>
References: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de>
 <707713f8-2d2b-f85e-ba8e-d32ee4a16615@redhat.com>
 <6991e542-cf59-0930-dd34-fec9ae61727d@oracle.com>
Message-ID: <a56224ba-075a-8847-24c8-b707ec8725be@redhat.com>

On 29/11/17 15:39, coleen.phillimore at oracle.com wrote:
> 
> 
> On 11/29/17 10:04 AM, Andrew Haley wrote:
>> On 29/11/17 14:08, John Paul Adrian Glaubitz wrote:
>>> Since the compiler built-ins for cmpxchg() work exactly like the current ARM-specific
>>> implementation in Zero, there is no need anymore to carry our own implementation but
>>> rather rely on gcc which helps simplifying the code.
>>>
>>> I have successfully tested this change in the following targets:
>>>
>>> - Linux ARMv4T
>>> - Linux ARMv7
>>>
>>> My change also removes a single empty line to make the formatting more
>>> consistent. Hope this is ok.
>> Hmm.  This doesn't fix a bug, and there's a non-zero probability of
>> introducing one.  I guess it should be OK, but this is a combination
>> of performance improvement (possibly) and cleanup.
>>
> Please save this change for JDK 11.

It's fine for JDK 11.

-- 
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 jcbeyler at google.com  Fri Dec 22 16:25:57 2017
From: jcbeyler at google.com (JC Beyler)
Date: Fri, 22 Dec 2017 08:25:57 -0800
Subject: RFR 8191987: TLAB Refills for PPC64
In-Reply-To: <05098ecd21624ed58d0cfe4b5ed674bc@sap.com>
References: <CAF9BGBycs9OZ6FfO7ViDc8k44risA_bFV2njPteDLzgAX30n6g@mail.gmail.com>
 <CAF9BGBwWCTs6VhwGFGBJfkE8txd+n0d3xesnisMHaKEqK6Yp=A@mail.gmail.com>
 <9de49afc59c645ae9e22726b0ce29c3d@sap.com>
 <04d220f336d14f1e8d1653711f89726d@sap.com>
 <05098ecd21624ed58d0cfe4b5ed674bc@sap.com>
Message-ID: <CAF9BGBwVQQ2A7xeyY8OeCV-P95KEXck_o0KZVCX8W02TVJqQrw@mail.gmail.com>

Thanks a lot all for the reviews and push :)
Jc

On Fri, Dec 22, 2017 at 3:03 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
> Hi all,
>
> pushed to jdk/hs.
>
> Thanks everyone and best regards,
> Martin
>
>
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 21. Dezember 2017 16:32
> To: Doerr, Martin <martin.doerr at sap.com>; JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
> Subject: RE: RFR 8191987: TLAB Refills for PPC64
>
> Looks good, thanks for the cleanup.
>
> Best regards,
>   Goetz.
>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of Doerr, Martin
>> Sent: Donnerstag, 21. Dezember 2017 16:07
>> To: JC Beyler <jcbeyler at google.com>; hotspot-dev at openjdk.java.net
>> Subject: RE: RFR 8191987: TLAB Refills for PPC64
>>
>> Hi Jc,
>>
>> excellent. I didn't really like the usage of SkipIfEqualZero in the current code.
>> I prefer your version.
>> I can push it after we got a 2nd review.
>>
>> Thanks and best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of JC Beyler
>> Sent: Mittwoch, 20. Dezember 2017 22:04
>> To: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR 8191987: TLAB Refills for PPC64
>>
>> Please see the updated webrev :)
>>
>>
>> WebRev: http://cr.openjdk.java.net/~jcbeyler/8191987/webrev.03/
>>
>> On Wed, Dec 20, 2017 at 12:30 PM, JC Beyler <jcbeyler at google.com> wrote:
>> > Hi all,
>> >
>> > The TLAB and the inline contiguous allocations handling are different
>> > for each architecture. On certain architectures, TLAB is never
>> > actually never refilled (ref:
>> > https://bugs.openjdk.java.net/browse/JDK-8190862).
>> >
>> > The PPC patch really only removes the code that augments the TLAB
>> > waste limit since that is already done in the common code slow path.
>> >
>> > Due to a double jump, there is an additional change to have code from
>> > SkipIfEqualZero available so that we don't have to manually generate
>> > that code in the template code.
>> >
>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8191987
>> > WebRev: http://cr.openjdk.java.net/~rasbold/8191987/webrev.03/
>> >
>> > Let me know what you think and if someone could test/verify it, that
>> > would be great.
>> >
>> > Thanks for your help,
>> > Jc

From jcbeyler at google.com  Fri Dec 22 16:26:12 2017
From: jcbeyler at google.com (JC Beyler)
Date: Fri, 22 Dec 2017 08:26:12 -0800
Subject: RFR 8191988: TLAB Refills for S390
In-Reply-To: <25a44ab234604b8aa58d9cc84549a2ee@sap.com>
References: <CAF9BGBxoT6a8CijL_c9oK-gRLWYgczFjOhzatfuiyXC9Jm5y_Q@mail.gmail.com>
 <ffb3c0ff-4b68-0da7-9090-06a85d92542f@physik.fu-berlin.de>
 <CAF9BGByzfKU8yM_bdO3zP8aj-Q6rWXbp4nU_z1QbFzs=GgndnQ@mail.gmail.com>
 <84f8d984974f41688a7a83a70a471ff9@sap.com>
 <3f87572dabd74455ab328fcf978dd453@sap.com>
 <25a44ab234604b8aa58d9cc84549a2ee@sap.com>
Message-ID: <CAF9BGBzqZgixM99=DPhbf67Fcs90SOmyPNfezCr8prXU_y-ccA@mail.gmail.com>

Thanks a lot all for the reviews and push :)
Jc

On Fri, Dec 22, 2017 at 3:01 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
> Hi all,
>
> I have changed priority to P3 and pushed it to jdk10 because it fixes ZeroTLAB. It will get merged into hs, later.
>
> Thanks everyone and best regards,
> Martin
>
>
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 21. Dezember 2017 16:28
> To: Doerr, Martin <martin.doerr at sap.com>; JC Beyler <jcbeyler at google.com>; John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: RFR 8191988: TLAB Refills for S390
>
> Hi,
>
> thanks for doing this, especially as it fixes compiler/memoryinitialization/ZeroTLABTest.java.
> Therefore this one might be a candidate to push to 10.
>
> Looks good.
>
> Best regards,
>   Goetz.
>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of Doerr, Martin
>> Sent: Donnerstag, 21. Dezember 2017 16:05
>> To: JC Beyler <jcbeyler at google.com>; John Paul Adrian Glaubitz
>> <glaubitz at physik.fu-berlin.de>
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: RE: RFR 8191988: TLAB Refills for S390
>>
>> Hi Jc,
>>
>> reviewed. Looks good.
>> I can push it together with the PPC change.
>>
>> Thanks and best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of JC Beyler
>> Sent: Mittwoch, 20. Dezember 2017 22:04
>> To: John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR 8191988: TLAB Refills for S390
>>
>> Sorry, I went too fast:
>>
>> WebRev: http://cr.openjdk.java.net/~jcbeyler/8191988/webrev.02/
>>
>> Thanks!
>> Jc
>>
>> 2017-12-20 12:49 GMT-08:00 John Paul Adrian Glaubitz
>> <glaubitz at physik.fu-berlin.de>:
>> > Hi JC!
>> >
>> > On 12/20/2017 09:33 PM, JC Beyler wrote:
>> >> WebRev: http://cr.openjdk.java.net/~rasbold/8191988/webrev.02/
>> >
>> > This URL 404s. Did you mean:
>> http://cr.openjdk.java.net/~rasbold/8191988/webrev.01/ ?
>> >
>> > Adrian
>> >
>> > --
>> >  .''`.  John Paul Adrian Glaubitz
>> > : :' :  Debian Developer - glaubitz at debian.org
>> > `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>> >   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From vladimir.kozlov at oracle.com  Fri Dec 22 20:14:34 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 22 Dec 2017 12:14:34 -0800
Subject: RFR 8192004: InspectedFrame.materializeVirtualObjects only
 updates locals with new objects
In-Reply-To: <5A3D581B.8080601@oracle.com>
References: <5A3BE1E2.6030105@oracle.com> <5A3D581B.8080601@oracle.com>
Message-ID: <ddc58b2a-50c8-3771-b398-bd2be399db38@oracle.com>

Posting to hotspot-dev alias since our group does not have JVMTI experts.
I looked and it seems fine but someone from serviceability should look too.

Thanks,
Vladimir

On 12/22/17 11:08 AM, Tom Rodriguez wrote:
> Could I get some reviews?? This doesn't change the way the logic behaves 
> for the core use of JVMTI.? It just extends the encoding so that numbers 
> after the locals are interpreted as expression stack and monitor values. 
>  ?I believe there are existing tests of the JVMTI set locals part and 
> JVMCI is the only only consumer of the monitor and expression stack part.
> 
> tom
> 
> Tom Rodriguez wrote:
>> JVMCI adds the ability to introspect on deoptimized frames which
>> requires early materialization of escape analyzed objects. The
>> jvmtiDeferredLocalVariableSet machinery is reused to capture the local
>> updates required for this. The existing code only updates locals,
>> leaving the stack and monitor information with out of date values. This
>> can lead to deadlocks and incorrect execution. The fix is to slightly
>> generalize jvmtiDeferredLocalVariableSet to handle expression stack and
>> monitor slots. Tested with new graal regression test
>> https://github.com/graalvm/graal/blob/7fd37bde8955780a57049964d87a51aa2407d86b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotStackIntrospectionTest.java 
>>
>> and previously failing Truffle use cases. I assume the new test case
>> will come across with a normal graal update. The clean mach5 run is in
>> the bug report.
>>
>> http://cr.openjdk.java.net/~never/8192004/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8192004

From glaubitz at physik.fu-berlin.de  Sat Dec 23 11:44:52 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sat, 23 Dec 2017 12:44:52 +0100
Subject: Zero and native support on linux-ia64
Message-ID: <2dd43f0d-bbe7-2a4f-d52a-2ed4132a9427@physik.fu-berlin.de>

Hi!

I am currently playing around with OpenJDK Zero on ia64 and notice that there
is some ia64-specific code left at least in OpenJDK 8 which was subsequently
removed in later versions.

So, I am wondering, did OpenJDK have native support for ia64 at some point or
was this all needed for Zero? I know that ia64 has some weird peculiarities
and was wondering whether it's still possible to build Zero here.

I'm not interested in a native port, I just want to keep Zero as portable
as possible and we just recently got an old HP Itanium blade to fool
around with, so I naturally tried to build Zero there :-).

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From aph at redhat.com  Sat Dec 23 16:00:09 2017
From: aph at redhat.com (Andrew Haley)
Date: Sat, 23 Dec 2017 16:00:09 +0000
Subject: Zero and native support on linux-ia64
In-Reply-To: <2dd43f0d-bbe7-2a4f-d52a-2ed4132a9427@physik.fu-berlin.de>
References: <2dd43f0d-bbe7-2a4f-d52a-2ed4132a9427@physik.fu-berlin.de>
Message-ID: <652936cb-5fe9-6b51-b5ba-24c2c33702dd@redhat.com>

On 23/12/17 11:44, John Paul Adrian Glaubitz wrote:
> So, I am wondering, did OpenJDK have native support for ia64 at some point or
> was this all needed for Zero? I know that ia64 has some weird peculiarities
> and was wondering whether it's still possible to build Zero here.

There was native support for ia64, but it never made it into OpenJDK.  You'd
have to see if Zero still builds.

-- 
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 glaubitz at physik.fu-berlin.de  Sat Dec 23 19:14:17 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sat, 23 Dec 2017 20:14:17 +0100
Subject: Zero and native support on linux-ia64
In-Reply-To: <652936cb-5fe9-6b51-b5ba-24c2c33702dd@redhat.com>
References: <2dd43f0d-bbe7-2a4f-d52a-2ed4132a9427@physik.fu-berlin.de>
 <652936cb-5fe9-6b51-b5ba-24c2c33702dd@redhat.com>
Message-ID: <cc7c353d-4a8b-b7ea-0788-ecac7bd750eb@physik.fu-berlin.de>

On 12/23/2017 05:00 PM, Andrew Haley wrote:
> On 23/12/17 11:44, John Paul Adrian Glaubitz wrote:
>> So, I am wondering, did OpenJDK have native support for ia64 at some point or
>> was this all needed for Zero? I know that ia64 has some weird peculiarities
>> and was wondering whether it's still possible to build Zero here.
> 
> There was native support for ia64, but it never made it into OpenJDK.  You'd
> have to see if Zero still builds.

Ok, thanks! I did manage to build Openjdk-8 using existing OpenJDK-7 binaries
from Debian Wheezy. However, the JVM crashes. My suspicion - I haven't done any
in-depth analysis yet - is that there are remnants of the native ia64 support
that were compiled in for this build and therefore resulted in the crash.

I also noticed that OpenJDK-10 has received more clean-up regarding the native
support and I suppose that only the necessary #ifdefs for Zero on ia64 are
left such as the one in [1]. However, since I haven't tried cross-compiling
OpenJDK yet, I had to start with OpenJDK-8 instead of 10.

The backtrace of the crash is below in any case.

(wheezy-backports_ia64-dchroot)glaubitz at titanium:~/debian/openjdk-8/openjdk-8-8u151-b12/build/jdk/bin$ gdb ./javac
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ia64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/build/jdk/bin/javac...done.
(gdb) r
Starting program: /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/build/jdk/bin/javac
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/ia64-linux-gnu/libthread_db.so.1".
[New Thread 0x2000000001627200 (LWP 1627)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0x2000000001627200 (LWP 1627)]
0x2000000000a328b1 in java_lang_String::compute_offsets () at
/home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/classfile/javaClasses.cpp:152
152     void java_lang_String::compute_offsets() {
(gdb) bt
#0  0x2000000000a328b1 in java_lang_String::compute_offsets ()
    at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/classfile/javaClasses.cpp:152
#1  0x2000000000ee4b70 in SystemDictionary::initialize_preloaded_classes (__the_thread__=0x60000000000116c0)
    at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/classfile/systemDictionary.cpp:1902
#2  0x2000000000f24bd0 in Universe::genesis (__the_thread__=0x60000000000116c0)
    at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/memory/universe.cpp:302
#3  0x2000000000f281d0 in universe2_init () at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/memory/universe.cpp:1021
#4  0x2000000000965a80 in init_globals () at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/runtime/init.cpp:116
#5  0x2000000000f046d0 in Threads::create_vm (args=0x20000000016267d0, canTryAgain=0x20000000016267b0)
    at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/runtime/thread.cpp:3421
#6  0x2000000000a70a20 in JNI_CreateJavaVM (vm=0x2000000001626808, penv=0x2000000001626800, args=0x20000000016267d0)
    at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/prims/jni.cpp:5220
#7  0x20000000000d43f0 in InitializeJVM (ifn=<optimized out>, penv=<optimized out>, pvm=<optimized out>)
    at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/jdk/src/share/bin/java.c:1215
#8  JavaMain (_args=0x60000fffffff73f0) at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/jdk/src/share/bin/java.c:376
#9  0x20000000000de910 in call_continuation (_args=0x60000fffffff73c8)
    at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/jdk/src/solaris/bin/java_md_solinux.c:1034
#10 0x200000000005ebb0 in start_thread () from /lib/ia64-linux-gnu/libpthread.so.0
#11 0x20000000002c98c0 in __clone2 () from /lib/ia64-linux-gnu/libc.so.6.1
#12 0x0000000000000000 in ?? ()
(gdb)

Adrian

> [1] http://hg.openjdk.java.net/jdk/hs/file/614068b0ddd7/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp#l356

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From david.holmes at oracle.com  Sat Dec 23 23:38:41 2017
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 24 Dec 2017 09:38:41 +1000
Subject: Zero and native support on linux-ia64
In-Reply-To: <cc7c353d-4a8b-b7ea-0788-ecac7bd750eb@physik.fu-berlin.de>
References: <2dd43f0d-bbe7-2a4f-d52a-2ed4132a9427@physik.fu-berlin.de>
 <652936cb-5fe9-6b51-b5ba-24c2c33702dd@redhat.com>
 <cc7c353d-4a8b-b7ea-0788-ecac7bd750eb@physik.fu-berlin.de>
Message-ID: <4b5d3e0b-479a-19c0-6854-4a36d35e01dc@oracle.com>

On 24/12/2017 5:14 AM, John Paul Adrian Glaubitz wrote:
> On 12/23/2017 05:00 PM, Andrew Haley wrote:
>> On 23/12/17 11:44, John Paul Adrian Glaubitz wrote:
>>> So, I am wondering, did OpenJDK have native support for ia64 at some point or
>>> was this all needed for Zero? I know that ia64 has some weird peculiarities
>>> and was wondering whether it's still possible to build Zero here.
>>
>> There was native support for ia64, but it never made it into OpenJDK.  You'd
>> have to see if Zero still builds.
> 
> Ok, thanks! I did manage to build Openjdk-8 using existing OpenJDK-7 binaries
> from Debian Wheezy. However, the JVM crashes. My suspicion - I haven't done any
> in-depth analysis yet - is that there are remnants of the native ia64 support
> that were compiled in for this build and therefore resulted in the crash.

Quite possible. As Andrew notes the IA64 code in the mainline predates 
OpenJDK and was never a supported platform in OpenJDK, but some 
licensees still used it. It took a while to get around to removing it 
from the OpenJDK codebase - except IIRC we tried not to touch Zero as 
Zero deals with architectures the rest of the code doesn't need to know 
about. So we may have left in unneeded code.

Cheers,
David

> I also noticed that OpenJDK-10 has received more clean-up regarding the native
> support and I suppose that only the necessary #ifdefs for Zero on ia64 are
> left such as the one in [1]. However, since I haven't tried cross-compiling
> OpenJDK yet, I had to start with OpenJDK-8 instead of 10.
> 
> The backtrace of the crash is below in any case.
> 
> (wheezy-backports_ia64-dchroot)glaubitz at titanium:~/debian/openjdk-8/openjdk-8-8u151-b12/build/jdk/bin$ gdb ./javac
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "ia64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/build/jdk/bin/javac...done.
> (gdb) r
> Starting program: /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/build/jdk/bin/javac
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/ia64-linux-gnu/libthread_db.so.1".
> [New Thread 0x2000000001627200 (LWP 1627)]
> 
> Program received signal SIGILL, Illegal instruction.
> [Switching to Thread 0x2000000001627200 (LWP 1627)]
> 0x2000000000a328b1 in java_lang_String::compute_offsets () at
> /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/classfile/javaClasses.cpp:152
> 152     void java_lang_String::compute_offsets() {
> (gdb) bt
> #0  0x2000000000a328b1 in java_lang_String::compute_offsets ()
>      at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/classfile/javaClasses.cpp:152
> #1  0x2000000000ee4b70 in SystemDictionary::initialize_preloaded_classes (__the_thread__=0x60000000000116c0)
>      at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/classfile/systemDictionary.cpp:1902
> #2  0x2000000000f24bd0 in Universe::genesis (__the_thread__=0x60000000000116c0)
>      at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/memory/universe.cpp:302
> #3  0x2000000000f281d0 in universe2_init () at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/memory/universe.cpp:1021
> #4  0x2000000000965a80 in init_globals () at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/runtime/init.cpp:116
> #5  0x2000000000f046d0 in Threads::create_vm (args=0x20000000016267d0, canTryAgain=0x20000000016267b0)
>      at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/runtime/thread.cpp:3421
> #6  0x2000000000a70a20 in JNI_CreateJavaVM (vm=0x2000000001626808, penv=0x2000000001626800, args=0x20000000016267d0)
>      at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/hotspot/src/share/vm/prims/jni.cpp:5220
> #7  0x20000000000d43f0 in InitializeJVM (ifn=<optimized out>, penv=<optimized out>, pvm=<optimized out>)
>      at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/jdk/src/share/bin/java.c:1215
> #8  JavaMain (_args=0x60000fffffff73f0) at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/jdk/src/share/bin/java.c:376
> #9  0x20000000000de910 in call_continuation (_args=0x60000fffffff73c8)
>      at /home/glaubitz/debian/openjdk-8/openjdk-8-8u151-b12/src/jdk/src/solaris/bin/java_md_solinux.c:1034
> #10 0x200000000005ebb0 in start_thread () from /lib/ia64-linux-gnu/libpthread.so.0
> #11 0x20000000002c98c0 in __clone2 () from /lib/ia64-linux-gnu/libc.so.6.1
> #12 0x0000000000000000 in ?? ()
> (gdb)
> 
> Adrian
> 
>> [1] http://hg.openjdk.java.net/jdk/hs/file/614068b0ddd7/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp#l356
> 

From david.holmes at oracle.com  Tue Dec 26 12:46:45 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 26 Dec 2017 22:46:45 +1000
Subject: Another question, if I may?
In-Reply-To: <98191FCC-06DC-49F9-8464-78B045A65F85@tedneward.com>
References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com>
 <bfc85d29-6ab7-c598-8ac1-4ac8643edda1@oracle.com>
 <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com>
 <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com>
 <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com>
 <385762d8-6714-29d9-0082-0316ddb2f0ff@oracle.com>
 <98191FCC-06DC-49F9-8464-78B045A65F85@tedneward.com>
Message-ID: <818b0d34-8007-a771-a277-e62fff4f5805@oracle.com>

On 24/12/2017 9:01 PM, Ted Neward wrote:
> So if I do a "make hotspot" it replaces the compiled Hotspot binary in the exploded build image?

I believe so, but simplest thing is to do a find for libjvm.so before 
and after the "make hotspot" and see which one(s) changed.

David

> The reason I ask is that this is what I tried, and it didn?t appear to show up in the list of "PrintFlagsFinal" output.
> 
> Ted Neward
> Author, Speaker, Mentor
> http://www.newardassociates.com
> t: @tedneward | m: (425) 647-4526
> 
> ?On 12/22/17, 12:32 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
> 
>      
>      
>      On 2017-12-22 01:06, David Holmes wrote:
>      >
>      > "make hotspot" won't update the image, you need to "make images" for
>      > that.
>      >
>      > Assuming you're building 9+ then when you change libjvm.so the module
>      > needs to be rebuilt etc.
>      >
>      > Or you can work from the exploded build the contents of e.g.
>      >
>      >  build/linux-x64-debug/jdk/
>      >
>      > though you still need a full build to prime that. But after that "make
>      > hotspot" should suffice. (Erik correct me if I'm wrong here please.)
>      This is correct. Using the exploded image as described is the shortcut
>      we have. The actual images are always built using jmod/jlink and yes,
>      that requires quite a bit of extra build time.
>      
>      If you are in JDK 8, you need to run "make jdk" to get the exploded
>      image updated with the new libjvm.so.
>      
>      /Erik
>      
> 
> 

From VicWang at zhaoxin.com  Thu Dec 28 06:59:32 2017
From: VicWang at zhaoxin.com (Vic Wang(BJ-RD))
Date: Thu, 28 Dec 2017 06:59:32 +0000
Subject: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai 
Message-ID: <cd1bc427b791405890328b5be2f70c03@zhaoxin.com>

Hi,
Here is a hotspot patch for supporting zhaoxin x86 cpu vendor ids (CentaurHauls id and Shanghai id). The original repository is http://hg.openjdk.java.net/jdk/hs.
Please help me to submit the changes . If there is anything incorrectly, please let me know. Thank you very much.

The following is the changeset by the diff command.

diff -Nur org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp
--- org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-08 03:33:00.000000000 +0800
+++ zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-28 11:31:30.000000000 +0800
@@ -3167,6 +3167,89 @@
     return;
   }

+  if (UseAddressNop && VM_Version::is_zx()) {
+    //
+    // Using multi-bytes nops "0x0F 0x1F [address]" for ZX
+    //  1: 0x90
+    //  2: 0x66 0x90
+    //  3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding)
+    //  4: 0x0F 0x1F 0x40 0x00
+    //  5: 0x0F 0x1F 0x44 0x00 0x00
+    //  6: 0x66 0x0F 0x1F 0x44 0x00 0x00
+    //  7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00
+    //  8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
+    //  9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
+    // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
+    // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
+
+    // The rest coding is ZX specific - don't use consecutive address nops
+
+    // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
+    // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
+    // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
+    // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
+
+    while(i >= 15) {
+      // For ZX don't generate consecutive addess nops (mix with regular nops)
+      i -= 15;
+      emit_int8(0x66);   // size prefix
+      emit_int8(0x66);   // size prefix
+      emit_int8(0x66);   // size prefix
+      addr_nop_8();
+      emit_int8(0x66);   // size prefix
+      emit_int8(0x66);   // size prefix
+      emit_int8(0x66);   // size prefix
+      emit_int8((unsigned char)0x90);
+                         // nop
+    }
+    switch (i) {
+      case 14:
+        emit_int8(0x66); // size prefix
+      case 13:
+        emit_int8(0x66); // size prefix
+      case 12:
+        addr_nop_8();
+        emit_int8(0x66); // size prefix
+        emit_int8(0x66); // size prefix
+        emit_int8(0x66); // size prefix
+        emit_int8((unsigned char)0x90);
+                         // nop
+        break;
+      case 11:
+        emit_int8(0x66); // size prefix
+      case 10:
+        emit_int8(0x66); // size prefix
+      case 9:
+        emit_int8(0x66); // size prefix
+      case 8:
+        addr_nop_8();
+        break;
+      case 7:
+        addr_nop_7();
+        break;
+      case 6:
+        emit_int8(0x66); // size prefix
+      case 5:
+        addr_nop_5();
+        break;
+      case 4:
+        addr_nop_4();
+        break;
+      case 3:
+        // Don't use "0x0F 0x1F 0x00" - need patching safe padding
+        emit_int8(0x66); // size prefix
+      case 2:
+        emit_int8(0x66); // size prefix
+      case 1:
+        emit_int8((unsigned char)0x90);
+                         // nop
+        break;
+      default:
+        assert(i == 0, " ");
+    }
+    return;
+  }
+
   // Using nops with size prefixes "0x66 0x90".
   // From AMD Optimization Guide:
   //  1: 0x90
diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp
--- org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-08 03:33:00.000000000 +0800
+++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-28 11:30:40.000000000 +0800
@@ -628,6 +628,11 @@
   if (UseSSE < 1)
     _features &= ~CPU_SSE;

+  //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0.
+  if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){
+UseAVX = 0;
+  }
+
   // first try initial setting and detect what we can support
   int use_avx_limit = 0;
   if (UseAVX > 0) {
@@ -1078,6 +1083,66 @@
   // UseXmmRegToRegMoveAll == true  --> movaps(xmm, xmm), movapd(xmm, xmm).
   // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm),  movsd(xmm, xmm).

+
+  if( is_zx() ) { // ZX cpus specific settings
+    if( FLAG_IS_DEFAULT(UseStoreImmI16) ) {
+      UseStoreImmI16 = false; // don't use it on ZX cpus
+    }
+    if( (cpu_family() == 6)|| (cpu_family() == 7) ) {
+      if( FLAG_IS_DEFAULT(UseAddressNop) ) {
+        // Use it on all ZX cpus
+        UseAddressNop = true;
+      }
+    }
+    if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) {
+      UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus
+    }
+    if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) {
+      if( supports_sse3() ) {
+        UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus
+      } else {
+        UseXmmRegToRegMoveAll = false;
+      }
+    }
+    if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() ) { // new ZX cpus
+#ifdef COMPILER2
+      if( FLAG_IS_DEFAULT(MaxLoopPad) ) {
+        // For new ZX cpus do the next optimization:
+        // don't align the beginning of a loop if there are enough instructions
+        // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp)
+        // in current fetch line (OptoLoopAlignment) or the padding
+        // is big (> MaxLoopPad).
+        // Set MaxLoopPad to 11 for new ZX cpus to reduce number of
+        // generated NOP instructions. 11 is the largest size of one
+        // address NOP instruction '0F 1F' (see Assembler::nop(i)).
+        MaxLoopPad = 11;
+      }
+#endif // COMPILER2
+      if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) {
+        UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus
+      }
+      if (supports_sse4_2()) { // new ZX cpus
+        if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) {
+          UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus
+        }
+      }
+      if (supports_sse4_2()) {
+        if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) {
+          FLAG_SET_DEFAULT(UseSSE42Intrinsics, true);
+        }
+      } else {
+        if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) {
+          warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled.");
+        }
+        FLAG_SET_DEFAULT(UseSSE42Intrinsics, false);
+      }
+    }
+
+    if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) {
+      FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3);
+    }
+  }
+
   if( is_amd() ) { // AMD cpus specific settings
     if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) {
       // Use it on new AMD cpus starting from Opteron.
@@ -1370,6 +1435,14 @@
 #ifdef COMPILER2
     if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) {
       FLAG_SET_DEFAULT(UseFPUForSpilling, true);
+    }
+#endif
+  }
+
+    if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3()) {
+#ifdef COMPILER2
+    if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) {
+      FLAG_SET_DEFAULT(UseFPUForSpilling, true);
     }
 #endif
   }
diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp
--- org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-08 03:33:00.000000000 +0800
+++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-28 14:15:18.000000000 +0800
@@ -305,6 +305,9 @@
   enum Extended_Family {
     // AMD
     CPU_FAMILY_AMD_11H       = 0x11,
+    // ZX
+    CPU_FAMILY_ZX_CORE_F6    = 6,
+    CPU_FAMILY_ZX_CORE_F7    = 7,
     // Intel
     CPU_FAMILY_INTEL_CORE    = 6,
     CPU_MODEL_NEHALEM        = 0x1e,
@@ -549,6 +552,16 @@
       }
     }

+// ZX features.
+    if(is_zx()) {
+      if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0)
+        result |= CPU_LZCNT;
+      // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw
+      if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) {
+        result |= CPU_3DNOW_PREFETCH;
+      }
+    }
+
     return result;
   }

@@ -657,6 +670,7 @@
   static bool is_P6()             { return cpu_family() >= 6; }
   static bool is_amd()            { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA'
   static bool is_intel()          { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG'
+  static bool is_zx()             { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS  '
   static bool is_atom_family()    { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton
   static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi

@@ -680,7 +694,16 @@
       }
     } else if (is_amd()) {
       result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1);
-    }
+    } else if (is_zx()) {
+  bool supports_topology = supports_processor_topology();
+      if (supports_topology) {
+        result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus /
+                 _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
+      }
+      if (!supports_topology || result == 0) {
+        result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1);
+      }
+}
     return result;
   }

@@ -688,7 +711,9 @@
     uint result = 1;
     if (is_intel() && supports_processor_topology()) {
       result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
-    } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) {
+    } else if (is_zx() && supports_processor_topology()) {
+  result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
+} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) {
       if (cpu_family() >= 0x17) {
         result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1;
       } else {
@@ -705,7 +730,9 @@
       result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1);
     } else if (is_amd()) {
       result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size;
-    }
+    } else if (is_zx()) {
+  result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1);
+}
     if (result < 32) // not defined ?
       result = 32;   // 32 bytes by default on x86 and other x64
     return result;

Finally, running the jtreg test. I run 2 jtreg tests(jtreg:test/jdk:tier1 and jtreg:test/langtools:tier1) and both of them are pass.
The results are as follows.
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk:tier1                               1660  1660     0     0
   jtreg:test/langtools:tier1                          3828  3828     0     0
   jtreg:test/nashorn:tier1                              0     0     0     0
   jtreg:test/jaxp:tier1                                 0     0     0     0
==============================
TEST SUCCESS

Best Regards!
VicWang | R&D
Telephone:+86-01082695388-892477


?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

From edward.nevill at gmail.com  Thu Dec 28 18:14:42 2017
From: edward.nevill at gmail.com (Edward Nevill)
Date: Thu, 28 Dec 2017 18:14:42 +0000
Subject: RFR 8191985: Tlab refills for ARM
In-Reply-To: <CAF9BGBzeMOokcQB_JHdw4FAzGYjBJLStnEkjDQFfkWDF-X9xeQ@mail.gmail.com>
References: <CAF9BGBwNyO1Hxqbpe2au8Cz1+9-PbAj_YJYUgBk-us9--esosg@mail.gmail.com>
 <356550c0-adb7-bc91-c28f-e1943fad0f81@oracle.com>
 <CAF9BGBy=3ORHGX=JWPXbZoNx7ri2PRP6EGdM_oUEfCzYrjs=Nw@mail.gmail.com>
 <b429ff80-c8f3-992f-10f1-cdd3b3480e2f@oracle.com>
 <1513776075.2757.7.camel@gmail.com>
 <8d5adc6a-86f0-7c18-5785-97d163159af2@oracle.com>
 <CAF9BGBzeMOokcQB_JHdw4FAzGYjBJLStnEkjDQFfkWDF-X9xeQ@mail.gmail.com>
Message-ID: <1514484882.2264.6.camel@gmail.com>

Hi,

I have built and tested this on a Samsung Chromebook (armv7l).

The tests I ran were jtreg hotspot tests patched vs original in three configurations, default gc (g1gc), parallelgc and serialgc. The results in all cases were identical before and after patching.

Default gc (g1gc): passed: 1,435; failed: 9; error: 116
ParallelGC: passed: 1,331; failed: 8; error: 112
SerialGC: passed: 1,326; failed: 7; error: 112

Patch looks good to me.

All the best,
Ed.

On Wed, 2017-12-20 at 09:06 -0800, JC Beyler wrote:
> Hi all,
> 
> Thanks for taking a look at the webrev!
> 
> Here is the change relative to jdk/hs:
> http://cr.openjdk.java.net/~jcbeyler/8191985/webrev.02/
> 
> Let me know what you think, hopefully I didn't make a mistake when
> making the webrev :)
> Jc
> 
> 
> On Wed, Dec 20, 2017 at 5:50 AM, Daniel D. Daugherty
> <daniel.daugherty at oracle.com> wrote:
> > On 12/20/17 8:21 AM, Edward Nevill wrote:
> > > 
> > > Hi Robin,
> > > 
> > > I have eyeballed this, comparing it against the x86 version, and it looks
> > > good to me.
> > > 
> > > I'll try to build and test this, but it will probably be sometime between
> > > Christmas and New Year.
> > > 
> > > Just to confirm, the repo I should be patching and building is the
> > > following?
> > > 
> > > 


From VicWang at zhaoxin.com  Fri Dec 29 06:27:24 2017
From: VicWang at zhaoxin.com (Vic Wang(BJ-RD))
Date: Fri, 29 Dec 2017 06:27:24 +0000
Subject: =?gb2312?B?tPC4tDogW3BhdGNoXSBzdXBwb3J0IHpoYW94aW4geDg2IGNwdSB2ZW5kb3Ig?=
 =?gb2312?Q?ids_CentaurHauls_and_Shanghai_?=
Message-ID: <d7e7a95d9c2547338e5bd1dd3f60e126@zhaoxin.com>

Hi,
Sorry to send this mail again. I send this mail, but I don?t receive any response . And I don?t receive it by myself since I am in the mailing list. So if you receive this, can you give a response for me?

Best Regards!
VicWang

-----????-----
???: Vic Wang(BJ-RD)
????: 2017?12?28? 15:00
???: 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
??: Cobe Chen(BJ-RD) <CobeChen at zhaoxin.com>
??: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai

Hi,
Here is a hotspot patch for supporting zhaoxin x86 cpu vendor ids (CentaurHauls id and Shanghai id). The original repository is http://hg.openjdk.java.net/jdk/hs.
Please help me to submit the changes . If there is anything incorrectly, please let me know. Thank you very much.

The following is the changeset by the diff command.

diff -Nur org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp
--- org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-08 03:33:00.000000000 +0800
+++ zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-28 11:31:30.000000000 +0800
@@ -3167,6 +3167,89 @@
     return;
   }

+  if (UseAddressNop && VM_Version::is_zx()) {
+    //
+    // Using multi-bytes nops "0x0F 0x1F [address]" for ZX
+    //  1: 0x90
+    //  2: 0x66 0x90
+    //  3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding)
+    //  4: 0x0F 0x1F 0x40 0x00
+    //  5: 0x0F 0x1F 0x44 0x00 0x00
+    //  6: 0x66 0x0F 0x1F 0x44 0x00 0x00
+    //  7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00
+    //  8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
+    //  9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
+    // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
+    // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
+
+    // The rest coding is ZX specific - don't use consecutive address
+ nops
+
+    // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
+    // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
+    // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
+    // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66
+ 0x66 0x66 0x90
+
+    while(i >= 15) {
+      // For ZX don't generate consecutive addess nops (mix with regular nops)
+      i -= 15;
+      emit_int8(0x66);   // size prefix
+      emit_int8(0x66);   // size prefix
+      emit_int8(0x66);   // size prefix
+      addr_nop_8();
+      emit_int8(0x66);   // size prefix
+      emit_int8(0x66);   // size prefix
+      emit_int8(0x66);   // size prefix
+      emit_int8((unsigned char)0x90);
+                         // nop
+    }
+    switch (i) {
+      case 14:
+        emit_int8(0x66); // size prefix
+      case 13:
+        emit_int8(0x66); // size prefix
+      case 12:
+        addr_nop_8();
+        emit_int8(0x66); // size prefix
+        emit_int8(0x66); // size prefix
+        emit_int8(0x66); // size prefix
+        emit_int8((unsigned char)0x90);
+                         // nop
+        break;
+      case 11:
+        emit_int8(0x66); // size prefix
+      case 10:
+        emit_int8(0x66); // size prefix
+      case 9:
+        emit_int8(0x66); // size prefix
+      case 8:
+        addr_nop_8();
+        break;
+      case 7:
+        addr_nop_7();
+        break;
+      case 6:
+        emit_int8(0x66); // size prefix
+      case 5:
+        addr_nop_5();
+        break;
+      case 4:
+        addr_nop_4();
+        break;
+      case 3:
+        // Don't use "0x0F 0x1F 0x00" - need patching safe padding
+        emit_int8(0x66); // size prefix
+      case 2:
+        emit_int8(0x66); // size prefix
+      case 1:
+        emit_int8((unsigned char)0x90);
+                         // nop
+        break;
+      default:
+        assert(i == 0, " ");
+    }
+    return;
+  }
+
   // Using nops with size prefixes "0x66 0x90".
   // From AMD Optimization Guide:
   //  1: 0x90
diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp
--- org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-08 03:33:00.000000000 +0800
+++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-28 11:30:40.000000000 +0800
@@ -628,6 +628,11 @@
   if (UseSSE < 1)
     _features &= ~CPU_SSE;

+  //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0.
+  if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){
+UseAVX = 0;
+  }
+
   // first try initial setting and detect what we can support
   int use_avx_limit = 0;
   if (UseAVX > 0) {
@@ -1078,6 +1083,66 @@
   // UseXmmRegToRegMoveAll == true  --> movaps(xmm, xmm), movapd(xmm, xmm).
   // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm),  movsd(xmm, xmm).

+
+  if( is_zx() ) { // ZX cpus specific settings
+    if( FLAG_IS_DEFAULT(UseStoreImmI16) ) {
+      UseStoreImmI16 = false; // don't use it on ZX cpus
+    }
+    if( (cpu_family() == 6)|| (cpu_family() == 7) ) {
+      if( FLAG_IS_DEFAULT(UseAddressNop) ) {
+        // Use it on all ZX cpus
+        UseAddressNop = true;
+      }
+    }
+    if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) {
+      UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus
+    }
+    if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) {
+      if( supports_sse3() ) {
+        UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus
+      } else {
+        UseXmmRegToRegMoveAll = false;
+      }
+    }
+    if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() )
+{ // new ZX cpus #ifdef COMPILER2
+      if( FLAG_IS_DEFAULT(MaxLoopPad) ) {
+        // For new ZX cpus do the next optimization:
+        // don't align the beginning of a loop if there are enough instructions
+        // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp)
+        // in current fetch line (OptoLoopAlignment) or the padding
+        // is big (> MaxLoopPad).
+        // Set MaxLoopPad to 11 for new ZX cpus to reduce number of
+        // generated NOP instructions. 11 is the largest size of one
+        // address NOP instruction '0F 1F' (see Assembler::nop(i)).
+        MaxLoopPad = 11;
+      }
+#endif // COMPILER2
+      if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) {
+        UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus
+      }
+      if (supports_sse4_2()) { // new ZX cpus
+        if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) {
+          UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus
+        }
+      }
+      if (supports_sse4_2()) {
+        if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) {
+          FLAG_SET_DEFAULT(UseSSE42Intrinsics, true);
+        }
+      } else {
+        if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) {
+          warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled.");
+        }
+        FLAG_SET_DEFAULT(UseSSE42Intrinsics, false);
+      }
+    }
+
+    if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) {
+      FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3);
+    }
+  }
+
   if( is_amd() ) { // AMD cpus specific settings
     if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) {
       // Use it on new AMD cpus starting from Opteron.
@@ -1370,6 +1435,14 @@
 #ifdef COMPILER2
     if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) {
       FLAG_SET_DEFAULT(UseFPUForSpilling, true);
+    }
+#endif
+  }
+
+    if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) &&
+supports_sse3()) { #ifdef COMPILER2
+    if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) {
+      FLAG_SET_DEFAULT(UseFPUForSpilling, true);
     }
 #endif
   }
diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp
--- org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-08 03:33:00.000000000 +0800
+++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-28 14:15:18.000000000 +0800
@@ -305,6 +305,9 @@
   enum Extended_Family {
     // AMD
     CPU_FAMILY_AMD_11H       = 0x11,
+    // ZX
+    CPU_FAMILY_ZX_CORE_F6    = 6,
+    CPU_FAMILY_ZX_CORE_F7    = 7,
     // Intel
     CPU_FAMILY_INTEL_CORE    = 6,
     CPU_MODEL_NEHALEM        = 0x1e,
@@ -549,6 +552,16 @@
       }
     }

+// ZX features.
+    if(is_zx()) {
+      if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0)
+        result |= CPU_LZCNT;
+      // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw
+      if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) {
+        result |= CPU_3DNOW_PREFETCH;
+      }
+    }
+
     return result;
   }

@@ -657,6 +670,7 @@
   static bool is_P6()             { return cpu_family() >= 6; }
   static bool is_amd()            { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA'
   static bool is_intel()          { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG'
+  static bool is_zx()             { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS  '
   static bool is_atom_family()    { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton
   static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi

@@ -680,7 +694,16 @@
       }
     } else if (is_amd()) {
       result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1);
-    }
+    } else if (is_zx()) {
+  bool supports_topology = supports_processor_topology();
+      if (supports_topology) {
+        result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus /
+                 _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
+      }
+      if (!supports_topology || result == 0) {
+        result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1);
+      }
+}
     return result;
   }

@@ -688,7 +711,9 @@
     uint result = 1;
     if (is_intel() && supports_processor_topology()) {
       result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
-    } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) {
+    } else if (is_zx() && supports_processor_topology()) {
+  result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
+} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) {
       if (cpu_family() >= 0x17) {
         result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1;
       } else {
@@ -705,7 +730,9 @@
       result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1);
     } else if (is_amd()) {
       result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size;
-    }
+    } else if (is_zx()) {
+  result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1);
+}
     if (result < 32) // not defined ?
       result = 32;   // 32 bytes by default on x86 and other x64
     return result;

Finally, running the jtreg test. I run 2 jtreg tests(jtreg:test/jdk:tier1 and jtreg:test/langtools:tier1) and both of them are pass.
The results are as follows.
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk:tier1                               1660  1660     0     0
   jtreg:test/langtools:tier1                          3828  3828     0     0
   jtreg:test/nashorn:tier1                              0     0     0     0
   jtreg:test/jaxp:tier1                                 0     0     0     0
==============================
TEST SUCCESS

Best Regards!
VicWang | R&D
Telephone:+86-01082695388-892477


?????
?????????????????????????????????????????????????????
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

From david.holmes at oracle.com  Fri Dec 29 12:16:25 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Dec 2017 22:16:25 +1000
Subject: =?UTF-8?Q?Re:_=e7=ad=94=e5=a4=8d:_[patch]_support_zhaoxin_x86_cpu_v?=
 =?UTF-8?Q?endor_ids_CentaurHauls_and_Shanghai?=
In-Reply-To: <d7e7a95d9c2547338e5bd1dd3f60e126@zhaoxin.com>
References: <d7e7a95d9c2547338e5bd1dd3f60e126@zhaoxin.com>
Message-ID: <08d04b16-1ba9-6642-3cdc-c860cbe65b01@oracle.com>

Hi,

Both mails came through okay. You can check the archive to see if it 
arrived at the list:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029669.html

Many people are on vacation at the moment - myself included :)

Cheers,
David

On 29/12/2017 4:27 PM, Vic Wang(BJ-RD) wrote:
> Hi,
> Sorry to send this mail again. I send this mail, but I don?t receive any response . And I don?t receive it by myself since I am in the mailing list. So if you receive this, can you give a response for me?
> 
> Best Regards!
> VicWang
> 
> -----????-----
> ???: Vic Wang(BJ-RD)
> ????: 2017?12?28? 15:00
> ???: 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> ??: Cobe Chen(BJ-RD) <CobeChen at zhaoxin.com>
> ??: [patch] support zhaoxin x86 cpu vendor ids CentaurHauls and Shanghai
> 
> Hi,
> Here is a hotspot patch for supporting zhaoxin x86 cpu vendor ids (CentaurHauls id and Shanghai id). The original repository is http://hg.openjdk.java.net/jdk/hs.
> Please help me to submit the changes . If there is anything incorrectly, please let me know. Thank you very much.
> 
> The following is the changeset by the diff command.
> 
> diff -Nur org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp
> --- org/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-08 03:33:00.000000000 +0800
> +++ zx/jdk/src/hotspot/cpu/x86/assembler_x86.cpp2017-12-28 11:31:30.000000000 +0800
> @@ -3167,6 +3167,89 @@
>       return;
>     }
> 
> +  if (UseAddressNop && VM_Version::is_zx()) {
> +    //
> +    // Using multi-bytes nops "0x0F 0x1F [address]" for ZX
> +    //  1: 0x90
> +    //  2: 0x66 0x90
> +    //  3: 0x66 0x66 0x90 (don't use "0x0F 0x1F 0x00" - need patching safe padding)
> +    //  4: 0x0F 0x1F 0x40 0x00
> +    //  5: 0x0F 0x1F 0x44 0x00 0x00
> +    //  6: 0x66 0x0F 0x1F 0x44 0x00 0x00
> +    //  7: 0x0F 0x1F 0x80 0x00 0x00 0x00 0x00
> +    //  8: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
> +    //  9: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
> +    // 10: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
> +    // 11: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00
> +
> +    // The rest coding is ZX specific - don't use consecutive address
> + nops
> +
> +    // 12: 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
> +    // 13: 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
> +    // 14: 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66 0x66 0x66 0x90
> +    // 15: 0x66 0x66 0x66 0x0F 0x1F 0x84 0x00 0x00 0x00 0x00 0x00 0x66
> + 0x66 0x66 0x90
> +
> +    while(i >= 15) {
> +      // For ZX don't generate consecutive addess nops (mix with regular nops)
> +      i -= 15;
> +      emit_int8(0x66);   // size prefix
> +      emit_int8(0x66);   // size prefix
> +      emit_int8(0x66);   // size prefix
> +      addr_nop_8();
> +      emit_int8(0x66);   // size prefix
> +      emit_int8(0x66);   // size prefix
> +      emit_int8(0x66);   // size prefix
> +      emit_int8((unsigned char)0x90);
> +                         // nop
> +    }
> +    switch (i) {
> +      case 14:
> +        emit_int8(0x66); // size prefix
> +      case 13:
> +        emit_int8(0x66); // size prefix
> +      case 12:
> +        addr_nop_8();
> +        emit_int8(0x66); // size prefix
> +        emit_int8(0x66); // size prefix
> +        emit_int8(0x66); // size prefix
> +        emit_int8((unsigned char)0x90);
> +                         // nop
> +        break;
> +      case 11:
> +        emit_int8(0x66); // size prefix
> +      case 10:
> +        emit_int8(0x66); // size prefix
> +      case 9:
> +        emit_int8(0x66); // size prefix
> +      case 8:
> +        addr_nop_8();
> +        break;
> +      case 7:
> +        addr_nop_7();
> +        break;
> +      case 6:
> +        emit_int8(0x66); // size prefix
> +      case 5:
> +        addr_nop_5();
> +        break;
> +      case 4:
> +        addr_nop_4();
> +        break;
> +      case 3:
> +        // Don't use "0x0F 0x1F 0x00" - need patching safe padding
> +        emit_int8(0x66); // size prefix
> +      case 2:
> +        emit_int8(0x66); // size prefix
> +      case 1:
> +        emit_int8((unsigned char)0x90);
> +                         // nop
> +        break;
> +      default:
> +        assert(i == 0, " ");
> +    }
> +    return;
> +  }
> +
>     // Using nops with size prefixes "0x66 0x90".
>     // From AMD Optimization Guide:
>     //  1: 0x90
> diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp
> --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-08 03:33:00.000000000 +0800
> +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.cpp2017-12-28 11:30:40.000000000 +0800
> @@ -628,6 +628,11 @@
>     if (UseSSE < 1)
>       _features &= ~CPU_SSE;
> 
> +  //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0.
> +  if(is_zx() && ((cpu_family()==6)||(cpu_family()==7))){
> +UseAVX = 0;
> +  }
> +
>     // first try initial setting and detect what we can support
>     int use_avx_limit = 0;
>     if (UseAVX > 0) {
> @@ -1078,6 +1083,66 @@
>     // UseXmmRegToRegMoveAll == true  --> movaps(xmm, xmm), movapd(xmm, xmm).
>     // UseXmmRegToRegMoveAll == false --> movss(xmm, xmm),  movsd(xmm, xmm).
> 
> +
> +  if( is_zx() ) { // ZX cpus specific settings
> +    if( FLAG_IS_DEFAULT(UseStoreImmI16) ) {
> +      UseStoreImmI16 = false; // don't use it on ZX cpus
> +    }
> +    if( (cpu_family() == 6)|| (cpu_family() == 7) ) {
> +      if( FLAG_IS_DEFAULT(UseAddressNop) ) {
> +        // Use it on all ZX cpus
> +        UseAddressNop = true;
> +      }
> +    }
> +    if( FLAG_IS_DEFAULT(UseXmmLoadAndClearUpper) ) {
> +      UseXmmLoadAndClearUpper = true; // use movsd on all ZX cpus
> +    }
> +    if( FLAG_IS_DEFAULT(UseXmmRegToRegMoveAll) ) {
> +      if( supports_sse3() ) {
> +        UseXmmRegToRegMoveAll = true; // use movaps, movapd on new ZX cpus
> +      } else {
> +        UseXmmRegToRegMoveAll = false;
> +      }
> +    }
> +    if( ((cpu_family() == 6)||(cpu_family() == 7)) && supports_sse3() )
> +{ // new ZX cpus #ifdef COMPILER2
> +      if( FLAG_IS_DEFAULT(MaxLoopPad) ) {
> +        // For new ZX cpus do the next optimization:
> +        // don't align the beginning of a loop if there are enough instructions
> +        // left (NumberOfLoopInstrToAlign defined in c2_globals.hpp)
> +        // in current fetch line (OptoLoopAlignment) or the padding
> +        // is big (> MaxLoopPad).
> +        // Set MaxLoopPad to 11 for new ZX cpus to reduce number of
> +        // generated NOP instructions. 11 is the largest size of one
> +        // address NOP instruction '0F 1F' (see Assembler::nop(i)).
> +        MaxLoopPad = 11;
> +      }
> +#endif // COMPILER2
> +      if (FLAG_IS_DEFAULT(UseXMMForArrayCopy)) {
> +        UseXMMForArrayCopy = true; // use SSE2 movq on new ZX cpus
> +      }
> +      if (supports_sse4_2()) { // new ZX cpus
> +        if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) {
> +          UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus
> +        }
> +      }
> +      if (supports_sse4_2()) {
> +        if (FLAG_IS_DEFAULT(UseSSE42Intrinsics)) {
> +          FLAG_SET_DEFAULT(UseSSE42Intrinsics, true);
> +        }
> +      } else {
> +        if (UseSSE42Intrinsics && !FLAG_IS_DEFAULT(UseAESIntrinsics)) {
> +          warning("SSE4.2 intrinsics require SSE4.2 instructions or higher. Intrinsics will be disabled.");
> +        }
> +        FLAG_SET_DEFAULT(UseSSE42Intrinsics, false);
> +      }
> +    }
> +
> +    if(FLAG_IS_DEFAULT(AllocatePrefetchInstr) && supports_3dnow_prefetch()) {
> +      FLAG_SET_DEFAULT(AllocatePrefetchInstr, 3);
> +    }
> +  }
> +
>     if( is_amd() ) { // AMD cpus specific settings
>       if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) {
>         // Use it on new AMD cpus starting from Opteron.
> @@ -1370,6 +1435,14 @@
>   #ifdef COMPILER2
>       if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) {
>         FLAG_SET_DEFAULT(UseFPUForSpilling, true);
> +    }
> +#endif
> +  }
> +
> +    if (is_zx() && ((cpu_family() == 6)||(cpu_family() == 7)) &&
> +supports_sse3()) { #ifdef COMPILER2
> +    if (FLAG_IS_DEFAULT(UseFPUForSpilling) && supports_sse4_2()) {
> +      FLAG_SET_DEFAULT(UseFPUForSpilling, true);
>       }
>   #endif
>     }
> diff -Nur org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp
> --- org/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-08 03:33:00.000000000 +0800
> +++ zx/jdk/src/hotspot/cpu/x86/vm_version_x86.hpp2017-12-28 14:15:18.000000000 +0800
> @@ -305,6 +305,9 @@
>     enum Extended_Family {
>       // AMD
>       CPU_FAMILY_AMD_11H       = 0x11,
> +    // ZX
> +    CPU_FAMILY_ZX_CORE_F6    = 6,
> +    CPU_FAMILY_ZX_CORE_F7    = 7,
>       // Intel
>       CPU_FAMILY_INTEL_CORE    = 6,
>       CPU_MODEL_NEHALEM        = 0x1e,
> @@ -549,6 +552,16 @@
>         }
>       }
> 
> +// ZX features.
> +    if(is_zx()) {
> +      if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0)
> +        result |= CPU_LZCNT;
> +      // for ZX, ecx.bits.misalignsse bit (bit 8) indicates support for prefetchw
> +      if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) {
> +        result |= CPU_3DNOW_PREFETCH;
> +      }
> +    }
> +
>       return result;
>     }
> 
> @@ -657,6 +670,7 @@
>     static bool is_P6()             { return cpu_family() >= 6; }
>     static bool is_amd()            { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA'
>     static bool is_intel()          { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG'
> +  static bool is_zx()             { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543)||(_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS  '
>     static bool is_atom_family()    { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton
>     static bool is_knights_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x57) || (extended_cpu_model() == 0x85))); } // Xeon Phi 3200/5200/7200 and Future Xeon Phi
> 
> @@ -680,7 +694,16 @@
>         }
>       } else if (is_amd()) {
>         result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1);
> -    }
> +    } else if (is_zx()) {
> +  bool supports_topology = supports_processor_topology();
> +      if (supports_topology) {
> +        result = _cpuid_info.tpl_cpuidB1_ebx.bits.logical_cpus /
> +                 _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
> +      }
> +      if (!supports_topology || result == 0) {
> +        result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1);
> +      }
> +}
>       return result;
>     }
> 
> @@ -688,7 +711,9 @@
>       uint result = 1;
>       if (is_intel() && supports_processor_topology()) {
>         result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
> -    } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) {
> +    } else if (is_zx() && supports_processor_topology()) {
> +  result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus;
> +} else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) {
>         if (cpu_family() >= 0x17) {
>           result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1;
>         } else {
> @@ -705,7 +730,9 @@
>         result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1);
>       } else if (is_amd()) {
>         result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size;
> -    }
> +    } else if (is_zx()) {
> +  result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1);
> +}
>       if (result < 32) // not defined ?
>         result = 32;   // 32 bytes by default on x86 and other x64
>       return result;
> 
> Finally, running the jtreg test. I run 2 jtreg tests(jtreg:test/jdk:tier1 and jtreg:test/langtools:tier1) and both of them are pass.
> The results are as follows.
> ==============================
> Test summary
> ==============================
>     TEST                                              TOTAL  PASS  FAIL ERROR
>     jtreg:test/jdk:tier1                               1660  1660     0     0
>     jtreg:test/langtools:tier1                          3828  3828     0     0
>     jtreg:test/nashorn:tier1                              0     0     0     0
>     jtreg:test/jaxp:tier1                                 0     0     0     0
> ==============================
> TEST SUCCESS
> 
> Best Regards!
> VicWang | R&D
> Telephone:+86-01082695388-892477
> 
> 
> ?????
> ?????????????????????????????????????????????????????
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.
> 

From ted at tedneward.com  Sun Dec 24 11:01:17 2017
From: ted at tedneward.com (Ted Neward)
Date: Sun, 24 Dec 2017 03:01:17 -0800
Subject: Another question, if I may?
In-Reply-To: <385762d8-6714-29d9-0082-0316ddb2f0ff@oracle.com>
References: <05445331-D592-47C9-BB92-A4F2CABD90D5@tedneward.com>
 <bfc85d29-6ab7-c598-8ac1-4ac8643edda1@oracle.com>
 <6d700333-64b5-17d8-bc1f-50f57c8b4397@oracle.com>
 <67405D37-1243-46D5-B1D1-1A7A7A345D1C@tedneward.com>
 <070a95b7-b806-09ef-dd8a-39e5baea0447@oracle.com>
 <385762d8-6714-29d9-0082-0316ddb2f0ff@oracle.com>
Message-ID: <98191FCC-06DC-49F9-8464-78B045A65F85@tedneward.com>

So if I do a "make hotspot" it replaces the compiled Hotspot binary in the exploded build image?

The reason I ask is that this is what I tried, and it didn?t appear to show up in the list of "PrintFlagsFinal" output.

Ted Neward
Author, Speaker, Mentor
http://www.newardassociates.com
t: @tedneward | m: (425) 647-4526

?On 12/22/17, 12:32 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:

    
    
    On 2017-12-22 01:06, David Holmes wrote:
    >
    > "make hotspot" won't update the image, you need to "make images" for 
    > that.
    >
    > Assuming you're building 9+ then when you change libjvm.so the module 
    > needs to be rebuilt etc.
    >
    > Or you can work from the exploded build the contents of e.g.
    >
    >  build/linux-x64-debug/jdk/
    >
    > though you still need a full build to prime that. But after that "make 
    > hotspot" should suffice. (Erik correct me if I'm wrong here please.)
    This is correct. Using the exploded image as described is the shortcut 
    we have. The actual images are always built using jmod/jlink and yes, 
    that requires quite a bit of extra build time.
    
    If you are in JDK 8, you need to run "make jdk" to get the exploded 
    image updated with the new libjvm.so.
    
    /Erik