February 2012 - core-libs-dev

hg: jdk8/tl/jdk: 7147087: Remove AWT/Swing/client tests from ProblemList
by alan.bateman＠oracle.com 20 Feb '12

20 Feb '12

Changeset: 5e56d498e913 Author: alanb Date: 2012-02-20 19:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e56d498e913 7147087: Remove AWT/Swing/client tests from ProblemList Reviewed-by: ohair ! test/Makefile ! test/ProblemList.txt

1 0

hg: jdk8/tl/jdk: 6346658: (se) Selector briefly spins when asynchronously closing a registered channel [win]
by alan.bateman＠oracle.com 20 Feb '12

20 Feb '12

Changeset: 7326971f09af Author: alanb Date: 2012-02-20 18:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7326971f09af 6346658: (se) Selector briefly spins when asynchronously closing a registered channel [win] Reviewed-by: chegar, coffeys ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/windows/classes/sun/nio/ch/NativeThread.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/native/sun/nio/ch/SocketDispatcher.c

1 0

7147087: Remove AWT/Swing/client tests from ProblemList
by Alan Bateman 20 Feb '12

20 Feb '12

When Kelly setup the ProblemList file to exclude tests then he initially excluded dozens of tests that he observed failing on platform or in some configuration. We've been chipping away at these issues since then but there are lots of tests for the client area that have not been removed (my guess is that folks in these areas were unaware of this file or do not run the tests via the make file). It's time to do a "reset" and just remove the these tests from the list. For those that are running these tests then feel free to re-add tests that are buggy, just make sure that there are bugs submitted. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7147087/webrev/ Note that I've used the opportunity to add a few other tests that have been failing intermittently (one persistently). Thanks, -Alan.

2 1

hg: jdk8/tl/jdk: 7146506: (fc) Add EACCES check to the return of fcntl native method
by littlee＠linux.vnet.ibm.com 20 Feb '12

20 Feb '12

Changeset: de7f6d5841b6 Author: littlee Date: 2012-02-20 11:24 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de7f6d5841b6 7146506: (fc) Add EACCES check to the return of fcntl native method Summary: Add EACCES check according to the spec of fcntl Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c

1 0

java.io.File field "path" is not declared final
by Rémi Forax 19 Feb '12

19 Feb '12

Reported by a user on the concurrency-interest mailing list, File field "path" is not declared final but should be. cheers, Rémi -------- Original Message -------- Subject: [concurrency-interest] File object is not immutable? Date: Wed, 15 Feb 2012 19:00:59 +0400 From: Ruslan Cheremin <cheremin(a)gmail.com> To: concurrency-interest(a)cs.oswego.edu I was very surprised to see that field "path" in java.io.File is not final. I was treating File object in concurrency area is something like String -- fully immutable, and completely thread-safe, even data-race safe. Am I right supposing that File object is _not_ thread safe by itself (as String does), and it is programmer's responsibility to safe publish it between threads? Or may be it is some kind of hidden magic, which makes File safe, even without explicit final? I mean, there is native calls to FileSystem in constructor and deserialization, which can create membars implictly... ---- Cheremin Ruslan On 02/15/2012 06:15 PM, Alan Bateman wrote: > On 15/02/2012 17:14, Rémi Forax wrote: >> >> The javadoc says File is immutable so it's a bug :( >> There is no guarantee that the fs object will do a memory barrier. >> >> I think path is not final because of the serialization code but >> it should be final and the seralization code should use >> reflection or sun.misc.Unsafe. >> >> I've put Alan Bateman in CC because I don't know if java.io.File is >> managed by the core team or the nio one. >> > Definitely bring it up on core-libs-dev as we should change it to be > final. > > -Alan

7 16

hg: jdk8/tl/jdk: 7146152: File.path should be final
by alan.bateman＠oracle.com 19 Feb '12

19 Feb '12

Changeset: 24c298ef20a8 Author: forax Date: 2012-02-19 16:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24c298ef20a8 7146152: File.path should be final Reviewed-by: alanb, dholmes, mduigou ! src/share/classes/java/io/File.java

2 1

cost of Java "assert" when disabled?
by Srinivas Ramakrishna 17 Feb '12

17 Feb '12

A Java language newbie question: Does anyone have any ballpark numbers on the cost (and its scaling) of peppering assert's in your Java code, but with asserts disabled (-da) ? In other words, is the disabled cost so vanishingly small that we need not think twice when using them, or should one be careful because the cost is non-negligible and can affect (bytecode) footprint or rutime performace even when switched off? thanks for any advice. -- ramki

2 1

hg: jdk8/tl/jdk: 4153167: separate between ANSI and OEM code pages on Windows
by xueming.shen＠oracle.com 17 Feb '12

17 Feb '12

Changeset: d38fed7d2ea7 Author: sherman Date: 2012-02-16 22:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d38fed7d2ea7 4153167: separate between ANSI and OEM code pages on Windows Summary: To use OEM code page for System.out&err when not redirected Reviewed-by: alanb ! src/share/classes/java/lang/System.java ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/windows/native/java/lang/java_props_md.c

1 0

Re: cost of Java "assert" when disabled?
by David Holmes 17 Feb '12

17 Feb '12

The corelibs side of things seems to have gotten dropped from the cc list - added back. On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: > Don't want to sidetrack this thread but I really wish javac had proper > conditional compilation support, which would make this issue mostly moot. But the whole point of Java assertions is to make them available at runtime. I seem to recall a very similar question only recently on the core-libs mailing list. So summary is: - Every assert requires checking if asserts are enabled - JIT Compiler can elide the checks - Presence of assert related bytecodes can impact JIT compiler inlining decisions David > Sent from my phone > > On Feb 16, 2012 5:14 PM, "John Rose" <john.r.rose(a)oracle.com > <mailto:john.r.rose@oracle.com>> wrote: > > On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: > >> I think one problem with them is that they count towards the >> inlining budget since their bytecodes still take up space. Not >> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. > > Optimized object code has (probably) no trace of the assertions > themselves, but as Vitaly said, they perturb the inlining budget. > Larger methods have a tendency to "discourage" the inliner from > inlining, causing more out-of-line calls and a rough net slowdown. > Currently, the non-executed bytecodes for assertions (which can be > arbitrarily complex) make methods look bigger than they really are. > This is (IMO) a bug in the inlining heuristics, which should be > fixed by examining inlining candidates with a little more care. > Since the escape analysis does a similar method summarization, > there isn't necessarily even a need for an extra pass over the methods. > > -- John >

3 3

hg: jdk8/tl/jdk: 6708398: Support integer overflow
by xueming.shen＠oracle.com 16 Feb '12

16 Feb '12

Changeset: b971b51bec01 Author: sherman Date: 2012-02-16 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b971b51bec01 6708398: Support integer overflow Summary: Added add/sub/multiply/toIntExact methods to j.l.Math and StrictMath classes Reviewed-by: emcmanus Contributed-by: roger.riggs(a)oracle.com ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java + test/java/lang/Math/ExactArithTests.java + test/java/lang/StrictMath/ExactArithTests.java

1 0