Hi Daniil,
Looks good, thanks!
/Robbin
On 9/25/19 12:45 AM, David Holmes wrote:
Looks good to me.
Thanks,
David
On 25/09/2019 2:36 am, Daniil Titov wrote:
Hi Daniel, David and Serguei,
Please review a new version of the fix (webrev.08) that as Daniel suggested
renames
ThreadTable to Threa
Hi Evgeny,
The change looks good to me.
Thanks!
--Daniil
From: serviceability-dev on
behalf of Evgeny Mandrikov
Date: Tuesday, September 24, 2019 at 1:32 AM
To: David Holmes
Cc:
Subject: Re: RFR: JDK-8199136: Dead code in
src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumen
Hi Richard,
Thanks for continuing the discussion. Some responses below.
On 25/09/2019 7:28 am, Reingruber, Richard wrote:
Hi,
I would like to get comments on the following questions:
1. Should optimizations be observable for JVMTI agents in general?
Not a yes/no question IMO. I certainly
It is also not clear to me that it is bug. Based on all description this functionality is used to
catch leaks in Java heap. But scalar replaced objects do not exists. JVMTI should not even see them.
Thanks,
Vladimir
On 9/24/19 3:37 PM, Vladimir Kozlov wrote:
can_tag_objects is "always" capabil
Looks good to me.
Thanks,
David
On 25/09/2019 2:36 am, Daniil Titov wrote:
Hi Daniel, David and Serguei,
Please review a new version of the fix (webrev.08) that as Daniel suggested
renames
ThreadTable to ThreadIdTable (related classes and variables are renamed as
well) and
corrects formattin
can_tag_objects is "always" capability.
If it is true then EA will be disabled in all cases when JVMTI agent is used.
It is too broad.
Am I missing something?
Thanks,
Vladimir
On 9/13/19 7:12 AM, Reingruber, Richard wrote:
Hi,
could I please get reviews for
Webrev: http://cr.openjdk.java.n
Frederic, could you figure out how to resolve
8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166
refresh
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ReservedStackTest/index.html
https://bugs.openjdk.java.net/browse/JDK-8231031
On Mon, Sep 23, 2019 at 1
To get started: my own answers to the questions:
Optimizations should _not_ be observable for JVMTI agents. They should be as
transparent as they are
for Java programs. Therefore EA should be disabled appropriately or JDK-8227745
should be realized
[3]
This is why:
Documentation states "[...]
Hi,
I would like to get comments on the following questions:
1. Should optimizations be observable for JVMTI agents in general?
2. Should in particular optimzations based on escape analysis be observable?
(a) Should GetOwnedMonitorInfo() exclude objects with eliminated locking?
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 Serguei,
Thank you for reviewing this version of the fix.
>Just one question about ThreadIdTable::remove_thread(jlong tid).
>What happens if there is no thread with the specified tid in ThreadIdTable?
>Is it possible?
It could be possible when the thread that was started while 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
On 9/24/19 12:36 PM, Daniil Titov wrote:
Hi Daniel, David and Serguei,
Please review a new version of the fix (webrev.08) that as Daniel suggested
renames
ThreadTable to ThreadIdTable (related classes and variables are renamed as
well) and
corrects formatting issues. There are no other changes
I read discussion and this change looks good to me.
May be add comment that it is onload capability and can't be changed during
execution.
Thanks,
Vladimir
On 9/6/19 7:24 AM, Reingruber, Richard wrote:
Hi,
could I please get reviews for
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019
Hi Daniil,
This version looks good to me.
Thank you for the update!
Just one question about ThreadIdTable::remove_thread(jlong tid).
What happens if there is no thread with the specified tid in ThreadIdTable?
Is it possible?
Thanks,
Serguei
On 9/24/19 9:36 AM, Daniil Titov wrote:
Hi Daniel, D
On 9/23/19 4:12 PM, Reingruber, Richard wrote:
> Please let me know, if you think this needs more attention and discussion. If
> so, I would like
> to start a new thread, because this one won't have to many followers anymore
> ;)
>
> Is mailing list discussion the right format at all?
Yes. This
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
Hi Daniel, David and Serguei,
Please review a new version of the fix (webrev.08) that as Daniel suggested
renames
ThreadTable to ThreadIdTable (related classes and variables are renamed as
well) and
corrects formatting issues. There are no other changes in this webrev.08
comparing
to the prev
$ 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
On Tue, Sep 24, 2019 at 8:15 AM David Holmes
wrote:
> I just spotted this review request languishing in the mailing list.
>
> The patch will need to be rebased against latest jdk sources, so please
> do that. I'll see if I can drum up a second reviewer and get a sponsor.
>
Hi David,
No pb, he
Hi David,
thanks for the discussion so far. I certainly learned from it.
I'll start a new thread were I'll ask for comments on the relationship of JVMTI
and optimizations,
especially those based on EA.
And thanks for your Review too. I'll wait until there's some feedback on the
new thread.
Ri
28 matches
Mail list logo
