Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On 4/01/2018 12:26 PM, Vitaly Davidovich wrote: On Wed, Jan 3, 2018 at 8:36 PM David Holmes > wrote: On 4/01/2018 3:13 AM, Vitaly Davidovich wrote: > On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman mailto:alan.bate...@oracle.com>> > wrote: >

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On Wed, Jan 3, 2018 at 8:36 PM David Holmes wrote: > On 4/01/2018 3:13 AM, Vitaly Davidovich wrote: > > On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman > > wrote: > > > >> The stack trace looks like JDK 8 or older. The initialization has > changed > >> quite a bit in JDK 9+ and would be interestin

Re: RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method

On Jan 3, 2018, at 3:23 AM, Alan Bateman wrote: > On 02/01/2018 23:43, Brian Burkhalter wrote: >> : >> >>> So not clear to me that Files.copy methods needs to use this. >> >> So you are suggesting leaving the call to InputStream.transferTo() in >> preference to IOSupport.copy()? > Yes, I think

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On 4/01/2018 3:13 AM, Vitaly Davidovich wrote: On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman wrote: The stack trace looks like JDK 8 or older. The initialization has changed quite a bit in JDK 9+ and would be interesting to see if you can duplicate it there. Yes - it's 8u152 as I mentioned i

Re: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the javax/xml/namespace package

Thanks Joe! Cheers, Joe On 1/3/2018 4:47 PM, Joseph D. Darcy wrote: Looks fine Joe; cheers, -Joe On 1/3/2018 3:32 PM, huizhe wang wrote: Hi, Please review a doc-only fix for two namespace classes. The broken links to the Errata are removed since the reference(s) to the Errata is part of t

Re: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the javax/xml/namespace package

Looks fine Joe; cheers, -Joe On 1/3/2018 3:32 PM, huizhe wang wrote: Hi, Please review a doc-only fix for two namespace classes. The broken links to the Errata are removed since the reference(s) to the Errata is part of the Namespaces in XML specification itself. There is no need for the ex

Re: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the javax/xml/namespace package

This change also fix: JBS: https://bugs.openjdk.java.net/browse/JDK-8184046 that contains the same broken link to "Namespaces in XML Errata". As Daniel indicated, the correct link was with a ".html" suffix. Since the content in this Errata has already been incorporated in the current specifica

RFR (JDK10/JAXP Doc-only) 8189704: broken links in the javax/xml/namespace package

Hi, Please review a doc-only fix for two namespace classes. The broken links to the Errata are removed since the reference(s) to the Errata is part of the Namespaces in XML specification itself. There is no need for the extra link(s).  Also, for NamespaceContext, the link to "Namespaces in XM

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

Let's try again without mail bounces ... On Wed, Jan 3, 2018 at 1:40 PM, Martin Buchholz wrote: > Here at Google we tried to fix JDK-8145371 because it looked like it was > causing rare problems in production. But after looking at the code, I'm > not sure... Anyways, > > http://cr.openjdk.java

JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

Here at Google we tried to fix JDK-8145371 because it looked like it was causing rare problems in production. But after looking at the code, I'm not sure... Anyways, http://cr.openjdk.java.net/~martin/webrevs/jdk/MethodHandle.form/ https://bugs.openjdk.java.net/browse/JDK-8145371 Copying to a lo

Re: API review for X25519/X448

+core-libs-dev (to get some additional API guidance) On 1/3/2018 11:26 AM, Adam Petcher wrote: Now that the JEP[1] for X25519/X448 key agreement is a candidate, we can proceed with the API and specification review. Please review the proposed API spec[2] and provide comments by the end of Satur

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman wrote: > The stack trace looks like JDK 8 or older. The initialization has changed > quite a bit in JDK 9+ and would be interesting to see if you can duplicate > it there. > Yes - it's 8u152 as I mentioned in the follow-up email (sorry, should've ment

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

The stack trace looks like JDK 8 or older. The initialization has changed quite a bit in JDK 9+ and would be interesting to see if you can duplicate it there. -Alan On 03/01/2018 16:56, Vitaly Davidovich wrote: Hi all, Consider the following stacktraces of the main app thread and a backgroun

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

Sorry, I should've mentioned that this is 8u152. On Wed, Jan 3, 2018 at 11:56 AM, Vitaly Davidovich wrote: > Hi all, > > Consider the following stacktraces of the main app thread and a background > thread: > > "main" #1 prio=5 os_prio=0 tid=0x01bfd000 nid=0x1958 waiting for > monitor ent

Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

Hi all, Consider the following stacktraces of the main app thread and a background thread: "main" #1 prio=5 os_prio=0 tid=0x01bfd000 nid=0x1958 waiting for monitor entry [0x2b98ceba3000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.Runtime.load

Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

Hi Martin, I'm afraid that's not easy to answer. The fix didn't made it into 8u162 which will be released in January 2018 [1]. It is targeted for 8u172 but there is no time-line for 8u172 yet [2]. The best you can do is to ask on the 8u-dev [3] mailing list or ask the people at AdoptOpenJDK (adop

Re: Adding SocketChannel toString to connection exception messages

On Fri, Dec 29, 2017 at 11:15 AM, Chris Hegarty wrote: > On 29 Dec 2017, at 00:33, Steven Schlansker > wrote: >> Thanks for the discussion! >> >> So, it sounds like amending the message by default is going to be a >> non-starter -- but at least adding the information otherwise might be >> poss

Re: Fix typo in InetSocketAddress.getAddress() documentation

On 03/01/2018 12:05, Christoph Dreis wrote: Hi, I just found a small typo in the documentation of InetSocketAddress.getAddress(). I'd be happy if the attached patch is reviewed and eventually sponsored. net-dev is the mailing list for the java.net code but what you have looks fine. -Alan

Fix typo in documentation of ModuleDescriptor.read() variant

Hi, I just found a typo in the documentation of ModuleDescriptor.read(ByteBuffer bb, Supplier> packageFinder). I'd be happy if the attached patch is reviewed and eventually sponsored. Cheers, Christoph == PATCH === diff -r 3a52333a5e57 src/java.base/share/classes/java/lang/module/ModuleD

Fix typo in InetSocketAddress.getAddress() documentation

Hi, I just found a small typo in the documentation of InetSocketAddress.getAddress(). I'd be happy if the attached patch is reviewed and eventually sponsored. Cheers, Christoph == PATCH diff -r 3a52333a5e57 src/java.base/share/classes/java/net/InetSocketAddress.java

Re: Adding SocketChannel toString to connection exception messages

On 02/01/2018 21:25, Steven Schlansker wrote: : This would definitely be better than nothing! But it's still difficult, for example a common allocation pattern for us would be to assign networks to availability zones: 10.0.1.0/24 10.0.2.0/24 10.0.3.0/24 then if you pick the same last number

Re: RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method

On 02/01/2018 23:43, Brian Burkhalter wrote: : So not clear to me that Files.copy methods needs to use this. So you are suggesting leaving the call to InputStream.transferTo() in preference to IOSupport.copy()? Yes, I think these two should use transferTo. -Alan