date:20130826

Hi Brian,

On 08/24/2013 03:39 AM, Brian Burkhalter wrote:
 file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
 
 would be appreciated.

I'm puzzled over this fix.

Isn't the scalability bottleneck being inherent to SecureRandom, because
it piggybacks on the system entropy pool, which is depleted every so
often? What good the thread-local instances of SR actually bring to us?

As discussed in the relevant threads in the original bug report, the
actual fix should be a very accurate replacement of SR with some other
faster and reliable RNG to avoid the inherent scalability bottlenecks.

 Rudimentary testing with JMH 
 (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any
 deleterious performance effects in single-threaded operation nor any
 obvious improvements in the dual threaded case but testing was done
 on on my aging Core 2 Duo notebook and is not likely representative
 of anything approaching real world conditions.

That further reinforces my belief this particular change is not really
required :)

-Aleksey.

Re: RFR (M) CR 8023234: StampedLock serializes readers on writer unlock

Reminder :)

-Aleksey.

On 08/23/2013 02:38 PM, Aleksey Shipilev wrote:
 Hm, I think I still need the second reviewer.
 Anyone?
 
   http://cr.openjdk.java.net/~shade/8023234/webrev.01/
 
 -Aleksey.
 
 On 08/21/2013 11:05 PM, Aleksey Shipilev wrote:
 Thanks Martin!

 I need a sponsor to push this.

 -Aleksey.

 P.S. The support for multi-threaded tests in jtreg/library is one of the
 things I'm eager to have.

 On 08/21/2013 10:53 PM, Martin Buchholz wrote:
 OK, approved!

 I would do things differently, and there is the deeper problem that
 openjdk provides no test infrastructure for multi-threaded tests, which
 we are suffering from here.  Now that testng is being used, it's a good
 time for someone to import test infrastructure from JSR166TestCase


 On Wed, Aug 21, 2013 at 10:46 AM, Aleksey Shipilev
 aleksey.shipi...@oracle.com mailto:aleksey.shipi...@oracle.com wrote:

 Hi Martin,

 On 08/21/2013 06:28 AM, Martin Buchholz wrote:
  If a Reader throws, the test might still pass, since only throwing
 from
  the main thread matters.  See infrastructure in JSR166TestCase, e.g.
  threadUnexpectedException.

 Yes. I still don't think there is a value in catching the exceptions in
 the threads for this concrete regression test. Should the reader die
 with the exception, the test will fail anyway, since enough readers are
 not available.

  OTOH, there seems no value in converting exceptions in the main thread
  to ISE.  Just declare main to throw Exception or whatever.

 This seems to be the stylistic nit. ;) There is the symmetry against
 readers code, which wraps the exceptions into the ISE. For my taste, it
 looks better to retain that symmetry.

 I can still make the changes to the test, if you insist.

 -Aleksey.

RFR: 5047859 : (reflect) Class.getField can't find String[].length

2013-08-26 Thread Joel Borggren-Franck

Hi,

Please review doc fix and test for 
http://bugs.sun.com/view_bug.do?bug_id=5047859

http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/

This is a spec change to update the spec to match the long-standing 
implementation.

There is also a clarification of getFields() javadoc without changing the
spec.

cheers
/Joel

Re: JDK 8 RFC 6470700: Math.random() / Math.initRNG() uses double checked locking

On 08/22/2013 03:37 AM, Brian Burkhalter wrote:
 With respect to this issue
 
 http://bugs.sun.com/view_bug.do?bug_id=6470700
 
 the code of concern from java.lang.Math is
 
 701private static Random randomNumberGenerator;
 702
 703private static synchronized Random initRNG() {
 704Random rnd = randomNumberGenerator;
 705return (rnd == null) ? (randomNumberGenerator = new Random()) : 
 rnd;
 706 }
 
 731public static double random() {
 732Random rnd = randomNumberGenerator;
 733if (rnd == null) rnd = initRNG();
 734return rnd.nextDouble();
 735}
 
 where the class variable randomNumberGenerator is not used anywhere else in 
 the class. The complaint is that this is an instance of the broken 
 double-checked locking pattern. While at first glance this might appear to be 
 the case, it does not seem so to me. It looks more like an attempt to avoid 
 calling a synchronized method if randomNumberGenerator has already been 
 initialized.
 
 A more typical pattern would be
 
 private static Random randomNumberGenerator;
 
 private static synchronized Random getRNG() {
 if (randomNumberGenerator == null) {
 randomNumberGenerator = new Random();
 }
 return randomNumberGenerator;
 }
 
 public static double random() {
 return getRNG().nextDouble();
 }
 
 Comments, please.

(Sorry, I'm late to the party!)

I'm surprised people are still haunted by DCL :) In the correct form, it
has generally negligible synchronization overheads associated with
volatile read, and in return you have no class metadata waste. As in:

  private static volatile Random rng;

  private static Random getRNG() {
if (rng == null) {
   synchronized(Math.class) {
  rng = new Random();
   }
}
return rng;
  }

  public static double random() {
return getRNG().nextDouble();
  }

Also, random() will probably be the scalability bottleneck anyway due to
j.l.Random internal atomics. That means, we do not have to provide the
best possible performance for getRNG(), but rather eliminate the
scalability bottleneck. Holder idiom has a benefit of being sequentially
faster (because JITs elide the class init checks, and read the static
field), but in this case of heavy-weight mechanics in j.u.Random, it is
irrelevant. Hence, we can minimize the downside for class metadata
growth by going with DCL.

I would think the *major* problem the patch should fix is the visibility
of new Random() state in the other threads, because its instance is
being published via the data race -- both correct DCL and Holder idiom
solve that. But then again, our current implementation for Random is
using AtomicLong, which has the inherent thread-safeness, making the
only erroneous scenario impossible.

Bottom-line: commit either correct DCL just to secure ourselves from
the adversarial j.u.Random changes.

-Aleksey.

Re: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks

2013-08-26 Thread Paul Sandoz


On Aug 26, 2013, at 2:19 PM, Aleksey Shipilev aleksey.shipi...@oracle.com 
wrote:

 Hi Brian,
 
 On 08/24/2013 03:39 AM, Brian Burkhalter wrote:
 file:///Users/bpb/Work/JSL/jdk/jdk8/tl8/jdk/7189139/index.html
 
 would be appreciated.
 
 I'm puzzled over this fix.
 
 Isn't the scalability bottleneck being inherent to SecureRandom, because
 it piggybacks on the system entropy pool, which is depleted every so
 often? What good the thread-local instances of SR actually bring to us?
 


Right, see here:

  http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/009176.html

I spent some time looking at the implementation of SecureRandom and of 
sun.security.provider.NativePRNG. The implementation of NativePRNG uses a 
static singleton to perform all of the work, so that looked like the 
concurrency bottleneck. But when I rewrote that class, it turns out that even 
removing all of the Java level concurrency bottlenecks, we still can't generate 
concurrent secure random numbers, because the NativePRNG reads /dev/urandom for 
each byte, and that is inherently sequential and is the bottleneck to the 
entire process of generating secure random numbers.


 As discussed in the relevant threads in the original bug report, the
 actual fix should be a very accurate replacement of SR with some other
 faster and reliable RNG to avoid the inherent scalability bottlenecks.
 

I don't know about the PRNG requirements for Miller-Rabin but the changes to 
TLR in review might be a possible substitute for SR in this case, since TLR 
will be updated to use the same PRNG algorithm as SplittableRandom, which 
passes DieHarder tests.  Otherwise, i think we may just be stuck with SR.

Paul.

 Rudimentary testing with JMH 
 (http://openjdk.java.net/projects/code-tools/jmh/) did not reveal any
 deleterious performance effects in single-threaded operation nor any
 obvious improvements in the dual threaded case but testing was done
 on on my aging Core 2 Duo notebook and is not likely representative
 of anything approaching real world conditions.
 
 That further reinforces my belief this particular change is not really
 required :)
 
 -Aleksey.

Re: RFR (M) CR 8023234: StampedLock serializes readers on writer unlock

2013-08-26 Thread Paul Sandoz


On Aug 26, 2013, at 2:20 PM, Aleksey Shipilev aleksey.shipi...@oracle.com 
wrote:

 Reminder :)
 

IIRC one reviewer should be sufficient, plus i don't feel qualified to review 
this at the moment. But i suspect you will also need a committer :-) i can do 
that for you.

Paul.

Re: RFR: 5047859 : (reflect) Class.getField can't find String[].length

2013-08-26 Thread Joel Borggren-Franck

Hi Florian,

Thanks for the comments,

On 2013-08-26, Florian Weimer wrote:
 On 08/26/2013 02:39 PM, Joel Borggren-Franck wrote:
 Hi,
 
 Please review doc fix and test for 
 http://bugs.sun.com/view_bug.do?bug_id=5047859
 
 http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/
 
 This is a spec change to update the spec to match the long-standing 
 implementation.
 
 Perhaps use {@code length} instead of 'length'?

I agree, will fix.

 Technically, I
 don't think the length field exists at all.  The Java language just
 happens to use field syntax to represent the arraylength opcode.
 But adding some clarification to the documentation certainly doesn't
 hurt.
 

The language spec (JLS $10.7) is very clear that there is a length
member for array types, and that it is public, final and a field. I
don't think most vm's implement it as a field, but that shouldn't
matter. So while I agree this is clarifying it is actually a bug fix
as well.

cheers
/Joel

Re: RFR (M) CR 8023234: StampedLock serializes readers on writer unlock

On 08/26/2013 05:18 PM, Paul Sandoz wrote:
 
 On Aug 26, 2013, at 2:20 PM, Aleksey Shipilev
 aleksey.shipi...@oracle.com wrote:
 
 Reminder :)
 
 
 IIRC one reviewer should be sufficient, plus i don't feel qualified
 to review this at the moment. But i suspect you will also need a
 committer :-) i can do that for you.

Ah, if only one reviewer is required, then Martin had already reviewed.
Please push! (Do you need the changeset?)

  http://cr.openjdk.java.net/~shade/8023234/webrev.01/

-Aleksey.

Re: RFR (M) CR 8023234: StampedLock serializes readers on writer unlock

On 08/26/2013 05:37 PM, Aleksey Shipilev wrote:
 On 08/26/2013 05:18 PM, Paul Sandoz wrote:

 On Aug 26, 2013, at 2:20 PM, Aleksey Shipilev
 aleksey.shipi...@oracle.com wrote:

 Reminder :)


 IIRC one reviewer should be sufficient, plus i don't feel qualified
 to review this at the moment. But i suspect you will also need a
 committer :-) i can do that for you.
 
 Ah, if only one reviewer is required, then Martin had already reviewed.
 Please push! (Do you need the changeset?)
 
   http://cr.openjdk.java.net/~shade/8023234/webrev.01/

Changeset:
  http://cr.openjdk.java.net/~shade/8023234/8023234.changeset

-Aleksey.

hg: jdk8/tl/jdk: 8023234: StampedLock serializes readers on writer unlock

2013-08-26 Thread paul . sandoz

Changeset: 8a36fc7f494c
Author:shade
Date:  2013-08-26 17:50 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a36fc7f494c

8023234: StampedLock serializes readers on writer unlock
Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock
Reviewed-by: martin, shade
Contributed-by: Doug Lea d...@cs.oswego.edu

! src/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java

Re: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

2013-08-26 Thread Guy Steele


On Aug 24, 2013, at 3:02 PM, Jeff Hain jeffh...@rocketmail.com wrote:

 
 Dmitry Nadezhin wrote:
 Nevertheless, I send this variant now in hope that it may be useful.
 
 Great! It's much faster than what I proposed, cleaner (only integers),
 and according to my tests it behaves the same.

Excellent!  Nice piece of work---thanks, Dmitry.

Re: RFR: 5047859 : (reflect) Class.getField can't find String[].length

2013-08-26 Thread roger riggs


Hi Joel,

Looks fine except for a typo in the test ArrayLength.java, line 28: 
Filed - Field.


(Not a Reviewer).

Roger

On 8/26/2013 8:39 AM, Joel Borggren-Franck wrote:

Hi,

Please review doc fix and test for 
http://bugs.sun.com/view_bug.do?bug_id=5047859

http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/

This is a spec change to update the spec to match the long-standing 
implementation.

There is also a clarification of getFields() javadoc without changing the
spec.

cheers
/Joel

hg: jdk8/tl/jdk: 8011944: Sort fails with ArrayIndexOutOfBoundsException

2013-08-26 Thread roger . riggs

Changeset: 07585a2483fa
Author:rriggs
Date:  2013-08-26 11:46 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07585a2483fa

8011944: Sort fails with ArrayIndexOutOfBoundsException
Summary: Increase the size of pending stack and add test cases
Reviewed-by: alanb

! src/share/classes/java/util/ComparableTimSort.java
! src/share/classes/java/util/TimSort.java
+ test/java/util/Arrays/TimSortStackSize.java

Re: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null in some cases

2013-08-26 Thread Joel Borggrén-Franck

Joe, Paul, Vicente,

Thanks for the reviews!

cheers
/Joel

On 16 aug 2013, at 14:17, Joel Borggren-Franck joel.fra...@oracle.com wrote:

 Hi
 
 Please review this small fix for a type annotation reflection issue.
 
 The javadoc spec for Class.getAnnotatedSuperclass says: 
 
 * If this Class represents either the Object class, an interface type, an
 * array type, a primitive type, or void, the return value is null.
 
 The patch fixes this.
 
 Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
 
 Patch also included it at the end of this mail.
 
 cheers
 /Joel
 
 
 
 diff -r b07b19182e40 src/share/classes/java/lang/Class.java
 --- a/src/share/classes/java/lang/Class.java  Thu Aug 15 15:04:59 2013 +0100
 +++ b/src/share/classes/java/lang/Class.java  Fri Aug 16 13:20:31 2013 +0200
 @@ -3338,8 +3338,16 @@
  * @since 1.8
  */
 public AnnotatedType getAnnotatedSuperclass() {
 - return 
 TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), 
 getConstantPool(), this);
 -}
 +if(this == Object.class ||
 +isInterface() ||
 +isArray() ||
 +isPrimitive() ||
 +this == Void.TYPE) {
 +return null;
 +}
 +
 +return 
 TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(), 
 getConstantPool(), this);
 +}
 
 /**
  * Returns an array of AnnotatedType objects that represent the use of 
 types to
 diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
 --- a/test/java/lang/annotation/TypeAnnotationReflection.java Thu Aug 15 
 15:04:59 2013 +0100
 +++ b/test/java/lang/annotation/TypeAnnotationReflection.java Fri Aug 16 
 13:20:31 2013 +0200
 @@ -23,7 +23,7 @@
 
 /*
  * @test
 - * @bug 8004698 8007073
 + * @bug 8004698 8007073 8022343
  * @summary Unit test for type annotations
  */
 
 @@ -58,7 +58,7 @@
 }
 
 private static void testSuper() throws Exception {
 -check(Object.class.getAnnotatedSuperclass().getAnnotations().length 
 == 0);
 +check(Object.class.getAnnotatedSuperclass() == null);
 check(Class.class.getAnnotatedSuperclass().getAnnotations().length == 
 0);
 
 AnnotatedType a;
 diff -r b07b19182e40 
 test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
 --- /dev/null Thu Jan 01 00:00:00 1970 +
 +++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java   
 Fri Aug 16 13:20:31 2013 +0200
 @@ -0,0 +1,50 @@
 +/*
 + * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
 + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 + *
 + * This code is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License version 2 only, as
 + * published by the Free Software Foundation.
 + *
 + * This code is distributed in the hope that it will be useful, but WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 + * version 2 for more details (a copy is included in the LICENSE file that
 + * accompanied this code).
 + *
 + * You should have received a copy of the GNU General Public License version
 + * 2 along with this work; if not, write to the Free Software Foundation,
 + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 + *
 + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 + * or visit www.oracle.com if you need additional information or have any
 + * questions.
 + */
 +
 +/*
 + * @test
 + * @bug 8022343
 + * @summary make sure Class.getAnnotatedSuperclass() returns null when 
 specified to do so
 + */
 +
 +import java.util.*;
 +import java.lang.annotation.*;
 +import java.lang.reflect.*;
 +import java.io.Serializable;
 +
 +public class GetAnnotatedSuperclass {
 +public static void main(String[] args) throws Exception {
 +check(Object.class.getAnnotatedSuperclass() == null);
 +check(If.class.getAnnotatedSuperclass() == null);
 +check(Object[].class.getAnnotatedSuperclass() == null);
 +check(void.class.getAnnotatedSuperclass() == null);
 +check(int.class.getAnnotatedSuperclass() == null);
 +}
 +
 +private static void check(boolean b) {
 +if (!b)
 +throw new RuntimeException();
 +}
 +interface If {}
 +}
 +

Re: RFR 8022761: SQE test regression on wrongly signed indexed jar file

2013-08-26 Thread Xueming Shen


On 08/19/2013 06:11 AM, Weijun Wang wrote:

Hi Sherman

I try out jar i after signing and it puts INDEX.LIST at the very beginning of 
the file. Does this mean INDEX.LIST was actually an exception? Or it's just a bug?

Anyway, I think I should update the fix for 8021788 and here is the webrev:

  http://cr.openjdk.java.net/~weijun/8022761/webrev.00/

Now it also skips INDEX.LIST, i.e. update line 142 to

  if (uname.equals(JarFile.MANIFEST_NAME) ||
  uname.equals(JarIndex.INDEX_NAME) ) {

After this change, if INDEX.LIST appears before the MANIFEST and signature-related files, 
it will not be treated as signed. This should usually be true because it only happens 
when you call jar i after signing a jar which means INDEX.LIST *is* unsigned.

Thanks
Max

On 8/12/13 12:18 PM, Weijun Wang wrote:

Hi Sherman

SQE observes a regression in their test suite and
the reason is my recent fix for 8021788 at

   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c

The jar file mentioned contains

 66 Mon Jun 04 15:42:18 CST 2007 META-INF/INDEX.LIST
323 Sat Apr 01 15:47:28 CST 2000 META-INF/MANIFEST.MF
376 Mon Jun 04 15:41:00 CST 2007 META-INF/MYKEY.SF
972 Sat Apr 01 15:47:38 CST 2000 META-INF/MYKEY.DSA
  0 Sat Apr 01 15:46:58 CST 2000 META-INF/
  0 Sat Apr 01 15:45:16 CST 2000 test/
 21 Sat Apr 01 15:46:24 CST 2000 test/test0
 21 Sat Apr 01 15:46:18 CST 2000 test/test1
 21 Sat Apr 01 15:46:04 CST 2000 test/test2
 21 Sat Apr 01 15:46:10 CST 2000 test/test3

After JDK-8021788, the file is regarded as an unsigned jar because the
updated JarVerifier goes thru all signature-related files and treats all
others not. Here the first one is not signature-related so none is.

Is fix for JDK-8021788 wrong? Inside JarVerifier.java, we have

   * Assumptions:
   * 1. The manifest should be the first entry in the META-INF directory.
   * 2. The .SF/.DSA/.EC files follow the manifest, before any normal
entries

Is this INDEX.LIST an exception?



Hi Max,

The assumption was made probably before the jar index was introduced(1.3?).
Jar spec never assumes the order of the files inside the meta-inf directory
(the spec treats the jar/zip file as a file system, the implementation then 
faces
this issue when the archive is handled in steam), but our implementation
does have the assumption. JarInputStream has a similar assumption regarding
the manifest.mf and a workaround for jarindex, if the jarindex is the first one.
I would take it as an implementation details.

The change looks fine.

-Sherman


Thanks
Max

Re: RFR: 5047859 : (reflect) Class.getField can't find String[].length

2013-08-26 Thread Mandy Chung


Joel,

The spec of the getFields and getDeclaredFields() methods both states this:

  This method returns an array of length 0 if the class
  or interface declares no fields, or if this|Class|  object
  represents a primitive type, an array class, or void.

The spec of the getDeclaredField() method has this sentence:

  Note that this method will not reflect the {@code length}
  field of an array class.

Your change is okay and it would be good to keep the getField(s)
and getDeclaredField(s) methods be consistent and states its
return value if this|Class|  object represents a primitive type,
an array class, or void

Mandy

On 8/26/2013 5:39 AM, Joel Borggren-Franck wrote:

Hi,

Please review doc fix and test for 
http://bugs.sun.com/view_bug.do?bug_id=5047859

http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/

This is a spec change to update the spec to match the long-standing 
implementation.

There is also a clarification of getFields() javadoc without changing the
spec.

cheers
/Joel

hg: jdk8/tl/jdk: 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions

2013-08-26 Thread sean . coffey

Changeset: 92a66af7f834
Author:igerasim
Date:  2013-08-26 18:26 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92a66af7f834

8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions
Reviewed-by: alanb, chegar

! src/share/classes/java/lang/AbstractStringBuilder.java

hg: jdk8/tl: 8023491: Remove target names from test/Makefile and defer to sub-repo makefiles.

2013-08-26 Thread mike . duigou

Changeset: f643fee2b40f
Author:mduigou
Date:  2013-08-26 10:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/f643fee2b40f

8023491: Remove target names from test/Makefile and defer to sub-repo makefiles.
Reviewed-by: erikj

! common/makefiles/Main.gmk
! test/Makefile

hg: jdk8/tl/langtools: 8023701: Fix badly named test

2013-08-26 Thread jonathan . gibbons

Changeset: 60f156c653d3
Author:jjg
Date:  2013-08-26 11:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/60f156c653d3

8023701: Fix badly named test
Reviewed-by: bpatel

- test/com/sun/javadoc/testNavagation/TestNavagation.java
- test/com/sun/javadoc/testNavagation/pkg/A.java
- test/com/sun/javadoc/testNavagation/pkg/C.java
- test/com/sun/javadoc/testNavagation/pkg/E.java
- test/com/sun/javadoc/testNavagation/pkg/I.java
+ test/com/sun/javadoc/testNavigation/TestNavigation.java
+ test/com/sun/javadoc/testNavigation/pkg/A.java
+ test/com/sun/javadoc/testNavigation/pkg/C.java
+ test/com/sun/javadoc/testNavigation/pkg/E.java
+ test/com/sun/javadoc/testNavigation/pkg/I.java

Re: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black)

2013-08-26 Thread Paul Sandoz


On Aug 25, 2013, at 8:04 PM, Remi Forax fo...@univ-mlv.fr wrote:

 On 08/21/2013 02:25 PM, Paul Sandoz wrote:
 Hi,
 
 Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a 
 webrev:
 
   
 http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/
 
 I also added some tests related to characteristics associated with fixing 
 another bug.
 
 Looking at the diffs will be tricky given there are so many changes.
 
 
 The code can be simplified a little bit by using the diamond syntax,
 HashMap (lines: 919, 963, 1026, 1497, 1569) and
 LinkedHashMap (lines: 255, 264, 270, 278)
 
 There are a bunch of @Override that are missing making the code harder than 
 it should to read.
 

Yes, i think this is because it sticks to the 166 style i suspect. Easy to 
change.


 HashMapSpliterator.est should be renamed to estimateSize.
 
 All occurences of (n - 1)  hash should be replaced by hash  (n - 1) 
 because it's easier to explain.
 

I am OK with how they are, and it's consistent with other code.


 TreeNode.getTreeNode() should be a static method and take a NodeK,V as 
 first argument,
 so most of the casts to TreeNodeK,V that bother you will disappear :)
  static TreeNodeK,V getTreeNode(NodeK,V node, int h, Object k) {
TreeNodeK,V first = (TreeNodeK,V)node;
return ((first.parent != null) ? first.root() : firt).find(h, k, null);
  }
 

Yes, that will reduce the casts.


 In putVal, line 654, the null check (e != null) makes the method hard to read,
 at least I think a comment saying that it means that an existing node need to 
 be altered is needed.
 

e.g.:

if (e != null) { // existing mapping for key


 And I still don't like the way the method clone() is implemented (the older 
 implementation has the same issue),
 result should not be initialized to null and the catch clause should thow an 
 InternalError or an AssertionError,
 

You mean like this:

public Object clone() {
HashMapK,V result = null;
try {
result = (HashMapK,V)super.clone();
} catch (CloneNotSupportedException e) {
// this shouldn't happen, since we are Cloneable
throw new InternalError(e);
}
result.reinitialize();
result.putMapEntries(this, false);
return result;
}



 Taking a look to the generated assemblies for HashMap.get(), there are three 
 differences,
 1) the old implementation and the new implementation both have a shortcut to 
 return null,
but the condition is slightly different, the old implementation test if 
 size == 0 while
the new one test if arraylength = 0.
So the new implementation use less load but at the price of a less general 
 condition.
 2) the new implementation do a lot of less bits twiddling on the hashCode 
 value
 3) the old implementation use an array of Object and not an array of Node, so
there is a supplementary fast checkcast.
 apart that the whole code is identical, so the introduction of the tree 
 implementation has
 no runtime cost if the tree is not needed.
 
 For HashMap.put, the new implementation has no runtime cost too and does 
 fewer loads
 because the code of the old implementation was written in the stupid way
 (the field 'table' has to be loaded several times by example).
 
 so the code is clearly an improvement compared to the previous versions in 
 term of 'assembly beauty' :)
 
 
 
 I fixed unchecked warnings in LinkedHashMap, but have not done so for 
 HashMap, where there are many more casts from Node to TreeNode. One way to 
 solve that is with a static method:
 
 @SuppressWarnings(unchecked)
 static K, V TreeNodeK, V asTreeNode(NodeK, V n) {
 return (TreeNodeK, V) n;
 }
 
 but i dunno what the performance implications are. Perhaps it's best to 
 simply stuff @SuppressWarnings on methods of TreeNode rather than trying to 
 modify code just for the sake of reducing the scope.
 
 You should not need the @SuppressWarnings here?
 

Doh, clearly i am not thinking straight here and got confused over unchecked!

Paul.

Re: 8020292: j.u.SplittableRandom

With most recent changes, +1.

Mike

On Aug 19 2013, at 04:06 , Paul Sandoz wrote:

 Hi,
 
 This is the patch for SplittableRandom:
 
  http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/
 
 The algorithm remains the same as reported by Doug on the 9th August:
 
  http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019768.html
 
 Paul.

RFR: JDK-8023647,, abc1c .matches( (\\w)+1\\1 )) returns false

2013-08-26 Thread Xueming Shen


Hi,

Please help review the proposed change for 8023647:

http://cr.openjdk.java.net/~sherman/8023647/webrev

It appears group index updating in situation of GroupCurly backing off
is incorrect from day one (the bug is reproducible back to jdk5). The
current implementation does not back off the index to a previous match,
but the one is being back off.

The ln#4459 is updating a local variable before return, which is not
necessary, I removed it with this change.

Thanks,
-Sherman

hg: jdk8/tl/jdk: 8020292: j.u.SplittableRandom

2013-08-26 Thread paul . sandoz

Changeset: 5ce9025c9e1a
Author:psandoz
Date:  2013-08-26 22:55 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ce9025c9e1a

8020292: j.u.SplittableRandom
Reviewed-by: mduigou
Contributed-by: Guy Steele guy.ste...@oracle.com, Doug Lea 
d...@cs.oswego.edu, Brian Goetz brian.go...@oracle.com, Paul Sandoz 
paul.san...@oracle.com

+ src/share/classes/java/util/SplittableRandom.java
+ test/java/util/SplittableRandom/SplittableRandomTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java

Re: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black)

2013-08-26 Thread Remi Forax


On 08/26/2013 10:10 PM, Paul Sandoz wrote:

On Aug 25, 2013, at 8:04 PM, Remi Forax fo...@univ-mlv.fr wrote:


On 08/21/2013 02:25 PM, Paul Sandoz wrote:

Hi,

Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a 
webrev:

   
http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/

I also added some tests related to characteristics associated with fixing 
another bug.

Looking at the diffs will be tricky given there are so many changes.


The code can be simplified a little bit by using the diamond syntax,
HashMap (lines: 919, 963, 1026, 1497, 1569) and
LinkedHashMap (lines: 255, 264, 270, 278)

There are a bunch of @Override that are missing making the code harder than it 
should to read.


Yes, i think this is because it sticks to the 166 style i suspect. Easy to 
change.



HashMapSpliterator.est should be renamed to estimateSize.

All occurences of (n - 1)  hash should be replaced by hash  (n - 1) 
because it's easier to explain.


I am OK with how they are, and it's consistent with other code.


Ok, not a big deal.





TreeNode.getTreeNode() should be a static method and take a NodeK,V as first 
argument,
so most of the casts to TreeNodeK,V that bother you will disappear :)
  static TreeNodeK,V getTreeNode(NodeK,V node, int h, Object k) {
TreeNodeK,V first = (TreeNodeK,V)node;
return ((first.parent != null) ? first.root() : firt).find(h, k, null);
  }


Yes, that will reduce the casts.



In putVal, line 654, the null check (e != null) makes the method hard to read,
at least I think a comment saying that it means that an existing node need to 
be altered is needed.


e.g.:

 if (e != null) { // existing mapping for key


Yes, perfect.





And I still don't like the way the method clone() is implemented (the older 
implementation has the same issue),
result should not be initialized to null and the catch clause should thow an 
InternalError or an AssertionError,


You mean like this:

 public Object clone() {
 HashMapK,V result = null;
 try {
 result = (HashMapK,V)super.clone();
 } catch (CloneNotSupportedException e) {
 // this shouldn't happen, since we are Cloneable
 throw new InternalError(e);
 }
 result.reinitialize();
 result.putMapEntries(this, false);
 return result;
 }


Yes, and in that case, you don't need to initialize result to null (the 
first line), because when result is used
(result.reinitialize()) result is already initialized by the return 
value of super.clone().


[... ]





I fixed unchecked warnings in LinkedHashMap, but have not done so for HashMap, 
where there are many more casts from Node to TreeNode. One way to solve that is 
with a static method:

 @SuppressWarnings(unchecked)
 static K, V TreeNodeK, V asTreeNode(NodeK, V n) {
 return (TreeNodeK, V) n;
 }

but i dunno what the performance implications are. Perhaps it's best to simply 
stuff @SuppressWarnings on methods of TreeNode rather than trying to modify 
code just for the sake of reducing the scope.

You should not need the @SuppressWarnings here?


Doh, clearly i am not thinking straight here and got confused over unchecked!

Paul.


regards,
Rémi

hg: jdk8/tl/jdk: 8023681: Fix raw type warning caused by Sink

2013-08-26 Thread henry . jen

Changeset: 35c1609d9488
Author:henryjen
Date:  2013-08-09 09:05 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35c1609d9488

8023681: Fix raw type warning caused by Sink
Reviewed-by: mduigou, briangoetz

! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DistinctOps.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SliceOps.java
! src/share/classes/java/util/stream/SortedOps.java

hg: jdk8/tl/langtools: 8023768: Use the unannotatedType in cyclicity checks.

2013-08-26 Thread jonathan . gibbons

Changeset: 7bf6313e1ced
Author:jjg
Date:  2013-08-26 15:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bf6313e1ced

8023768: Use the unannotatedType in cyclicity checks.
Reviewed-by: jjg
Contributed-by: wdi...@gmail.com

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ 
test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java

Re: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

2013-08-26 Thread Brian Burkhalter

On Aug 26, 2013, at 7:52 AM, Guy Steele wrote:

 On Aug 24, 2013, at 3:02 PM, Jeff Hain jeffh...@rocketmail.com wrote:
 
 
 Dmitry Nadezhin wrote:
 Nevertheless, I send this variant now in hope that it may be useful.
 
 Great! It's much faster than what I proposed, cleaner (only integers),
 and according to my tests it behaves the same.
 
 Excellent!  Nice piece of work---thanks, Dmitry.

Indeed - thanks, Dmitry! That is much better than what I proposed.

I did a quick and dirty JMH test with this code and it looks to be more than 6% 
faster for double and more than 24% faster for float versus the current 
codebase. The speed up is probably more than these values which should be 
considered lower bounds on speed improvement.

I have updated the webrev accordingly:

http://cr.openjdk.java.net/~bpb/8010430/

Approval by a Reviewer of this patch is still needed.

Thanks,

Brian

hg: jdk8/tl/jdk: 8014135: The JVMTI specification does not conform to recent changes in JNI specification

2013-08-26 Thread david . holmes

Changeset: 9586ca82bd8b
Author:bpittore
Date:  2013-08-26 11:27 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9586ca82bd8b

8014135: The JVMTI specification does not conform to recent changes in JNI 
specification
Summary: Added support for statically linked agents
Reviewed-by: alanb, sspitsyn, bobv, coleenp

! src/share/classes/com/sun/tools/attach/VirtualMachine.java

RFR: JDK-8023765 -- Improve MaxPathLength.java testcase and reduce its test load

2013-08-26 Thread Dan Xu


Hi All,

MaxPathLength.javais a troublesome testcase, and fails intermittently in 
the nightly test. And it also runs for a long time, especially on 
Windows platforms. Inorder to improve the test stability, I remove its 
unnecessary test iterations, and use NIOdelete method todo the clean-up 
to make the potential failureseasier for diagnosis. Please review 
thechanges. Thanks!


bug: https://bugs.openjdk.java.net/browse/JDK-8023765
webrev: http://cr.openjdk.java.net/~dxu/8023765/webrev/

-Dan

Re: RFR: 8021591 : (s) Additional explicit null checks

On Aug 19 2013, at 15:35 , Martin Buchholz wrote:

My feeling is that the JDK specs have been creeping in the direction of
excessive pedantry and doc lawyerism. I think it's overall a benefit of Java
that its documentation is more readable (at the cost of being a little less
precise) than the typical ISO spec.

There is a definite tension here. We would like to keep the documentation and
specification as readable as possible while still being sufficiently exacting
so that behaviour of an API can be correctly predicted by a reader. It goes
further than that though because Oracle employs an entire group of engineers
who examine the JDK API javadocs looking for normative statements and then
write tests to confirm that implementations conform to the API
documentation/specification. The number and quality of tests they provide to
ensure conformance has been steadily increasing (and accelerating). Is this a
good thing? To me it seems so. When I hear that people encounter problems
(other than performance) when switching among
Vector-ArrayList-LinkedList-CopyOnWriteArrayList or
HashMap-ConcurrentHashMap or TreeSet-ConcurrentSkipListSet because of
arbitrary corner case differences between implementations I become smy

So we usually say returns true if the foo got frozzled instead of the more
precise returns true if and only if the foo got frozzled.
It's obvious that an NPE is thrown on an attempt to derefence a null arg,
which might not happen in some corner case. I think it's overall a detriment
if either extra null checks are inserted or the spec is made more precise but
less readable.

Unfortunately the need for NPE documentation is something that seems to have
recently gotten worse. It seems to becoming accepted that it is necessary to
document what happens when a null reference is passed even when the parameter
provides no specific mention of null handling. I blame the plethora of APIs
that for inadequate reasons use null as their universal solvent--absent,
don't care, default, unknown, maybe-it-works. This could include some JDK
APIs such as use of null Comparator to mean natural order. I remain hopeful
that the JSR 305 annotations will reduce some of the burden of documenting null
handling.

Consider the Throws spec for
http://download.java.net/jdk8/docs/api/java/util/TreeMap.html#containsKey(java.lang.Object)

ClassCastException - if the specified key cannot be compared with the keys
currently in the map

That's incomplete and imprecise, but don't pessimize by adding code to
compare the arg with every key in the map! (which is the equivalent of what
is happening here)

Yes, more precise would be to say could not be compared to some key currently
already in the map, but the intent was clear.

On the opposite side we have regular requests
(https://bugs.openjdk.java.net/browse/JDK-7014079 plus duplicates it
references) to fix the specification of HashSet contains() so that it
mentions it considers the hashCode() value in addition to equals(). The belief
expressed by these reporters is generally that if the JDK developers had fully
specified the contract in the HashSet.contains() method along with it's actual
behaviour then they would not have used the class incorrectly (generally
missing or incorrect equals()/hashCode()).

A vote from me for maintaining the already high level of pedantry we have,
but not raising it any further.

I always imagine it's more like limbo. ;-)

Mike

On Mon, Aug 19, 2013 at 3:15 PM, Mike Duigou mike.dui...@oracle.com wrote:

On Aug 1 2013, at 08:57 , Alan Bateman wrote:

On 26/07/2013 16:31, Mike Duigou wrote:
Hello all;

This patch adds some missing checks for null that, according to interface
contract, should be throwing NPE. It also improves the existing tests to
check for these cases.

http://cr.openjdk.java.net/~mduigou/JDK-8021591/0/webrev/

The changes to
src/share/classes/java/util/concurrent/ConcurrentHashMap.java will be
synchronized separately with the jsr166 workspace. They are part of this
review to avoid test failures.

Mike
As retainAll and removeAll are long standing methods, are there are cases
where we might now throw NPE when we didn't previously?

Yes.

retainAll(null) and removeAll(null) will more consistently throw NPE.
Previously the NPE was not thrown by some collections when the collection
they were empty.

I'm just wondering if any of these need to be looked at more closely,
minimally to get into release/compatibility notes.

I will definitely tag this issue for release notes mention.

-Alan

Re: RFR: 5047859 : (reflect) Class.getField can't find String[].length

2013-08-26 Thread David Holmes


Hi Joel,

On 26/08/2013 10:39 PM, Joel Borggren-Franck wrote:

Hi,

Please review doc fix and test for 
http://bugs.sun.com/view_bug.do?bug_id=5047859

http://cr.openjdk.java.net/~jfranck/5047859/webrev.00/

This is a spec change to update the spec to match the long-standing 
implementation.


Have to wonder why reflection chose to ignore 'length' when the JLS is 
so clear that it is a field ??


Anyway ... I think the added wording to getField() is okay but:

1604  * follows.  Let C be the class or interface represented by 
this object:


I don't think it necessary, or desirable to replace 'class' with 'class 
or interface' here. If you do then you should do it everywhere - which 
would be bad. Plus does it really mean class, or interface, or enum, or 
annotation ? Sometimes class just means the thing a Class represents.



There is also a clarification of getFields() javadoc without changing the
spec.


I don't think this change make sense given it already says it returns a 
zero-length array for array classes - as Mandy pointed out. I don't 
think this clarification is needed.


David


cheers
/Joel

Re: RFR: 8021591 : (s) Additional explicit null checks


On Aug 26 2013, at 18:37 , Mike Duigou wrote:

 
 On Aug 19 2013, at 15:35 , Martin Buchholz wrote:
 
 My feeling is that the JDK specs have been creeping in the direction of 
 excessive pedantry and doc lawyerism.  I think it's overall a benefit of 
 Java that its documentation is more readable (at the cost of being a little 
 less precise) than the typical ISO spec.
 
 There is a definite tension here. We would like to keep the documentation and 
 specification as readable as possible while still being sufficiently exacting 
 so that behaviour of an API can be correctly predicted by a reader. It goes 
 further than that though because Oracle employs an entire group of engineers 
 who examine the JDK API javadocs looking for normative statements and then 
 write tests to confirm that implementations conform to the API 
 documentation/specification.  The number and quality of tests they provide to 
 ensure conformance has been steadily increasing (and accelerating). Is this a 
 good thing? To me it seems so. When I hear that people encounter problems 
 (other than performance) when switching among 
 Vector-ArrayList-LinkedList-CopyOnWriteArrayList or 
 HashMap-ConcurrentHashMap or TreeSet-ConcurrentSkipListSet because of 
 arbitrary corner case differences between implementations I become smy

Sorry, replying to my own message to finish an incomplete sentence.

...sympathetic to concerns that the JDK docs/specs are not specific enough.

Mike

Re: RFR(2nd): 8023275: Wrapping collections should override default methods

Looks good. 

On Aug 21 2013, at 16:19 , Henry Jen wrote:

 On 08/20/2013 02:21 AM, Paul Sandoz wrote:
 [resending unsigned, sorry if a dup arrives later on]
 
 On Aug 19, 2013, at 9:18 PM, Henry Jen henry@oracle.com wrote:
 
 Hi,
 
 Please review the webrev at
 http://cr.openjdk.java.net/~henryjen/tl/8023275/0/webrev/
 
 The patch adds override on default methods for a couple wrapping classed
 and delegate those to underlying class.
 
 There is a minor revise on synchronizedCollection javadoc to cover Stream.
 
 
 Looks good.
 
 
 A sanity check on wrapper classes to ensure default methods are override.
 
 
 You might want to additionally use an ArrayList instance for 
 unmodifiableList/synchronizedList/checkedList, so as to check both unmod 
 list impls:
 
   public static T ListT unmodifiableList(List? extends T list) {
   return (list instanceof RandomAccess ?
   new UnmodifiableRandomAccessList(list) :
   new UnmodifiableList(list));
   }
 
 
 Good point, I also added Navigable into the test.

Thank you for adding these.

Mike

 http://cr.openjdk.java.net/~henryjen/tl/8023275/2/webrev/
 
 Cheers,
 Henry

hg: jdk8/tl/corba: 2 new changesets

Changeset: d411c60a8c2f
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/d411c60a8c2f

Added tag jdk8-b103 for changeset 49c4a777fdfd

! .hgtags

Changeset: 4e38de7c767e
Author:cl
Date:  2013-08-22 09:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/4e38de7c767e

Added tag jdk8-b104 for changeset d411c60a8c2f

! .hgtags

hg: jdk8/tl/nashorn: 5 new changesets

Changeset: afc100513451
Author:cl
Date:  2013-08-15 09:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/afc100513451

Added tag jdk8-b103 for changeset 414203de4374

! .hgtags

Changeset: 74244f43c577
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/74244f43c577

Added tag jdk8-b104 for changeset afc100513451

! .hgtags

Changeset: 1f2394beecf7
Author:lana
Date:  2013-08-20 17:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1f2394beecf7

Merge

- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: f484bfb624dd
Author:lana
Date:  2013-08-23 14:18 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f484bfb624dd

Merge

- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java

Changeset: a18f92a0a910
Author:lana
Date:  2013-08-26 14:54 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a18f92a0a910

Merge

hg: jdk8/tl: 9 new changesets

Changeset: ceefd94ef326
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/ceefd94ef326

Added tag jdk8-b103 for changeset b7e64be81c8a

! .hgtags

Changeset: 4fb877dfe5c4
Author:erikj
Date:  2013-08-15 17:14 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/4fb877dfe5c4

8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines 
does not generate the bundles directory in the build directory
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in

Changeset: f10f673d9b17
Author:igerasim
Date:  2013-08-16 14:43 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/f10f673d9b17

8023156: make dist-clean should remove javacservers directory
Reviewed-by: erikj

! common/makefiles/Main.gmk

Changeset: dadf49495ab4
Author:erikj
Date:  2013-08-19 10:31 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/dadf49495ab4

8021430: 64 bit JDK build fails on windows 7 due to missing corba source files
Reviewed-by: tbell, katleman

! common/makefiles/IdlCompilation.gmk

Changeset: 96c1b9b7524b
Author:katleman
Date:  2013-08-20 15:42 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/96c1b9b7524b

Merge


Changeset: c3b5197f2851
Author:cl
Date:  2013-08-22 09:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/c3b5197f2851

Added tag jdk8-b104 for changeset 96c1b9b7524b

! .hgtags

Changeset: e8a3edda1f60
Author:lana
Date:  2013-08-20 17:40 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/e8a3edda1f60

Merge


Changeset: 056398db9dcb
Author:lana
Date:  2013-08-23 14:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/056398db9dcb

Merge

! common/autoconf/generated-configure.sh

Changeset: 163091288aeb
Author:lana
Date:  2013-08-26 14:49 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/163091288aeb

Merge

! common/makefiles/Main.gmk

hg: jdk8/tl/jaxws: 3 new changesets

Changeset: 42211ab0ab1c
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/42211ab0ab1c

Added tag jdk8-b103 for changeset 6cdc6ed98780

! .hgtags

Changeset: 88390df7ed2c
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88390df7ed2c

Added tag jdk8-b104 for changeset 42211ab0ab1c

! .hgtags

Changeset: 533c1032337c
Author:lana
Date:  2013-08-26 14:50 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/533c1032337c

Merge

hg: jdk8/tl/jaxp: 4 new changesets

Changeset: a22fe9bd01e6
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a22fe9bd01e6

Added tag jdk8-b103 for changeset b1ceab582fc6

! .hgtags

Changeset: af28b93bfb6f
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/af28b93bfb6f

Added tag jdk8-b104 for changeset a22fe9bd01e6

! .hgtags

Changeset: d4d6422ec564
Author:lana
Date:  2013-08-20 17:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d4d6422ec564

Merge


Changeset: 09a46ec11f88
Author:lana
Date:  2013-08-23 14:09 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/09a46ec11f88

Merge

hg: jdk8/tl/langtools: 6 new changesets

Changeset: dd4a00c220c6
Author:cl
Date:  2013-08-15 09:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dd4a00c220c6

Added tag jdk8-b103 for changeset 76cfe7c61f25

! .hgtags

Changeset: f2ee3a4e7927
Author:cl
Date:  2013-08-22 09:10 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f2ee3a4e7927

Added tag jdk8-b104 for changeset dd4a00c220c6

! .hgtags

Changeset: b59a0b4675c9
Author:lana
Date:  2013-08-20 17:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b59a0b4675c9

Merge

- 
test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: 375834b5cf08
Author:lana
Date:  2013-08-23 14:17 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/375834b5cf08

Merge

- 
test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java

Changeset: 00ca54ceca1b
Author:lana
Date:  2013-08-26 14:54 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/00ca54ceca1b

Merge


Changeset: cc3fb73f5e08
Author:lana
Date:  2013-08-26 22:18 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc3fb73f5e08

Merge

hg: jdk8/tl/hotspot: 32 new changesets

Changeset: 0bbd1c775bef
Author:cl
Date:  2013-08-15 09:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0bbd1c775bef

Added tag jdk8-b103 for changeset 6f9be7f87b96

! .hgtags

Changeset: 39127bb12d32
Author:amurillo
Date:  2013-08-09 01:39 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39127bb12d32

8022688: new hotspot build - hs25-b46
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ca0165daa6ec
Author:sspitsyn
Date:  2013-08-06 16:33 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca0165daa6ec

7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments
Summary: Restore the appendix argument after PopFrame() call
Reviewed-by: twisti, coleenp
Contributed-by: serguei.spit...@oracle.com

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp

Changeset: c54a3122f9c8
Author:omajid
Date:  2013-08-06 12:28 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c54a3122f9c8

8022188: Make zero compile after 8016131 and 8016697
Reviewed-by: dholmes, twisti

! src/cpu/zero/vm/entryFrame_zero.hpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/stubGenerator_zero.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp

Changeset: 196aa14f9f29
Author:dholmes
Date:  2013-08-06 21:06 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/196aa14f9f29

Merge


Changeset: 195ff07bc7f6
Author:dsamersoff
Date:  2013-08-07 19:02 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/195ff07bc7f6

8021771: warning stat64 is deprecated - when building on OSX 10.7.5
Summary: stat64 have to be replaced with stat
Reviewed-by: dholmes, kmo
Contributed-by: rednaxel...@gmail.com

! src/os/bsd/vm/attachListener_bsd.cpp

Changeset: 31f3b1e1c5e5
Author:dcubed
Date:  2013-08-08 09:21 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31f3b1e1c5e5

8016601: Unable to build hsx24 on Windows using project creator and Visual 
Studio
Summary: ProjectCreator tool is modified to support two new options: 
'-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker 
errors. Also fixed some cmd line build linker warnings. Misc cleanups.
Reviewed-by: rdurbin, coleenp

! make/windows/create.bat
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/trace.make
! make/windows/makefiles/vm.make
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java

Changeset: c661fa2e5189
Author:iklam
Date:  2013-08-08 14:45 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c661fa2e5189

8022093: syntax error near umpiconninfo_t -- when building on Solaris 10
Summary: Added extra help message in make/solaris/makefiles/dtrace.make
Reviewed-by: dholmes, sspitsyn

! make/solaris/makefiles/dtrace.make

Changeset: 57ac7245594c
Author:minqi
Date:  2013-08-08 15:19 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57ac7245594c

8019583: [TESTBUG] runtime/7107135 always passes
Summary: If java test return none zero, the value will be override by 'if' 
statement, the exit value will always '0' and pass. Fix by recording the result 
in a variable.
Reviewed-by: coleenp, dholmes, iklam
Contributed-by: yumin...@oracle.com

! test/runtime/7107135/Test7107135.sh

Changeset: 6222a021d582
Author:minqi
Date:  2013-08-08 20:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6222a021d582

Merge


Changeset: 98aa538fd97e
Author:mikael
Date:  2013-08-09 09:51 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98aa538fd97e

8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2
Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor 
cleanup
Reviewed-by: coleenp, dsamersoff

! src/os/windows/vm/os_windows.cpp

Changeset: ed7c17e7d45b
Author:dcubed
Date:  2013-08-09 13:19 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed7c17e7d45b

Merge


Changeset: 7b03590c334b
Author:dcubed
Date:  2013-08-09 15:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b03590c334b

Merge


Changeset: bd0e82136b03
Author:iklam
Date:  2013-08-10 10:56 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd0e82136b03

8022740: Visual 2008 IDE build is broken
Summary: Fixed project generation code, and added warning to

hg: jdk8/tl/jdk: 23 new changesets