RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

Hi, @Venkat: Sorry for late response, but I had to try something 1st. This is an official request for reviewing a patch for fixing a data race between cloning a SimpleTimeZone object and lazily initializing its 3 cache fields which may produce a clone with inconsistent cache state. Here's

Re: RFR(s): 8191859: SoftReference clock/timestamp should be declared volatile

These fields have been this way for a very long time, probably intentionally non-volatile. Is there an observable problem being solved here? I see that out-of-thin-air longs are theoretically possible, but very rare in practice on current platforms. If all you're trying to do is to ensure

Re: Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()

On 24/11/2017 17:29, Schaef, Martin wrote: There is a fix in Java 10 that increases the precision for File.lastModified (https://bugs.openjdk.java.net/browse/JDK-8177809 ). My issue is that the two methods (File.lastModified and BasicFileAttributes.lastModifiedTime) behave differently

Re: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1

Looks good.  Thanks for fixing the test, Rahul. Mandy On 11/24/17 3:16 AM, Rahul Raghavan wrote: Hi, Please review the following fix proposal for 8191813. webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ jbs - https://bugs.openjdk.java.net/browse/JDK-8191813 -- reported

Re: Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()

There is a fix in Java 10 that increases the precision for File.lastModified (https://bugs.openjdk.java.net/browse/JDK-8177809 ). My issue is that the two methods (File.lastModified and BasicFileAttributes.lastModifiedTime) behave differently depending on the gcc version. And this is not

Re: RFR(s): 8191859: SoftReference clock/timestamp should be declared volatile

Hi, On Fri, 2017-11-24 at 14:13 +0100, Per Liden wrote: > The clock and timestamp fields in SoftReference should be declared > volatile. These fields are read or updated by the VM, (possibly) > concurrently with the execution of Java threads. > > To be more specific, the timestamp field is

Replacement of dual-pivot quicksort in java.util.Arrays with new 3-pivot quicksort?

Hi, I found the 2009 discussion and work surrounding dual-pivot quicksort fascinating. At that time, 3-pivot quicksort was described as slower; however, since then a new 3-pivot partition algorithm was published and if you want the fastest sorting time for primitives then the results are again

Re: Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()

Hi Martin, which specific Operating system are you observing this issue ?. Mostly all modern OS's supports higher precision time stamp. Thanks, Vyom On Friday 24 November 2017 08:23 PM, Schaef, Martin wrote: We are experiencing a problem with the following test case:

Re: Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()

On 24/11/2017 14:53, Schaef, Martin wrote: We are experiencing a problem with the following test case: https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L364 Depending on which gcc version we use to compile OpenJDK, the assertion

Re: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1

On 11/24/17 6:16 AM, Rahul Raghavan wrote: Hi, Please review the following fix proposal for 8191813. webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ test/hotspot/jtreg/compiler/runtime/SpreadNullArg.java     No comments. So this style of call:    

Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()

We are experiencing a problem with the following test case: https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L364 Depending on which gcc version we use to compile OpenJDK, the assertion in

Re: Which test groups to run instead of :jdk (8176838)

On Fri, Nov 24, 2017 at 11:02 AM, Lindenmaier, Goetz wrote: > HI Volker, > > this might be what Oracle is running, but it is not the same as > the target jdk. > > E.g., jdk used to include jdk_awt, which is not included by jdk_stable. > > Also, that page is outdated, it

RFR(s): 8191859: SoftReference clock/timestamp should be declared volatile

The clock and timestamp fields in SoftReference should be declared volatile. These fields are read or updated by the VM, (possibly) concurrently with the execution of Java threads. To be more specific, the timestamp field is read by the GC during reference discovery, e.g. during G1/CMS

[10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1

Hi, Please review the following fix proposal for 8191813. webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ jbs - https://bugs.openjdk.java.net/browse/JDK-8191813 -- reported issue - After the latest sync from jdk/jdk the test SpreadNullArg started to fail in tier1 on all

RE: Which test groups to run instead of :jdk (8176838)

HI Volker, this might be what Oracle is running, but it is not the same as the target jdk. E.g., jdk used to include jdk_awt, which is not included by jdk_stable. Also, that page is outdated, it talks about tests in jdk/test etc, while these directories don't exist any more. Best regards,

Re: Which test groups to run instead of :jdk (8176838)

http://download.java.net/openjdk/testresults/10/docs/howtoruntests.html documents that Oracle seems to use :jdk_stable for running the jdk JTreg tests. Regards, Volker On Fri, Nov 24, 2017 at 9:46 AM, Lindenmaier, Goetz wrote: > Hi, > > we used to run test target

Which test groups to run instead of :jdk (8176838)

Hi, we used to run test target :jdk. This has been removed in 8176838. Which target should we run now to get the same or similar set of tests? Best regards, Goetz.