Re: --dry-run description enhancement

On 12/07/2016 4:00 PM, Paul Benedict wrote: Mandy, perhaps there is a JVM technicality here I'm unfamiliar with. My understanding of loading a class has always been that it's coupled with running its static initializers. Loading, linking (resolution) and initialization are all distinct parts o

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

On 12/07/2016 4:17 PM, Martin Buchholz wrote: Amy, sorry you have so many picky reviewers! Difference between patching a failing test and completely redesigning it from scratch. The latter was not warranted in my opinion. Here's how I might write it: import java.util.concurrent.CountDownLa

Re: --dry-run description enhancement

Hi Paul, On 7/12/16 8:00 AM, Paul Benedict wrote: Mandy, perhaps there is a JVM technicality here I'm unfamiliar with. My understanding of loading a class has always been that it's coupled with running its static initializers. So my inference was that the class does not get loaded into memory be

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Hi Amy, On 12/07/2016 3:28 PM, Amy Lu wrote: Please help to review the updated webrev, getting rid of ThreadDeath and using join(): http://cr.openjdk.java.net/~amlu/8132548/webrev.03/ I still think a simple change to the original code suffices, but given you have gone this far ... Busy-loo

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

And then somehow the unnecessary statics started to bother me: import java.util.concurrent.CountDownLatch; import java.util.concurrent.atomic.AtomicReference; public class Stop { public static void main(String[] args) throws Exception { final CountDownLatch ready = new CountDownLatch

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Amy, sorry you have so many picky reviewers! Here's how I might write it: import java.util.concurrent.CountDownLatch; import java.util.concurrent.atomic.AtomicReference; public class Stop { private static final CountDownLatch ready = new CountDownLatch(1); private static final ThreadGrou

Re: --dry-run description enhancement

Mandy, perhaps there is a JVM technicality here I'm unfamiliar with. My understanding of loading a class has always been that it's coupled with running its static initializers. So my inference was that the class does not get loaded into memory because the latter no longer occurs with --dry-run. On

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Please help to review the updated webrev, getting rid of ThreadDeath and using join(): http://cr.openjdk.java.net/~amlu/8132548/webrev.03/ Thanks, Amy On 7/11/16 6:55 PM, David Holmes wrote: On 11/07/2016 6:14 PM, Amy Lu wrote: Thank you David, though the email crossed-by, I hope all the c

Re: --dry-run description enhancement

> On Jul 12, 2016, at 10:35 AM, Paul Benedict wrote: > > Mandy, can you please give a look to the first email in this thread and see > if you believe the enhanced message I suggested is helpful? I think it would > be. > > Your Suggestion: "create VM but do not load mainclass or execute main

Re: --dry-run description enhancement

Mandy, can you please give a look to the first email in this thread and see if you believe the enhanced message I suggested is helpful? I think it would be. On Jul 11, 2016 8:32 PM, "Mandy Chung" wrote: > > > On Jul 12, 2016, at 6:13 AM, Paul Benedict wrote: > > > > Alan, I wish I found this be

Re: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers()

> On Jul 12, 2016, at 12:18 AM, Volker Simonis wrote: > > Hi, > > here comes a new version of this change. I've tried to address most of > the concerns/suggestions: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564.v1/ > This version looks okay in general. I suggest to combine th

Re: --dry-run description enhancement

> On Jul 12, 2016, at 6:13 AM, Paul Benedict wrote: > > Alan, I wish I found this before I responded to you, but, anyway, here you > go: > > https://bugs.openjdk.java.net/browse/JDK-8160698 > "java --dry-run should not cause main class be initialized” > Yes this has been fixed. Mandy > Cheer

RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

Hi, Please help review the change for JDK-7031075. issue: https://bugs.openjdk.java.net/browse/JDK-7031075 webrev: http://cr.openjdk.java.net/~sherman/7031075/webrev This is a corner case in current implementation, in which the "readEOF" flag is only set when/after the read/skip method is invok

Re: --dry-run description enhancement

Alan, I wish I found this before I responded to you, but, anyway, here you go: https://bugs.openjdk.java.net/browse/JDK-8160698 "java --dry-run should not cause main class be initialized" Cheers, Paul On Mon, Jul 11, 2016 at 5:09 PM, Paul Benedict wrote: > So I just tested "--dry-run" and I se

Re: --dry-run description enhancement

So I just tested "--dry-run" and I see it does load the class. My apologies. I was following the commit trail but somehow the loading of the class escaped me. I swore at one point it wasn't loading, but my error, nevertheless. Was there any debate on this issue? The problem I currently see with lo

Re: --dry-run description enhancement

On 11/07/2016 22:01, Paul Benedict wrote: The current help of --dry-run is this: "create VM but do not execute main method" But I think it's pretty important to note that the class is also not even loaded. The main class should be loaded. The original intention was that it do everything except

Re: JDK 9 RFR of 8160215: jdk/test/java/io/Reader/ReaderBulkReadContract.java should clean up better

Hi Brian, Good to go from me :-) > On Jul 11, 2016, at 4:38 PM, Brian Burkhalter > wrote: > > On Jul 11, 2016, at 3:32 AM, Lance Andersen > wrote: > >>> On Jul 11, 2016, at 3:56 AM, Alan Bateman >> > wrote: >>> >>> On 10/07/20

--dry-run description enhancement

The current help of --dry-run is this: "create VM but do not execute main method" But I think it's pretty important to note that the class is also not even loaded. Not even static initializers will execute. Does anyone think this would would be a worthwhile tweak? Suggestion: "create VM but do no

Re: JDK 9 RFR of 8160215: jdk/test/java/io/Reader/ReaderBulkReadContract.java should clean up better

On Jul 11, 2016, at 3:32 AM, Lance Andersen wrote: >> On Jul 11, 2016, at 3:56 AM, Alan Bateman wrote: >> >> On 10/07/2016 15:50, Lance Andersen wrote: >> >>> : >>> I had issues in the past where SQE was using read only directories so >>> writing to test.dir would fail for me. So I used the

Re: CompletableFuture eventual race condition

In this program there is a race between the program ending and the computation trying to print from the daemon thread in the forkjoin pool! import java.util.concurrent.*; public class HelloWorld { public static void main(String[] args) { CompletableFuture.supplyAsync(() -> "Hejjo Worjd

Re: CompletableFuture eventual race condition

> On 11 Jul 2016, at 18:44, Francois Green wrote: > > I sorry for posting in list, but I need an authoritative answer. I was > told by one of the developers of another JVM (Ceylon) language that > > CompletableFuture.supplyAsync(() -> "Hejjo Worjd from Java") >.thenApply(s -> s.replace

Re: CompletableFuture eventual race condition

Why not try to create a sscce that demonstrates the problem? Your snippet looks like it ought to work. On Mon, Jul 11, 2016 at 10:44 AM, Francois Green wrote: > I sorry for posting in list, but I need an authoritative answer. I was > told by one of the developers of another JVM (Ceylon) languag

CompletableFuture eventual race condition

I sorry for posting in list, but I need an authoritative answer. I was told by one of the developers of another JVM (Ceylon) language that CompletableFuture.supplyAsync(() -> "Hejjo Worjd from Java") .thenApply(s -> s.replaceAll("j","l")) .thenAccept(System.out::println); would e

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

> How about the following helper method on ModulePool: > > Optional findModule(ModuleEntry me); > > then the intent in code might be a littler clearer on the context. After thinking about this at bit: If we did that and then later worked out a way to optimize across modules, we’d have to hunt

Re: ByteBuffer views, alignment, word tearing

On 11/07/16 17:04, Paul Sandoz wrote: > I opted to directly use Unsafe rather than defer. I am not sure it’s > always possible to defer to the underlying buffer since its > positional and order state is mutable. Eww. The view has its own position, and the byte ordering is fixed when the view is

Re: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers()

Hi, here comes a new version of this change. I've tried to address most of the concerns/suggestions: http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564.v1/ 1. Added a private 'check()' method to the VersionProps class which ensures that every single part of a version number starts with a d

Re: ByteBuffer views, alignment, word tearing

Hi Andrew, See also: https://bugs.openjdk.java.net/browse/JDK-8151163 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/

ByteBuffer views, alignment, word tearing

I saw a few ACCEPTABLE_SPEC results for ByteBuffer views in jcstress. This results from word tearing. I was rather surprised, because I'd worked on the HeapByteBuffer implementation, and I knew that on we would't expect to see any word tearing for HeapByteBuffers or DirectByteBuffers, at least for

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

Sent from my iPhone > On Jul 11, 2016, at 11:09 AM, Paul Sandoz wrote: > > >> On 11 Jul 2016, at 14:17, Jim Laskey (Oracle) >> wrote: >> >> I’m not sure if we can determine supplied classes vs others unless we >> provide a flag or the set of supplied modules. At any rate, the rules for

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

> On 11 Jul 2016, at 14:17, Jim Laskey (Oracle) wrote: > > I’m not sure if we can determine supplied classes vs others unless we provide > a flag or the set of supplied modules. At any rate, the rules for cross > module optimization would still be complex. > Ok. > ModuleEntry.findEntry: I

Re: RFR 8154737: Rename VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange

On 22/06/16 10:34, Paul Sandoz wrote: > This patch renames VarHandle.compareAndExchangeVolatile to > VarHandle.compareAndExchange so the naming scheme is consistent with > compareAndSet, and is also a little shorter. I guess this means that if we want a relaxed compareAndExchange we'll have to us

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

I’m not sure if we can determine supplied classes vs others unless we provide a flag or the set of supplied modules. At any rate, the rules for cross module optimization would still be complex. ModuleEntry.findEntry: I was half thinking the same once I realized the limits of the lookup. The c

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

On 11/07/2016 6:14 PM, Amy Lu wrote: Thank you David, though the email crossed-by, I hope all the concerns have been resolved in the updated webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.02/ Sorry but no, the changes are neither necessary nor sufficient. With the new code the Threa

Typo in internal Javadoc of Pattern.Bound

Probably not worth a pull request -- somebody can piggyback on another change. diff -r ff7d1c47fef8 src/java.base/share/classes/java/util/regex/Pattern.java --- a/src/java.base/share/classes/java/util/regex/Pattern.java Thu Jul 07 19:00:10 2016 + +++ b/src/java.base/share/classes/java/util/re

Re: JDK 9 RFR of 8160215: jdk/test/java/io/Reader/ReaderBulkReadContract.java should clean up better

> On Jul 11, 2016, at 3:56 AM, Alan Bateman wrote: > > On 10/07/2016 15:50, Lance Andersen wrote: > >> : >> I had issues in the past where SQE was using read only directories so >> writing to test.dir would fail for me. So I used the current directory >> instead which is the work directory

Re: RFR: jsr166 jdk9 integration wave 7

> On 8 Jul 2016, at 22:10, Martin Buchholz wrote: > > > > On Thu, Jul 7, 2016 at 3:39 AM, Paul Sandoz > wrote: > > Here is a spec diff for the atomics: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080603-concurrent-unsafe-vhs/specdiff/java/util/concurrent

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

Hi Jim. Do you anticipate support across module boundaries given your comment? 282 // Navigating other modules via requires and exports is problematic 283 // since we cannot construct the runtime model of loaders and layers. it might be possible to emulate runtime resolution a

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

On 7/11/16 4:14 PM, Amy Lu wrote: Thank you David, though the email crossed-by, I hope all the concerns have been resolved in the updated webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.02/ I had rewrote the test with CountDownLatch and join(long millis). Also unlike the old version, t

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Thank you David, though the email crossed-by, I hope all the concerns have been resolved in the updated webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.02/ I had rewrote the test with CountDownLatch and join(long millis). Also unlike the old version, test thread 'first' and 'second' do

Re: JDK 9 RFR of 8160215: jdk/test/java/io/Reader/ReaderBulkReadContract.java should clean up better

On 10/07/2016 15:50, Lance Andersen wrote: : I had issues in the past where SQE was using read only directories so writing to test.dir would fail for me. So I used the current directory instead which is the work directory which will get cleaned up after. You might be thinking `test.src` wh

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Simplification ... On 11/07/2016 5:12 PM, David Holmes wrote: Hi Amy, Thanks for tackling this. On 8/07/2016 4:01 PM, Amy Lu wrote: Thank you Joe for your review. The intent is to give it more chance "for the thread group stop to be issued", not to extend the whole test execution timeout. I

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

My last email crossed with yours. Please see it. David On 11/07/2016 5:20 PM, Amy Lu wrote: Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.02/ Thanks, Amy On 7/11/16 9:20 AM, Amy Lu wrote: Thank you for all the valuable comments. I'm updating the webrev...

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.02/ Thanks, Amy On 7/11/16 9:20 AM, Amy Lu wrote: Thank you for all the valuable comments. I'm updating the webrev... Thanks, Amy On 7/9/16 1:34 AM, Martin Buchholz wrote: jdk/test/java/util/concurrent/tck has

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Hi Amy, Thanks for tackling this. On 8/07/2016 4:01 PM, Amy Lu wrote: Thank you Joe for your review. The intent is to give it more chance "for the thread group stop to be issued", not to extend the whole test execution timeout. I updated the webrev to make this in a retry, limit to 5 times of