I'll have the default method throw UOE. That's the same as the other default
methods do.
The necessary test fix is in
test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/server/ServerThreadMXBeanNew.java,
which needs a new getCurrentThreadAllocatedBytes method, defined as
public long
On 19/09/2019 12:57 pm, Mandy Chung wrote:
On 9/18/19 5:00 PM, Hohensee, Paul wrote:
They all implement com.sun.management.ThreadMXBean, so adding a
getCurrentThreadAllocatedBytes broke them. Potential fix is to give it
a default implementation, vis
public default long
On 9/18/19 5:00 PM, Hohensee, Paul wrote:
They all implement com.sun.management.ThreadMXBean, so adding a
getCurrentThreadAllocatedBytes broke them. Potential fix is to give it a
default implementation, vis
public default long getCurrentThreadAllocatedBytes() {
return -1;
}
gt;> > > > >> It looks great now!
> >>> > > > >>
> >>> > > > >> Thanks,
> >>> > > >
gt;
>>> > > > >> Thanks,
>>> > > > >> Serguei
>>> > > > >>
>>> > > > >>
>>> > > > >> On 9/15/19 02:52, Hohensee, P
> > >> Serguei
>>> > > > >>
>>> > > > >>
>>> > > > >>
> > > > David
> > > >
> > > >> Paul
> > > >>
> > > >> *From:
On 18/09/2019 8:50 am, David Holmes wrote:
>> > > > > On 18/09/2019 12:10 am, Hohensee,
>> Paul wrote:
>> > > > >>
> >>
> > > > >> David, are you ok with the patch?
> > > > >
> > > > > Yep, nothing further from me.
> > > > >
> > > >
instances of “TEST FAILED: “.
> > > >>
> > > >>
> > > >>
> >
> > > >> Paul
> > > >>
> > > >> *From: *"serguei.spit...@oracle.com"
> > > >> *Date: *Tuesday, Septem
>
> > > > David
> > > >
> > > >> Paul
> > > >>
> > > >> *From: *"serguei.spit...@oracle.com"
> >
> > >> return path after it
> > >>
> > >> has obtained the first memory
value. The check might also
> > >> fail if using
>
> David
> > >
> > >> Paul
> > >>
> > >> *From: *"serguei.spit...@oracle.com"
> > >> *Date: *Tuesday, Septem
gt; *Date: *Tuesday, September 17, 2019 at 2:26 AM
>> *To: *"Hohensee, Paul" , David Holmes
>> , Mandy Chung
>> *Cc: *OpenJDK Serviceability ,
>> "hotspot-gc-...@openjdk.java.net"
>>
> > >> Paul
> > >>
> > >> *From: *"serguei.spit...@oracle.com"
> > >> *Date: *Tuesday, September 17, 2019 at 2:26 AM
> >
>> *From: *"serguei.spit...@oracle.com"
> >> *Date: *Tuesday, September 17, 2019 at 2:26 AM
> >> *To: *"Hohensee, Paul" , David Holmes
> >> , Mandy Chung
> >> *Cc: *OpenJD
>> *Date: *Tuesday, September 17, 2019 at 2:26 AM
> >> *To: *"Hohensee, Paul" , David Holmes
> >> , Mandy Chung
> >> *Cc: *OpenJDK Serviceability
,
> >> "hotspot-gc-...@openjdk.ja
t; that results in
>>
>> it executing a handshake operation that performs
>> allocation. Potentially
>>
>> there could be numerous non-deterministic actions that
>> might occur
>>
l"
>> <mailto:hohen...@amazon.com>, David Holmes
>> <mailto:david.hol...@oracle.com>, Mandy Chung
>> <mailto:mandy.ch...@oracle.com>
>> *Cc: *OpenJDK Serviceability
>&g
>> *Date: *Tuesday, September 17, 2019 at 2:26 AM
>> *To: *"Hohensee, Paul" , David Holmes
>> , Mandy Chung
>> *Cc: *OpenJDK Serviceability ,
>> "hotspot-gc-...@openjdk.java.net"
>> *Subje
"
>> <mailto:hohen...@amazon.com>, David Holmes
>> <mailto:david.hol...@oracle.com>, Mandy Chung
>> <mailto:mandy.ch...@oracle.com>
>> *Cc: *OpenJDK Serviceability
>> <mailto:serviceability-dev@ope
om>, Mandy Chung
<mailto:mandy.ch...@oracle.com>
*Cc: *OpenJDK Serviceability
<mailto:serviceability-dev@openjdk.java.net>,
"hotspot-gc-...@openjdk.java.net"
<mailto:hotspot-gc-...@openjdk.java.net>
<mailto:hotspot-gc-...@openjdk.java.net>
hung
> <mailto:mandy.ch...@oracle.com>
> *Cc: *OpenJDK Serviceability
> <mailto:serviceability-dev@openjdk.java.net>,
> "hotspot-gc-...@openjdk.java.net"
> <mailto:hotspot-gc-...@openjdk.java.net>
, Mandy Chung
*Cc: *OpenJDK Serviceability ,
"hotspot-gc-...@openjdk.java.net"
*Subject: *Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes()
can be quicker for self thread
Hi Paul,
Thank you for refactoring and fixing the test.
It looks great now!
Thanks,
Serguei
On 9/15/
enJDK Serviceability
,
"hotspot-gc-...@openjdk.java.net"
Subject: Re: RFR (M): 8207266:
ThreadMXBean::getThreadAllocatedBytes() can be quicker for
self thread
Hi Paul,
k it is
reliably doable.
Thanks,
David
-
>
> Paul
>
> *From: *Mandy Chung
> *Date: *Thursday, September 12, 2019 at 10:09 AM
> *To: *"Hohensee, Paul"
> *Cc: *OpenJDK Serviceability ,
> "hotspot-gc-
10:09 AM
> *To: *"Hohensee, Paul"
> *Cc: *OpenJDK Serviceability ,
> "hotspot-gc-...@openjdk.java.net"
> *Subject: *Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes()
> can be quicker for self thread
>
> On 9/3/19 12:38 PM,
> Paul
>
> *From: *Mandy Chung
> *Date: *Thursday, September 12, 2019 at 10:09 AM
> *To: *"Hohensee, Paul"
> *Cc: *OpenJDK Serviceability ,
> "hotspot-gc-...@openjdk.java.net"
> *Subject: *Re: RFR (M): 8207266: ThreadMXBea
207266: ThreadMXBean::getThreadAllocatedBytes()
can be quicker for self thread
On 9/3/19 12:38 PM, Hohensee, Paul wrote:
Minor update in new
webrevhttp://cr.openjdk.java.net/~phh/8207266/webrev.05/.
I only reviewed the library side implementation that looks good. I
expect the serviceab
Paul"
Date: Thursday, September 12, 2019 at 5:29 PM
To: Mandy Chung
Cc: OpenJDK Serviceability ,
"hotspot-gc-...@openjdk.java.net"
Subject: Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be
quicker for self thread
Thanks for clarifying the review rules
t;
Subject: Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be
quicker for self thread
On 9/3/19 12:38 PM, Hohensee, Paul wrote:
Minor update in new webrev http://cr.openjdk.java.net/~phh/8207266/webrev.05/.
I only reviewed the library side implementation that l
On 9/3/19 12:38 PM, Hohensee, Paul wrote:
Minor update in new webrev http://cr.openjdk.java.net/~phh/8207266/webrev.05/.
I only reviewed the library side implementation that looks good. I
expect the serviceability team to review the test and hotspot change.
Need a confirmatory review to
;Hohensee, Paul"
Cc: OpenJDK Serviceability ,
"hotspot-gc-...@openjdk.java.net"
Subject: Re: RFR (M): 8207266:
ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
CSR reviewed.
management.cp
Paul
From: Mandy Chung
Date: Friday, August 30, 2019 at 4:26 PM
To: "Hohensee, Paul"
Cc: OpenJDK Serviceability ,
"hotspot-gc-...@openjdk.java.net"
Subject: Re: RFR (M): 8207266: ThreadMXBean::getThreadAl
ity-dev@openjdk.java.net>,
"hotspot-gc-...@openjdk.java.net"<mailto:hotspot-gc-...@openjdk.java.net>
<mailto:hotspot-gc-...@openjdk.java.net>
Subject: Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can
be quicker for self thread
Hi Paul,
, Paul"
Cc: OpenJDK Serviceability ,
"hotspot-gc-...@openjdk.java.net"
Subject: Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be
quicker for self thread
CSR reviewed.
management.cpp
2083 java_thread = (JavaThread*)THREAD;
2084 if (java_thread->is_Java_
the test please?
Paul
*From: *Mandy Chung
*Date: *Friday, August 30, 2019 at 10:22 AM
*To: *"Hohensee, Paul"
*Cc: *OpenJDK Serviceability ,
"hotspot-gc-...@openjdk.java.net"
*Subject: *Re: RFR (M): 8207266:
ThreadMXBean::getThreadAllocatedBytes() can be quicker for self t
bility-dev@openjdk.java.net>,
"hotspot-gc-...@openjdk.java.net"<mailto:hotspot-gc-...@openjdk.java.net>
<mailto:hotspot-gc-...@openjdk.java.net>
Subject: Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be
quicker for self thread
Hi Paul,
The CSR propose
s,
Paul
*From: *Mandy Chung
*Date: *Wednesday, August 28, 2019 at 3:59 PM
*To: *"Hohensee, Paul"
*Cc: *OpenJDK Serviceability ,
"hotspot-gc-...@openjdk.java.net"
*Subject: *Re: RFR (M): 8207266:
ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
Hi
Yes. See previous email.
Thanks,
On 8/29/19, 12:19 AM, "Alan Bateman" wrote:
On 28/08/2019 23:58, Mandy Chung wrote:
> Hi Paul,
>
> The CSR proposes this method in java.lang.management.ThreadMXBean as a
> Java SE feature.
>
> Has this been discussed with the GC
On 28/08/2019 23:58, Mandy Chung wrote:
Hi Paul,
The CSR proposes this method in java.lang.management.ThreadMXBean as a
Java SE feature.
Has this been discussed with the GC team to commit measuring current
thread's allocated bytes as Java SE feature? Can this be supported
by all JVM
Hi Paul,
The CSR proposes this method in java.lang.management.ThreadMXBean as a
Java SE feature.
Has this been discussed with the GC team to commit measuring current
thread's allocated bytes as Java SE feature? Can this be supported by
all JVM implementation? What is the overhead if
On 28/08/2019 20:22, Hohensee, Paul wrote:
Please review a performance improvement for
ThreadMXBean.getThreadAllocatedBytes and the addition of
getCurrentThreadAllocatedBytes.
JBS issue:https://bugs.openjdk.java.net/browse/JDK-8207266
44 matches
Mail list logo
