Excellent!
David and Mandy have formally approved, so I'll push the current version of the
patch.
Paul
On 9/25/19, 11:39 AM, "Mandy Chung" wrote:
One point to note is that JVM TI, JDI and JDWP are supported interfaces.
jmm.h (and jvm.h and possibly others) are private interface
One point to note is that JVM TI, JDI and JDWP are supported interfaces.
jmm.h (and jvm.h and possibly others) are private interface between VM
and libraries and it has the freedom to make any change (even dropping
JMM_VERSION - this can be done in the future).
For this patch to move forward,
In the interest of getting this patch pushed, can I get confirmation to leave
it as is with JMM_VERSION_3 = 0x2003000? It's not used anywhere yet.
Imo best to file a new issue to change to the new scheme, which would redefine
JMM_VERSION_3 = JMM_VERSION_14 = 0x200E. JMM_VERSION_2 would get c
I can change 0x2003 to 0x200E to conform to that. Let me know what's
wanted.
Paul
On 9/24/19, 12:46 PM, "serguei.spit...@oracle.com"
wrote:
Hi Paul and Mandy,
There was a move from Mikael Vidsted to unify the versioning.
The idea is to keep versions in sync with the
Hi Paul and Mandy,
There was a move from Mikael Vidsted to unify the versioning.
The idea is to keep versions in sync with the JDK versions.
Now, for JVMTI we have (see,
https://bugs.openjdk.java.net/browse/JDK-8219023):
enum {
JVMTI_VERSION_1 = 0x3001,
JVMTI_VERSION_1_0 = 0x3001
Excellent. Updated webrev at http://cr.openjdk.java.net/~phh/8231209/webrev.02/
On 9/24/19, 10:03 AM, "Mandy Chung" wrote:
It's fine by me. I have no strong opinion.
Mandy
On 9/24/19 9:58 AM, Hohensee, Paul wrote:
> Do we want to increment the JMM version by one whenev
It's fine by me. I have no strong opinion.
Mandy
On 9/24/19 9:58 AM, Hohensee, Paul wrote:
Do we want to increment the JMM version by one whenever we change the spec
regardless of JDK version? If so, we'd have
JMM_VERSION_2 = 0x2002, // JDK 10
JMM_VERSION_3 = 0x2003, // JDK 14
JMM_V
Do we want to increment the JMM version by one whenever we change the spec
regardless of JDK version? If so, we'd have
JMM_VERSION_2 = 0x2002, // JDK 10
JMM_VERSION_3 = 0x2003, // JDK 14
JMM_VERSION = JMM_VERSION_3
On 9/24/19, 9:54 AM, "Mandy Chung" wrote:
On 9/24/19 9:51 AM, Ho
On 9/24/19 9:51 AM, Hohensee, Paul wrote:
I did JBS queries for, e.g.,
Issuetype=CSR AND Subcomponent="java.lang.management" AND fixVersion=11
For 11, I got
https://bugs.openjdk.java.net/browse/JDK-8199295: Remove SNMP agent
https://bugs.openjdk.java.net/browse/JDK-8198732:
ThreadInfo.from
I did JBS queries for, e.g.,
Issuetype=CSR AND Subcomponent="java.lang.management" AND fixVersion=11
For 11, I got
https://bugs.openjdk.java.net/browse/JDK-8199295: Remove SNMP agent
https://bugs.openjdk.java.net/browse/JDK-8198732:
ThreadInfo.from(CompositeData) does not throw IAE when the giv
On 9/24/19 8:45 AM, Hohensee, Paul wrote:
Good idea. The current definition is
enum {
JMM_VERSION_1 = 0x2001,
JMM_VERSION_1_0 = 0x2001,
JMM_VERSION_1_1 = 0x20010100, // JDK 6
JMM_VERSION_1_2 = 0x20010200, // JDK 7
JMM_VERSION_1_2_1 = 0x20010201, // JDK 7 GA
JMM_VERSIO
$ hg annot src/hotspot/share/include/jmm.h | grep JMM_VERSION_2
47592: JMM_VERSION_2 = 0x2002, // JDK 10
$ hg log -r 47592
changeset: 47592:68d46cb9be45
user: uvangapally
date: Thu Oct 05 01:31:53 2017 -0700
summary: 8185003: JMX: Add a version of ThreadMXBean.dumpAllT
Thank you, Mandy.
Paul
On 9/23/19, 8:29 PM, "Mandy Chung" wrote:
Looks fine.
I added myself to the CSR reviewer. I don't categorize it as source
incompatibility as other implementation outside JDK is not supported. I
took the liberty to edit the compatibility kind.
Good idea. The current definition is
enum {
JMM_VERSION_1 = 0x2001,
JMM_VERSION_1_0 = 0x2001,
JMM_VERSION_1_1 = 0x20010100, // JDK 6
JMM_VERSION_1_2 = 0x20010200, // JDK 7
JMM_VERSION_1_2_1 = 0x20010201, // JDK 7 GA
JMM_VERSION_1_2_2 = 0x20010202,
JMM_VERSION_2 = 0x2002000
Good question.
When HS express (mix-n-matched JDK and HS version) was supported, the
JMM_VERSION was rev'ed to enable the version checking. HS express is no
longer supported. JDK is supported to run with this version of HotSpot
VM. OTOH, this adds a new function in the middle of the functio
Looks fine.
I added myself to the CSR reviewer. I don't categorize it as source
incompatibility as other implementation outside JDK is not supported. I
took the liberty to edit the compatibility kind.
Mandy
On 9/23/19 5:42 PM, Hohensee, Paul wrote:
Update:
Bug: https://bugs.openjdk.java.
Hi Paul,
I have a question about JMM_VERSION. Since the changeset introduces a new
method in the interface
should not JMM_VERSION declared in src/hotspot/share/include/jmm.h be bumped?
Thank you,
--Daniil
On 9/23/19, 5:43 PM, "serviceability-dev on behalf of Hohensee, Paul"
wrote:
U
Hi Paul,
That all seems fine to me.
CSR reviewed as well.
Thanks,
David
-
On 24/09/2019 10:42 am, Hohensee, Paul wrote:
Update:
Bug: https://bugs.openjdk.java.net/browse/JDK-8231209
CSR: https://bugs.openjdk.java.net/browse/JDK-8231374
Webrev: http://cr.openjdk.java.net/~phh/8231209/webr
Update:
Bug: https://bugs.openjdk.java.net/browse/JDK-8231209
CSR: https://bugs.openjdk.java.net/browse/JDK-8231374
Webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.01/
All test suites that reference getThreadAllocatedBytes pass. These are
hotspot/jtreg/vmTestbase/nsk/monitoring (contained
Hi,
On 21/09/2019 00:28, Hohensee, Paul wrote:
java.lang.management.ThreadMXBean has two default methods that throw
UnsupportedOperationException:
ThreadInfo[] getThreadInfo(long[], boolean, boolean, int)
ThreadInfo[] dumpAllThreads(boolean, boolean, int)
Without actually testing it, is it sa
java.lang.management.ThreadMXBean has two default methods that throw
UnsupportedOperationException:
ThreadInfo[] getThreadInfo(long[], boolean, boolean, int)
ThreadInfo[] dumpAllThreads(boolean, boolean, int)
Without actually testing it, is it safe to assume that since
com.sun.management.Thread
Hi Paul,
It might be worth double checking what happens if you create a
MXBean proxy to access the com.sun.management.ThreadMXBean
in a remote server:
https://download.java.net/java/early_access/jdk14/docs/api/java.management/java/lang/management/ManagementFactory.html#getPlatformMXBean(javax.ma
Hi Paul,
I have almost the same comments as David:
- the same two spots of changes identified
- the addition of the default method was expected
- the change in test is a surprise (I also doubt, it is really needed)
- new CSR is needed
Sorry, I forgot to remind about running the vmTestbase m
On 20/09/2019 9:33 am, Mandy Chung wrote:
On 9/19/19 4:06 PM, David Holmes wrote:
2. You implemented the new method in the test class.
I don't understand why you did that. The test can't be calling the new
method. Now that it is a default method we will get past the
compilation failure that
On 9/19/19 4:06 PM, David Holmes wrote:
2. You implemented the new method in the test class.
I don't understand why you did that. The test can't be calling the new
method. Now that it is a default method we will get past the
compilation failure that caused the problem. So no change to the
Hi Paul,
On 20/09/2019 2:52 am, Hohensee, Paul wrote:
More formally,
Bug: https://bugs.openjdk.java.net/browse/JDK-8231209
Webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.00/
I'm assuming there are only two changes here:
1. The new method is now a default method that throws UOE.
That
On 9/19/19 9:52 AM, Hohensee, Paul wrote:
More formally,
Bug: https://bugs.openjdk.java.net/browse/JDK-8231209
Webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.00/
The new metric you added is an attribute (not an operation). So the
change in ServerThreadMXBeanNew should call getLon
More formally,
Bug: https://bugs.openjdk.java.net/browse/JDK-8231209
Webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.00/
Thanks,
On 9/19/19, 9:44 AM, "serviceability-dev on behalf of Hohensee, Paul"
wrote:
Off by 2 error. Changed the subject to reflect 8231209.
http://cr
Off by 2 error. Changed the subject to reflect 8231209.
http://cr.openjdk.java.net/~phh/8231209/webrev.00/
Paul
On 9/19/19, 6:31 AM, "Daniel D. Daugherty" wrote:
> http://cr.openjdk.java.net/~phh/8231211/webrev.00/
The redo bug is 8231209. 8231211 is closed as a dup of 8231210.
29 matches
Mail list logo
