Re: RFR (XS): 8198539: Cleanup of unused imports in java/util/jar/Attributes.java (java.base) and JdpController.java (jdk.management.agent)

Hi Christoph, Looks fine. .. Thomas On Feb 22, 2018 09:42, "Langer, Christoph" wrote: > Hi, > > please review a simple import cleanup fix for > java/util/jar/Attributes.java and sun/management/jdp/JdpController.java. > > Bug:

RE: Remove unused import proposal: in JdpController.java

Thank you Christoph Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From: "Langer, Christoph" To: David Holmes ,

RE: Remove unused import proposal: in JdpController.java

Hi Andrew, I'll take this on as I have a similar include cleanup change in my queue for java/util/jar/Attributes.java. Will post a separate review request... Best regards Christoph > -Original Message- > From: serviceability-dev [mailto:serviceability-dev- > boun...@openjdk.java.net]

RFR (XS): 8198539: Cleanup of unused imports in java/util/jar/Attributes.java (java.base) and JdpController.java (jdk.management.agent)

Hi, please review a simple import cleanup fix for java/util/jar/Attributes.java and sun/management/jdp/JdpController.java. Bug: https://bugs.openjdk.java.net/browse/JDK-8198539 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8198539.0/ Thanks and best regards Christoph

Re: RFR (XS): 8198539: Cleanup of unused imports in java/util/jar/Attributes.java (java.base) and JdpController.java (jdk.management.agent)

looks good Cheers Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From: "Langer, Christoph" To: OpenJDK Dev list

8u: RFR(S): 8197943: Unable to use JDWP API in JDK 8 to debug JDK 9 VM

Hi JDK 8 reviewers, I'd like to propose a fix for a backport of JDI changes that came with modularization. Egor has brought this up in 8u-dev: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-February/007230.html The fix is straightforward and is used by Egor in JetBrains, as well as we

Re: Thread Native ID Access

There isn't a pressing need. I wrote this patch almost 5 years ago. We can do what we've always done and keep the patch locally. It's just more work for us to keep forward porting it, and loss of potential benefit to the community. I can certainly understand not wanting this in the high-value

Re: RFR 8198533 Remove obsolete JDIScaffold class from repo

Hi Paru, Looks good. Chris On 2/22/18 11:41 AM, Paru Somashekar wrote: Hi Please review fix for JDK-8198533 While removing obsolete JDIScaffold class, found one more class :

Re: RFR 8198533 Remove obsolete JDIScaffold class from repo

Thanks Chris. thanks, Paru. On 2/22/18, 1:21 PM, Chris Plummer wrote: Hi Paru, Looks good. Chris On 2/22/18 11:41 AM, Paru Somashekar wrote: Hi Please review fix for JDK-8198533 While removing obsolete JDIScaffold class, found one more class : NativeInstanceFilter, that needed to be

RFR 8198533 Remove obsolete JDIScaffold class from repo

Hi Please review fix for JDK-8198533 While removing obsolete JDIScaffold class, found one more class : NativeInstanceFilter, that needed to be updated to use TestScaffold. Bug : JDK-8198533 Webrev :

Re: Thread Native ID Access

Agreed, when those hit the Code they will require a different Change. (Which does not make it less useful for the current Code). Probably the ID is from the days of green threads anyway.  -- http://bernd.eckenfels.net Von: Jeremy Manson Gesendet: Donnerstag, 22. Februar 2018 20:15 An: Bernd

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

Ping for a review please. Thanks, Paul On 2/16/18, 12:26 PM, "serviceability-dev on behalf of Hohensee, Paul" wrote: The CSR https://bugs.openjdk.java.net/browse/JDK-8196719 for the original fix has been

Re: Thread Native ID Access

Hello, one Option would be to use nid as tid on platforms where the datatype is compatible. Thread#getId() is „positive Long“. That should work(?) at least on Windows and Linux, it will actually reduce some Overhead and make the identifier more useful for Debugging without adding a new API.

Re: RFR 8198533 Remove obsolete JDIScaffold class from repo

Hi Paru, +1 Thanks, Serguei On 2/22/18 13:21, Chris Plummer wrote: Hi Paru, Looks good. Chris On 2/22/18 11:41 AM, Paru Somashekar wrote: Hi

Re: RFR 8198533 Remove obsolete JDIScaffold class from repo

Thanks Serguei. thanks, Paru. On 2/22/18, 2:22 PM, serguei.spit...@oracle.com wrote: Hi Paru, +1 Thanks, Serguei On 2/22/18 13:21, Chris Plummer wrote: Hi Paru, Looks good. Chris On 2/22/18 11:41 AM, Paru Somashekar wrote: Hi Please review fix for JDK-8198533 While removing obsolete

Re: Thread Native ID Access

On 23/02/2018 5:19 AM, Bernd Eckenfels wrote: Agreed, when those hit the Code they will require a different Change. (Which does not make it less useful for the current Code). Probably the ID is from the days of green threads anyway.  No it was added in Java SE 5 as a way to uniquely identify

RFR(XS): 8198585: add asserts to verify that ServiceUtil::visible_oop is not needed

Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8198585 http://cr.openjdk.java.net/~cjplummer/8198585/webrev.00/webrev/ Before removing ServiceUtil::visible_oop(), I want to make sure it really isn't needed. Supposedly it should never return false, thus negating

Re: Thread Native ID Access

On 23/02/2018 3:04 PM, John Rose wrote: On Feb 22, 2018, at 8:49 PM, David Holmes > wrote: I don't think this request has any impact on Fibers at all. At any given time a piece of executing Java code is executing on a current Thread,

RFR(S): 8196992: Resolve disabled warnings for libdt_socket

Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8196992 diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk --- a/make/lib/Lib-jdk.jdwp.agent.gmk +++ b/make/lib/Lib-jdk.jdwp.agent.gmk @@ -43,7 +43,6 @@ OPTIMIZATION := LOW, \

Re: Thread Native ID Access

On Feb 22, 2018, at 8:49 PM, David Holmes wrote: > > I don't think this request has any impact on Fibers at all. At any given time > a piece of executing Java code is executing on a current Thread, and that > current Thread must be running on a native thread

Re: Thread Native ID Access

I think we're all pretty much agreed that fibers imply native tids can change. I think that, as long as we document that, we're fine. An API where there is probably a worse implementation problem is ThreadMXBean#getThreadCpuTime

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

Hi Jeremy, I have revised the spec of ThreadInfo::from to include "since" column: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198253/api/java/lang/management/ThreadInfo.html#from(javax.management.openmbean.CompositeData) I caught a few other issues like mix-n-match older version of

Re: Thread Native ID Access

On 21/02/2018 22:40, Jeremy Manson wrote: Hey folks, I mentioned earlier in the thread about the ThreadInfo.from() bug that I found this because I was looking at fixing JDK-8154176, which proposes introducing native thread ids to Thread and ThreadInfo.