Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

Hi Peter, > ...so the only way for this to not cause the same problem is for > Class.reflectionFactory field to be initialized before SecurityManager > is set. > > Was this pure luck and we were just waiting for a situation where this > was not the case? I don't know. If you run with -Xlog:class

Re: jdk.internal.reflect.ReflectionFactory and SecurityManager

Hi David, On 12/26/2016 10:16 PM, David Holmes wrote: Hi Peter, I know this is response to the problems with your other recent change, but this is an enhancement in my opinion, not a bug fix, and the time for enhancements is passed - though there is still a process to request them. I do not

Re: MethodHandle initialization process - problem with JVM TI early VM start event

Looking further into this the crash occurs because java.lang.Class has not been initialized yet. Logging shows we go straight from initializing Object to initializing java.net.Authenticator then to java.lang.invoke.MethodHandleNatives. [3.484s][debug][vtables ] Initializing: java/lang/invoke/M

Re: Review Request: JDK-8172215 java launcher no longer accepts -cp "" empty string

On 4/01/2017 12:03 PM, Mandy Chung wrote: On Jan 3, 2017, at 5:23 PM, Paul Sandoz wrote: On 3 Jan 2017, at 15:59, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/ This fixes the regression caused by JDK-8168836 such that java -cp “” would be accepted

MethodHandle initialization process - problem with JVM TI early VM start event

We have encountered a crash in a JVM TI test, starting with b148, that is caused by the attempted use of MethodRefs and invoke_dynamic within class loading that occurs from the "early VM start" JVM TI event callback - which happens before the VM and core classes are fully initialized. The class

Re: RFR of JDK-8030175: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due to timeout

Is some one available to review the patch? Thank you -Hamlin On 2016/12/26 16:51, Hamlin Li wrote: Would you please review the below patches? bug: https://bugs.openjdk.java.net/browse/JDK-8030175 webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/ webrev (version B): http:/

Re: Review Request: JDK-8172215 java launcher no longer accepts -cp "" empty string

> On Jan 3, 2017, at 5:23 PM, Paul Sandoz wrote: > > >> On 3 Jan 2017, at 15:59, Mandy Chung wrote: >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/ >> >> This fixes the regression caused by JDK-8168836 such that java -cp “” would >> be accepted. It’s surprise that n

Re: JDK 9 RFR of JDK-8172200: Mark StressLoopback.java as intermittently failing

Hi Joe, Looks fine. Brian On Jan 3, 2017, at 4:27 PM, joe darcy wrote: > java/nio/channels/AsynchronousSocketChannel/StressLoopback.java > > intermittently fails on Solaris x64 on one of our testing systems. The test > should be marked accordingly. Please review the patch below which does th

Re: RFR 8172201 Replace assert of return type in VarHandle.AccessMode with test

> On Jan 3, 2017, at 5:12 PM, Paul Sandoz wrote: > > Hi, > > Please review the following which removes an assert statement from the > constructor of VarHandle.AccessMode and replaces it with a test: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8172201-vh-accessmode-return-type-assert/

Re: Review Request: JDK-8172215 java launcher no longer accepts -cp "" empty string

> On 3 Jan 2017, at 15:59, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/ > > This fixes the regression caused by JDK-8168836 such that java -cp “” would > be accepted. It’s surprise that no launcher test covering such test case. > Now it’s added in

RFR 8172201 Replace assert of return type in VarHandle.AccessMode with test

Hi, Please review the following which removes an assert statement from the constructor of VarHandle.AccessMode and replaces it with a test: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8172201-vh-accessmode-return-type-assert/webrev/jdk.patch

Re: JDK 9 RFR of JDK-8172200: Mark StressLoopback.java as intermittently failing

+1 > On Jan 3, 2017, at 7:27 PM, joe darcy wrote: > > Hello, > > The test > > java/nio/channels/AsynchronousSocketChannel/StressLoopback.java > > intermittently fails on Solaris x64 on one of our testing systems. The test > should be marked accordingly. Please review the patch below which doe

JDK 9 RFR of JDK-8172200: Mark StressLoopback.java as intermittently failing

Hello, The test java/nio/channels/AsynchronousSocketChannel/StressLoopback.java intermittently fails on Solaris x64 on one of our testing systems. The test should be marked accordingly. Please review the patch below which does this. Thanks, -Joe diff -r d27bab22ff62 test/java/nio/channel

Review Request: JDK-8172215 java launcher no longer accepts -cp "" empty string

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/ This fixes the regression caused by JDK-8168836 such that java -cp “” would be accepted. It’s surprise that no launcher test covering such test case. Now it’s added in JavaClassPathTest. This patch also renames the testlibrary

Re: Review Request: jdeps --require and --check should detect the specified module in the image

> On 3 Jan 2017, at 14:55, Mandy Chung wrote: > > >> On Jan 3, 2017, at 2:45 PM, Mandy Chung wrote: >> >> >>> >>> >>> 154 // jdeps --module-path -m root paths >>> 155 String cmd = String.format("jdeps --module-path %s >>> --add-modules %s %s%n", >>> 156 MODS_D

Re: Review Request: jdeps --require and --check should detect the specified module in the image

> On Jan 3, 2017, at 2:45 PM, Mandy Chung wrote: > > >> >> >> 154 // jdeps --module-path -m root paths >> 155 String cmd = String.format("jdeps --module-path %s --add-modules >> %s %s%n", >> 156 MODS_DIR, roots.stream().collect(Collectors.joining(",")), >> 157

Re: RFR: 8170785: Excessive allocation in ParseUtil.encodePath

Hi Roger, On 2017-01-03 22:22, Roger Riggs wrote: Hi Claes, So Windows didn't suffer from having the '\' separator. relatively speaking Windows won't see any speed-up when dealing with file system paths, but most places where we see encodePath in profiles is actually not files: jar/runtime im

Re: Review Request: jdeps --require and --check should detect the specified module in the image

Hi Mandy I saw the revised webrev.01 and it looks fine > On Jan 3, 2017, at 5:45 PM, Mandy Chung wrote: > >> >> On Jan 3, 2017, at 2:21 PM, Paul Sandoz wrote: >> >> Hi, >> >> Minor stuff: >> >> JdepsTask >> — >> >> 845 private Comparator> comparator() { >> 846 Functio

Re: Review Request: jdeps --require and --check should detect the specified module in the image

> On Jan 3, 2017, at 2:21 PM, Paul Sandoz wrote: > > Hi, > > Minor stuff: > > JdepsTask > — > > 845 private Comparator> comparator() { > 846 Function, String> name = deque -> > deque.peekFirst().getName(); > 847 ToIntFunction> length = Deque::size; > 848 > 849

Re: Review Request: jdeps --require and --check should detect the specified module in the image

Hi, Minor stuff: JdepsTask — 845 private Comparator> comparator() { 846 Function, String> name = deque -> deque.peekFirst().getName(); 847 ToIntFunction> length = Deque::size; 848 849 return Comparator.comparing(name) 850

Re: RFR: 8170785: Excessive allocation in ParseUtil.encodePath

Hi Claes, So Windows didn't suffer from having the '\' separator. ParseUtil: firstEncodeIndex:121: 'a' - 'z' seems more frequent than '/' or '.'; does it improve the stats to move that range to the beginning of the if. (yes the compiler can re-order). line 125: Since 127 is known to

Review Request: jdeps --require and --check should detect the specified module in the image

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172212/webrev.00/ This is a simple patch that fixes jdeps in analyzing modules linked in the image. It fixes the following commands which are currently not working properly. $ jdeps -I -—require jdk.compiler $ jdeps -—check jdk.compiler This patc

Re: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy

> On 2 Jan 2017, at 03:25, Claes Redestad wrote: > > > > Hi Peter, > > agreed, it appears this assert could be replaced by a test - similar to what > was already > done for VarHandle.AccessMode[1] - which might increase robustness of early > use of > VarHandles and give our core reflection

Re: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

Hi Max, Sorry for the delay. Since this not part of the specification of the behavior I'm ok with the informal descriptions. Roger On 1/2/2017 10:40 PM, Wang Weijun wrote: Ping again. On Dec 22, 2016, at 8:23 AM, Wang Weijun wrote: Hi Roger On Dec 20, 2016, at 11:49 PM, Roger Riggs w

Re: Does jvisualvm work in JDK 9?

Hi, I had a similar problem on Mac. Downloaded the latest version of VisualVM (https://visualvm.github.io/) and it did work. It seems that the version bundled with JDK 9 is out of date. Dmitry On 28/12/16 06:47, Frank Yuan wrote: Hi all I tried to run jvisualvm in Linux with both b14

Re: RFR 8172190: Re-apply the fix for bugs 8062389, 8029459, 8061950

Hi Peter, letting you know I've submitted a build and test job for this to run over night. Thanks! /Claes On 01/03/2017 05:52 PM, Peter Levart wrote: Hi, Now that initialization cycle has been broken by Claes' fix for: https://bugs.openjdk.java.net/browse/JDK-8172048 I prepared a re

RFR 8172190: Re-apply the fix for bugs 8062389, 8029459, 8061950

Hi, Now that initialization cycle has been broken by Claes' fix for: https://bugs.openjdk.java.net/browse/JDK-8172048 I prepared a revised fix for issues described in the following bugs: https://bugs.openjdk.java.net/browse/JDK-8062389 https://bugs.openjdk.java.net/browse/JDK-8029

RFR: 8170785: Excessive allocation in ParseUtil.encodePath

Hi, some users reports high allocation rates in ParseUtil.encodePath, regardless of whether paths actually need to be encoded or not. Since this is a commonly used utility it makes sense. Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK

Re: RFR: 8071566 Improve testing for multi-version JAR file maker tool

Andrey, > On 30 Dec 2016, at 14:11, Andrey Nazarov wrote: > > Hi, > > Following tests for Jar tool were added: > > Tests for API validator. Jar tool should detect API changes between releases. > Test for custom manifest file. > Test for version format in --release option > > Also refactori

RE: Does jvisualvm work in JDK 9?

Thank you for tne clarification! Frank > -Original Message- > From: Seán Coffey [mailto:sean.cof...@oracle.com] > Subject: Re: Does jvisualvm work in JDK 9? > > I don't believe jvisualvm will ship bundled with JDK 9 and is due for > removal. Probably best to download the latest visualvm

Re: Does jvisualvm work in JDK 9?

I don't believe jvisualvm will ship bundled with JDK 9 and is due for removal. Probably best to download the latest visualvm binaries from the VisualVM project website. See https://blogs.oracle.com/java-platform-group/entry/visual_vm_in_jdk_9 regards, Sean. On 29/12/2016 02:39, Frank Yuan wro