Re: RFR(M): 8220628: Move the HeapMonitor library to C++

[Chris Plummer]

  
  
That's fine. LGMT.


Chris



On 3/13/19 8:00 PM, Jean Christophe
  Beyler wrote:


  
  Hi Chris,


Thanks for the review, we could debate here about
  reinterpret vs static (my theory/understanding was do static
  if all else fails (and then do C style if that fails)) but
  really I'm going to do new/delete right after this and so all
  those casts will disappear in the next webrev. So in my
  opinion if your Looks good can be a LGTM then we will remove
  the casts in the next ones.


Let me know what you think.


Thanks,
Jc




  
  
  
On Wed, Mar 13, 2019 at 5:59
  PM Chris Plummer 
  wrote:


  
Hi
  JC,
  
  Looks good. My only question is your use of
  reinterpret_cast instead of static_cast. Not an area of
  C++ I know much about, other than  having just read some
  varying opinions that aren't all that good at explaining
  what's going on.
  
  thanks,
  
  Chris
  
  On 3/13/19 4:07 PM, Jean Christophe Beyler wrote:


  Hi all,


Could I get a review of:
Bug: https://bugs.openjdk.java.net/browse/JDK-8220628

Webrev: http://cr.openjdk.java.net/~jcbeyler/8220628/


I've not tried to do anything special here to keep
  the review simple; in the next webrev or two, I'll
  move more code to more C++ style and then work on
  diagnostic print-outs (in C++ :-)) to figure out the
  issues with the bugs related to these tests.


This passed testing on my dev machine and a submit
  repo run (which I'm not sure runs these test but still
  good to check).



  Thanks!
  
  

  Jc

  

  



  

  
  
  
  
  -- 
  

  
  
  Thanks,
  Jc

  



  

Re: RFR(M): 8220628: Move the HeapMonitor library to C++

[Jean Christophe Beyler]

Hi Chris,

Thanks for the review, we could debate here about reinterpret vs static (my
theory/understanding was do static if all else fails (and then do C style
if that fails)) but really I'm going to do new/delete right after this and
so all those casts will disappear in the next webrev. So in my opinion if
your Looks good can be a LGTM then we will remove the casts in the next
ones.

Let me know what you think.

Thanks,
Jc



On Wed, Mar 13, 2019 at 5:59 PM Chris Plummer 
wrote:

> Hi JC,
>
> Looks good. My only question is your use of reinterpret_cast instead of
> static_cast. Not an area of C++ I know much about, other than  having just
> read some varying opinions that aren't all that good at explaining what's
> going on.
>
> thanks,
>
> Chris
>
> On 3/13/19 4:07 PM, Jean Christophe Beyler wrote:
>
> Hi all,
>
> Could I get a review of:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220628
> Webrev: http://cr.openjdk.java.net/~jcbeyler/8220628/
>
> I've not tried to do anything special here to keep the review simple; in
> the next webrev or two, I'll move more code to more C++ style and then work
> on diagnostic print-outs (in C++ :-)) to figure out the issues with the
> bugs related to these tests.
>
> This passed testing on my dev machine and a submit repo run (which I'm not
> sure runs these test but still good to check).
>
> Thanks!
> Jc
>
>
>

-- 

Thanks,
Jc

Re: RFR(M): 8220628: Move the HeapMonitor library to C++

[Chris Plummer]

  
  
Hi JC,
  
  Looks good. My only question is your use of reinterpret_cast
  instead of static_cast. Not an area of C++ I know much about,
  other than  having just read some varying opinions that aren't all
  that good at explaining what's going on.
  
  thanks,
  
  Chris
  
  On 3/13/19 4:07 PM, Jean Christophe Beyler wrote:


  
  Hi all,


Could I get a review of:
Bug: https://bugs.openjdk.java.net/browse/JDK-8220628

Webrev: http://cr.openjdk.java.net/~jcbeyler/8220628/


I've not tried to do anything special here to keep the
  review simple; in the next webrev or two, I'll move more code
  to more C++ style and then work on diagnostic print-outs (in
  C++ :-)) to figure out the issues with the bugs related to
  these tests.


This passed testing on my dev machine and a submit repo run
  (which I'm not sure runs these test but still good to check).



  Thanks!
  
  

  Jc

  

  



  

Re: RFR(M): 8220628: Move the HeapMonitor library to C++

[serguei.spit...@oracle.com]

  
  
Hi Jc,
  
  I do not see any issues, it looks good.
  This is nice as the code became simpler.
  
  Thanks,
  Serguei
  
  
  On 3/13/19 16:07, Jean Christophe Beyler wrote:


  Hi all,


Could I get a review of:
Bug: https://bugs.openjdk.java.net/browse/JDK-8220628

Webrev: http://cr.openjdk.java.net/~jcbeyler/8220628/


I've not tried to do anything special here to keep the
  review simple; in the next webrev or two, I'll move more code
  to more C++ style and then work on diagnostic print-outs (in
  C++ :-)) to figure out the issues with the bugs related to
  these tests.


This passed testing on my dev machine and a submit repo run
  (which I'm not sure runs these test but still good to check).



  Thanks!
  
  

  Jc

  

  


  

Re: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

[dean . long]

I don't know how to interpret "ignore checks if thread was collected", 
so it doesn't add much value for me.

How about something like "ignore ownedMonitors() failure"?

dl

On 3/13/19 8:54 AM, Gary Adams wrote:

One last set of diffs ...
  - added comments on the ignored exceptions
  - commented out excessive diagnostic print out
 (this will remove the jtreg truncated output)

Ok to use dan, dean and jc as reveiwers?

diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java 
b/test/jdk/com/sun/jdi/SimulResumerTest.java

--- a/test/jdk/com/sun/jdi/SimulResumerTest.java
+++ b/test/jdk/com/sun/jdi/SimulResumerTest.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -210,7 +210,9 @@
 }

 } catch (IncompatibleThreadStateException ee) {
-    // ignore
+    // ignore checks if thread was not suspended
+    } catch (ObjectCollectedException ee) {
+    // ignore checks if thread was collected
 } catch (VMDisconnectedException ee) {
 // This is how we stop.  The debuggee runs to completion
 // and we get this exception.
@@ -249,7 +251,7 @@
 public void run() {
 while (true) {
 iters++;
-    System.out.println("bkpts = " + bkpts + ", 
iters = " + iters);
+    // System.out.println("bkpts = " + bkpts + ", 
iters = " + iters);

 try {
 Thread.sleep(waitTime);
 check(debuggeeThread1);



On 3/7/19, 8:19 AM, Gary Adams wrote:

While trying to reproduce the timeout reported in
  JDK-8000669: com/sun/jdi/SimulResumerTest.java times out

I was unable to reproduce the timeout failure, but I did occasionally
see the ObjectCollectedException. The output from the test is very 
verbose
and may be the source of the occasional timeout. I'd like to close 
JDK-8000669
as cannot reproduce and if it shows up again look into limiting the 
amount

of non-essential output from the test.

This is a racy test to begin with and it already is ignoring exceptions
due to unexpected thread states. Adding the ignore for 
ObjectCollectedException

allows the test to complete without errors.

The graal label was recently removed. We should also remove it from 
the summary.


Proposed changeset:


diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java 
b/test/jdk/com/sun/jdi/SimulResumerTest.java

--- a/test/jdk/com/sun/jdi/SimulResumerTest.java
+++ b/test/jdk/com/sun/jdi/SimulResumerTest.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All 
rights reserved.
+ * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All 
rights reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -211,6 +211,8 @@

 } catch (IncompatibleThreadStateException ee) {
 // ignore
+    } catch (ObjectCollectedException ee) {
+    // ignore
 } catch (VMDisconnectedException ee) {
 // This is how we stop.  The debuggee runs to 
completion

 // and we get this exception.

Re: [11] [12] RFR 8210457: JVM crash in ResolvedMethodTable::add_method(Handle)

[coleen . phillimore]

Thank you Serguei!
Coleen

On 3/13/19 1:48 PM, serguei.spit...@oracle.com wrote:

Hi Coleen,

Both backports look good to me.

Thanks,
Serguei


On 3/12/19 15:07, coleen.phillim...@oracle.com wrote:
Summary: Add a function to call NSME in ResolvedMethodTable to 
replace deleted methods.


Please review a backport of this bug to JDK 11 and 12.  The JDK 12 
backport required some manual merging in 
ResolvedMethodTable::adjust_method_entries to account for some 
preceding cleanup in the original.  The JDK 11 backport patched 
cleanly from the 12 backport except for the copyright on Unsafe.java.


The JDK 13 patch: http://hg.openjdk.java.net/jdk/jdk/rev/09cba396916f

JDK 12 webrev: 
http://cr.openjdk.java.net/~coleenp/2019/8210457.01.12/webrev
JDK 11 webrev: 
http://cr.openjdk.java.net/~coleenp/2019/8210457.01.11/webrev


I only have approval for JDK 11 at the moment.

These patches passed mach5 tier1 and 2, and the jvmti and 
java/lang/instrument redefinition jtreg tests.


Thanks,
Coleen

Re: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle

[serguei.spit...@oracle.com]

Hi Chris,

Looks good.

Thanks,
Serguei


On 3/12/19 23:28, Chris Plummer wrote:

Hi,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8220352
http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/

The possible use of an invalid jni handle is being avoided by not 
deleting the globalrefs as the test exits. This is the same fix that 
was applied to JDK-8172995 when the same situation turned up there.


Before the fix I was able to reproduce the issue after 700 runs. I did 
1100 after the fix and did not see any problems.


thanks,

Chris

Re: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed

[serguei.spit...@oracle.com]

  
  
Hi Daniil,
  
  LGTM++
  
  Thanks,
  Serguei
  
  On 3/11/19 17:43, Jean Christophe Beyler wrote:


  Hi Daniil,

  
Looks good to me :)

  Thanks,
Jc
  
  
  
On Mon, Mar 11, 2019 at 4:32
  PM Daniil Titov 
  wrote:

Hi Dean, JC and Daniel,
  
  Thank you for reviewing this change. Based on the overall
  output it seems as the common consensus is that the broader
  discussions is required to decide what would be a proper way
  to optionally hide/mute JVMCI compiler threads (and probably
  some other “system” Java threads) from JVMTI clients.  Thus,
  my suggestion is to move this discussion in a new enhancement
  [3] and limit the current issue just to the fixing the test
  itself.
  
  Please review a new version of the webrev that adds  JVMCI
  compiler and "HotSpotGraalManagement Bean Registration"
  threads to the list of the threads the tests must ignore.
  
  
  Reference:
  --
  [1] Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 
  
  [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8218812
  
  [3] Enhancement: https://bugs.openjdk.java.net/browse/JDK-8220468
  
  Thanks,
  Daniil
  
  From: 
  Organization: Oracle Corporation
  Date: Thursday, March 7, 2019 at 12:19 PM
  To: Daniil Titov ,
  OpenJDK Serviceability 
  Subject: Re: RFR: 8218812:
  vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java
  failed
  
  There are other places where is_hidden_from_external_view() is
  used.  Should is_hidden_from_external_view() also check the
  new capability?  If so, then you can simplify your changes. 
  I'm not sure the new capability is the best choice, however. 
  There is still no way to control whether compiler threads can
  post events, hit breakpoints, single-step, etc.  And "compiler
  thread" might be too specific.  There might be other types of
  "system thread" that we want to ignore.  Since this is a JVMTI
  spec change, I think it deserves more discussion.  For
  example, an alternative would be a way to set "can
  debug"/"visible"/"can post events"/etc flags on individual
  threads.
  
  dl
  On 3/7/19 9:54 AM, Daniil Titov wrote:
  Please review a change that fixes this test. 
   
  The problem here is that the test checks the number of threads
  and with Graal on additional threads the test doesn't expect
  are started and cause the test fail. 
   
  The fix introduces a new capability "
  can_show_compiler_threads" that affects whether Java compiler
  threads are retuned with JVMTI GetAllThreads call. By default
  this capability is off. The fix also adds "
  HotSpotGraalManagement Bean Registration" thread to the list
  of the threads the tests must ignore. 
   
  Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01
  
  Bug: https://bugs.openjdk.java.net/browse/JDK-8218812
  
   
  Mach5 tier1, tier2 and tier3 tests successfully passed with
  this change. 
   
  Thanks!
  -Daniil
   
  
  
  
  

  
  
  
  
  -- 
  

  
  
  Thanks,
  Jc

  


  

Re: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle

[Chris Plummer]

  
  
Thanks for the reviews!



On 3/13/19 8:27 AM, Jean Christophe
  Beyler wrote:


  
  Looks good to me as well :). I was going to ask a
question but got the answer in the bug comment you put :),
thanks for being thorough in the explanation there!
Jc
  
  
  
On Wed, Mar 13, 2019 at 3:34
  AM gary.ad...@oracle.com 
  wrote:

Looks
  good to me.
  
  On 3/13/19 2:28 AM, Chris Plummer wrote:
  > Hi,
  >
  > Please review the following:
  >
  > https://bugs.openjdk.java.net/browse/JDK-8220352
  > http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/
  >
  > The possible use of an invalid jni handle is being
  avoided by not 
  > deleting the globalrefs as the test exits. This is the
  same fix that 
  > was applied to JDK-8172995 when the same situation turned
  up there.
  >
  > Before the fix I was able to reproduce the issue after
  700 runs. I did 
  > 1100 after the fix and did not see any problems.
  >
  > thanks,
  >
  > Chris
  
  

  
  
  
  
  -- 
  

  
  
  Thanks,
  Jc

  



  

Re: [11] [12] RFR 8210457: JVM crash in ResolvedMethodTable::add_method(Handle)

[serguei.spit...@oracle.com]

Hi Coleen,

Both backports look good to me.

Thanks,
Serguei


On 3/12/19 15:07, coleen.phillim...@oracle.com wrote:
Summary: Add a function to call NSME in ResolvedMethodTable to replace 
deleted methods.


Please review a backport of this bug to JDK 11 and 12.  The JDK 12 
backport required some manual merging in 
ResolvedMethodTable::adjust_method_entries to account for some 
preceding cleanup in the original.  The JDK 11 backport patched 
cleanly from the 12 backport except for the copyright on Unsafe.java.


The JDK 13 patch: http://hg.openjdk.java.net/jdk/jdk/rev/09cba396916f

JDK 12 webrev: 
http://cr.openjdk.java.net/~coleenp/2019/8210457.01.12/webrev
JDK 11 webrev: 
http://cr.openjdk.java.net/~coleenp/2019/8210457.01.11/webrev


I only have approval for JDK 11 at the moment.

These patches passed mach5 tier1 and 2, and the jvmti and 
java/lang/instrument redefinition jtreg tests.


Thanks,
Coleen

Re: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

[Jean Christophe Beyler]

Yes for me :) (though I'm not a Reviewer and I don't like commented code
generally, for diagnostic tests I usually just put a flag that is off by
default but no need to change it for me/this :-)),
Jc

On Wed, Mar 13, 2019 at 8:55 AM Gary Adams  wrote:

> One last set of diffs ...
>- added comments on the ignored exceptions
>- commented out excessive diagnostic print out
>   (this will remove the jtreg truncated output)
>
> Ok to use dan, dean and jc as reveiwers?
>
> diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java
> b/test/jdk/com/sun/jdi/SimulResumerTest.java
> --- a/test/jdk/com/sun/jdi/SimulResumerTest.java
> +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights
> reserved.
>* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>*
>* This code is free software; you can redistribute it and/or modify it
> @@ -210,7 +210,9 @@
>   }
>
>   } catch (IncompatibleThreadStateException ee) {
> -// ignore
> +// ignore checks if thread was not suspended
> +} catch (ObjectCollectedException ee) {
> +// ignore checks if thread was collected
>   } catch (VMDisconnectedException ee) {
>   // This is how we stop.  The debuggee runs to completion
>   // and we get this exception.
> @@ -249,7 +251,7 @@
>   public void run() {
>   while (true) {
>   iters++;
> -System.out.println("bkpts = " + bkpts + ",
> iters = " + iters);
> +// System.out.println("bkpts = " + bkpts + ",
> iters = " + iters);
>   try {
>   Thread.sleep(waitTime);
>   check(debuggeeThread1);
>
>
>
> On 3/7/19, 8:19 AM, Gary Adams wrote:
> > While trying to reproduce the timeout reported in
> >   JDK-8000669: com/sun/jdi/SimulResumerTest.java times out
> >
> > I was unable to reproduce the timeout failure, but I did occasionally
> > see the ObjectCollectedException. The output from the test is very
> > verbose
> > and may be the source of the occasional timeout. I'd like to close
> > JDK-8000669
> > as cannot reproduce and if it shows up again look into limiting the
> > amount
> > of non-essential output from the test.
> >
> > This is a racy test to begin with and it already is ignoring exceptions
> > due to unexpected thread states. Adding the ignore for
> > ObjectCollectedException
> > allows the test to complete without errors.
> >
> > The graal label was recently removed. We should also remove it from
> > the summary.
> >
> > Proposed changeset:
> >
> >
> > diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java
> > b/test/jdk/com/sun/jdi/SimulResumerTest.java
> > --- a/test/jdk/com/sun/jdi/SimulResumerTest.java
> > +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java
> > @@ -1,5 +1,5 @@
> >  /*
> > - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights
> > reserved.
> > + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights
> > reserved.
> >   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> >   *
> >   * This code is free software; you can redistribute it and/or modify it
> > @@ -211,6 +211,8 @@
> >
> >  } catch (IncompatibleThreadStateException ee) {
> >  // ignore
> > +} catch (ObjectCollectedException ee) {
> > +// ignore
> >  } catch (VMDisconnectedException ee) {
> >  // This is how we stop.  The debuggee runs to completion
> >  // and we get this exception.
>
>

-- 

Thanks,
Jc

Re: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

[Gary Adams]

One last set of diffs ...
  - added comments on the ignored exceptions
  - commented out excessive diagnostic print out
 (this will remove the jtreg truncated output)

Ok to use dan, dean and jc as reveiwers?

diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java 
b/test/jdk/com/sun/jdi/SimulResumerTest.java

--- a/test/jdk/com/sun/jdi/SimulResumerTest.java
+++ b/test/jdk/com/sun/jdi/SimulResumerTest.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -210,7 +210,9 @@
 }

 } catch (IncompatibleThreadStateException ee) {
-// ignore
+// ignore checks if thread was not suspended
+} catch (ObjectCollectedException ee) {
+// ignore checks if thread was collected
 } catch (VMDisconnectedException ee) {
 // This is how we stop.  The debuggee runs to completion
 // and we get this exception.
@@ -249,7 +251,7 @@
 public void run() {
 while (true) {
 iters++;
-System.out.println("bkpts = " + bkpts + ", 
iters = " + iters);
+// System.out.println("bkpts = " + bkpts + ", 
iters = " + iters);

 try {
 Thread.sleep(waitTime);
 check(debuggeeThread1);



On 3/7/19, 8:19 AM, Gary Adams wrote:

While trying to reproduce the timeout reported in
  JDK-8000669: com/sun/jdi/SimulResumerTest.java times out

I was unable to reproduce the timeout failure, but I did occasionally
see the ObjectCollectedException. The output from the test is very 
verbose
and may be the source of the occasional timeout. I'd like to close 
JDK-8000669
as cannot reproduce and if it shows up again look into limiting the 
amount

of non-essential output from the test.

This is a racy test to begin with and it already is ignoring exceptions
due to unexpected thread states. Adding the ignore for 
ObjectCollectedException

allows the test to complete without errors.

The graal label was recently removed. We should also remove it from 
the summary.


Proposed changeset:


diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java 
b/test/jdk/com/sun/jdi/SimulResumerTest.java

--- a/test/jdk/com/sun/jdi/SimulResumerTest.java
+++ b/test/jdk/com/sun/jdi/SimulResumerTest.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -211,6 +211,8 @@

 } catch (IncompatibleThreadStateException ee) {
 // ignore
+} catch (ObjectCollectedException ee) {
+// ignore
 } catch (VMDisconnectedException ee) {
 // This is how we stop.  The debuggee runs to completion
 // and we get this exception.

Fwd: Re: JMX

[netbeans]

-- Původní e-mail --
Od: Daniel Fuchs 
Komu: netbe...@post.cz, jdk-...@openjdk.java.net
Datum: 19. 2. 2019 19:56:19
Předmět: Re: JMX
"Hi,

JMX related issues are mostly discussed on the
serviceability-dev mailing list these days.

On 19/02/2019 09:31, netbe...@post.cz wrote:
>
> Dear Dev.
>
> 1) MXBeans
>
> I would like to recommend you simplify MXBeans as currently it is not so
> easy to use.
>
> E.g. If you need Map where even Serializable can be
> simple open types, so like dynamical for dirent key.

MXBeans are used to map model-specific interfaces to generic
openmbeans types. If your model consists of a map with dynamic
key value pairs - as opposed to an interface that has a number
of specific getters - then MXBeans may not be what you should
use.

For instance, you can achieve what you describe by reverting to using
an OpenMBean directly, and expose your map as a CompositeData
instead.

See:
https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/
management/package-summary.html
https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/
management/MXBean.html
and
https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/
management/openmbean/package-summary.html

[...]

> Additionally there is Date, but why it is not there new java.time objects.


JMX was added in Java 5. java.time in Java 8.

Extending the set of open types supported by MXBeans would offer
interesting challenges as to maintaining interoperability with
applications running on previous version of the JVM.
In other words: that might be hard.

> Or maybe MXBeans should be deprecated at all.

MXBeans work very well for their intended target usage.
They do have their limitations, but so have other types of
MBeans. It's a trade-off.


You can read about the different types of MBeans here:
https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/
management/package-summary.html


> 2) Maps vs MBean
>
> As you my know there is use e.g. what ever type parameter you choose there

> is get(Object) and similar to other methods.
>
> So if you would like to use it as MBean Proxy you need to create new
> interface extending e.g. Map (even target does it) and you

> have to explicitly create get(String).
>
> If you do not do it.

I am not sure I have understood all your concerns, but I believe
OpenMBeans and CompositeData is what might correspond to your needs.

best regards,

-- daniel

"

Re: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

[Gary Adams]

There is a caution in the disableCollection() docs that it should be used
sparingly, because the behavior between debug and non-debug runs
could differ. I actually prefer leaving the test in it's racy configuration.
The collection of the object is not central to what the test is actually
trying to observe. Ignoring the exception if it does occur allows the
test to complete the work it intends to cover.

On 3/12/19, 2:22 PM, Daniil Titov wrote:

Hi Gary,

The fix looks good. However, since there are only two references 
(debuggeeThread1 and debuggeeThread2) the test checks, an alternative to 
catching and ignoring ObjectCollectedException  could be just calling 
disableCollection() on these two thread references when a breakpoint handle is 
called (lines 130 and 135).

Thanks!

Best regards,
Daniil



On 3/12/19, 11:05 AM, "serviceability-dev on behalf of Gary 
Adams"  wrote:

 Still need 2 more reviewers ...

 On 3/7/19, 9:45 AM, Daniel D. Daugherty wrote:
 >  Gary,
 >
 >  Since the 'graal' label was recently removed, I also removed "[Graal]"
 >  from the bug synopsis. Please make sure you update your commit mesg.
 >
 >
 >  On 3/7/19 8:19 AM, Gary Adams wrote:
 >>  While trying to reproduce the timeout reported in
 >>JDK-8000669: com/sun/jdi/SimulResumerTest.java times out
 >>
 >>  I was unable to reproduce the timeout failure, but I did occasionally
 >>  see the ObjectCollectedException. The output from the test is very
 >>  verbose
 >>  and may be the source of the occasional timeout. I'd like to close
 >>  JDK-8000669
 >>  as cannot reproduce and if it shows up again look into limiting the
 >>  amount
 >>  of non-essential output from the test.
 >>
 >>  This is a racy test to begin with and it already is ignoring exceptions
 >>  due to unexpected thread states. Adding the ignore for
 >>  ObjectCollectedException
 >>  allows the test to complete without errors.
 >>
 >>  The graal label was recently removed. We should also remove it from
 >>  the summary.
 >>
 >>  Proposed changeset:
 >>
 >>
 >>  diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java
 >>  b/test/jdk/com/sun/jdi/SimulResumerTest.java
 >>  --- a/test/jdk/com/sun/jdi/SimulResumerTest.java
 >>  +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java
 >>  @@ -1,5 +1,5 @@
 >>   /*
 >>  - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All
 >>  rights reserved.
 >>  + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All
 >>  rights reserved.
 >>* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 >>*
 >>* This code is free software; you can redistribute it and/or modify 
it
 >>  @@ -211,6 +211,8 @@
 >>
 >>   } catch (IncompatibleThreadStateException ee) {
 >>   // ignore
 >>  +} catch (ObjectCollectedException ee) {
 >>  +// ignore
 >>   } catch (VMDisconnectedException ee) {
 >>   // This is how we stop.  The debuggee runs to
 >>  completion
 >>   // and we get this exception.
 >
 >  There should be some sort of comment explaining why it is okay to ignore
 >  the ObjectCollectedException. When the IncompatibleThreadStateException
 >  was ignored, there should have been a comment added for that also.
 >
 >  Dan
 >

Re: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle

[gary.ad...@oracle.com]

Looks good to me.

On 3/13/19 2:28 AM, Chris Plummer wrote:

Hi,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8220352
http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/

The possible use of an invalid jni handle is being avoided by not 
deleting the globalrefs as the test exits. This is the same fix that 
was applied to JDK-8172995 when the same situation turned up there.


Before the fix I was able to reproduce the issue after 700 runs. I did 
1100 after the fix and did not see any problems.


thanks,

Chris

RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle

[Chris Plummer]

Hi,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8220352
http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/

The possible use of an invalid jni handle is being avoided by not 
deleting the globalrefs as the test exits. This is the same fix that was 
applied to JDK-8172995 when the same situation turned up there.


Before the fix I was able to reproduce the issue after 700 runs. I did 
1100 after the fix and did not see any problems.


thanks,

Chris