Re: RFR: 8145936 - Fixes required to build and run Zero arm64 iOS Mobile JRE

Looks good to me. /Erik On 2015-12-21 21:18, Bob Vandette wrote: http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ Please review the following fixes that were required to complete the initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest. 1. Change the VAR_CPU_A

Re: RFR (JAXP): 8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty

Thanks Roger! On 12/21/2015 1:35 PM, Roger Riggs wrote: Hi Joe, A few comments: InputSource: I assume you meant javax.xml.transform.Source (there was an error in Source's javadoc where the return statement referred to it as InputSource). - Should the default method return true? The defau

Re: RFR (JAXP): 8144967: javax.xml.transform.Source and org.xml.sax.InputSource can be empty

Hi Joe, A few comments: InputSource: - Should the default method return true? The default method is only present to allow source compatibility with unknown subtypes. I would expect that without any specific implementation knowledge it would need to be false. All of the JDK provided S

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi Stephen, Confirmed, the reviews are in progress to update the spec for 9 and fix the implementation in 8. Thanks, Roger On 12/21/2015 2:05 PM, Stephen Colebourne wrote: On 11 December 2015 at 20:07, Roger Riggs wrote: Stephen, can you confirm that the added text and test in DateTimeForm

RFR: 8145936 - Fixes required to build and run Zero arm64 iOS Mobile JRE

http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ Please review the following fixes that were required to complete the initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest. 1. Change the VAR_CPU_ARCH for 64-bit to "arm" from “aarch64 in order to ensure that OPENJ

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

Thanks for all the reviews! Pushed. /Claes On 2015-12-21 11:06, Chris Hegarty wrote: Thanks for doing this Claes. The changes look good to me. -Chris. On 20/12/15 23:06, Claes Redestad wrote: Hi all, On 2015-12-20 20:43, Ulf wrote: Hi Claes, I had a very short look and found in j.l.Thread

Re: RFR 8145909: tools/jjs/jjs-fileTest.sh fails after JDK-8145750 except on windows

Hi Sundar, Yes, we talked about this offline. The fix looks good. -- Jon Line termination issue in an "expected output" file. Ran dos2unix on the expected output file on Windows. Verified by jtreg run is fine on Windows and Ubuntu Linux. Please review. You won't see anything on webrev as it i

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

On 11 December 2015 at 20:07, Roger Riggs wrote: > Stephen, can you confirm that the added text and test in DateTimeFormatter > is not a specification change? I thought I replied to this earlier, but maybe not. This is not a change to the spec, but a clarification to add a clear spec in an area

Re: RFR:8143413:add toEpochSecond methods for efficient access

The comment for the new LocalDate.EPOCH field should use 1970-01-01, not 1970-1-1. However, the code should omit the zeroes: Replace: LocalDate.of(1970, 01, 01) with LocalDate.of(1970, 1, 1) The new method should follow the documentation of the similar method on ChronoLocalDateTime: * This

Re: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java'

On 2015-12-21 19:52, Roger Riggs wrote: Hi Claes, The commandline() should be longer than the command(); if not then it has been truncated and the test should be skipped. Updated the webrev in place. http://cr.openjdk.java.net/~rriggs/webrev-info-8136597/ +1 /Claes

Re: RFR:JDK-8145166 : Duration.toString violates specification

Looks good to me. thanks Stephen On 19 December 2015 at 13:45, nadeesh tv wrote: > Hi all, > > Please review > > Bug Id - https://bugs.openjdk.java.net/browse/JDK-8145166 > > Issue - Duration.toString violates specification for Durations which have > value in the range -59 to -60, -119 to -120 s

Re: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java'

Hi Claes, The commandline() should be longer than the command(); if not then it has been truncated and the test should be skipped. Updated the webrev in place. http://cr.openjdk.java.net/~rriggs/webrev-info-8136597/ Roger On 12/21/2015 11:25 AM, Claes Redestad wrote: On 2015-12-21 17:21

Re: RFR 8145909: tools/jjs/jjs-fileTest.sh fails after JDK-8145750 except on windows

Looks fine Sundar; thanks, -Joe On 12/21/2015 9:44 AM, Sundararajan Athijegannathan wrote: Line termination issue in an "expected output" file. Ran dos2unix on the expected output file on Windows. Verified by jtreg run is fine on Windows and Ubuntu Linux. Please review. You won't see anythin

Re: RFR:JDK-8145166 : Duration.toString violates specification

Hi Nadeesh, Looks fine. I can integrate it tomorrow. Thanks, Roger On 12/19/2015 8:45 AM, nadeesh tv wrote: Hi all, Please review Bug Id - https://bugs.openjdk.java.net/browse/JDK-8145166 Issue - Duration.toString violates specification

RFR 8145909: tools/jjs/jjs-fileTest.sh fails after JDK-8145750 except on windows

Line termination issue in an "expected output" file. Ran dos2unix on the expected output file on Windows. Verified by jtreg run is fine on Windows and Ubuntu Linux. Please review. You won't see anything on webrev as it ignores whitespaces. The following is the patch file: http://cr.openjdk.j

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

Sure, rerunning with -XX:TieredStopAtLevel=1 there's evidently a very small overhead of return !falseValue over return trueValue: DefaultInitBench.trueWithFalseValue avgt 15 5.482 ± 0.077 ns/op DefaultInitBench.trueWithTrueValue avgt 15 5.147 ± 0.037 ns/op I prefer to keep the patch as-is. /Cl

Re: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java'

On 2015-12-21 17:21, Roger Riggs wrote: Hi Claes, I considered that, but it might be that the command line contained 'java' in the path name (not at the end) or that the truncation occurred just after 'java' in the pathname. With the possibility of truncation, there may be no reliable test a

Re: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java'

Hi Claes, I considered that, but it might be that the command line contained 'java' in the path name (not at the end) or that the truncation occurred just after 'java' in the pathname. With the possibility of truncation, there may be no reliable test at all and it should be removed. Roger

Re: RFR [9] Move sun.misc math support classes to jdk.internal.math

Looks fine; thanks, -Joe On 12/21/2015 8:09 AM, Chris Hegarty wrote: There are 5 "math" related classes in the sun.misc package, DoubleConsts, FDBigInteger, FloatConsts, FloatingDecimal, and FormattedFloatingDecimal. They provide support for various standard constants, and conversation/formatti

Re: RFR [9] Move sun.misc math support classes to jdk.internal.math

Sounds reasonable. Either jdk.internal.math or com.sun.math. Brian On Dec 21, 2015, at 8:09 AM, Chris Hegarty wrote: > I think it makes > sense for them to be co-located in their own internal package, > jdk.internal.math ( open to other suggestions on the name ), rather > than jdk.internal.misc

Re: RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java'

Hi, On 2015-12-21 16:40, Roger Riggs wrote: Please review this test fix to allow the test to pass even if the OS provided commandline information is truncated and does not include the full command. It appears on Solaris when the path to the java command is longer than 80 chars. webrev: ht

RFR [9] Move sun.misc math support classes to jdk.internal.math

There are 5 "math" related classes in the sun.misc package, DoubleConsts, FDBigInteger, FloatConsts, FloatingDecimal, and FormattedFloatingDecimal. They provide support for various standard constants, and conversation/formatting utilities, etc. They are used by the JDK in a few public packages, ja

Re: JDK 9 RFR of JDK-8145869: Mark test JMXStartStopTest.java and TestJstatdServer.java as intermittently failing

Looks fine Amy; thanks, -Joe On 12/20/2015 8:53 PM, Amy Lu wrote: sun/management/jmxremote/startstop/JMXStartStopTest.java sun/tools/jstatd/TestJstatdServer.java Above tests are known to fail intermittently, this patch is to mark the test accordingly with keyword 'intermittent'. bug: https:

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

So for C2 it doesn't matter. From what I can tell using javap, the xor generates the fewest number of bytecode operations. Not that this breaks the bank but, one would think that fewer bytecodes would help C1. Jason From: core-libs-dev on behalf of Al

RFR 9: 8136597 : java/lang/ProcessHandle/InfoTest.java fails: commandLine() should at least contain 'java'

Please review this test fix to allow the test to pass even if the OS provided commandline information is truncated and does not include the full command. It appears on Solaris when the path to the java command is longer than 80 chars. webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi Sherman, 2015-12-20 16:35 GMT+09:00 Xueming Shen : > It is no longer necessary to touch the native code (zip_util.c/h) after the > native ZipFile implementation has been moved up to the java level. Those > native code are for vm access only now, which I dont think care about the > password supp

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

On 12/19/2015 04:07 PM, Claes Redestad wrote: > When meticulously going through and checking each usage for odd pattern > like this I accidentally did a bit of extra cleanup, mostly addressing a > number of cases where the volatile field was being read twice. Sorry! > > Bug: https://bugs.openjdk.j

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

On 19/12/2015 13:07, Claes Redestad wrote: Hi, initializing volatile fields to their default value has a well-known performance penalty, and removing these should typically be safe. This patch addresses java.base. There are however some corner cases that we need to check for, see examples

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

Am 21.12.2015 um 11:31 schrieb Ulf: Am 21.12.2015 um 00:06 schrieb Claes Redestad: Hi all, On 2015-12-20 20:43, Ulf wrote: Hi Claes, I had a very short look and found in j.l.Thread: 211 * Java thread status for tools, 0 indicate thread 'not yet started' I guess you meant: 211 *

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

Am 21.12.2015 um 00:06 schrieb Claes Redestad: Hi all, On 2015-12-20 20:43, Ulf wrote: Hi Claes, I had a very short look and found in j.l.Thread: 211 * Java thread status for tools, 0 indicate thread 'not yet started' I guess you meant: 211 * Java thread status for tools; 0 indicat

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

Thanks for doing this Claes. The changes look good to me. -Chris. On 20/12/15 23:06, Claes Redestad wrote: Hi all, On 2015-12-20 20:43, Ulf wrote: Hi Claes, I had a very short look and found in j.l.Thread: 211 * Java thread status for tools, 0 indicate thread 'not yet started' I guess

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

On 12/21/2015 12:46 PM, Andrew Haley wrote: >> See: "Speed-kings of inverting booleans" at >> http://www.javaspecialists.eu/archive/Issue042.html > > That's from 2002, and not valid any more. Maybe not valid even back > then. It is not valid today, I've checked a while ago: http://cr.openjdk.ja

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

On 20/12/15 20:02, Jason Mehrens wrote: > For the cases where boolean was being assigned to 'true' (ASSCI and > FileLockImpl) does it hurt performance since the accessor methods > will now include a branch at the bytecode level? That depends on the caller. A trivial accessor method will usually