From Alan.Bateman at oracle.com Tue Jan 2 16:14:39 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Jan 2018 16:14:39 +0000
Subject: RFR [11] JDK-8179424: Remove terminally deprecated
sun.reflect.Reflection.getCallerClass
In-Reply-To: <0a57854d-b5d5-a30a-02cb-14617ef625ca@oracle.com>
References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com>
<81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com>
<0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com>
<302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com>
<628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com>
<99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com>
<6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com>
<9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com>
<4e811ed4-54c6-b253-44cb-e2f6a9dd83fe@oracle.com>
<34412585-eac6-0e62-a5b8-e8f8dd42645e@oracle.com>
<0a57854d-b5d5-a30a-02cb-14617ef625ca@oracle.com>
Message-ID: <9e92d615-319e-2901-e55f-72fc814236b5@oracle.com>
On 22/12/2017 10:16, Chris Hegarty wrote:
>
> On 21/12/17 21:40, mandy chung wrote:
>> ?... >
>> ReflectionFactory or other class in sun.reflect package would do it.
>>>> and create an issue to follow up sun.reflect.Reflection as flagged
>>>> as a removed API.
>>> That?s what the test now does with my changes. Why separate it
>>> out into a separate issue??? If we need a test for an internal API, I
>>> can add a scenario that uses sun.reflect.ReflectionFactory.
>>
>> Yes please. That's what this case intends to verify.
>
> Webrev with the test updated as suggested:
> ? http://cr.openjdk.java.net/~chegar/8179424/webrev.03/
Updated webrev looks good to me too.
-Alan
From Alan.Bateman at oracle.com Tue Jan 2 16:35:03 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Jan 2018 16:35:03 +0000
Subject: Adding SocketChannel toString to connection exception messages
In-Reply-To:
References:
<82A01DB9-7DB5-4D16-B890-FCB4306455DF@gmail.com>
<160EE294-4802-4A5B-8EDE-1EB68EF329CE@gmail.com>
<3874615e-a801-67d9-b466-bdc70fa9e835@oracle.com>
<1b83507a-bded-4e2b-1818-cd51e94d5176@oracle.com>
<8546d3d3-dd76-059c-dd28-03ca2f782c01@oracle.com>
Message-ID:
On 29/12/2017 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 possible.
>
There are examples in other area where exceptions include detail
information (for diagnostics purposes) when not running with a security
manager. This may be something to look at here (and easy to try out too
as it wouldn't require touching any native code either).
-Alan
From Alan.Bateman at oracle.com Tue Jan 2 17:01:22 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Jan 2018 17:01:22 +0000
Subject: RFR 8193842: Refactor InputStream-to-OutputStream copy into a
utility method
In-Reply-To: <448C891C-06DA-41E9-87DC-6B0A8AB0A781@oracle.com>
References: <448C891C-06DA-41E9-87DC-6B0A8AB0A781@oracle.com>
Message-ID:
On 22/12/2017 21:51, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8194133
> http://cr.openjdk.java.net/~bpb/8194133/webrev.00/
>
> Add jdk.internal.io.IOSupport with copy() methods for InputStream-to-OutputStream copying and modify some classes to use these new methods.
>
> One thing that I noticed when looking at this is that in the fix for https://bugs.openjdk.java.net/browse/JDK-8193842, the Files.copy() method had a loop like
>
> while ((n = read(?)) > 0)
>
> whereas InputStream.transferTo() had
>
> while((n = read(?)) >= 0)
>
> which is to say that Files.copy() would terminate if there were an empty read() but transferTo() would not. The patch for 8193842 therefore possibly introduced a subtle behavioral change which no one noticed.
>
read(byte[]) is blocking so it should only return 0 if called with a
0-length array. So not clear to me that Files.copy methods needs to use
this.
For JrtPath then the code is specific to the jimage -> jimage case. I
think that can be left along too or just replaced with a better
implementation for jrtfs.
-Alan.
From Alan.Bateman at oracle.com Tue Jan 2 16:42:12 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Jan 2018 16:42:12 +0000
Subject: RFR: 8194154 patch for crash at File.getCanonicalPath()
In-Reply-To:
References:
Message-ID: <5dc3e332-2c36-3261-e2f7-a7ecc532ce72@oracle.com>
On 25/12/2017 09:40, Wenqian Pei wrote:
> Hi:
>
> Bug:?https://bugs.openjdk.java.net/browse/JDK-8194154
>
> We?found?that?if?user?defines?-Duser.dir?like?"/home/a/b/c/",?jvm?will?crash?at?File.getCanonicalPath()?in?java?process?bootstrap?(before?invoking?user's?java?code).?The?native?implematation?of?canonicalize_md.c:collapsible(char?*names)?has?problem?in?processing?double?'/',?parameter 'names' need?normalized?before?JNI_CALL.
>
user.dir is a "read-only" property and should never be changed on the
command-line or in a running VM (it breaks APIs in other areas to have
user.dir be different to the actual working directory). Someday we need
to figure out how to enforce this.
In the mean-time, the runtime shouldn't crash so I agree it should be fixed.
-Alan.
From stevenschlansker at gmail.com Tue Jan 2 21:25:28 2018
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Tue, 2 Jan 2018 13:25:28 -0800
Subject: Adding SocketChannel toString to connection exception messages
In-Reply-To:
References:
<82A01DB9-7DB5-4D16-B890-FCB4306455DF@gmail.com>
<160EE294-4802-4A5B-8EDE-1EB68EF329CE@gmail.com>
<3874615e-a801-67d9-b466-bdc70fa9e835@oracle.com>
<1b83507a-bded-4e2b-1818-cd51e94d5176@oracle.com>
<8546d3d3-dd76-059c-dd28-03ca2f782c01@oracle.com>
Message-ID: <862C913E-845F-4A8A-8090-0079F861B67B@gmail.com>
On Dec 31, 2017, at 7:24 AM, Peter Levart wrote:
>
> Hi,
>>
>> I believe there are concerns with too much information that can be considered "sensitive" (like host names and IP addresses) appearing in error messages due to them ending up in log files and bug reports.
>>
>> David
>
> For debugging purposes it might sometimes be enough to get just a hint about the actual address / port but not reveal it entirely. The person doing debugging probably knows more about the environment than an average person so the hint might give him enough information to discern the actual address / port. Exposing just the last octet of an IP address and the last digit of the port might do. For example:
>
> java.net.ConnectException: Connection to X.X.X.205:XXX8 refused.
>
> So Steven, I'm curious whether such hint would help in your case?
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 for a well known service, you might end up with instances at 10.0.1.2, 10.0.2.2, 10.0.3.2 -- so depending on which octets are obscured you may end up with no useful information.
The triggering incident for us was that one of our Amazon ELBs started responding incorrectly (blackholing data) --
so when you resolve "my-elb-1.amazonaws.amazon.com" you'd get three different IP addresses, and depending on which one
is picked for the connect operation, you'll get all data blackholed.
The author of the code in question obviously had not considered a failure mode where one of the "It Is In The Cloud So It Always Works" load balancer instances did not behave like the others -- so it did not emit any diagnostic information other than the hostname, and until we got a network operator in with WireShark it was quite difficult to determine that it was in fact exactly one instance of three failing. The pain of using WireShark to diagnose what should have been a quick scan through the logs, coupled with the sheer impossibility of annotating every network call in every application across our organization, pushed me to open this discussion to do it in one central place :)
> An attacker that knows something about the environment could find out the missing pieces without such hints anyway (simply by scanning IPs / ports), so such partial information is not that sensitive nowadays.
I've never really understood the justification behind this rule -- we have a similar policy in our organization, all IP addresses must be stripped. But knowing the layout of the network, I can tell you that if you are on the outside and have one of our 10.x.x.x IP addresses it gives you almost nothing (good luck routing to it) -- and if you are on the inside, it's not exactly difficult to enumerate these. DNS contains every name / IP you might find and it'll happily divulge all that information to you, and failing that, nmap can map out the majority of the network fairly reliably in seconds...
I respect that the JVM has to be conservative, but there is a real usability problem here, and the security gain is a little questionable to me!
> Another idea: define a one way function that maps the IP:port pair into a value which is displayed in the exception message. For debugging purposes this might be enough since the one doing debugging might know the set of possible IP:port pairs in advance. He could then apply the function to each of them in turn and find out the matching pair.
This is interesting, but only if you can enumerate the IP:port that might match. We have a Apache Mesos cluster with O(100) nodes, each of which is assigned a pool of 1000 ports to assign to applications. Needing to enumerate a million possible hash matches could be a royal pain, and my understanding is that 100 nodes is not even near the size of the largest production clusters out there. It's not quite to the level of a non-starter, but as those numbers scale it could easily become useless.
Some of the exceptions may not have a specific port (hostname resolution), may have port 0, or such a dynamically assigned port, so you'd have to guess these special cases too.
Additionally, with cloud providers, you may not understand the space of IPs that an Abstract Cloud Device like ELB might come from -- it's coming from an AWS pool that you have no visibility into.
> On Jan 2, 2018, at 8:35 AM, Alan Bateman wrote:
>
> On 29/12/2017 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 possible.
>>
> There are examples in other area where exceptions include detail information (for diagnostics purposes) when not running with a security manager. This may be something to look at here (and easy to try out too as it wouldn't require touching any native code either).
I like that!
For now, I will proceed with improving my prototype to follow this suggestion -- unless there is a security manager, the exceptions are annotated.
An alternate way to activate it, by configuring the platform logger e.g. "java.net.SocketException=TRACE", might be useful in case we want to allow end users to configure the feature explicitly and independent of security manager.
Unfortunately I don't see how I can avoid changing the native code -- the exception message is initialized in native code, and by the time we call back to Java code, the necessary information is not passed in to the SocketException subclass constructor. So I may be misinterpreting your guidance here, but I'm not seeing it.
I think I will hold off on adding Java level fields to the exception types. I expect if I do that, I will then have to get a spec change to add appropriate public API to make the data actually usable. Since the goal here is for log diagnostics as opposed to more structured data at the Java level, I'll avoid it. It also avoids any complications with regards to changing the serial format for such a common type. But I do think it means the work has to be done in the native code.
From brian.burkhalter at oracle.com Tue Jan 2 23:43:57 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 2 Jan 2018 15:43:57 -0800
Subject: RFR 8193842: Refactor InputStream-to-OutputStream copy into a
utility method
In-Reply-To:
References: <448C891C-06DA-41E9-87DC-6B0A8AB0A781@oracle.com>
Message-ID: <232750C7-7D37-4F36-A842-AE4D38273C91@oracle.com>
On Jan 2, 2018, at 9:01 AM, Alan Bateman wrote:
>> One thing that I noticed when looking at this is that in the fix for https://bugs.openjdk.java.net/browse/JDK-8193842, the Files.copy() method had a loop like
>>
>> while ((n = read(?)) > 0)
>>
>> whereas InputStream.transferTo() had
>>
>> while((n = read(?)) >= 0)
>>
>> which is to say that Files.copy() would terminate if there were an empty read() but transferTo() would not. The patch for 8193842 therefore possibly introduced a subtle behavioral change which no one noticed.
>>
> read(byte[]) is blocking so it should only return 0 if called with a 0-length array.
Good point so ?>? should be used.
> 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()?
> For JrtPath then the code is specific to the jimage -> jimage case. I think that can be left along too or just replaced with a better implementation for jrtfs.
It would simplify this patch a little to leave this part out.
Brian
From hboehm at google.com Wed Jan 3 01:16:26 2018
From: hboehm at google.com (Hans Boehm)
Date: Tue, 2 Jan 2018 17:16:26 -0800
Subject: FileOutputStream.getFD() vs finalization
In-Reply-To: <3b973fb9-beac-b0cb-67ce-d61977dd6f6d@gmail.com>
References:
<3b973fb9-beac-b0cb-67ce-d61977dd6f6d@gmail.com>
Message-ID:
Thanks!
I had missed the fact that FileDescriptor keeps a list of all owners.
Apparently (1) closing a single File*Stream effectively closes all such
Streams using the same FileDescriptor? And (2) whenever one such Stream is
reachable they are all retained. Thus presumably none can be finalized
until the last JNI instance method is called, which indeed should be enough
to avoid the problem. (I'm not sure whether the JNI spec actually requires
that, but certainly in the absence of cross-language optimization, it's
sufficient.)
Should (1) and (2) be documented? They both seem to potentially matter to
users and, unless I missed something else, are not at all apparent from the
current documentation. I do have to admit that I'm hazy on what the usage
model here is intended to be, and why FileDescriptor is user visible.
Hans
On Sun, Dec 31, 2017 at 3:53 AM, Peter Levart
wrote:
> Hi,
>
> Maybe I'm missing something but...
>
> Hans Boehm je 28. 12. 2017 ob 21:32 napisal:
>
> The design of the getFD() calls in some Java *Stream classes seems
> problematic, and doesn't seem cleanly fixable without a spec change. I
> first noticed this in JDK 8 code, but Roger Riggs recent JDK 10 changes
> also don't seem to fully address this specific problem, particularly since
> the code paths remain more-or-less similar when a FOS subclass has a close
> method. It probably remains easier to describe this in a JDK 8/9 setting,
> so I'll do so initially.
>
> Close() on the *Stream closes the FD. The finalize() method on the Stream
> (not the FD!) calls close(). Assuming JLS 12.6.2 finalization semantics, if
> my program consists of:
>
> {
> FileOutputStream f1 = new FileOutputStream("foo");
> FileDescriptor fd = f1.getFD();
> A:
> FileOutputStream f2 = new FileOutputStream(fd);
> }
>
> f2 may be associated with a closed fd, since f1 could have been finalized
> at any pointer after its construction, in particular at point A.
>
>
> I think there is no such problem here. Each stream (FileInputStream,
> FileOutputStream and RandomAccessFile) keeps a reference to the
> FileDescriptor (via 'fd' field) and FileDescriptor keeps a reference to all
> associated streams (established in stream constructor via
> FileDescriptor.attach(Closeable) where the Closeable instance is the
> stream instance). So as long as 'fd' above is reachable, so is 'f1'.
>
> This is slightly aggravated by the fact that close() is implemented in a
> way that doesn't guarantee reachability of the FileOutputStream while, or
> before, it runs. Close() could easily be inlined, and the *Stream fields
> promoted to registers. Thus even if you always call close() explicitly, I
> think you are still affected by this problem.
>
>
> File[Input|Output]Stream.close() is an instance method that among other
> things, calls close0() native instance method which accesses field 'fd' in
> native code via JNI. While close0() native instance method is being
> executed, the stream instance is kept reachable (by the JNI spec). In fact,
> all stream native methods that do make use of 'fd' are instance methods
> that keep stream instance is reachable while being executed - making the
> native resource access.
>
> So I think FileInputStream, FileOutputStream and RandomAccessFile are
> examples of code where finalization was actually done right, because it is
> consistently combined with native instance methods. Unlike direct NIO
> buffers that keep native resource (long address) in a field and pass its
> value around to other classes (Unsafe) not making sure that the buffer
> instance which is tracked by Cleaner is kept reachable everywhere the
> underlying native memory is being accessed.
>
>
> Regards, Peter
>
> Fundamentally the result of getFD() is only valid as long as the underlying
> *Stream is reachable, and that is not defined in a way that's
> understandable by most programmers. That also makes this API un-Java-like,
> in that the user has to worry about very subtle object lifetime rules.
>
> The only semi-plausible solution seems to involve judicious use of
> ReachabilityFence() on FileOutputStreams after the getFD() result is no
> longer needed. I personally don't think that's really a very plausible
> request of the programmer.
>
> I think Roger's JDK 10 changes may help in the case in which there is not
> an overridden close() method, since the cleanup action is registered on the
> underlying FileDescriptor. But if a subclass overrides close(), I think
> we're basically still in the same boat. For the reasons he already gave,
> that seems hard to avoid. And again I think the problem applies even if
> close() is explicitly called, since that doesn't really prevent
> finalization of the Stream object.
>
> Has this been discussed anywhere? Opinions about how to deal with it?
>
> (This arose while going through the core libraries, looking for premature
> finalization issues. So far, this one seems special, in that It really
> seems to require an API change.)
>
> Hans
>
>
>
From Martin.Evans at kingfisher.com Tue Jan 2 17:55:18 2018
From: Martin.Evans at kingfisher.com (Evans, Martin)
Date: Tue, 2 Jan 2018 17:55:18 +0000
Subject: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by
providing empty basic implementations of getSystemCpuLoad and
getProcessCpuLoad
In-Reply-To:
References: <6838c67f5a7f44c0a48a79e8ac47e889@sap.com>
Message-ID:
Hi Volker,
Happy new year!
Do you have a rough idea as to when it will make it into the regular update?
Kind regards,
Martin
-----Original Message-----
From: Volker Simonis [mailto:volker.simonis at gmail.com]
Sent: 22 December 2017 16:25
To: Evans, Martin
Cc: Baesken, Matthias ; jdk8u-dev-request at openjdk.java.net; core-libs-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; build-dev
Subject: Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad
Hi Martin,
I've just pushed the fix to jdk8u/jdk8u-dev [1] so it should be in the next regular 8u update (probably 8u172 ?).
You can of course test it any time by building the tip of http://hg.openjdk.java.net/jdk8u/jdk8u-dev yourself :)
Merry Christmas and a happy new year,
Volker
[1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/def07b5ce3be
On Wed, Dec 20, 2017 at 11:18 AM, Evans, Martin wrote:
> Many thanks guys, I look forward to testing.
>
> Regards,
>
> Martin
>
> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: 20 December 2017 09:33
> To: Baesken, Matthias
> Cc: jdk8u-dev-request at openjdk.java.net;
> core-libs-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net;
> Simonis, Volker ; Evans, Martin
> ; build-dev
> Subject: Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by
> providing empty basic implementations of getSystemCpuLoad and
> getProcessCpuLoad
>
> Hi Matthias,
>
> the change looks good!
> I can sponsor it once we get the approval.
>
> Also forwarded to buil-dev for the minimal build change.
>
> Thank you and best regards,
> Volker
>
>
> On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias wrote:
>> Hello , Mark reported this issue on AIX with OpenJDK8 :
>>
>>>
>>>I'm getting an unsatisfied link error when using logstash on AIX but I suspect the issue is with AIX or the JRE, the exception is:
>>>
>>> java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()D
>>> getProcessCpuLoad at sun/management/OperatingSystemImpl.java:-2
>>> at org/logstash/instrument/monitors/ProcessMonitor.java:40
>>> detect at org/logstash/instrument/monitors/ProcessMonitor.java:79
>>> generate at
>>> org/logstash/instrument/reports/ProcessReport.java:15
>>>
>>> this is the line in logstash:
>>>
>>> this.cpuProcessPercent =
>>> scaleLoadToPercent(unixOsBean.getProcessCpuLoad());
>>>
>>> https://github.com/elastic/logstash/blob/master/logstash-core/src/ma
>>> i n/java/org/logstash/instrument/monitors/ProcessMonitor.java
>>>
>>>
>>> Could anybody help steer me in the right direction?
>>>
>>
>> This fix addresses the missing getSystemCpuLoad and getProcessCpuLoad on AIX .
>> JDK8 is only affected , JDK9 and higher is not affected .
>>
>> Could I get a review for this change ?
>>
>>
>> Change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8193807/
>>
>> Bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8193807
>>
>>
>> Thanks, Matthias
> ------------ Kingfisher plc Registered Office: 3 Sheldon Square, Paddington, London W2 6PX Registered in England, Number 1664812 This e-mail is only intended for the person(s) to whom it is addressed and may contain confidential information. Unless stated to the contrary, any opinions or comments are personal to the writer and do not represent the official view of the company. If you have received this e-mail in error, please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person. Thank you for your co-operation.
------------ Kingfisher plc Registered Office: 3 Sheldon Square, Paddington, London W2 6PX Registered in England, Number 1664812 This e-mail is only intended for the person(s) to whom it is addressed and may contain confidential information. Unless stated to the contrary, any opinions or comments are personal to the writer and do not represent the official view of the company. If you have received this e-mail in error, please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person. Thank you for your co-operation.
From wenqian.peiwq at alibaba-inc.com Wed Jan 3 02:09:26 2018
From: wenqian.peiwq at alibaba-inc.com (Wenqian Pei)
Date: Wed, 03 Jan 2018 10:09:26 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaUkZSOiA4MTk0MTU0IHBhdGNoIGZvciBjcmFzaCBhdCBGaWxlLmdldENhbm9u?=
=?UTF-8?B?aWNhbFBhdGgoKQ==?=
In-Reply-To: 5dc3e332-2c36-3261-e2f7-a7ecc532ce72@oracle.com
References: ,
5dc3e332-2c36-3261-e2f7-a7ecc532ce72@oracle.com
Message-ID: <6e2f7f43-dcc0-4e1a-ad0d-6c52b25c5f71.wenqian.peiwq@alibaba-inc.com>
Can you please review this patch?
Thanks in advance!
Wenqian Pei
------------------------------------------------------------------????Alan Bateman ?????2018?1?3?(???) 01:30???????(??) ; core-libs-dev ???????(??) ; ???(??) ????Re: RFR: 8194154 patch for crash at File.getCanonicalPath()
On?25/12/2017?09:40,?Wenqian?Pei?wrote:
>?Hi:
>
>?Bug:?https://bugs.openjdk.java.net/browse/JDK-8194154
>
>?We?found?that?if?user?defines?-Duser.dir?like?"/home/a/b/c/",?jvm?will?crash?at?File.getCanonicalPath()?in?java?process?bootstrap?(before?invoking?user's?java?code).?The?native?implematation?of?canonicalize_md.c:collapsible(char?*names)?has?problem?in?processing?double?'/',?parameter?'names'?need?normalized?before?JNI_CALL.
>
user.dir?is?a?"read-only"?property?and?should?never?be?changed?on?the?
command-line?or?in?a?running?VM?(it?breaks?APIs?in?other?areas?to?have?
user.dir?be?different?to?the?actual?working?directory).?Someday?we?need?
to?figure?out?how?to?enforce?this.
In?the?mean-time,?the?runtime?shouldn't?crash?so?I?agree?it?should?be?fixed.
-Alan.
From peter.levart at gmail.com Wed Jan 3 07:01:18 2018
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 3 Jan 2018 08:01:18 +0100
Subject: Adding SocketChannel toString to connection exception messages
In-Reply-To: <862C913E-845F-4A8A-8090-0079F861B67B@gmail.com>
References:
<82A01DB9-7DB5-4D16-B890-FCB4306455DF@gmail.com>
<160EE294-4802-4A5B-8EDE-1EB68EF329CE@gmail.com>
<3874615e-a801-67d9-b466-bdc70fa9e835@oracle.com>
<1b83507a-bded-4e2b-1818-cd51e94d5176@oracle.com>
<8546d3d3-dd76-059c-dd28-03ca2f782c01@oracle.com>
<862C913E-845F-4A8A-8090-0079F861B67B@gmail.com>
Message-ID:
Hi Steven,
Steven Schlansker je 02. 01. 2018 ob 22:25?napisal:
>> On Jan 2, 2018, at 8:35 AM, Alan Bateman wrote:
>>
>> On 29/12/2017 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 possible.
>>>
>> There are examples in other area where exceptions include detail information (for diagnostics purposes) when not running with a security manager. This may be something to look at here (and easy to try out too as it wouldn't require touching any native code either).
> I like that!
>
> For now, I will proceed with improving my prototype to follow this suggestion -- unless there is a security manager, the exceptions are annotated.
>
> An alternate way to activate it, by configuring the platform logger e.g. "java.net.SocketException=TRACE", might be useful in case we want to allow end users to configure the feature explicitly and independent of security manager.
>
> Unfortunately I don't see how I can avoid changing the native code -- the exception message is initialized in native code, and by the time we call back to Java code, the necessary information is not passed in to the SocketException subclass constructor. So I may be misinterpreting your guidance here, but I'm not seeing it.
>
> I think I will hold off on adding Java level fields to the exception types. I expect if I do that, I will then have to get a spec change to add appropriate public API to make the data actually usable. Since the goal here is for log diagnostics as opposed to more structured data at the Java level, I'll avoid it. It also avoids any complications with regards to changing the serial format for such a common type. But I do think it means the work has to be done in the native code.
>
I haven't studied the actual code, but one thing to consider might be to
create a java.net package-private exception type (unrelated to
java.net.SocketException) with a constructor that takes necessary
information (host, IP, port, but no message) and then throw this
exception from native code instead of java.net.SocketException. On the
Java side, you then wrap calls to native methods with try/catch and
throw java.net.SocketException with appropriately formatted message
instead (and with no cause). Moving formatting logic to Java might
simplify native code and it's always good to keep native code simple
(not having to deal with SecurityManager, system properties, logger(s)
etc.).
What do you think?
Regards, Peter
From Alan.Bateman at oracle.com Wed Jan 3 11:23:50 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 3 Jan 2018 11:23:50 +0000
Subject: RFR 8193842: Refactor InputStream-to-OutputStream copy into a
utility method
In-Reply-To: <232750C7-7D37-4F36-A842-AE4D38273C91@oracle.com>
References: <448C891C-06DA-41E9-87DC-6B0A8AB0A781@oracle.com>
<232750C7-7D37-4F36-A842-AE4D38273C91@oracle.com>
Message-ID: <9f81b074-5a62-2869-ad24-256eff0c0837@oracle.com>
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
From Alan.Bateman at oracle.com Wed Jan 3 11:37:04 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 3 Jan 2018 11:37:04 +0000
Subject: Adding SocketChannel toString to connection exception messages
In-Reply-To: <862C913E-845F-4A8A-8090-0079F861B67B@gmail.com>
References:
<82A01DB9-7DB5-4D16-B890-FCB4306455DF@gmail.com>
<160EE294-4802-4A5B-8EDE-1EB68EF329CE@gmail.com>
<3874615e-a801-67d9-b466-bdc70fa9e835@oracle.com>
<1b83507a-bded-4e2b-1818-cd51e94d5176@oracle.com>
<8546d3d3-dd76-059c-dd28-03ca2f782c01@oracle.com>
<862C913E-845F-4A8A-8090-0079F861B67B@gmail.com>
Message-ID: <78354b1e-34e2-adc4-00f4-be85e2323dae@oracle.com>
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 for a well known service, you might end up with instances at 10.0.1.2, 10.0.2.2, 10.0.3.2 -- so depending on which octets are obscured you may end up with no useful information.
>
> The triggering incident for us was that one of our Amazon ELBs started responding incorrectly (blackholing data) --
> so when you resolve "my-elb-1.amazonaws.amazon.com" you'd get three different IP addresses, and depending on which one
> is picked for the connect operation, you'll get all data blackholed.
Socket/SocketChannel connect take a single address, not a hostname that
is potentially mapped to multiple addresses. Maybe you mean the Socket
constructors that takes a hostname and do the lookup before attempt to
establish a connection?
In any case, if the exception message includes the address/port details
then it shouldn't matter which constructors are used. Also note that
when you look at the non-blocking cases then you'll see the exception is
thrown by finishConnect, not connect. This is nothing reason to handle
this completely in java and avoid changes to the native code.
-Alan
From christoph.dreis at freenet.de Wed Jan 3 12:05:59 2018
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Wed, 3 Jan 2018 13:05:59 +0100
Subject: Fix typo in InetSocketAddress.getAddress() documentation
Message-ID: <000001d3848b$382b78d0$a8826a70$@freenet.de>
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
--- a/src/java.base/share/classes/java/net/InetSocketAddress.java Tue
Jan 02 16:35:04 2018 -0500
+++ b/src/java.base/share/classes/java/net/InetSocketAddress.java Wed
Jan 03 12:55:26 2018 +0100
@@ -317,10 +317,9 @@
}
/**
- *
* Gets the {@code InetAddress}.
*
- * @return the InetAdress or {@code null} if it is unresolved.
+ * @return the InetAddress or {@code null} if it is unresolved.
*/
public final InetAddress getAddress() {
return holder.getAddress();
From christoph.dreis at freenet.de Wed Jan 3 12:49:48 2018
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Wed, 3 Jan 2018 13:49:48 +0100
Subject: Fix typo in documentation of ModuleDescriptor.read() variant
Message-ID: <000101d38491$570c13d0$05243b70$@freenet.de>
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/ModuleDescriptor.java
--- a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
Tue Jan 02 16:35:04 2018 -0500
+++ b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
Wed Jan 03 13:42:27 2018 +0100
@@ -2521,7 +2521,7 @@
* the {@code packageFinder} throws an {@link UncheckedIOException}
then
* {@link IOException} cause will be re-thrown.
*
- * The module descriptor is read from the buffer stating at index
+ *
The module descriptor is read from the buffer starting at index
* {@code p}, where {@code p} is the buffer's {@link
ByteBuffer#position()
* position} when this method is invoked. Upon return the buffer's
position
* will be equal to {@code p + n} where {@code n} is the number of
bytes
From Alan.Bateman at oracle.com Wed Jan 3 12:56:14 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 3 Jan 2018 12:56:14 +0000
Subject: Fix typo in InetSocketAddress.getAddress() documentation
In-Reply-To: <000001d3848b$382b78d0$a8826a70$@freenet.de>
References: <000001d3848b$382b78d0$a8826a70$@freenet.de>
Message-ID: <1e253538-020a-9376-4f15-53c1085ebb35@oracle.com>
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
From david.lloyd at redhat.com Wed Jan 3 13:47:00 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 3 Jan 2018 07:47:00 -0600
Subject: Adding SocketChannel toString to connection exception messages
In-Reply-To:
References:
<82A01DB9-7DB5-4D16-B890-FCB4306455DF@gmail.com>
<160EE294-4802-4A5B-8EDE-1EB68EF329CE@gmail.com>
<3874615e-a801-67d9-b466-bdc70fa9e835@oracle.com>
<1b83507a-bded-4e2b-1818-cd51e94d5176@oracle.com>
<8546d3d3-dd76-059c-dd28-03ca2f782c01@oracle.com>
Message-ID:
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 possible.
>>
>> One possibility would be to add new fields to SocketException, for example an InetSocketAddress representing both the local and remote (if available).
>
> You would need to careful to not disclose resolved addresses to untrusted code. SocketException, since a subtype of IOException, can wind up in many places.
>
> Would you be proposing to add these new fields to the serial-form of SocketException? What behaviour do you envisage for deserializing instances from previous releases? This will have an impact of any potential API.
This is an advantage to a setter-only message supplement method: if
the supplementary field is set, the writeReplace method can swap it
for a new instance with the combined message.
--
- DML
From volker.simonis at gmail.com Wed Jan 3 14:30:05 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 3 Jan 2018 15:30:05 +0100
Subject: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by
providing empty basic implementations of getSystemCpuLoad and
getProcessCpuLoad
In-Reply-To:
References: <6838c67f5a7f44c0a48a79e8ac47e889@sap.com>
Message-ID:
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 (adoption-discuss at openjdk.java.net [4]) to
merge the fix into their current builds. That would be actually a good
smoke test for their tool chain :)
Regards,
Volker
[1] http://openjdk.java.net/projects/jdk8u/releases/8u162.html
[2] http://openjdk.java.net/projects/jdk8u/
[3] http://mail.openjdk.java.net/mailman/listinfo/jdk8u-dev
[4] http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss
On Tue, Jan 2, 2018 at 6:55 PM, Evans, Martin
wrote:
> Hi Volker,
>
> Happy new year!
>
> Do you have a rough idea as to when it will make it into the regular update?
>
> Kind regards,
>
> Martin
>
> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: 22 December 2017 16:25
> To: Evans, Martin
> Cc: Baesken, Matthias ; jdk8u-dev-request at openjdk.java.net; core-libs-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; build-dev
> Subject: Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad
>
> Hi Martin,
>
> I've just pushed the fix to jdk8u/jdk8u-dev [1] so it should be in the next regular 8u update (probably 8u172 ?).
>
> You can of course test it any time by building the tip of http://hg.openjdk.java.net/jdk8u/jdk8u-dev yourself :)
>
> Merry Christmas and a happy new year,
> Volker
>
> [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/def07b5ce3be
>
> On Wed, Dec 20, 2017 at 11:18 AM, Evans, Martin wrote:
>> Many thanks guys, I look forward to testing.
>>
>> Regards,
>>
>> Martin
>>
>> -----Original Message-----
>> From: Volker Simonis [mailto:volker.simonis at gmail.com]
>> Sent: 20 December 2017 09:33
>> To: Baesken, Matthias
>> Cc: jdk8u-dev-request at openjdk.java.net;
>> core-libs-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net;
>> Simonis, Volker ; Evans, Martin
>> ; build-dev
>> Subject: Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by
>> providing empty basic implementations of getSystemCpuLoad and
>> getProcessCpuLoad
>>
>> Hi Matthias,
>>
>> the change looks good!
>> I can sponsor it once we get the approval.
>>
>> Also forwarded to buil-dev for the minimal build change.
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias wrote:
>>> Hello , Mark reported this issue on AIX with OpenJDK8 :
>>>
>>>>
>>>>I'm getting an unsatisfied link error when using logstash on AIX but I suspect the issue is with AIX or the JRE, the exception is:
>>>>
>>>> java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()D
>>>> getProcessCpuLoad at sun/management/OperatingSystemImpl.java:-2
>>>> at org/logstash/instrument/monitors/ProcessMonitor.java:40
>>>> detect at org/logstash/instrument/monitors/ProcessMonitor.java:79
>>>> generate at
>>>> org/logstash/instrument/reports/ProcessReport.java:15
>>>>
>>>> this is the line in logstash:
>>>>
>>>> this.cpuProcessPercent =
>>>> scaleLoadToPercent(unixOsBean.getProcessCpuLoad());
>>>>
>>>> https://github.com/elastic/logstash/blob/master/logstash-core/src/ma
>>>> i n/java/org/logstash/instrument/monitors/ProcessMonitor.java
>>>>
>>>>
>>>> Could anybody help steer me in the right direction?
>>>>
>>>
>>> This fix addresses the missing getSystemCpuLoad and getProcessCpuLoad on AIX .
>>> JDK8 is only affected , JDK9 and higher is not affected .
>>>
>>> Could I get a review for this change ?
>>>
>>>
>>> Change :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8193807/
>>>
>>> Bug :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8193807
>>>
>>>
>>> Thanks, Matthias
>> ------------ Kingfisher plc Registered Office: 3 Sheldon Square, Paddington, London W2 6PX Registered in England, Number 1664812 This e-mail is only intended for the person(s) to whom it is addressed and may contain confidential information. Unless stated to the contrary, any opinions or comments are personal to the writer and do not represent the official view of the company. If you have received this e-mail in error, please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person. Thank you for your co-operation.
> ------------ Kingfisher plc Registered Office: 3 Sheldon Square, Paddington, London W2 6PX Registered in England, Number 1664812 This e-mail is only intended for the person(s) to whom it is addressed and may contain confidential information. Unless stated to the contrary, any opinions or comments are personal to the writer and do not represent the official view of the company. If you have received this e-mail in error, please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person. Thank you for your co-operation.
From vitalyd at gmail.com Wed Jan 3 16:56:23 2018
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 3 Jan 2018 11:56:23 -0500
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
Message-ID:
Hi all,
Consider the following stacktraces of the main app thread and a background
thread:
"main" #1 prio=5 os_prio=0 tid=0x0000000001bfd000 nid=0x1958 waiting for
monitor entry [0x00002b98ceba3000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Runtime.loadLibrary0(Runtime.java:862)
- waiting to lock <0x00000007bf834b20> (a java.lang.Runtime)
at java.lang.System.loadLibrary(System.java:1122)
at sun.nio.fs.UnixNativeDispatcher$1.run(
UnixNativeDispatcher.java:573)
at sun.nio.fs.UnixNativeDispatcher$1.run(
UnixNativeDispatcher.java:571)
at java.security.AccessController.doPrivileged(Native
Method)
at sun.nio.fs.UnixNativeDispatcher.(
UnixNativeDispatcher.java:571)
at sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:67)
at sun.nio.fs.LinuxFileSystem.<
init>(LinuxFileSystem.java:39)
at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
LinuxFileSystemProvider.java:46)
at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
LinuxFileSystemProvider.java:39)
at sun.nio.fs.UnixFileSystemProvider.(
UnixFileSystemProvider.java:56)
at sun.nio.fs.LinuxFileSystemProvider.
(LinuxFileSystemProvider.java:41)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(
NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorI
mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.
newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at sun.nio.fs.DefaultFileSystemProvider.createProvider(
DefaultFileSystemProvider.java:48)
at sun.nio.fs.DefaultFileSystemProvider.create(
DefaultFileSystemProvider.java:63)
at java.nio.file.FileSystems$DefaultFileSystemHolder.
getDefaultProvider(FileSystems.java:108)
at java.nio.file.FileSystems$DefaultFileSystemHolder.
access$000(FileSystems.java:89)
at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(
FileSystems.java:98)
at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(
FileSystems.java:96)
at java.security.AccessController.doPrivileged(Native
Method)
at java.nio.file.FileSystems$DefaultFileSystemHolder.
defaultFileSystem(FileSystems.java:96)
at java.nio.file.FileSystems$DefaultFileSystemHolder.<
clinit>(FileSystems.java:90)
at java.nio.file.FileSystems.getDefault(FileSystems.java:
176)
at java.nio.file.Paths.get(Paths.java:84)
at .ServiceLoader.
setup(ServiceLoader.java:446)
at .MetadataAdminLoader.main(
MetadataAdminLoader.java:52)
"shardDbExecutor-0-pool-0" #33 prio=5 os_prio=0 tid=0x0000000001ebf000
nid=0x1d01 in Object.wait() [0x00002b991f941000]
java.lang.Thread.State: RUNNABLE
at java.nio.file.FileSystems.getDefault(FileSystems.java:
176)
at java.nio.file.Paths.get(Paths.java:138)
at sun.misc.Launcher$ExtClassLoader.findLibrary(
Launcher.java:224)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1830)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
- locked <0x00000007bf834b20> (a java.lang.Runtime)
at java.lang.System.loadLibrary(System.java:1122)
at sun.security.ec.SunEC$1.run(SunEC.java:60)
at sun.security.ec.SunEC$1.run(SunEC.java:58)
at java.security.AccessController.doPrivileged(Native
Method)
at sun.security.ec.SunEC.(SunEC.java:58)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(
NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorI
mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.
newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at sun.security.jca.ProviderConfig$2.run(
ProviderConfig.java:221)
at sun.security.jca.ProviderConfig$2.run(
ProviderConfig.java:206)
at java.security.AccessController.doPrivileged(Native
Method)
at sun.security.jca.ProviderConfig.doLoadProvider(
ProviderConfig.java:206)
at sun.security.jca.ProviderConfig.getProvider(
ProviderConfig.java:187)
- locked <0x00000007bea03f48> (a sun.security.jca.
ProviderConfig)
at sun.security.jca.ProviderList.
getProvider(ProviderList.java:233)
at sun.security.jca.ProviderList.
getService(ProviderList.java:331)
at sun.security.jca.GetInstance.
getInstance(GetInstance.java:157)
at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
at com.microsoft.sqlserver.jdbc.
TDSChannel.enableSSL(IOBuffer.java:1658)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.
connectHelper(SQLServerConnection.java:1976)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(
SQLServerConnection.java:1627)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.
connectInternal(SQLServerConnection.java:1458)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(
SQLServerConnection.java:772)
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(
SQLServerDriver.java:1168)
at java.sql.DriverManager.getConnection(DriverManager.
java:664)
at java.sql.DriverManager.getConnection(DriverManager.
java:208)
at .ConnectionPool.createGoodConnection(
ConnectionPool.java:565)
at .ConnectionPool.createNewConnection(
ConnectionPool.java:519)
at .ConnectionPool.
getConnection(ConnectionPool.java:407)
at .StatementCachingConnectionImpl
.setupConnection(StatementCachingConnectionImpl.java:94)
at .StatementCachingConnectionImpl.(
StatementCachingConnectionImpl.java:54)
at .TestConnectionFactories$
FaultInjectingConnection.(TestConnectionFactories.java:90)
at .TestConnectionFactories.lambda$static$3(
TestConnectionFactories.java:33)
at .TestConnectionFactories$$
Lambda$12/1738236591.newConnection(Unknown Source)
at .SedaExecutor.
setupConnections(SedaExecutor.java:130)
at .SedaExecutor$SedaThreadFactory.lambda$
newThread$0(SedaExecutor.java:165)
at
.SedaExecutor$SedaThreadFactory$$Lambda$22/1392419022.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:748)
The application intermittently hangs on startup, and the above callstacks
are present. It seems like there's a deadlock due to concurrent class
loading and default FileSystem initialization (which itself triggers class
loading here).
I wasn't able to find any existing JBS entries reporting anything similar.
Am I seeing this right? Is this a known issue?
Thanks
From vitalyd at gmail.com Wed Jan 3 16:57:28 2018
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 3 Jan 2018 11:57:28 -0500
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
In-Reply-To:
References:
Message-ID:
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=0x0000000001bfd000 nid=0x1958 waiting for
> monitor entry [0x00002b98ceba3000]
>
> java.lang.Thread.State: BLOCKED (on object monitor)
>
> at java.lang.Runtime.loadLibrary0(Runtime.java:862)
>
> - waiting to lock <0x00000007bf834b20> (a
> java.lang.Runtime)
>
> at java.lang.System.loadLibrary(System.java:1122)
>
> at sun.nio.fs.UnixNativeDispatche
> r$1.run(UnixNativeDispatcher.java:573)
>
> at sun.nio.fs.UnixNativeDispatche
> r$1.run(UnixNativeDispatcher.java:571)
>
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> at sun.nio.fs.UnixNativeDispatche
> r.(UnixNativeDispatcher.java:571)
>
> at sun.nio.fs.UnixFileSystem. t>(UnixFileSystem.java:67)
>
> at sun.nio.fs.LinuxFileSystem. it>(LinuxFileSystem.java:39)
>
> at sun.nio.fs.LinuxFileSystemProv
> ider.newFileSystem(LinuxFileSystemProvider.java:46)
>
> at sun.nio.fs.LinuxFileSystemProv
> ider.newFileSystem(LinuxFileSystemProvider.java:39)
>
> at sun.nio.fs.UnixFileSystemProvi
> der.(UnixFileSystemProvider.java:56)
>
> at sun.nio.fs.LinuxFileSystemProvider.(
> LinuxFileSystemProvider.java:41)
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at sun.reflect.NativeConstructorA
> ccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at sun.reflect.DelegatingConstruc
> torAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.
> newInstance(Constructor.java:423)
>
> at java.lang.Class.newInstance(Class.java:442)
>
> at sun.nio.fs.DefaultFileSystemPr
> ovider.createProvider(DefaultFileSystemProvider.java:48)
>
> at sun.nio.fs.DefaultFileSystemPr
> ovider.create(DefaultFileSystemProvider.java:63)
>
> at java.nio.file.FileSystems$Defa
> ultFileSystemHolder.getDefaultProvider(FileSystems.java:108)
>
> at java.nio.file.FileSystems$Defa
> ultFileSystemHolder.access$000(FileSystems.java:89)
>
> at java.nio.file.FileSystems$Defa
> ultFileSystemHolder$1.run(FileSystems.java:98)
>
> at java.nio.file.FileSystems$Defa
> ultFileSystemHolder$1.run(FileSystems.java:96)
>
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> at java.nio.file.FileSystems$Defa
> ultFileSystemHolder.defaultFileSystem(FileSystems.java:96)
>
> at java.nio.file.FileSystems$Defa
> ultFileSystemHolder.(FileSystems.java:90)
>
> at java.nio.file.FileSystems.getD
> efault(FileSystems.java:176)
>
> at java.nio.file.Paths.get(Paths.java:84)
>
> at .ServiceLoader.s
> etup(ServiceLoader.java:446)
>
> at .MetadataAdminLo
> ader.main(MetadataAdminLoader.java:52)
>
>
>
>
>
> "shardDbExecutor-0-pool-0" #33 prio=5 os_prio=0 tid=0x0000000001ebf000
> nid=0x1d01 in Object.wait() [0x00002b991f941000]
>
> java.lang.Thread.State: RUNNABLE
>
> at java.nio.file.FileSystems.getD
> efault(FileSystems.java:176)
>
> at java.nio.file.Paths.get(Paths.java:138)
>
> at sun.misc.Launcher$ExtClassLoad
> er.findLibrary(Launcher.java:224)
>
> at java.lang.ClassLoader.loadLibr
> ary(ClassLoader.java:1830)
>
> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>
> - locked <0x00000007bf834b20> (a java.lang.Runtime)
>
> at java.lang.System.loadLibrary(System.java:1122)
>
> at sun.security.ec.SunEC$1.run(SunEC.java:60)
>
> at sun.security.ec.SunEC$1.run(SunEC.java:58)
>
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> at sun.security.ec.SunEC.(SunEC.java:58)
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at sun.reflect.NativeConstructorA
> ccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at sun.reflect.DelegatingConstruc
> torAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.
> newInstance(Constructor.java:423)
>
> at java.lang.Class.newInstance(Class.java:442)
>
> at sun.security.jca.ProviderConfi
> g$2.run(ProviderConfig.java:221)
>
> at sun.security.jca.ProviderConfi
> g$2.run(ProviderConfig.java:206)
>
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> at sun.security.jca.ProviderConfi
> g.doLoadProvider(ProviderConfig.java:206)
>
> at sun.security.jca.ProviderConfi
> g.getProvider(ProviderConfig.java:187)
>
> - locked <0x00000007bea03f48> (a
> sun.security.jca.ProviderConfig)
>
> at sun.security.jca.ProviderList.
> getProvider(ProviderList.java:233)
>
> at sun.security.jca.ProviderList.
> getService(ProviderList.java:331)
>
> at sun.security.jca.GetInstance.g
> etInstance(GetInstance.java:157)
>
> at javax.net.ssl.SSLContext.getIn
> stance(SSLContext.java:156)
>
> at com.microsoft.sqlserver.jdbc.T
> DSChannel.enableSSL(IOBuffer.java:1658)
>
> at com.microsoft.sqlserver.jdbc.S
> QLServerConnection.connectHelper(SQLServerConnection.java:1976)
>
> at com.microsoft.sqlserver.jdbc.S
> QLServerConnection.login(SQLServerConnection.java:1627)
>
> at com.microsoft.sqlserver.jdbc.S
> QLServerConnection.connectInternal(SQLServerConnection.java:1458)
>
> at com.microsoft.sqlserver.jdbc.S
> QLServerConnection.connect(SQLServerConnection.java:772)
>
> at com.microsoft.sqlserver.jdbc.S
> QLServerDriver.connect(SQLServerDriver.java:1168)
>
> at java.sql.DriverManager.getConn
> ection(DriverManager.java:664)
>
> at java.sql.DriverManager.getConn
> ection(DriverManager.java:208)
>
> at .ConnectionPool.
> createGoodConnection(ConnectionPool.java:565)
>
> at .ConnectionPool.
> createNewConnection(ConnectionPool.java:519)
>
> at .ConnectionPool.
> getConnection(ConnectionPool.java:407)
>
> at .StatementCachingConnectionImpl.
> setupConnection(StatementCachingConnectionImpl.java:94)
>
> at .StatementCachin
> gConnectionImpl.(StatementCachingConnectionImpl.java:54)
>
> at .TestConnectionF
> actories$FaultInjectingConnection.(TestConnectionFactories.java:90)
>
> at .TestConnectionF
> actories.lambda$static$3(TestConnectionFactories.java:33)
>
> at .TestConnectionFactories$$Lambda$12/
> 1738236591.newConnection(Unknown Source)
>
> at .SedaExecutor.se
> tupConnections(SedaExecutor.java:130)
>
> at .SedaExecutor$Se
> daThreadFactory.lambda$newThread$0(SedaExecutor.java:165)
>
> at .SedaExecutor$Se
> daThreadFactory$$Lambda$22/1392419022.run(Unknown Source)
>
> at java.lang.Thread.run(Thread.java:748)
>
>
> The application intermittently hangs on startup, and the above callstacks
> are present. It seems like there's a deadlock due to concurrent class
> loading and default FileSystem initialization (which itself triggers class
> loading here).
>
> I wasn't able to find any existing JBS entries reporting anything
> similar. Am I seeing this right? Is this a known issue?
>
> Thanks
>
From Alan.Bateman at oracle.com Wed Jan 3 17:00:32 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 3 Jan 2018 17:00:32 +0000
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
In-Reply-To:
References:
Message-ID:
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 background
> thread:
>
> "main" #1 prio=5 os_prio=0 tid=0x0000000001bfd000 nid=0x1958 waiting for
> monitor entry [0x00002b98ceba3000]
>
> java.lang.Thread.State: BLOCKED (on object monitor)
>
> at java.lang.Runtime.loadLibrary0(Runtime.java:862)
>
> - waiting to lock <0x00000007bf834b20> (a java.lang.Runtime)
>
> at java.lang.System.loadLibrary(System.java:1122)
>
> at sun.nio.fs.UnixNativeDispatcher$1.run(
> UnixNativeDispatcher.java:573)
>
> at sun.nio.fs.UnixNativeDispatcher$1.run(
> UnixNativeDispatcher.java:571)
>
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> at sun.nio.fs.UnixNativeDispatcher.(
> UnixNativeDispatcher.java:571)
>
> at sun.nio.fs.UnixFileSystem.(UnixFileSystem.java:67)
>
> at sun.nio.fs.LinuxFileSystem.<
> init>(LinuxFileSystem.java:39)
>
> at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
> LinuxFileSystemProvider.java:46)
>
> at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
> LinuxFileSystemProvider.java:39)
>
> at sun.nio.fs.UnixFileSystemProvider.(
> UnixFileSystemProvider.java:56)
>
> at sun.nio.fs.LinuxFileSystemProvider.
> (LinuxFileSystemProvider.java:41)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(
> NativeConstructorAccessorImpl.java:62)
>
> at sun.reflect.DelegatingConstructorAccessorI
> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.
> newInstance(Constructor.java:423)
>
> at java.lang.Class.newInstance(Class.java:442)
>
> at sun.nio.fs.DefaultFileSystemProvider.createProvider(
> DefaultFileSystemProvider.java:48)
>
> at sun.nio.fs.DefaultFileSystemProvider.create(
> DefaultFileSystemProvider.java:63)
>
> at java.nio.file.FileSystems$DefaultFileSystemHolder.
> getDefaultProvider(FileSystems.java:108)
>
> at java.nio.file.FileSystems$DefaultFileSystemHolder.
> access$000(FileSystems.java:89)
>
> at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(
> FileSystems.java:98)
>
> at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(
> FileSystems.java:96)
>
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> at java.nio.file.FileSystems$DefaultFileSystemHolder.
> defaultFileSystem(FileSystems.java:96)
>
> at java.nio.file.FileSystems$DefaultFileSystemHolder.<
> clinit>(FileSystems.java:90)
>
> at java.nio.file.FileSystems.getDefault(FileSystems.java:
> 176)
>
> at java.nio.file.Paths.get(Paths.java:84)
>
> at .ServiceLoader.
> setup(ServiceLoader.java:446)
>
> at .MetadataAdminLoader.main(
> MetadataAdminLoader.java:52)
>
>
>
>
>
> "shardDbExecutor-0-pool-0" #33 prio=5 os_prio=0 tid=0x0000000001ebf000
> nid=0x1d01 in Object.wait() [0x00002b991f941000]
>
> java.lang.Thread.State: RUNNABLE
>
> at java.nio.file.FileSystems.getDefault(FileSystems.java:
> 176)
>
> at java.nio.file.Paths.get(Paths.java:138)
>
> at sun.misc.Launcher$ExtClassLoader.findLibrary(
> Launcher.java:224)
>
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1830)
>
> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>
> - locked <0x00000007bf834b20> (a java.lang.Runtime)
>
> at java.lang.System.loadLibrary(System.java:1122)
>
> at sun.security.ec.SunEC$1.run(SunEC.java:60)
>
> at sun.security.ec.SunEC$1.run(SunEC.java:58)
>
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> at sun.security.ec.SunEC.(SunEC.java:58)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(
> NativeConstructorAccessorImpl.java:62)
>
> at sun.reflect.DelegatingConstructorAccessorI
> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.
> newInstance(Constructor.java:423)
>
> at java.lang.Class.newInstance(Class.java:442)
>
> at sun.security.jca.ProviderConfig$2.run(
> ProviderConfig.java:221)
>
> at sun.security.jca.ProviderConfig$2.run(
> ProviderConfig.java:206)
>
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> at sun.security.jca.ProviderConfig.doLoadProvider(
> ProviderConfig.java:206)
>
> at sun.security.jca.ProviderConfig.getProvider(
> ProviderConfig.java:187)
>
> - locked <0x00000007bea03f48> (a sun.security.jca.
> ProviderConfig)
>
> at sun.security.jca.ProviderList.
> getProvider(ProviderList.java:233)
>
> at sun.security.jca.ProviderList.
> getService(ProviderList.java:331)
>
> at sun.security.jca.GetInstance.
> getInstance(GetInstance.java:157)
>
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
>
> at com.microsoft.sqlserver.jdbc.
> TDSChannel.enableSSL(IOBuffer.java:1658)
>
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.
> connectHelper(SQLServerConnection.java:1976)
>
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(
> SQLServerConnection.java:1627)
>
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.
> connectInternal(SQLServerConnection.java:1458)
>
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(
> SQLServerConnection.java:772)
>
> at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(
> SQLServerDriver.java:1168)
>
> at java.sql.DriverManager.getConnection(DriverManager.
> java:664)
>
> at java.sql.DriverManager.getConnection(DriverManager.
> java:208)
>
> at .ConnectionPool.createGoodConnection(
> ConnectionPool.java:565)
>
> at .ConnectionPool.createNewConnection(
> ConnectionPool.java:519)
>
> at .ConnectionPool.
> getConnection(ConnectionPool.java:407)
>
> at .StatementCachingConnectionImpl
> .setupConnection(StatementCachingConnectionImpl.java:94)
>
> at .StatementCachingConnectionImpl.(
> StatementCachingConnectionImpl.java:54)
>
> at .TestConnectionFactories$
> FaultInjectingConnection.(TestConnectionFactories.java:90)
>
> at .TestConnectionFactories.lambda$static$3(
> TestConnectionFactories.java:33)
>
> at .TestConnectionFactories$$
> Lambda$12/1738236591.newConnection(Unknown Source)
>
> at .SedaExecutor.
> setupConnections(SedaExecutor.java:130)
>
> at .SedaExecutor$SedaThreadFactory.lambda$
> newThread$0(SedaExecutor.java:165)
>
> at
> .SedaExecutor$SedaThreadFactory$$Lambda$22/1392419022.run(Unknown
> Source)
>
> at java.lang.Thread.run(Thread.java:748)
>
>
> The application intermittently hangs on startup, and the above callstacks
> are present. It seems like there's a deadlock due to concurrent class
> loading and default FileSystem initialization (which itself triggers class
> loading here).
>
> I wasn't able to find any existing JBS entries reporting anything similar.
> Am I seeing this right? Is this a known issue?
>
> Thanks
From vitalyd at gmail.com Wed Jan 3 17:13:52 2018
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 3 Jan 2018 12:13:52 -0500
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
In-Reply-To:
References:
Message-ID:
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
mentioned that initially).
Trying this on JDK9 is a bit tricky as the code (and its dependencies) in
question isn't easily runnable on 9 without quite a bit of work.
Do you agree with the deadlock assessment though? That's what it looks like
to me but wanted to make sure I'm not missing anything.
Thanks Alan
>
> -Alan
>
>
> On 03/01/2018 16:56, 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=0x0000000001bfd000 nid=0x1958 waiting for
>> monitor entry [0x00002b98ceba3000]
>>
>> java.lang.Thread.State: BLOCKED (on object monitor)
>>
>> at java.lang.Runtime.loadLibrary0(Runtime.java:862)
>>
>> - waiting to lock <0x00000007bf834b20> (a
>> java.lang.Runtime)
>>
>> at java.lang.System.loadLibrary(System.java:1122)
>>
>> at sun.nio.fs.UnixNativeDispatcher$1.run(
>> UnixNativeDispatcher.java:573)
>>
>> at sun.nio.fs.UnixNativeDispatcher$1.run(
>> UnixNativeDispatcher.java:571)
>>
>> at java.security.AccessController.doPrivileged(Native
>> Method)
>>
>> at sun.nio.fs.UnixNativeDispatcher.(
>> UnixNativeDispatcher.java:571)
>>
>> at sun.nio.fs.UnixFileSystem.> t>(UnixFileSystem.java:67)
>>
>> at sun.nio.fs.LinuxFileSystem.<
>> init>(LinuxFileSystem.java:39)
>>
>> at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
>> LinuxFileSystemProvider.java:46)
>>
>> at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
>> LinuxFileSystemProvider.java:39)
>>
>> at sun.nio.fs.UnixFileSystemProvider.(
>> UnixFileSystemProvider.java:56)
>>
>> at sun.nio.fs.LinuxFileSystemProvider.
>> (LinuxFileSystemProvider.java:41)
>>
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>>
>> at sun.reflect.NativeConstructorA
>> ccessorImpl.newInstance(
>> NativeConstructorAccessorImpl.java:62)
>>
>> at sun.reflect.DelegatingConstructorAccessorI
>> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>
>> at java.lang.reflect.Constructor.
>> newInstance(Constructor.java:423)
>>
>> at java.lang.Class.newInstance(Class.java:442)
>>
>> at sun.nio.fs.DefaultFileSystemProvider.createProvider(
>> DefaultFileSystemProvider.java:48)
>>
>> at sun.nio.fs.DefaultFileSystemProvider.create(
>> DefaultFileSystemProvider.java:63)
>>
>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
>> getDefaultProvider(FileSystems.java:108)
>>
>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
>> access$000(FileSystems.java:89)
>>
>> at java.nio.file.FileSystems$Defa
>> ultFileSystemHolder$1.run(
>> FileSystems.java:98)
>>
>> at java.nio.file.FileSystems$Defa
>> ultFileSystemHolder$1.run(
>> FileSystems.java:96)
>>
>> at java.security.AccessController.doPrivileged(Native
>> Method)
>>
>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
>> defaultFileSystem(FileSystems.java:96)
>>
>> at java.nio.file.FileSystems$DefaultFileSystemHolder.<
>> clinit>(FileSystems.java:90)
>>
>> at java.nio.file.FileSystems.getD
>> efault(FileSystems.java:
>> 176)
>>
>> at java.nio.file.Paths.get(Paths.java:84)
>>
>> at .ServiceLoader.
>> setup(ServiceLoader.java:446)
>>
>> at .MetadataAdminLoader.main(
>> MetadataAdminLoader.java:52)
>>
>>
>>
>>
>>
>> "shardDbExecutor-0-pool-0" #33 prio=5 os_prio=0 tid=0x0000000001ebf000
>> nid=0x1d01 in Object.wait() [0x00002b991f941000]
>>
>> java.lang.Thread.State: RUNNABLE
>>
>> at java.nio.file.FileSystems.getD
>> efault(FileSystems.java:
>> 176)
>>
>> at java.nio.file.Paths.get(Paths.java:138)
>>
>> at sun.misc.Launcher$ExtClassLoader.findLibrary(
>> Launcher.java:224)
>>
>> at java.lang.ClassLoader.loadLibr
>> ary(ClassLoader.java:1830)
>>
>> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>
>> - locked <0x00000007bf834b20> (a java.lang.Runtime)
>>
>> at java.lang.System.loadLibrary(System.java:1122)
>>
>> at sun.security.ec.SunEC$1.run(SunEC.java:60)
>>
>> at sun.security.ec.SunEC$1.run(SunEC.java:58)
>>
>> at java.security.AccessController.doPrivileged(Native
>> Method)
>>
>> at sun.security.ec.SunEC.(SunEC.java:58)
>>
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>>
>> at sun.reflect.NativeConstructorA
>> ccessorImpl.newInstance(
>> NativeConstructorAccessorImpl.java:62)
>>
>> at sun.reflect.DelegatingConstructorAccessorI
>> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>
>> at java.lang.reflect.Constructor.
>> newInstance(Constructor.java:423)
>>
>> at java.lang.Class.newInstance(Class.java:442)
>>
>> at sun.security.jca.ProviderConfig$2.run(
>> ProviderConfig.java:221)
>>
>> at sun.security.jca.ProviderConfig$2.run(
>>
>> ProviderConfig.java:206)
>>
>> at java.security.AccessController.doPrivileged(Native
>> Method)
>>
>> at sun.security.jca.ProviderConfig.doLoadProvider(
>> ProviderConfig.java:206)
>>
>> at sun.security.jca.ProviderConfig.getProvider(
>> ProviderConfig.java:187)
>>
>> - locked <0x00000007bea03f48> (a sun.security.jca.
>> ProviderConfig)
>>
>> at sun.security.jca.ProviderList.
>> getProvider(ProviderList.java:233)
>>
>> at sun.security.jca.ProviderList.
>> getService(ProviderList.java:331)
>>
>> at sun.security.jca.GetInstance.
>> getInstance(GetInstance.java:157)
>>
>> at javax.net.ssl.SSLContext.getIn
>> stance(SSLContext.java:156)
>>
>> at com.microsoft.sqlserver.jdbc.
>> TDSChannel.enableSSL(IOBuffer.java:1658)
>>
>> at com.microsoft.sqlserver.jdbc.SQLServerConnection.
>> connectHelper(SQLServerConnection.java:1976)
>>
>> at com.microsoft.sqlserver.jdbc.S
>> QLServerConnection.login(
>> SQLServerConnection.java:1627)
>>
>> at com.microsoft.sqlserver.jdbc.SQLServerConnection.
>> connectInternal(SQLServerConnection.java:1458)
>>
>> at com.microsoft.sqlserver.jdbc.S
>> QLServerConnection.connect(
>> SQLServerConnection.java:772)
>>
>> at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(
>> SQLServerDriver.java:1168)
>>
>> at java.sql.DriverManager.getConnection(DriverManager.
>> java:664)
>>
>> at java.sql.DriverManager.getConnection(DriverManager.
>> java:208)
>>
>> at .ConnectionPool.createGoodConnection(
>> ConnectionPool.java:565)
>>
>> at .ConnectionPool.createNewConnection(
>> ConnectionPool.java:519)
>>
>> at .ConnectionPool.
>> getConnection(ConnectionPool.java:407)
>>
>> at .StatementCachingConnectionImpl
>> .setupConnection(StatementCachingConnectionImpl.java:94)
>>
>> at .StatementCachingConnectionImpl.(
>> StatementCachingConnectionImpl.java:54)
>>
>> at .TestConnectionFactories$
>> FaultInjectingConnection.(TestConnectionFactories.java:90)
>>
>> at .TestConnectionF
>> actories.lambda$static$3(
>> TestConnectionFactories.java:33)
>>
>> at .TestConnectionFactories$$
>> Lambda$12/1738236591.newConnection(Unknown Source)
>>
>> at .SedaExecutor.
>> setupConnections(SedaExecutor.java:130)
>>
>> at .SedaExecutor$SedaThreadFactory.lambda$
>> newThread$0(SedaExecutor.java:165)
>>
>> at
>> .SedaExecutor$SedaThreadFactory$$Lambda$22/139
>> 2419022.run(Unknown
>> Source)
>>
>> at java.lang.Thread.run(Thread.java:748)
>>
>>
>> The application intermittently hangs on startup, and the above callstacks
>> are present. It seems like there's a deadlock due to concurrent class
>> loading and default FileSystem initialization (which itself triggers class
>> loading here).
>>
>> I wasn't able to find any existing JBS entries reporting anything similar.
>> Am I seeing this right? Is this a known issue?
>>
>> Thanks
>>
>
>
From adam.petcher at oracle.com Wed Jan 3 19:36:20 2018
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 3 Jan 2018 14:36:20 -0500
Subject: API review for X25519/X448
In-Reply-To: <9425dc17-1099-9544-d314-95ab9d56bc47@oracle.com>
References: <9425dc17-1099-9544-d314-95ab9d56bc47@oracle.com>
Message-ID: <9a46a28b-1fbe-13a2-8b81-507e9438667d@oracle.com>
+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 Saturday,?
> January 13, anywhere on earth. At that point, I will combine your
> feedback with the initial feedback from the CSR group[3] and submit
> the API for final review by the CSR.
>
> The only significant change to the API since our last discussion[4] is
> that I changed the names of the key specs and interfaces from "XDH..."
> to "XEC..." This makes them more general and reusable in things like
> XEdDSA[5] and other non-Diffie-Hellman cryptosystems based on the
> representations/operations defined in RFC 7748[6].
>
> [1] http://openjdk.java.net/jeps/324
> [2] https://bugs.openjdk.java.net/browse/JDK-8189806
> [3] https://wiki.openjdk.java.net/display/csr/Main
> [4]
> http://mail.openjdk.java.net/pipermail/security-dev/2017-September/016325.html
> [5] https://signal.org/docs/specifications/xeddsa/
> [6] https://tools.ietf.org/html/rfc7748
>
From martinrb at google.com Wed Jan 3 21:40:45 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 3 Jan 2018 13:40:45 -0800
Subject: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache
Message-ID:
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 local in customize() must be an improvement.
The UNSAFE publication in updateForm looks fishy, as does that comment
in MethodHandleImpl.java. Is there something the fullFence() is supposed
to do that isn't taken care of by putObjectVolatile ?
Feel free to take ownership of this bug from me.
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java
@@ -1660,13 +1660,13 @@
assert(newForm.customized == null || newForm.customized == this);
if (form == newForm) return;
newForm.prepare(); // as in MethodHandle.
- UNSAFE.putObject(this, FORM_OFFSET, newForm);
- UNSAFE.fullFence();
+ UNSAFE.putObjectVolatile(this, FORM_OFFSET, newForm);
}
/** Craft a LambdaForm customized for this particular MethodHandle */
/*non-public*/
void customize() {
+ final LambdaForm form = this.form;
if (form.customized == null) {
LambdaForm newForm = form.customize(this);
updateForm(newForm);
diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
@@ -909,7 +909,7 @@
int c = count;
maybeCustomizeTarget();
if (c <= 1) {
- // Try to limit number of updates.
MethodHandle.updateForm() doesn't guarantee LF update visibility.
+ // Try to limit number of updates.
if (isCounting) {
isCounting = false;
return true;
From martinrb at google.com Wed Jan 3 21:51:45 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 3 Jan 2018 13:51:45 -0800
Subject: JDK-8145371 ClassCastException thrown in
LambdaFormEditor.getInCache
In-Reply-To:
References:
Message-ID:
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.net/~martin/webrevs/jdk/MethodHandle.form/
> https://bugs.openjdk.java.net/browse/JDK-8145371
> Copying to a local in customize() must be an improvement.
> The UNSAFE publication in updateForm looks fishy, as does that comment
> in MethodHandleImpl.java. Is there something the fullFence() is supposed
> to do that isn't taken care of by putObjectVolatile ?
>
> Feel free to take ownership of this bug from me.
>
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java
> @@ -1660,13 +1660,13 @@
> assert(newForm.customized == null || newForm.customized == this);
> if (form == newForm) return;
> newForm.prepare(); // as in MethodHandle.
> - UNSAFE.putObject(this, FORM_OFFSET, newForm);
> - UNSAFE.fullFence();
> + UNSAFE.putObjectVolatile(this, FORM_OFFSET, newForm);
> }
>
> /** Craft a LambdaForm customized for this particular MethodHandle */
> /*non-public*/
> void customize() {
> + final LambdaForm form = this.form;
> if (form.customized == null) {
> LambdaForm newForm = form.customize(this);
> updateForm(newForm);
> diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> @@ -909,7 +909,7 @@
> int c = count;
> maybeCustomizeTarget();
> if (c <= 1) {
> - // Try to limit number of updates. MethodHandle.updateForm() doesn't guarantee LF update visibility.
> + // Try to limit number of updates.
> if (isCounting) {
> isCounting = false;
> return true;
>
>
>
From huizhe.wang at oracle.com Wed Jan 3 23:32:55 2018
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 3 Jan 2018 15:32:55 -0800
Subject: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the
javax/xml/namespace package
Message-ID: <556cae77-3efb-ad7b-3310-b1f7c8389387@oracle.com>
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
XML" shall be to the specification, not the QName section, the fragment
portion of the link, e.g. "#ns-qualnames" therefore is also removed.
JBS: https://bugs.openjdk.java.net/browse/JDK-8189704
webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8189704/webrev/
Thanks,
Joe
From huizhe.wang at oracle.com Wed Jan 3 23:53:26 2018
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 3 Jan 2018 15:53:26 -0800
Subject: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the
javax/xml/namespace package
In-Reply-To: <556cae77-3efb-ad7b-3310-b1f7c8389387@oracle.com>
References: <556cae77-3efb-ad7b-3310-b1f7c8389387@oracle.com>
Message-ID:
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
specification that the link to "Namespaces in XML" points to, there's no
more reason to link to the Errata.
Thanks,
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 extra link(s).? Also, for NamespaceContext, the link to
> "Namespaces in XML" shall be to the specification, not the QName
> section, the fragment portion of the link, e.g. "#ns-qualnames"
> therefore is also removed.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8189704
> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8189704/webrev/
>
> Thanks,
> Joe
From joe.darcy at oracle.com Thu Jan 4 00:47:41 2018
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 03 Jan 2018 16:47:41 -0800
Subject: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the
javax/xml/namespace package
In-Reply-To: <556cae77-3efb-ad7b-3310-b1f7c8389387@oracle.com>
References: <556cae77-3efb-ad7b-3310-b1f7c8389387@oracle.com>
Message-ID: <5A4D79AD.4040000@oracle.com>
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 extra link(s). Also, for NamespaceContext, the link to
> "Namespaces in XML" shall be to the specification, not the QName
> section, the fragment portion of the link, e.g. "#ns-qualnames"
> therefore is also removed.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8189704
> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8189704/webrev/
>
> Thanks,
> Joe
From huizhe.wang at oracle.com Thu Jan 4 01:05:54 2018
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 3 Jan 2018 17:05:54 -0800
Subject: RFR (JDK10/JAXP Doc-only) 8189704: broken links in the
javax/xml/namespace package
In-Reply-To: <5A4D79AD.4040000@oracle.com>
References: <556cae77-3efb-ad7b-3310-b1f7c8389387@oracle.com>
<5A4D79AD.4040000@oracle.com>
Message-ID: <0cf557b4-14df-5722-e2a9-02cee6fb2219@oracle.com>
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 the Namespaces in XML specification itself. There is no
>> need for the extra link(s).? Also, for NamespaceContext, the link to
>> "Namespaces in XML" shall be to the specification, not the QName
>> section, the fragment portion of the link, e.g. "#ns-qualnames"
>> therefore is also removed.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8189704
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8189704/webrev/
>>
>> Thanks,
>> Joe
>
From david.holmes at oracle.com Thu Jan 4 01:35:53 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Jan 2018 11:35:53 +1000
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
In-Reply-To:
References:
Message-ID:
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 in the follow-up email (sorry, should've
> mentioned that initially).
>
> Trying this on JDK9 is a bit tricky as the code (and its dependencies) in
> question isn't easily runnable on 9 without quite a bit of work.
>
> Do you agree with the deadlock assessment though? That's what it looks like
> to me but wanted to make sure I'm not missing anything.
You're not missing anything. It's a class initialization related "deadlock".
Thread A has called FileSystems.getDefault() which is doing of
DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrary0
which needs to lock the Runtime instance.
Thread B is already doing a loadLibrary and holds the Runtime lock, the
loadLibrary code then needs to do FileSystems.getDefault() which has to
load and initialize DefaultFileSystemHolder, but that initialization is
already in progress so internally the thread does a wait().
So Thread B is waiting for Thread A to finish initialization, but holds
the monitor lock that Thread A needs to finish the initialization. Deadlock.
AFAICS this will still be possible in 9/10/11
Cheers,
David
> Thanks Alan
>
>>
>> -Alan
>>
>>
>> On 03/01/2018 16:56, 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=0x0000000001bfd000 nid=0x1958 waiting for
>>> monitor entry [0x00002b98ceba3000]
>>>
>>> java.lang.Thread.State: BLOCKED (on object monitor)
>>>
>>> at java.lang.Runtime.loadLibrary0(Runtime.java:862)
>>>
>>> - waiting to lock <0x00000007bf834b20> (a
>>> java.lang.Runtime)
>>>
>>> at java.lang.System.loadLibrary(System.java:1122)
>>>
>>> at sun.nio.fs.UnixNativeDispatcher$1.run(
>>> UnixNativeDispatcher.java:573)
>>>
>>> at sun.nio.fs.UnixNativeDispatcher$1.run(
>>> UnixNativeDispatcher.java:571)
>>>
>>> at java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>> at sun.nio.fs.UnixNativeDispatcher.(
>>> UnixNativeDispatcher.java:571)
>>>
>>> at sun.nio.fs.UnixFileSystem.>> t>(UnixFileSystem.java:67)
>>>
>>> at sun.nio.fs.LinuxFileSystem.<
>>> init>(LinuxFileSystem.java:39)
>>>
>>> at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
>>> LinuxFileSystemProvider.java:46)
>>>
>>> at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
>>> LinuxFileSystemProvider.java:39)
>>>
>>> at sun.nio.fs.UnixFileSystemProvider.(
>>> UnixFileSystemProvider.java:56)
>>>
>>> at sun.nio.fs.LinuxFileSystemProvider.
>>> (LinuxFileSystemProvider.java:41)
>>>
>>> at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method)
>>>
>>> at sun.reflect.NativeConstructorA
>>> ccessorImpl.newInstance(
>>> NativeConstructorAccessorImpl.java:62)
>>>
>>> at sun.reflect.DelegatingConstructorAccessorI
>>> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>
>>> at java.lang.reflect.Constructor.
>>> newInstance(Constructor.java:423)
>>>
>>> at java.lang.Class.newInstance(Class.java:442)
>>>
>>> at sun.nio.fs.DefaultFileSystemProvider.createProvider(
>>> DefaultFileSystemProvider.java:48)
>>>
>>> at sun.nio.fs.DefaultFileSystemProvider.create(
>>> DefaultFileSystemProvider.java:63)
>>>
>>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
>>> getDefaultProvider(FileSystems.java:108)
>>>
>>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
>>> access$000(FileSystems.java:89)
>>>
>>> at java.nio.file.FileSystems$Defa
>>> ultFileSystemHolder$1.run(
>>> FileSystems.java:98)
>>>
>>> at java.nio.file.FileSystems$Defa
>>> ultFileSystemHolder$1.run(
>>> FileSystems.java:96)
>>>
>>> at java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
>>> defaultFileSystem(FileSystems.java:96)
>>>
>>> at java.nio.file.FileSystems$DefaultFileSystemHolder.<
>>> clinit>(FileSystems.java:90)
>>>
>>> at java.nio.file.FileSystems.getD
>>> efault(FileSystems.java:
>>> 176)
>>>
>>> at java.nio.file.Paths.get(Paths.java:84)
>>>
>>> at .ServiceLoader.
>>> setup(ServiceLoader.java:446)
>>>
>>> at .MetadataAdminLoader.main(
>>> MetadataAdminLoader.java:52)
>>>
>>>
>>>
>>>
>>>
>>> "shardDbExecutor-0-pool-0" #33 prio=5 os_prio=0 tid=0x0000000001ebf000
>>> nid=0x1d01 in Object.wait() [0x00002b991f941000]
>>>
>>> java.lang.Thread.State: RUNNABLE
>>>
>>> at java.nio.file.FileSystems.getD
>>> efault(FileSystems.java:
>>> 176)
>>>
>>> at java.nio.file.Paths.get(Paths.java:138)
>>>
>>> at sun.misc.Launcher$ExtClassLoader.findLibrary(
>>> Launcher.java:224)
>>>
>>> at java.lang.ClassLoader.loadLibr
>>> ary(ClassLoader.java:1830)
>>>
>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
>>>
>>> - locked <0x00000007bf834b20> (a java.lang.Runtime)
>>>
>>> at java.lang.System.loadLibrary(System.java:1122)
>>>
>>> at sun.security.ec.SunEC$1.run(SunEC.java:60)
>>>
>>> at sun.security.ec.SunEC$1.run(SunEC.java:58)
>>>
>>> at java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>> at sun.security.ec.SunEC.(SunEC.java:58)
>>>
>>> at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>> Method)
>>>
>>> at sun.reflect.NativeConstructorA
>>> ccessorImpl.newInstance(
>>> NativeConstructorAccessorImpl.java:62)
>>>
>>> at sun.reflect.DelegatingConstructorAccessorI
>>> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>
>>> at java.lang.reflect.Constructor.
>>> newInstance(Constructor.java:423)
>>>
>>> at java.lang.Class.newInstance(Class.java:442)
>>>
>>> at sun.security.jca.ProviderConfig$2.run(
>>> ProviderConfig.java:221)
>>>
>>> at sun.security.jca.ProviderConfig$2.run(
>>>
>>> ProviderConfig.java:206)
>>>
>>> at java.security.AccessController.doPrivileged(Native
>>> Method)
>>>
>>> at sun.security.jca.ProviderConfig.doLoadProvider(
>>> ProviderConfig.java:206)
>>>
>>> at sun.security.jca.ProviderConfig.getProvider(
>>> ProviderConfig.java:187)
>>>
>>> - locked <0x00000007bea03f48> (a sun.security.jca.
>>> ProviderConfig)
>>>
>>> at sun.security.jca.ProviderList.
>>> getProvider(ProviderList.java:233)
>>>
>>> at sun.security.jca.ProviderList.
>>> getService(ProviderList.java:331)
>>>
>>> at sun.security.jca.GetInstance.
>>> getInstance(GetInstance.java:157)
>>>
>>> at javax.net.ssl.SSLContext.getIn
>>> stance(SSLContext.java:156)
>>>
>>> at com.microsoft.sqlserver.jdbc.
>>> TDSChannel.enableSSL(IOBuffer.java:1658)
>>>
>>> at com.microsoft.sqlserver.jdbc.SQLServerConnection.
>>> connectHelper(SQLServerConnection.java:1976)
>>>
>>> at com.microsoft.sqlserver.jdbc.S
>>> QLServerConnection.login(
>>> SQLServerConnection.java:1627)
>>>
>>> at com.microsoft.sqlserver.jdbc.SQLServerConnection.
>>> connectInternal(SQLServerConnection.java:1458)
>>>
>>> at com.microsoft.sqlserver.jdbc.S
>>> QLServerConnection.connect(
>>> SQLServerConnection.java:772)
>>>
>>> at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(
>>> SQLServerDriver.java:1168)
>>>
>>> at java.sql.DriverManager.getConnection(DriverManager.
>>> java:664)
>>>
>>> at java.sql.DriverManager.getConnection(DriverManager.
>>> java:208)
>>>
>>> at .ConnectionPool.createGoodConnection(
>>> ConnectionPool.java:565)
>>>
>>> at .ConnectionPool.createNewConnection(
>>> ConnectionPool.java:519)
>>>
>>> at .ConnectionPool.
>>> getConnection(ConnectionPool.java:407)
>>>
>>> at .StatementCachingConnectionImpl
>>> .setupConnection(StatementCachingConnectionImpl.java:94)
>>>
>>> at .StatementCachingConnectionImpl.(
>>> StatementCachingConnectionImpl.java:54)
>>>
>>> at .TestConnectionFactories$
>>> FaultInjectingConnection.(TestConnectionFactories.java:90)
>>>
>>> at .TestConnectionF
>>> actories.lambda$static$3(
>>> TestConnectionFactories.java:33)
>>>
>>> at .TestConnectionFactories$$
>>> Lambda$12/1738236591.newConnection(Unknown Source)
>>>
>>> at .SedaExecutor.
>>> setupConnections(SedaExecutor.java:130)
>>>
>>> at .SedaExecutor$SedaThreadFactory.lambda$
>>> newThread$0(SedaExecutor.java:165)
>>>
>>> at
>>> .SedaExecutor$SedaThreadFactory$$Lambda$22/139
>>> 2419022.run(Unknown
>>> Source)
>>>
>>> at java.lang.Thread.run(Thread.java:748)
>>>
>>>
>>> The application intermittently hangs on startup, and the above callstacks
>>> are present. It seems like there's a deadlock due to concurrent class
>>> loading and default FileSystem initialization (which itself triggers class
>>> loading here).
>>>
>>> I wasn't able to find any existing JBS entries reporting anything similar.
>>> Am I seeing this right? Is this a known issue?
>>>
>>> Thanks
>>>
>>
>>
From brian.burkhalter at oracle.com Thu Jan 4 01:48:43 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 3 Jan 2018 17:48:43 -0800
Subject: RFR 8193842: Refactor InputStream-to-OutputStream copy into a
utility method
In-Reply-To: <9f81b074-5a62-2869-ad24-256eff0c0837@oracle.com>
References: <448C891C-06DA-41E9-87DC-6B0A8AB0A781@oracle.com>
<232750C7-7D37-4F36-A842-AE4D38273C91@oracle.com>
<9f81b074-5a62-2869-ad24-256eff0c0837@oracle.com>
Message-ID: <8A10FB3C-A0FD-427E-BFDD-0315EE4D8A8A@oracle.com>
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 these two should use transferTo.
I don?t think that transferTo() can be used in JrtPath right now as BUILD_JRTFS sets the compiler option ??release 8? and transferTo() was added in 9. So unless this can be changed to 9, then JrtPath would need either to remain unchanged or use IOSupport.copy().
Brian
From vitalyd at gmail.com Thu Jan 4 02:26:18 2018
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 04 Jan 2018 02:26:18 +0000
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
In-Reply-To:
References:
Message-ID:
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 interesting to see if you can
> duplicate
> >> it there.
> >>
> > Yes - it's 8u152 as I mentioned in the follow-up email (sorry, should've
> > mentioned that initially).
> >
> > Trying this on JDK9 is a bit tricky as the code (and its dependencies) in
> > question isn't easily runnable on 9 without quite a bit of work.
> >
> > Do you agree with the deadlock assessment though? That's what it looks
> like
> > to me but wanted to make sure I'm not missing anything.
>
> You're not missing anything. It's a class initialization related
> "deadlock".
>
> Thread A has called FileSystems.getDefault() which is doing of
> DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrary0
> which needs to lock the Runtime instance.
>
> Thread B is already doing a loadLibrary and holds the Runtime lock, the
> loadLibrary code then needs to do FileSystems.getDefault() which has to
> load and initialize DefaultFileSystemHolder, but that initialization is
> already in progress so internally the thread does a wait().
>
> So Thread B is waiting for Thread A to finish initialization, but holds
> the monitor lock that Thread A needs to finish the initialization.
> Deadlock.
>
> AFAICS this will still be possible in 9/10/11
That?s what I thought - thanks for confirming David. I?m slightly
surprised this hasn?t been reported before, although perhaps I?ve failed in
finding the report.
Does this deserve a bug report? I know Hotspot and some core classes in the
JDK do an elaborate dance to avoid classloading issues, but this is ?user?
code. This has been worked around on our end by forcing the default FS to
load before this code runs. Perhaps something similar can be done as the
JDK bootstraps.
>
>
> Cheers,
> David
>
> > Thanks Alan
> >
> >>
> >> -Alan
> >>
> >>
> >> On 03/01/2018 16:56, 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=0x0000000001bfd000 nid=0x1958 waiting
> for
> >>> monitor entry [0x00002b98ceba3000]
> >>>
> >>> java.lang.Thread.State: BLOCKED (on object monitor)
> >>>
> >>> at java.lang.Runtime.loadLibrary0(Runtime.java:862)
> >>>
> >>> - waiting to lock <0x00000007bf834b20> (a
> >>> java.lang.Runtime)
> >>>
> >>> at java.lang.System.loadLibrary(System.java:1122)
> >>>
> >>> at sun.nio.fs.UnixNativeDispatcher$1.run(
> >>> UnixNativeDispatcher.java:573)
> >>>
> >>> at sun.nio.fs.UnixNativeDispatcher$1.run(
> >>> UnixNativeDispatcher.java:571)
> >>>
> >>> at java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>> at sun.nio.fs.UnixNativeDispatcher.(
> >>> UnixNativeDispatcher.java:571)
> >>>
> >>> at sun.nio.fs.UnixFileSystem. >>> t>(UnixFileSystem.java:67)
> >>>
> >>> at sun.nio.fs.LinuxFileSystem.<
> >>> init>(LinuxFileSystem.java:39)
> >>>
> >>> at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
> >>> LinuxFileSystemProvider.java:46)
> >>>
> >>> at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
> >>> LinuxFileSystemProvider.java:39)
> >>>
> >>> at sun.nio.fs.UnixFileSystemProvider.(
> >>> UnixFileSystemProvider.java:56)
> >>>
> >>> at sun.nio.fs.LinuxFileSystemProvider.
> >>> (LinuxFileSystemProvider.java:41)
> >>>
> >>> at
> >>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> >>> Method)
> >>>
> >>> at sun.reflect.NativeConstructorA
> >>> ccessorImpl.newInstance(
> >>> NativeConstructorAccessorImpl.java:62)
> >>>
> >>> at sun.reflect.DelegatingConstructorAccessorI
> >>> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >>>
> >>> at java.lang.reflect.Constructor.
> >>> newInstance(Constructor.java:423)
> >>>
> >>> at java.lang.Class.newInstance(Class.java:442)
> >>>
> >>> at
> sun.nio.fs.DefaultFileSystemProvider.createProvider(
> >>> DefaultFileSystemProvider.java:48)
> >>>
> >>> at sun.nio.fs.DefaultFileSystemProvider.create(
> >>> DefaultFileSystemProvider.java:63)
> >>>
> >>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
> >>> getDefaultProvider(FileSystems.java:108)
> >>>
> >>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
> >>> access$000(FileSystems.java:89)
> >>>
> >>> at java.nio.file.FileSystems$Defa
> >>> ultFileSystemHolder$1.run(
> >>> FileSystems.java:98)
> >>>
> >>> at java.nio.file.FileSystems$Defa
> >>> ultFileSystemHolder$1.run(
> >>> FileSystems.java:96)
> >>>
> >>> at java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>> at java.nio.file.FileSystems$DefaultFileSystemHolder.
> >>> defaultFileSystem(FileSystems.java:96)
> >>>
> >>> at
> java.nio.file.FileSystems$DefaultFileSystemHolder.<
> >>> clinit>(FileSystems.java:90)
> >>>
> >>> at java.nio.file.FileSystems.getD
> >>> efault(FileSystems.java:
> >>> 176)
> >>>
> >>> at java.nio.file.Paths.get(Paths.java:84)
> >>>
> >>> at .ServiceLoader.
> >>> setup(ServiceLoader.java:446)
> >>>
> >>> at .MetadataAdminLoader.main(
> >>> MetadataAdminLoader.java:52)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> "shardDbExecutor-0-pool-0" #33 prio=5 os_prio=0 tid=0x0000000001ebf000
> >>> nid=0x1d01 in Object.wait() [0x00002b991f941000]
> >>>
> >>> java.lang.Thread.State: RUNNABLE
> >>>
> >>> at java.nio.file.FileSystems.getD
> >>> efault(FileSystems.java:
> >>> 176)
> >>>
> >>> at java.nio.file.Paths.get(Paths.java:138)
> >>>
> >>> at sun.misc.Launcher$ExtClassLoader.findLibrary(
> >>> Launcher.java:224)
> >>>
> >>> at java.lang.ClassLoader.loadLibr
> >>> ary(ClassLoader.java:1830)
> >>>
> >>> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> >>>
> >>> - locked <0x00000007bf834b20> (a java.lang.Runtime)
> >>>
> >>> at java.lang.System.loadLibrary(System.java:1122)
> >>>
> >>> at sun.security.ec.SunEC$1.run(SunEC.java:60)
> >>>
> >>> at sun.security.ec.SunEC$1.run(SunEC.java:58)
> >>>
> >>> at java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>> at sun.security.ec.SunEC.(SunEC.java:58)
> >>>
> >>> at
> >>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> >>> Method)
> >>>
> >>> at sun.reflect.NativeConstructorA
> >>> ccessorImpl.newInstance(
> >>> NativeConstructorAccessorImpl.java:62)
> >>>
> >>> at sun.reflect.DelegatingConstructorAccessorI
> >>> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >>>
> >>> at java.lang.reflect.Constructor.
> >>> newInstance(Constructor.java:423)
> >>>
> >>> at java.lang.Class.newInstance(Class.java:442)
> >>>
> >>> at sun.security.jca.ProviderConfig$2.run(
> >>> ProviderConfig.java:221)
> >>>
> >>> at sun.security.jca.ProviderConfig$2.run(
> >>>
> >>> ProviderConfig.java:206)
> >>>
> >>> at java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>> at sun.security.jca.ProviderConfig.doLoadProvider(
> >>> ProviderConfig.java:206)
> >>>
> >>> at sun.security.jca.ProviderConfig.getProvider(
> >>> ProviderConfig.java:187)
> >>>
> >>> - locked <0x00000007bea03f48> (a sun.security.jca.
> >>> ProviderConfig)
> >>>
> >>> at sun.security.jca.ProviderList.
> >>> getProvider(ProviderList.java:233)
> >>>
> >>> at sun.security.jca.ProviderList.
> >>> getService(ProviderList.java:331)
> >>>
> >>> at sun.security.jca.GetInstance.
> >>> getInstance(GetInstance.java:157)
> >>>
> >>> at javax.net.ssl.SSLContext.getIn
> >>> stance(SSLContext.java:156)
> >>>
> >>> at com.microsoft.sqlserver.jdbc.
> >>> TDSChannel.enableSSL(IOBuffer.java:1658)
> >>>
> >>> at com.microsoft.sqlserver.jdbc.SQLServerConnection.
> >>> connectHelper(SQLServerConnection.java:1976)
> >>>
> >>> at com.microsoft.sqlserver.jdbc.S
> >>> QLServerConnection.login(
> >>> SQLServerConnection.java:1627)
> >>>
> >>> at com.microsoft.sqlserver.jdbc.SQLServerConnection.
> >>> connectInternal(SQLServerConnection.java:1458)
> >>>
> >>> at com.microsoft.sqlserver.jdbc.S
> >>> QLServerConnection.connect(
> >>> SQLServerConnection.java:772)
> >>>
> >>> at
> com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(
> >>> SQLServerDriver.java:1168)
> >>>
> >>> at
> java.sql.DriverManager.getConnection(DriverManager.
> >>> java:664)
> >>>
> >>> at
> java.sql.DriverManager.getConnection(DriverManager.
> >>> java:208)
> >>>
> >>> at
> .ConnectionPool.createGoodConnection(
> >>> ConnectionPool.java:565)
> >>>
> >>> at .ConnectionPool.createNewConnection(
> >>> ConnectionPool.java:519)
> >>>
> >>> at .ConnectionPool.
> >>> getConnection(ConnectionPool.java:407)
> >>>
> >>> at .StatementCachingConnectionImpl
> >>> .setupConnection(StatementCachingConnectionImpl.java:94)
> >>>
> >>> at
> .StatementCachingConnectionImpl.(
> >>> StatementCachingConnectionImpl.java:54)
> >>>
> >>> at .TestConnectionFactories$
> >>> FaultInjectingConnection.(TestConnectionFactories.java:90)
> >>>
> >>> at .TestConnectionF
> >>> actories.lambda$static$3(
> >>> TestConnectionFactories.java:33)
> >>>
> >>> at .TestConnectionFactories$$
> >>> Lambda$12/1738236591.newConnection(Unknown Source)
> >>>
> >>> at .SedaExecutor.
> >>> setupConnections(SedaExecutor.java:130)
> >>>
> >>> at
> .SedaExecutor$SedaThreadFactory.lambda$
> >>> newThread$0(SedaExecutor.java:165)
> >>>
> >>> at
> >>> .SedaExecutor$SedaThreadFactory$$Lambda$22/139
> >>> 2419022.run(Unknown
> >>> Source)
> >>>
> >>> at java.lang.Thread.run(Thread.java:748)
> >>>
> >>>
> >>> The application intermittently hangs on startup, and the above
> callstacks
> >>> are present. It seems like there's a deadlock due to concurrent class
> >>> loading and default FileSystem initialization (which itself triggers
> class
> >>> loading here).
> >>>
> >>> I wasn't able to find any existing JBS entries reporting anything
> similar.
> >>> Am I seeing this right? Is this a known issue?
> >>>
> >>> Thanks
> >>>
> >>
> >>
>
--
Sent from my phone
From david.holmes at oracle.com Thu Jan 4 03:30:15 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Jan 2018 13:30:15 +1000
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
In-Reply-To:
References:
Message-ID: <8b8aff4d-bb8a-f30b-7ff3-d0b8b83da59e@oracle.com>
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
> >
> > 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
> > mentioned that initially).
> >
> > Trying this on JDK9 is a bit tricky as the code (and its
> dependencies) in
> > question isn't easily runnable on 9 without quite a bit of work.
> >
> > Do you agree with the deadlock assessment though? That's what it
> looks like
> > to me but wanted to make sure I'm not missing anything.
>
> You're not missing anything. It's a class initialization related
> "deadlock".
>
> Thread A has called FileSystems.getDefault() which is doing of
> DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrary0
> which needs to lock the Runtime instance.
>
> Thread B is already doing a loadLibrary and holds the Runtime lock, the
> loadLibrary code then needs to do FileSystems.getDefault() which has to
> load and initialize DefaultFileSystemHolder, but that initialization is
> already in progress so internally the thread does a wait().
>
> So Thread B is waiting for Thread A to finish initialization, but holds
> the monitor lock that Thread A needs to finish the initialization.
> Deadlock.
>
> AFAICS this will still be possible in 9/10/11
>
>
> That?s what I thought - thanks for confirming David.? I?m slightly
> surprised this hasn?t been reported before, although perhaps I?ve failed
> in finding the report.
I couldn't find anything either. Although it seems "obvious" upon
analysis it may be very rare to have such an initialization race.
>
> Does this deserve a bug report? I know Hotspot and some core classes in
> the JDK do an elaborate dance to avoid classloading issues, but this is
> ?user? code.? This has been worked around on our end by forcing the
> default FS to load before this code runs.? Perhaps something similar can
> be done as the JDK bootstraps.
Definitely worth a bug report. Not sure what we can do on the JDK side
as I'm unclear whether the default filesystem necessarily gets
initialized after the module system is up.
Cheers,
David
>
>
> Cheers,
> David
>
> > Thanks Alan
> >
> >>
> >> -Alan
> >>
> >>
> >> On 03/01/2018 16:56, 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=0x0000000001bfd000 nid=0x1958
> waiting for
> >>> monitor entry [0x00002b98ceba3000]
> >>>
> >>>? ? ? java.lang.Thread.State: BLOCKED (on object monitor)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.lang.Runtime.loadLibrary0(Runtime.java:862)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?- waiting to lock <0x00000007bf834b20> (a
> >>> java.lang.Runtime)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.lang.System.loadLibrary(System.java:1122)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.nio.fs.UnixNativeDispatcher$1.run(
> >>> UnixNativeDispatcher.java:573)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.nio.fs.UnixNativeDispatcher$1.run(
> >>> UnixNativeDispatcher.java:571)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.nio.fs.UnixNativeDispatcher.(
> >>> UnixNativeDispatcher.java:571)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.nio.fs.UnixFileSystem. >>> t>(UnixFileSystem.java:67)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.nio.fs.LinuxFileSystem.<
> >>> init>(LinuxFileSystem.java:39)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
> >>> LinuxFileSystemProvider.java:46)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
> >>> LinuxFileSystemProvider.java:39)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.nio.fs.UnixFileSystemProvider.(
> >>> UnixFileSystemProvider.java:56)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.nio.fs.LinuxFileSystemProvider.
> >>> (LinuxFileSystemProvider.java:41)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> >>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> >>> Method)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.reflect.NativeConstructorA
> >>> ccessorImpl.newInstance(
> >>> NativeConstructorAccessorImpl.java:62)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.reflect.DelegatingConstructorAccessorI
> >>> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.lang.reflect.Constructor.
> >>> newInstance(Constructor.java:423)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.lang.Class.newInstance(Class.java:442)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> sun.nio.fs.DefaultFileSystemProvider.createProvider(
> >>> DefaultFileSystemProvider.java:48)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.nio.fs.DefaultFileSystemProvider.create(
> >>> DefaultFileSystemProvider.java:63)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.nio.file.FileSystems$DefaultFileSystemHolder.
> >>> getDefaultProvider(FileSystems.java:108)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.nio.file.FileSystems$DefaultFileSystemHolder.
> >>> access$000(FileSystems.java:89)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.nio.file.FileSystems$Defa
> >>> ultFileSystemHolder$1.run(
> >>> FileSystems.java:98)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.nio.file.FileSystems$Defa
> >>> ultFileSystemHolder$1.run(
> >>> FileSystems.java:96)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.nio.file.FileSystems$DefaultFileSystemHolder.
> >>> defaultFileSystem(FileSystems.java:96)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.nio.file.FileSystems$DefaultFileSystemHolder.<
> >>> clinit>(FileSystems.java:90)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.nio.file.FileSystems.getD
> >>> efault(FileSystems.java:
> >>> 176)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.nio.file.Paths.get(Paths.java:84)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at .ServiceLoader.
> >>> setup(ServiceLoader.java:446)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at .MetadataAdminLoader.main(
> >>> MetadataAdminLoader.java:52)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> "shardDbExecutor-0-pool-0" #33 prio=5 os_prio=0
> tid=0x0000000001ebf000
> >>> nid=0x1d01 in Object.wait() [0x00002b991f941000]
> >>>
> >>>? ? ? java.lang.Thread.State: RUNNABLE
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.nio.file.FileSystems.getD
> >>> efault(FileSystems.java:
> >>> 176)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.nio.file.Paths.get(Paths.java:138)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.misc.Launcher$ExtClassLoader.findLibrary(
> >>> Launcher.java:224)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.lang.ClassLoader.loadLibr
> >>> ary(ClassLoader.java:1830)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.lang.Runtime.loadLibrary0(Runtime.java:870)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?- locked <0x00000007bf834b20> (a
> java.lang.Runtime)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.lang.System.loadLibrary(System.java:1122)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.ec.SunEC$1.run(SunEC.java:60)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.ec.SunEC$1.run(SunEC.java:58)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.ec.SunEC.(SunEC.java:58)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> >>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> >>> Method)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.reflect.NativeConstructorA
> >>> ccessorImpl.newInstance(
> >>> NativeConstructorAccessorImpl.java:62)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.reflect.DelegatingConstructorAccessorI
> >>> mpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.lang.reflect.Constructor.
> >>> newInstance(Constructor.java:423)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.lang.Class.newInstance(Class.java:442)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.jca.ProviderConfig$2.run(
> >>> ProviderConfig.java:221)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.jca.ProviderConfig$2.run(
> >>>
> >>> ProviderConfig.java:206)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> sun.security.jca.ProviderConfig.doLoadProvider(
> >>> ProviderConfig.java:206)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.jca.ProviderConfig.getProvider(
> >>> ProviderConfig.java:187)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?- locked <0x00000007bea03f48> (a
> sun.security.jca.
> >>> ProviderConfig)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.jca.ProviderList.
> >>> getProvider(ProviderList.java:233)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.jca.ProviderList.
> >>> getService(ProviderList.java:331)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at sun.security.jca.GetInstance.
> >>> getInstance(GetInstance.java:157)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at javax.net.ssl.SSLContext.getIn
> >>> stance(SSLContext.java:156)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at com.microsoft.sqlserver.jdbc.
> >>> TDSChannel.enableSSL(IOBuffer.java:1658)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> com.microsoft.sqlserver.jdbc.SQLServerConnection.
> >>> connectHelper(SQLServerConnection.java:1976)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at com.microsoft.sqlserver.jdbc.S
> >>> QLServerConnection.login(
> >>> SQLServerConnection.java:1627)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> com.microsoft.sqlserver.jdbc.SQLServerConnection.
> >>> connectInternal(SQLServerConnection.java:1458)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at com.microsoft.sqlserver.jdbc.S
> >>> QLServerConnection.connect(
> >>> SQLServerConnection.java:772)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(
> >>> SQLServerDriver.java:1168)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.sql.DriverManager.getConnection(DriverManager.
> >>> java:664)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> java.sql.DriverManager.getConnection(DriverManager.
> >>> java:208)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> .ConnectionPool.createGoodConnection(
> >>> ConnectionPool.java:565)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> .ConnectionPool.createNewConnection(
> >>> ConnectionPool.java:519)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at .ConnectionPool.
> >>> getConnection(ConnectionPool.java:407)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at .StatementCachingConnectionImpl
> >>> .setupConnection(StatementCachingConnectionImpl.java:94)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> .StatementCachingConnectionImpl.(
> >>> StatementCachingConnectionImpl.java:54)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at .TestConnectionFactories$
> >>> FaultInjectingConnection.(TestConnectionFactories.java:90)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at .TestConnectionF
> >>> actories.lambda$static$3(
> >>> TestConnectionFactories.java:33)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at .TestConnectionFactories$$
> >>> Lambda$12/1738236591.newConnection(Unknown Source)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at .SedaExecutor.
> >>> setupConnections(SedaExecutor.java:130)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> .SedaExecutor$SedaThreadFactory.lambda$
> >>> newThread$0(SedaExecutor.java:165)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at
> >>> .SedaExecutor$SedaThreadFactory$$Lambda$22/139
> >>> 2419022.run(Unknown
> >>> Source)
> >>>
> >>>? ? ? ? ? ? ? ? ? ?at java.lang.Thread.run(Thread.java:748)
> >>>
> >>>
> >>> The application intermittently hangs on startup, and the above
> callstacks
> >>> are present.? It seems like there's a deadlock due to
> concurrent class
> >>> loading and default FileSystem initialization (which itself
> triggers class
> >>> loading here).
> >>>
> >>> I wasn't able to find any existing JBS entries reporting
> anything similar.
> >>> Am I seeing this right? Is this a known issue?
> >>>
> >>> Thanks
> >>>
> >>
> >>
>
> --
> Sent from my phone
From Alan.Bateman at oracle.com Thu Jan 4 08:03:08 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 4 Jan 2018 08:03:08 +0000
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
In-Reply-To:
References:
Message-ID: <356f9d2a-2682-ae17-6425-6b55d8cf5a36@oracle.com>
On 04/01/2018 01:35, David Holmes wrote:
>
> You're not missing anything. It's a class initialization related
> "deadlock".
>
> Thread A has called FileSystems.getDefault() which is doing
> of DefaultFileSystemHolder, which in turn leads to
> Runtime.loadLibrary0 which needs to lock the Runtime instance.
>
> Thread B is already doing a loadLibrary and holds the Runtime lock,
> the loadLibrary code then needs to do FileSystems.getDefault() which
> has to load and initialize DefaultFileSystemHolder, but that
> initialization is already in progress so internally the thread does a
> wait().
>
> So Thread B is waiting for Thread A to finish initialization, but
> holds the monitor lock that Thread A needs to finish the
> initialization. Deadlock.
>
> AFAICS this will still be possible in 9/10/11
Startup and initialization has changed quite a bit since JDK 8. In JDK 9
the file system is initialized early (long before main). However, it
changes again in JDK 10 due to ongoing work to makes things lazy and
improve startup time. Separately, FilePermission and the JarFile support
have been re-written so it should be loaded before any user code
executes. So I think needs to be studied again, I agree with your other
mail to create a bug to track that.
-Alan
From Alan.Bateman at oracle.com Thu Jan 4 08:06:38 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 4 Jan 2018 08:06:38 +0000
Subject: RFR 8193842: Refactor InputStream-to-OutputStream copy into a
utility method
In-Reply-To: <8A10FB3C-A0FD-427E-BFDD-0315EE4D8A8A@oracle.com>
References: <448C891C-06DA-41E9-87DC-6B0A8AB0A781@oracle.com>
<232750C7-7D37-4F36-A842-AE4D38273C91@oracle.com>
<9f81b074-5a62-2869-ad24-256eff0c0837@oracle.com>
<8A10FB3C-A0FD-427E-BFDD-0315EE4D8A8A@oracle.com>
Message-ID:
On 04/01/2018 01:48, Brian Burkhalter wrote:
> 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 these two should use transferTo.
>
> I don?t think that transferTo() can be used in JrtPath right now as
> BUILD_JRTFS sets the compiler option ??release 8? and transferTo() was
> added in 9. So unless this can be changed to 9, then JrtPath would
> need either to remain unchanged or use IOSupport.copy().
>
Sorry, when I said "these two should use transferTo" then I meant the
Files.copy(Path, OutputStream) and Files.copy(InputStream, Path)
methods, not the jrtfs code. You are right that jrtfs is complicated as
it is compiled and packaged into jrtfs.jar for use by tools running on
JDK 8. You'll have to leave that as is (it can't use IOSupport.copy or
any other internal API).
-Alan
From vitalyd at gmail.com Thu Jan 4 12:05:05 2018
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 4 Jan 2018 07:05:05 -0500
Subject: Possible VM deadlock due to FileSystems.getDefault and
System.loadLibrary interplay
In-Reply-To: <356f9d2a-2682-ae17-6425-6b55d8cf5a36@oracle.com>
References:
<356f9d2a-2682-ae17-6425-6b55d8cf5a36@oracle.com>
Message-ID:
On Thu, Jan 4, 2018 at 3:03 AM, Alan Bateman
wrote:
> On 04/01/2018 01:35, David Holmes wrote:
>
>>
>> You're not missing anything. It's a class initialization related
>> "deadlock".
>>
>> Thread A has called FileSystems.getDefault() which is doing of
>> DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrary0 which
>> needs to lock the Runtime instance.
>>
>> Thread B is already doing a loadLibrary and holds the Runtime lock, the
>> loadLibrary code then needs to do FileSystems.getDefault() which has to
>> load and initialize DefaultFileSystemHolder, but that initialization is
>> already in progress so internally the thread does a wait().
>>
>> So Thread B is waiting for Thread A to finish initialization, but holds
>> the monitor lock that Thread A needs to finish the initialization. Deadlock.
>>
>> AFAICS this will still be possible in 9/10/11
>>
> Startup and initialization has changed quite a bit since JDK 8. In JDK 9
> the file system is initialized early (long before main). However, it
> changes again in JDK 10 due to ongoing work to makes things lazy and
> improve startup time. Separately, FilePermission and the JarFile support
> have been re-written so it should be loaded before any user code executes.
> So I think needs to be studied again, I agree with your other mail to
> create a bug to track that.
Alan, David - thanks for your comments.
Alan - I'm assuming someone from Oracle will file a bug report for this?
>
>
> -Alan
>
From brian.burkhalter at oracle.com Thu Jan 4 17:18:47 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 4 Jan 2018 09:18:47 -0800
Subject: RFR 8193842: Refactor InputStream-to-OutputStream copy into a
utility method
In-Reply-To:
References: <448C891C-06DA-41E9-87DC-6B0A8AB0A781@oracle.com>
<232750C7-7D37-4F36-A842-AE4D38273C91@oracle.com>
<9f81b074-5a62-2869-ad24-256eff0c0837@oracle.com>
<8A10FB3C-A0FD-427E-BFDD-0315EE4D8A8A@oracle.com>
Message-ID:
On Jan 4, 2018, at 12:06 AM, Alan Bateman 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.
>>
>> I don?t think that transferTo() can be used in JrtPath right now as BUILD_JRTFS sets the compiler option ??release 8? and transferTo() was added in 9. So unless this can be changed to 9, then JrtPath would need either to remain unchanged or use IOSupport.copy().
>>
> Sorry, when I said "these two should use transferTo" then I meant the Files.copy(Path, OutputStream) and Files.copy(InputStream, Path) methods, not the jrtfs code. You are right that jrtfs is complicated as it is compiled and packaged into jrtfs.jar for use by tools running on JDK 8. You'll have to leave that as is (it can't use IOSupport.copy or any other internal API).
Patch updated per this e-mail thread:
http://cr.openjdk.java.net/~bpb/8194133/webrev.01/
Thanks,
Brian
From brian.burkhalter at oracle.com Thu Jan 4 18:14:33 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 4 Jan 2018 10:14:33 -0800
Subject: RFR 8194649: Minor cleanup of parameter checking in
ByteArrayOutputStream and ObjectInputStream
Message-ID: <8EF32576-288E-49A8-81E1-341CB4C649F7@oracle.com>
https://bugs.openjdk.java.net/browse/JDK-8194649
Please see the proposed change included below. In the OIS case the requireNonNull() call is not needed as a NPE would be thrown at the next line anyway if arrayType were null.
Thanks,
Brian
--- a/src/java.base/share/classes/java/io/ByteArrayOutputStream.java
+++ b/src/java.base/share/classes/java/io/ByteArrayOutputStream.java
@@ -27,6 +27,7 @@
import java.nio.charset.Charset;
import java.util.Arrays;
+import java.util.Objects;
/**
* This class implements an output stream in which the data is
@@ -147,10 +148,7 @@
* @param len the number of bytes to write.
*/
public synchronized void write(byte b[], int off, int len) {
- if ((off < 0) || (off > b.length) || (len < 0) ||
- ((off + len) - b.length > 0)) {
- throw new IndexOutOfBoundsException();
- }
+ Objects.checkFromIndexSize(off, len, b.length);
ensureCapacity(count + len);
System.arraycopy(b, off, buf, count, len);
count += len;
--- a/src/java.base/share/classes/java/io/ObjectInputStream.java
+++ b/src/java.base/share/classes/java/io/ObjectInputStream.java
@@ -1296,7 +1296,6 @@
* @throws InvalidClassException if the filter rejects creation
*/
private void checkArray(Class> arrayType, int arrayLength) throws InvalidClassException {
- Objects.requireNonNull(arrayType);
if (! arrayType.isArray()) {
throw new IllegalArgumentException("not an array type");
}
From roger.riggs at oracle.com Thu Jan 4 18:20:37 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 4 Jan 2018 13:20:37 -0500
Subject: RFR 8194649: Minor cleanup of parameter checking in
ByteArrayOutputStream and ObjectInputStream
In-Reply-To: <8EF32576-288E-49A8-81E1-341CB4C649F7@oracle.com>
References: <8EF32576-288E-49A8-81E1-341CB4C649F7@oracle.com>
Message-ID: <5e996ff6-d44d-9fb0-aa81-fb82730407da@oracle.com>
+1,
(There has been some variation in opinion about use of requireNonNull
even where the VM would check a reference for null; but it does seem
redundant on the face of it, even if hotspot would optimize it)
On 1/4/18 1:14 PM, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8194649
>
> Please see the proposed change included below. In the OIS case the requireNonNull() call is not needed as a NPE would be thrown at the next line anyway if arrayType were null.
>
> Thanks,
>
> Brian
>
> --- a/src/java.base/share/classes/java/io/ByteArrayOutputStream.java
> +++ b/src/java.base/share/classes/java/io/ByteArrayOutputStream.java
> @@ -27,6 +27,7 @@
>
> import java.nio.charset.Charset;
> import java.util.Arrays;
> +import java.util.Objects;
>
> /**
> * This class implements an output stream in which the data is
> @@ -147,10 +148,7 @@
> * @param len the number of bytes to write.
> */
> public synchronized void write(byte b[], int off, int len) {
> - if ((off < 0) || (off > b.length) || (len < 0) ||
> - ((off + len) - b.length > 0)) {
> - throw new IndexOutOfBoundsException();
> - }
> + Objects.checkFromIndexSize(off, len, b.length);
> ensureCapacity(count + len);
> System.arraycopy(b, off, buf, count, len);
> count += len;
>
> --- a/src/java.base/share/classes/java/io/ObjectInputStream.java
> +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java
> @@ -1296,7 +1296,6 @@
> * @throws InvalidClassException if the filter rejects creation
> */
> private void checkArray(Class> arrayType, int arrayLength) throws InvalidClassException {
> - Objects.requireNonNull(arrayType);
> if (! arrayType.isArray()) {
> throw new IllegalArgumentException("not an array type");
> }
From brian.burkhalter at oracle.com Thu Jan 4 21:05:29 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 4 Jan 2018 13:05:29 -0800
Subject: RFR 8193861: Typo in API documentation of File.toPath()
Message-ID: <55253F55-6C85-4070-8B05-C5C24121BCD2@oracle.com>
https://bugs.openjdk.java.net/browse/JDK-8193861
http://cr.openjdk.java.net/~bpb/8193861/webrev.00/
Thanks,
Brian
From roger.riggs at oracle.com Thu Jan 4 21:25:21 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 4 Jan 2018 16:25:21 -0500
Subject: RFR 8193861: Typo in API documentation of File.toPath()
In-Reply-To: <55253F55-6C85-4070-8B05-C5C24121BCD2@oracle.com>
References: <55253F55-6C85-4070-8B05-C5C24121BCD2@oracle.com>
Message-ID:
+1
On 1/4/18 4:05 PM, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8193861
> http://cr.openjdk.java.net/~bpb/8193861/webrev.00/
>
> Thanks,
>
> Brian
From brian.burkhalter at oracle.com Thu Jan 4 21:29:12 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 4 Jan 2018 13:29:12 -0800
Subject: Fix typo in InetSocketAddress.getAddress() documentation
In-Reply-To:
References: <001501d38571$b87943f0$296bcbd0$@freenet.de>
Message-ID:
Hi Chris,
Sure, no problem: http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html
Brian
On Jan 4, 2018, at 1:13 PM, Chris Hegarty wrote:
> Would you mind adding the below typo to another you are fixing under JDK-8193861 ( to reduce the overhead ).
From brian.burkhalter at oracle.com Thu Jan 4 21:39:00 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 4 Jan 2018 13:39:00 -0800
Subject: RFR 8193861: Typo in API documentation of File.toPath()
In-Reply-To: <55253F55-6C85-4070-8B05-C5C24121BCD2@oracle.com>
References: <55253F55-6C85-4070-8B05-C5C24121BCD2@oracle.com>
Message-ID:
Updated to include a fix for a typo in InetSocketAddress.getAddress() [1]:
http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html
Thanks,
Brian
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050814.html
On Jan 4, 2018, at 1:05 PM, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8193861
> http://cr.openjdk.java.net/~bpb/8193861/webrev.00/
>
> Thanks,
>
> Brian
From lance.andersen at oracle.com Thu Jan 4 21:41:43 2018
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 4 Jan 2018 16:41:43 -0500
Subject: RFR 8193861: Typo in API documentation of File.toPath()
In-Reply-To:
References: <55253F55-6C85-4070-8B05-C5C24121BCD2@oracle.com>
Message-ID: <8A22C281-55A0-415A-BEAF-D068EF346825@oracle.com>
+1
> On Jan 4, 2018, at 4:39 PM, Brian Burkhalter wrote:
>
> Updated to include a fix for a typo in InetSocketAddress.getAddress() [1]:
>
> http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html
>
> Thanks,
>
> Brian
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050814.html
>
> On Jan 4, 2018, at 1:05 PM, Brian Burkhalter wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8193861
>> http://cr.openjdk.java.net/~bpb/8193861/webrev.00/
>>
>> Thanks,
>>
>> Brian
>