Re: RFR: 8009428 and 8009429 - Profile related fixes and clean ups

2013-03-11 Thread Alan Bateman
On 11/03/2013 01:24, David Holmes wrote: I had overlooked the need to update the ct.sym creation tool to recognize the new syntax in the profile spec file. That process also uncovered a few bugs in the listing that needed correcting. The javadoc generation of compact profile information is

Re: RFR 8009517: Disable fatal compiler warning in the old build

2013-03-11 Thread Erik Joelsson
I have a suggestion for how to at least partly enable -Werror in the new build. The penalty is slightly longer compile time, but the difference should be negligible. We split the big java compilation in jdk in two. The first pass with -Werror and all warnings turned on, the second without. We

Re: Request for review- RFE 8005716

2013-03-11 Thread Alan Bateman
On 08/03/2013 02:22, BILL PITTORE wrote: Moved the string allocation into buildJniFunctionName as Alan suggested. Built and tested on windows and linux. Updated the webrev: http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ bill I see this updates the method descriptions to take on

Re: RFR 8009517: Disable fatal compiler warning in the old build

2013-03-11 Thread Erik Joelsson
I tried implementing a PoC for this. Without sjavac, it works, except that the first pass must be run without -Werror and the second with. Since we use -implicit:none, this is fine. With sjavac I had to let it compile the full set of classes first and then run a second time (into a different

Re: RFR 8009517: Disable fatal compiler warning in the old build

2013-03-11 Thread Chris Hegarty
Thank you for trying this Erik. I did think of this workaround myself, but felt if might not be acceptable due to the performance penalty. But this information is great to have. I wonder if we should try to get all alternatives/proposals on the table, then make a decision. I know of two

Re: Request for review- RFE 8005716

2013-03-11 Thread BILL PITTORE
On 3/11/2013 9:40 AM, Alan Bateman wrote: On 08/03/2013 02:22, BILL PITTORE wrote: Moved the string allocation into buildJniFunctionName as Alan suggested. Built and tested on windows and linux. Updated the webrev: http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/ bill I see this

hg: jdk8/tl/langtools: 6181889: Empty try/finally results in bytecodes being generated

2013-03-11 Thread vicente . romero
Changeset: c61add6bf8ac Author:vromero Date: 2013-03-11 15:35 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c61add6bf8ac 6181889: Empty try/finally results in bytecodes being generated Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java +

hg: jdk8/tl/langtools: 8009742: Bad lambda name for lambda in a static initializer or ctor

2013-03-11 Thread robert . field
Changeset: d0ae21e3a382 Author:rfield Date: 2013-03-11 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d0ae21e3a382 8009742: Bad lambda name for lambda in a static initializer or ctor Reviewed-by: mcimadamore !

Status of 4500542: WeakIdentityHashMap?

2013-03-11 Thread Sergey Bylokhov
Hello, Everybody. Does anyone know the status of 4500542? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500542 It was postponed? I counted at least 3 similar but slightly different internal implementations of it in the jdk. Probably additional option could be added to the WeakHashMap to

Re: Review Request: BigInteger patch for efficient multiplication and division (#4837946)

2013-03-11 Thread Brian Burkhalter
Hi Tim, On Mar 10, 2013, at 1:39 PM, Tim Buktu wrote: I have updated the patch. It now contains Alan Eliasen's fast square() and pow() implementations. Special characters have been replaced with ASCII ones. Also included is a patched MutableBigInteger which uses the fast division

Re: AWT Dev [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u

2013-03-11 Thread Phil Race
Konstantin, On 3/11/2013 1:45 PM, Konstantin Shefov wrote: Phil, 12.03.2013 0:22, Phil Race wrote: On 3/11/2013 1:07 PM, Konstantin Shefov wrote: All these tests compile and run under all OSs, not MacOS only. I find that very difficult to believe.

Re: AWT Dev [8] Review request for CR 7145406 - [macosx] Migrate Apple tests from macosx-port to 7u

2013-03-11 Thread Phil Race
On 3/11/2013 1:07 PM, Konstantin Shefov wrote: All these tests compile and run under all OSs, not MacOS only. I find that very difficult to believe. \re\jdk\8\promoted\latest\binaries\windows-i586\bin\javac APIPresent.java APIPresent.java:31: error: package com.apple.eio does not exist import

Re: Code review request: JDK-8008670 (partial java.util.stream implementation)

2013-03-11 Thread Brian Goetz
I've posted an updated webrev incorporating comments received to date: http://cr.openjdk.java.net/~briangoetz/jdk-8008670.2/webrev/ On 2/21/2013 2:16 PM, Brian Goetz wrote: At: http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/ there is a webrev of a subset of the

Mismatch between JDK and JVM re largest byte array that VM can allocate?

2013-03-11 Thread Srinivas Ramakrishna
I am looking at code in (for example) ByteArrayOutputStream.java :- 96 /** 97 * Increases the capacity to ensure that it can hold at least the 98 * number of elements specified by the minimum capacity argument. 99 * 100 * @param

Re: Code review request: JDK-8008670 (partial java.util.stream implementation)

2013-03-11 Thread Paul Benedict
My comments... 1) TerminalOp: When default methods are very simple (i.e., a one-liner), you are sometimes (not always) putting the body on a new line. I think you should use a consistent coding style and always start the body on the next line. 2) I find X_IN and X_OUT type parameters to be

Re: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

2013-03-11 Thread Dan Xu
Thanks for all your comments. I have updated the fix accordingly. Please see the webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.02/. For the language concern in getLastErrorString(char *buf, size_t len) function, I will log another bug and address it later. Thanks! -Dan On Thu

Re: Define JNIEXPORT as visibility default with GCC?

2013-03-11 Thread Martin Buchholz
The latest version of my webrev is here: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/ It includes this line: Reviewed-by: coleenp, ddehaven, dcubed Ok to push? On Fri, Mar 8, 2013 at 10:31 AM, Coleen Phillmore coleen.phillim...@oracle.com wrote: The hotspot definitions

Re: Mismatch between JDK and JVM re largest byte array that VM can allocate?

2013-03-11 Thread David Holmes
Hi Ramki, The maximum array size is a VM limitation based on the internal implementation, so I don't think the JDK code should be aware of this limitation. At least with the present code the request for a size of Integer.MAX_VALUE will fail immediately, rather than spending half an hour

Re: Code review request: JDK-8008670 (partial java.util.stream implementation)

2013-03-11 Thread Mike Duigou
Some notes: - Copyrights update. - The order of notes on files is the order that I read the files. It seems like not a bad order to review them. - package docs? Coming next? java.util.Map:: - @since 1.8 missing for defaults - tt/tt should be replace with {@code} - default methods need the

hg: jdk8/tl/langtools: 8009843: sjavac should accept -cp as synonym for -classpath

2013-03-11 Thread jonathan . gibbons
Changeset: fbb6e470079d Author:ohrstrom Date: 2013-03-11 19:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fbb6e470079d 8009843: sjavac should accept -cp as synonym for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/Main.java

Re: Code review request: JDK-8008670 (partial java.util.stream implementation)

2013-03-11 Thread Brian Goetz
2) I find X_IN and X_OUT type parameters to be disruptive to reading. Sticking to a simple I and O would be much easier to read. I'll answer this one because we've gotten it from a few places. This is a nice idea, and it works fine up to a certain level of complexity. But when you have a

Re: Mismatch between JDK and JVM re largest byte array that VM can allocate?

2013-03-11 Thread Srinivas Ramakrishna
It's causing an issue -- which can be worked around in our code -- which is how I stumbled upon this. My thinking was that perhaps the jvm limit could be communicated to the libs via a suitable jvm method. Or better still the unnecessary limitation could be removed for the 64 bit jvm and