Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

[Erik Joelsson]

Build changes are looking pretty good. Just one thing that I would like 
to add. Since the executable jspawnhelper is linking in an object file 
from libjava, it would be good to declare that dependency. See unpack200 
for a similar situation.


$(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)

/Erik

On 2013-07-04 15:41, Rob McKenna wrote:

Hi Alan,

I've just uploaded the latest changes which rebase the fix to the 
current repo. (required post 8008118) I've also swapped out useFork 
for jdk.lang.Process.launchMechanism. (it affords us the flexibility 
to enable or disable other mechanisms on the various platforms at a 
later date) I have a couple of questions about this:


1) I'm thinking of including a unit test which will run through the 
various permutations across each platform making sure we fail when 
expected.


2) Should we simply ignore the flag on Windows or should we throw the 
same error if its provided?


cc'ing Erik for a build review.

http://cr.openjdk.java.net/~robm/5049299/webrev.04/

-Rob


On 02/07/13 16:41, Alan Bateman wrote:

On 23/12/2012 01:19, Rob McKenna wrote:

Hi Martin, thanks a lot for this.

I've renamed LINKFLAG to the more appropriate (and common) ARCHFLAG. 
It seems to pop up all around our source but if build-dev know of a 
better (or canonical) way of doing it I'll take it!


The BUILD_JEXEC differences don't show up in my webrev or hg diff, 
but I see them in the jdk.patch generated by webrev. I have no idea 
why this is. (I did use the JEXEC stuff as a template for the 
JSPAWNHELPER code, but I don't recall altering the JEXEC stuff in 
any way. It looks like its limited to indentation. Strange.)


W.r.t. useFork, I'll discuss this with Alan once he has a spare 
minute. I believe he may have had some concerns, but I'll let you 
know how that goes either way.


The only __APPLE__ should be to get the call to _NSGetEnviron(). 
Everything else should be bsd.


I've put a webrev at:

http://cr.openjdk.java.net/~robm/5049299/webrev.03/ 



I hope this addresses the rest of your comments.

-Rob
Rob - this was great work but I don't think we brought it to a 
conclusion. Are you planning to re-base the patch and send out a new 
webrev?


-Alan

Re: 7122142 : (ann) Race condition between isAnnotationPresent and getAnnotations

[Peter Levart]

On 07/04/2013 07:34 PM, Joel Borggrén-Franck wrote:

Also, can you please explain to me why the update race is safe. I have done 
the/some research myself but I would like to know which angles you have covered.

Well, one thing is that AnnotationType class is now effectively final, meaning that all 
it's state is referenced using final fields. If a reference to an instance of such class 
is obtained via data-race, all it's state is observed consistent by the thread that 
obtained the reference. The other thing is racy caching. If two or more threads are 
concurrently requesting AnnotationType for the same Class, many of them might construct 
and use it's own instance and the one published "latest" will finally be the 
one being cached. Since all such AnnotationType instances are constructed from the same 
input data, they are equivalent and it doesn't matter which one is used by which thread.


Actually they aren't, something have been bugging me and I finally figured it 
out today. The problem is with default valued elements. Previously all threads 
have been seeing the same instance of default values but now that will only be 
guaranteed for Classes, Strings and Integers inside the value cache. While I 
don't think it is in the spec that annotation default value instances should be 
== for all threads I don't think it is a race we should introduce. Given this I 
think you should use some approach to produce a winner that every thread will 
use (like in the other annotations patch). My gut feeling is that CASing in a 
result will be better under contention that the current lock solution (while 
also correct and deadlock free) for a net win.


Hi Joel,

Here's the 4th revision of the patch:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.04/

This one introduces CAS-ing of the AnnotationType instance into the 
Class.annotationType field so that there's only a single instance ever 
returned for a single Class. I also introduced new private static 
Class.Atomic nested class that is used to lazily initialize Unsafe 
machinery and to provide a safe wrapper for internal j.l.Class use. 
Previously this was part of ReflectionData nested class because it was 
only used for it's purpose. In anticipation to have a need for more 
atomic operations in the future, I moved this code to a separate class. 
ReflectionData is now just a record.


Regards, Peter

Re: RFR: JAXP 1.5 for JDK8/7u40: 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown

[Alan Bateman]

On 04/07/2013 21:25, huizhe wang wrote:


Reverted back to the original code: 
http://cr.openjdk.java.net/~joehw/jdk8/8016648/webrev/
The code split the version number and look at the 1st or 2nd element, 
it thus works for both the current format and the proposed one, e.g. 
for 1.7.0, it compares with the 2nd element, and for the proposed 
MAJOR.MINOR.FU.*, the 1st or MAJOR.
Thanks for dropping the dependency on javax.lang.model. What you now is 
probably okay although I'm a bit dubious about attempting to support an 
alternative format (I'm not aware of any proposal that changes the 
format of the java.version property as changing it would like cause a 
lot of breakage).


A minor point but isJDKOrAbove looks a bit odd to me, I'd probably go 
for something like isJavaVersionGTE or isJavaVersionAtLeast but as it's 
not part of the API then it doesn't matter of course.


I think I mentioned it a while back but have warnings emitted with 
System.err can be problematic (gets mixed up with application messages 
to stderr). I realize the Xerces code seems to do this in places but we 
really need to see about eliminating these messages or getting 
consistent logging into this code.



:

The last scenario to work on is if FSP is set on the Validator instead 
of SchemaFactory. With that, I'm looking at refactoring the way 
properties are represented so that they carry state. It would then be 
cleaner to pass them from SchemaFactory over to Schema and then 
Validator. It's a bit of work. Fortunately, we only have three of them 
to deal with.

So are you planning to send another webrev or do it as a separate issue?

-Alan

Re: RFR 8019484 Sync j.u.c.ConcurrentHashMap from 166 to tl

[Paul Sandoz]

A few bugs where found in CHM and fixed. I updated the webrev.

The diff can be viewed here:

  http://hg.openjdk.java.net/lambda/lambda/jdk/rev/291a872e1763

Paul.

On Jul 1, 2013, at 2:44 PM, Paul Sandoz  wrote:

> Hi,
> 
> The following is the final j.u.c patch that syncs CMH classes from 166 j.u.c 
> to tl.
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8019484-chm/webrev/
> 
> (i am sure there will be more patches to follow as tweaks are made to various 
> areas, but hopefully they will not need so bulky.)
> 
> ConcurrentMap.replaceAll in tl was more up to date than that in 166.
> 
> Quite tricky to review CHM since there is a fair bit of code shuffling due to:
> 
> 480  * This file is organized to make things a little easier to follow
> 481  * while reading than they might otherwise: First the main static
> 482  * declarations and utilities, then fields, then main public
> 483  * methods (with a few factorings of multiple public methods into
> 484  * internal ones), then sizing methods, trees, traversers, and
> 485  * bulk operations.
> 
> Paul.

Re: Possible HashMap update

[Paul Sandoz]

I played with these in the lambda repo. 

I needed to make the following additional change for things to compile:

--- a/src/share/classes/java/io/ExpiringCache.java  Fri Jul 05 10:04:00 
2013 +0200
+++ b/src/share/classes/java/io/ExpiringCache.java  Fri Jul 05 10:45:10 
2013 +0200
@@ -64,8 +64,8 @@
 @SuppressWarnings("serial")
 ExpiringCache(long millisUntilExpiration) {
 this.millisUntilExpiration = millisUntilExpiration;
-map = new LinkedHashMap() {
-protected boolean removeEldestEntry(Map.Entry 
eldest) {
+map = new LinkedHashMap() {
+protected boolean 
removeEldestEntry(Map.Entry eldest) {
   return size() > MAX_ENTRIES;
 }
   };

I don't quite know why, need to look in more detail.


Passes the stream tests and selected j.u tests.

The test java/util/Map/CheckRandomHashSeed needs updating, but i presume this 
test should be removed if similar updates are planed for WeakHashMap and 
Hashtable:

diff -r 291a872e1763 test/java/util/Map/CheckRandomHashSeed.java
--- a/test/java/util/Map/CheckRandomHashSeed.java   Fri Jul 05 10:04:00 
2013 +0200
+++ b/test/java/util/Map/CheckRandomHashSeed.java   Fri Jul 05 10:53:50 
2013 +0200
@@ -53,8 +53,6 @@
 throw new Error("Error in test setup: " + (expectRandom ? "" : 
"not " ) + "expecting random hashSeed, but " + PROP_NAME + " is " + (propSet ? 
"" : "not ") + "enabled");
 }
 
-testMap(new HashMap());
-testMap(new LinkedHashMap());
 testMap(new WeakHashMap());
 testMap(new Hashtable());
 }


Paul.

On Jul 4, 2013, at 12:55 AM, Doug Lea  wrote:

> 
> A few weeks ago, in the course of doing a (hopefully-last) reworking of
> JDK8 ConcurrentHashMap (CHM) internals based on experience with
> preview versions, I noticed that the balanced tree scheme now in place
> as a fallback in the case of usages with many keys all with the same
> hashCode could also be profitably used in other cases: CHM (like
> HashMap) previously performed some bit-scrambling of user hashCodes to
> make it less likely that user hashCodes that were non-identical but
> highly-non-random will collide in the same bins (thus with O(n) vs the
> expected O(1) performance).  This bit-scrambling is an
> anti-optimization in many usages that do not contain the kinds of
> systematic hashCode bias that most hurt performance.  While it is
> reasonably fast, it still places computation where you do not
> want it: in front of the likely cache-miss to access an entry. Plus,
> bit-scrambling is only statistically likely to help.  It is still
> possible to encounter hashCodes that systematically collide. It would
> be nice to provide O(log N) guarantees for these cases as well.
> 
> So, CHM now omits bit-scrambling (well, almost -- just a single xor to
> avoid losing impact of top bits), and instead rolls over into using
> trees for bins that contain a statistically unlikely number of keys,
> and rolling back into simple bin form if/when they don't due to
> deletions or resizings. ("Statistically unlikely" is a surprisingly
> low number. More than 8 nodes are expected only about once per ten
> million under perfectly random keys; this is also often (depending on
> cost of equals() methods, additional dispatch overhead, etc), around
> the break-even point for using trees vs lists).  The updated tree
> mechanics now provide O(log N) worst-case performance in either of two
> cases: (colliding non-identical-hashCodes), and (identical hashCodes
> but mutually Comparable keys). And does so while also speeding up by a
> little those typical usages that do not encounter systematic
> collisions.  Also, there is no sense at all in using any form of
> hashSeed in this scheme. It basically behaves the same whether or not
> you use one.
> 
> The overall impact appears to be a net win.  Non-heavily-colliding
> cases are a bit faster. Some colliding cases are a little slower and
> use more memory (tree-based nodes are bigger than plain ones), but
> have much better worst (and typical) case bounds unless people use
> crazily-bad keys that all have same hashCodes but are never equal or
> comparable to others, in which case treeification is wasted effort
> (but only by a constant factor of about 2 in both time and space).
> 
> This seemed to be enough of an improvement in terms of both worst-case
> and expected performance to try applying it to TreeBin-enabled
> HashMap. So I gave it a try. To enable bidirectional tree<->plain node
> conversion, I used the subclassing strategy mentioned during
> discussion of the initial balanced tree version. This in turn requires
> a completely different within-package internal API to allow
> LinkedHashMap to continue to subclass HashMap.  A couple of internal
> constructions exist solely to allow the same source code to be
> identical in HashMap and ConcurrenHashMap (but not the same compiled
> code, since the types they operate on are and

Re: 7122142 : (ann) Race condition between isAnnotationPresent and getAnnotations

[Peter Levart]

Hi Again,

Sorry, the 4th revision I posted is not rebased to the current tip of 
jdk8-tl so it contained some diffs that reverted some things.


Here's the correct patch:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/


Regards, Peter


On 07/05/2013 10:32 AM, Peter Levart wrote:

Hi Joel,

Here's the 4th revision of the patch:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.04/

This one introduces CAS-ing of the AnnotationType instance into the 
Class.annotationType field so that there's only a single instance ever 
returned for a single Class. I also introduced new private static 
Class.Atomic nested class that is used to lazily initialize Unsafe 
machinery and to provide a safe wrapper for internal j.l.Class use. 
Previously this was part of ReflectionData nested class because it was 
only used for it's purpose. In anticipation to have a need for more 
atomic operations in the future, I moved this code to a separate 
class. ReflectionData is now just a record.


Regards, Peter

hg: jdk8/tl/langtools: 5 new changesets

[maurizio . cimadamore]

Changeset: 7b756b307e12
Author:mcimadamore
Date:  2013-07-05 11:00 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7b756b307e12

8017618: NullPointerException in RichDiagnosticFormatter for bad input program
Summary: RDF crashes when diagnostic contains type 'void'
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/lambda/BadNestedLambda.java
+ test/tools/javac/lambda/BadNestedLambda.out

Changeset: 70b37cdb19d5
Author:mcimadamore
Date:  2013-07-05 11:02 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/70b37cdb19d5

8019480: Javac crashes when method is called on a type-variable receiver from 
lambda expression
Summary: Logic for shortcircuiting speculative attribution doesn't handle 
type-variable receivers
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/lambda/8019480/T8019480.java
+ test/tools/javac/lambda/8019480/T8019480.out

Changeset: b0386f0dc28e
Author:mcimadamore
Date:  2013-07-05 11:03 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0386f0dc28e

8016059: Cannot compile following lambda
8016060: Lambda isn't compiled with return statement
Summary: Spurious error triggered during unnecessary recovery round
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/lambda/TargetType75.java

Changeset: bfbedbfc522a
Author:mcimadamore
Date:  2013-07-05 11:04 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bfbedbfc522a

8016702: use of ternary operator in lambda expression gives incorrect results
Summary: Constant types erroneously creep in during inference
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/conditional/T8016702.java

Changeset: 42b3c5e92461
Author:mcimadamore
Date:  2013-07-05 11:05 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/42b3c5e92461

8019824: very long error messages on inference error
Summary: Inference error messages shows several spurious captured variables 
generated during an inference loop
Reviewed-by: jjg, vromero

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/generics/inference/8019824/T8019824.java
+ test/tools/javac/generics/inference/8019824/T8019824.out

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

[Ivan Gerasimov]

I'm looking at the log of the job you've run:
http://prt-web.us.oracle.com//archive/2013/07/2013-07-05-045326.ddaugher.8016838_exp/logs/linux_x64-product-c2-jdk_lang.log.FAILED.log

And it looks like both tests failed, not only the first one:

FAIL: Virtual memory usage increased by 1411072Kb (greater than 32768Kb)
FAIL: RedefineBigClassApp exited with status of 1
...
FAIL: Virtual memory usage increased by 1411072Kb (greater than 32768Kb)
FAIL: RetransformBigClassApp exited with status of 1


I have these two tests locally on 64-bit Linux and they both fail with similar 
results in logs.

I may not tell for sure why the tests didn't fail on 32-bit Linux.
Whether it was because the /proc/self/stat approach didn't work or 
because the leak is specific to 64-bit platform.


I have tested the RedefineBigClass test on JPRT with JDK6 (the code was 
a bit different, but the approach was the same).
The test passed with JDK6u60 and failed (as expected) with JDK6u51 on 
both 32 and 64-bit Linux machines.


I'm going to do more testings today.

Sincerely yours,
Ivan

On 05.07.2013 9:37, Daniel D. Daugherty wrote:

In a JPRT test job I just ran:

RedefineBigClass.sh passed on 9 platforms and failed on Linux 64-bit.
RetransformBigClass.sh passed on all 10 platforms.

Does your own testing only showing failure on the Linux 64-bit VM
and passed on the Linux 32-bit VM?

Dan



On 7/4/13 10:35 PM, Daniel D. Daugherty wrote:

Ivan,

The changes look fine, I can sponsor your commit, looks like your
OpenJDK user name is 'igerasim', but I need to know a little bit
more about your testing of these fixes. Did you do a test JPRT
job to run the JLI tests (or just the two tests themselves)?

Based on e-mail about this bug fix, I believe you've found a new
leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh.
That's a good thing, but I think Alan and company would be a bit
grumpy with me if I pushed a test that failed as soon as someone
ran it. :-) Do you know if the revised RetransformBigClass.sh also
finds a new memory leak in JDK8/HSX-25?

The way to deal with that is to put the test on the Problem.list
as part of the same changeset. However, the T&L folks might not like
that either...

Dan


On 7/4/13 6:59 PM, Ivan Gerasimov wrote:

Thank you, Daniel!

Please find an updated webrev at 
http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/.
It now includes the RetransformBigClass test modified in the same 
way as RedefineBigClass
If the changes look fine, may I ask you to sponsor the commit, as 
I'm not a committer?

Here's a link to hg export:
http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch 



Thanks in advance,
Ivan

On 04.07.2013 21:45, Daniel D. Daugherty wrote:

On 7/4/13 11:19 AM, Ivan Gerasimov wrote:

Daniel, thank you for review!

Here's the updated with all all your suggestions adopted.
http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/


Looks good.




I haven't yet considered applying the approach to 
RetransformBigClass.
Do you want me to include this into this same change set or should 
I make it separately?


I would include it in the same changeset.

Dan




Sincerely yours,
Ivan


On 04.07.2013 19:34, Daniel D. Daugherty wrote:

On 7/3/13 11:12 AM, Ivan Gerasimov wrote:

Hello everybody!

We have a request to improve jtreg test.
The test had been written to verify fix for memory leak during 
class redefinition.
The problem is that it always is reported as PASSED even in the 
presence of the leak.


The proposed change is platform specific.
It allows memory leak detection only on Linux.
This is because the memory leak was in native code, so there's 
no easy way to detect it from within Java code.


Here's the webrev for JDK8 repository:
http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/


Very nicely done! The logic in RedefineBigClass.sh only catches a
leak big enough to cause an Exception to be thrown.

When I originally wrote this test and its companion:

test/java/lang/instrument/RetransformBigClass*

I could not come up with a platform independent way to put a small
upper limit on memory growth. It never dawned on me that putting in
something on one platform (Linux) was better than nothing.

Are you planning to add this same logic to RetransformBigClass*?



test/java/lang/instrument/RedefineBigClass.sh
No comments.

test/java/lang/instrument/RedefineBigClassApp.java
line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb
Would be better at the top of RedefineBigClassApp rather 
than

"buried" down here.

line 51: Long.valueOf(vmMemDelta)
There are several places where a long is passed to 
Long.valueOf().
Is there some reason you're not passing them directly to 
println()?


line 54: } else {
The "else" is redundant due to the "System.exit(1)" call 
above it.
You can drop the "else {" and "}" and shift that last 
println() to

the left.

line 71: return Long.pa

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

[Ivan Gerasimov]

On 05.07.2013 8:35, Daniel D. Daugherty wrote:

Ivan,

The changes look fine, I can sponsor your commit, looks like your
OpenJDK user name is 'igerasim', but I need to know a little bit
more about your testing of these fixes. Did you do a test JPRT
job to run the JLI tests (or just the two tests themselves)?

I've only run test from java/lang/instrument when checked the change 
with JDK6u60 (all passed) and with JDK6u51 (the test failed as expected, 
since the leak had still been there.)



Based on e-mail about this bug fix, I believe you've found a new
leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh.

Right. The test shown a memleak with the the latest jdk8.
I filed a bug 8019845 about this leak.
Stefan Karlsson guessed that this may be related to 8003419 (NPG: Clean 
up metadata created during class loading if failure)
Then I've checked the builds b57 (test failed) and b58 (test passed), so 
I confirmed that it may be the reason of the leak being observed now.

But now I think that the reason may be different.
It just turns out that the test shows failures for (at least) three 
different leaks - the one you, Daniel, solved (7121600), the one Stefan 
wrote about (8003419) and the one currently observed (8019845).



That's a good thing, but I think Alan and company would be a bit
grumpy with me if I pushed a test that failed as soon as someone
ran it. :-) Do you know if the revised RetransformBigClass.sh also
finds a new memory leak in JDK8/HSX-25?

The way to deal with that is to put the test on the Problem.list
as part of the same changeset. However, the T&L folks might not like
that either...


Well, the leak is there, and why not have a failing test as a reminder 
to have it fixed?


Sincerely yours,
Ivan Gerasimov



Dan


On 7/4/13 6:59 PM, Ivan Gerasimov wrote:

Thank you, Daniel!

Please find an updated webrev at 
http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/.
It now includes the RetransformBigClass test modified in the same way 
as RedefineBigClass
If the changes look fine, may I ask you to sponsor the commit, as I'm 
not a committer?

Here's a link to hg export:
http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch 



Thanks in advance,
Ivan

On 04.07.2013 21:45, Daniel D. Daugherty wrote:

On 7/4/13 11:19 AM, Ivan Gerasimov wrote:

Daniel, thank you for review!

Here's the updated with all all your suggestions adopted.
http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/


Looks good.




I haven't yet considered applying the approach to RetransformBigClass.
Do you want me to include this into this same change set or should 
I make it separately?


I would include it in the same changeset.

Dan




Sincerely yours,
Ivan


On 04.07.2013 19:34, Daniel D. Daugherty wrote:

On 7/3/13 11:12 AM, Ivan Gerasimov wrote:

Hello everybody!

We have a request to improve jtreg test.
The test had been written to verify fix for memory leak during 
class redefinition.
The problem is that it always is reported as PASSED even in the 
presence of the leak.


The proposed change is platform specific.
It allows memory leak detection only on Linux.
This is because the memory leak was in native code, so there's no 
easy way to detect it from within Java code.


Here's the webrev for JDK8 repository:
http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/


Very nicely done! The logic in RedefineBigClass.sh only catches a
leak big enough to cause an Exception to be thrown.

When I originally wrote this test and its companion:

test/java/lang/instrument/RetransformBigClass*

I could not come up with a platform independent way to put a small
upper limit on memory growth. It never dawned on me that putting in
something on one platform (Linux) was better than nothing.

Are you planning to add this same logic to RetransformBigClass*?



test/java/lang/instrument/RedefineBigClass.sh
No comments.

test/java/lang/instrument/RedefineBigClassApp.java
line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb
Would be better at the top of RedefineBigClassApp rather than
"buried" down here.

line 51: Long.valueOf(vmMemDelta)
There are several places where a long is passed to 
Long.valueOf().
Is there some reason you're not passing them directly to 
println()?


line 54: } else {
The "else" is redundant due to the "System.exit(1)" call 
above it.
You can drop the "else {" and "}" and shift that last 
println() to

the left.

line 71: return Long.parseLong(line.split(" ")[22]) / 1024;
How about at least a comment referring to the Linux proc(5)
man page... and the fact that the 23rd field is:

vsize %lu   Virtual memory size in bytes.

Again, very nicely done!

Dan




The surprising thing is that modified test detected the leak with 
the latest JDK8!

Latest 6 and 7 are fine, so it might be regression in JDK8.

I've filled a bug http://bugs.sun.com/view_bug.d

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

[Seán Coffey]

Nice work indeed Ivan. Good to have a reliable testcase to catch leaks 
in this area.


I'd also suggest that this test goes on the ProblemList until the new 
leak is sorted out for jdk8. The goal of JPRT runs is to have clean 
runs.  If it's on the problemList, then it's a known issue and is 
normally tagged with the relevant bug ID so that the responsible 
engineer knows the current state.


regards,
Sean.

On 05/07/2013 11:53, Ivan Gerasimov wrote:


On 05.07.2013 8:35, Daniel D. Daugherty wrote:

Ivan,

The changes look fine, I can sponsor your commit, looks like your
OpenJDK user name is 'igerasim', but I need to know a little bit
more about your testing of these fixes. Did you do a test JPRT
job to run the JLI tests (or just the two tests themselves)?

I've only run test from java/lang/instrument when checked the change 
with JDK6u60 (all passed) and with JDK6u51 (the test failed as 
expected, since the leak had still been there.)



Based on e-mail about this bug fix, I believe you've found a new
leak in JDK8/HSX-25 with test java/lang/instrument/RedefineBigClass.sh.

Right. The test shown a memleak with the the latest jdk8.
I filed a bug 8019845 about this leak.
Stefan Karlsson guessed that this may be related to 8003419 (NPG: 
Clean up metadata created during class loading if failure)
Then I've checked the builds b57 (test failed) and b58 (test passed), 
so I confirmed that it may be the reason of the leak being observed now.

But now I think that the reason may be different.
It just turns out that the test shows failures for (at least) three 
different leaks - the one you, Daniel, solved (7121600), the one 
Stefan wrote about (8003419) and the one currently observed (8019845).



That's a good thing, but I think Alan and company would be a bit
grumpy with me if I pushed a test that failed as soon as someone
ran it. :-) Do you know if the revised RetransformBigClass.sh also
finds a new memory leak in JDK8/HSX-25?

The way to deal with that is to put the test on the Problem.list
as part of the same changeset. However, the T&L folks might not like
that either...


Well, the leak is there, and why not have a failing test as a reminder 
to have it fixed?


Sincerely yours,
Ivan Gerasimov



Dan


On 7/4/13 6:59 PM, Ivan Gerasimov wrote:

Thank you, Daniel!

Please find an updated webrev at 
http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/.
It now includes the RetransformBigClass test modified in the same 
way as RedefineBigClass
If the changes look fine, may I ask you to sponsor the commit, as 
I'm not a committer?

Here's a link to hg export:
http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch 



Thanks in advance,
Ivan

On 04.07.2013 21:45, Daniel D. Daugherty wrote:

On 7/4/13 11:19 AM, Ivan Gerasimov wrote:

Daniel, thank you for review!

Here's the updated with all all your suggestions adopted.
http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/


Looks good.




I haven't yet considered applying the approach to 
RetransformBigClass.
Do you want me to include this into this same change set or should 
I make it separately?


I would include it in the same changeset.

Dan




Sincerely yours,
Ivan


On 04.07.2013 19:34, Daniel D. Daugherty wrote:

On 7/3/13 11:12 AM, Ivan Gerasimov wrote:

Hello everybody!

We have a request to improve jtreg test.
The test had been written to verify fix for memory leak during 
class redefinition.
The problem is that it always is reported as PASSED even in the 
presence of the leak.


The proposed change is platform specific.
It allows memory leak detection only on Linux.
This is because the memory leak was in native code, so there's 
no easy way to detect it from within Java code.


Here's the webrev for JDK8 repository:
http://cr.openjdk.java.net/~igerasim/8016838/0/webrev/


Very nicely done! The logic in RedefineBigClass.sh only catches a
leak big enough to cause an Exception to be thrown.

When I originally wrote this test and its companion:

test/java/lang/instrument/RetransformBigClass*

I could not come up with a platform independent way to put a small
upper limit on memory growth. It never dawned on me that putting in
something on one platform (Linux) was better than nothing.

Are you planning to add this same logic to RetransformBigClass*?



test/java/lang/instrument/RedefineBigClass.sh
No comments.

test/java/lang/instrument/RedefineBigClassApp.java
line 48: final long MEM_LEAK_THRESHOLD = 32 * 1024; // 32Mb
Would be better at the top of RedefineBigClassApp rather 
than

"buried" down here.

line 51: Long.valueOf(vmMemDelta)
There are several places where a long is passed to 
Long.valueOf().
Is there some reason you're not passing them directly to 
println()?


line 54: } else {
The "else" is redundant due to the "System.exit(1)" call 
above it.
You can drop the "else {" and "}" and shift that last 
println() to

the left.

line 71: r

patch: 6646588 : OutputStream.write() IndexOutOfBoundsException condition could be simplified

[Dmytro Sheyko]

Hello,

I would like propose a patch for bug #6646588
OutputStream.write() IndexOutOfBoundsException condition could be simplified
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6646588


1. Range check logic is moved from various streams/readers/writers to 
IndexOutOfBoundsException.
I.e. I replaced code like this
    if ((off < 0) || (off> b.length) || (len < 0) ||
    ((off + len)> b.length) || ((off + len) < 0)) {
    throw new IndexOutOfBoundsException();
    }
with following
    IndexOutOfBoundsException.checkBounds(b, off, len);

2. Additionally in several places I replaced
    if (b == null) {
    throw new NullPointerException()
    }
with
    Objects.requireNotNull(b);
Note that for method InflaterOutputStream.write() I changed NPE message from 
"Null buffer for read" to more correct (in my opinion) "Null buffer for write". 
It seems that this message with surrounding code was just copy-pasted from 
DeflaterInputStream.read().

3. In PushbackReader I removed
    } catch (ArrayIndexOfBoundsException e) {
    throw new IndexOfBoundsException();
    }
I believe this catch is unnecessary because (a) range is already checked above 
and System.arraycopy should not fail and (b) ArrayIndexOfBoundsException is 
subclass of IndexOfBoundsException, so even if AIOBE happens there is nothing 
wrong to let it go farther.

Thus many trivial changes are made in following packages:
java.io.*
java.util.zip.*
sun.**

jtreg test for IndexOutOfBoundsException.checkBounds(...) is also attached.

Please review.

Regards,
Dmytro

Re: 7122142 : (ann) Race condition between isAnnotationPresent and getAnnotations

[Joel Borggrén-Franck]

Hi Peter,

Thanks for the quick update!

While I have looked over the changes to j.l.Class and the cas in AnnotationType 
I don't think I'm qualified to review that. (FWIW it looked fine to me but my 
jmm isn't swapped in at the moment so I won't pretend to know the interactions 
between volatile and Unsafe cas). Thinking out loud I suppose we can assume a 
stable offset of fields in Class, and I realize that part has been under review 
before.

The rest of AnnotationType, AnnotationParser and the tests look fine though. I 
also ran the tests before and after the change and results were as expected.

Since I'm not a Reviewer kind of reviewer you need to get one those to sign off 
but after that I think you are good to go. I can sponsor this as well if Alan 
is busy.

cheers
/Joel

On 5 jul 2013, at 11:12, Peter Levart  wrote:

> Hi Again,
> 
> Sorry, the 4th revision I posted is not rebased to the current tip of jdk8-tl 
> so it contained some diffs that reverted some things.
> 
> Here's the correct patch:
> 
> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/
> 
> 
> Regards, Peter
> 
> 
> On 07/05/2013 10:32 AM, Peter Levart wrote:
>> Hi Joel,
>> 
>> Here's the 4th revision of the patch:
>> 
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.04/
>> 
>> This one introduces CAS-ing of the AnnotationType instance into the 
>> Class.annotationType field so that there's only a single instance ever 
>> returned for a single Class. I also introduced new private static 
>> Class.Atomic nested class that is used to lazily initialize Unsafe machinery 
>> and to provide a safe wrapper for internal j.l.Class use. Previously this 
>> was part of ReflectionData nested class because it was only used for it's 
>> purpose. In anticipation to have a need for more atomic operations in the 
>> future, I moved this code to a separate class. ReflectionData is now just a 
>> record.
>> 
>> Regards, Peter
> 

Re: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace

[Erik Helin]

Hi all,

still looking for a review for this testfix. Looping in
hotspot-gc-...@openjdk.java.net as well.

Thanks,
Erik

On 2013-07-01, Erik Helin wrote:
> Hi all,
> 
> this change updates MemoryTest.java to take the newly added Metaspace
> and Compressed Class Space MemoryMXBeans into account, as well as the
> new Metaspace Memory Manager.
> 
> This change also removes the following two tests from ProblemList.txt
> since they are now passing again:
> -java/lang/management/MemoryMXBean/MemoryTestAllGC.sh generic-all
> -java/lang/management/MemoryMXBean/MemoryTest.java generic-all
> 
> Webrev: http://cr.openjdk.java.net/~ehelin/8010734/webrev.00/
> 
> Thanks,
> Erik

Re: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace

[Alan Bateman]

On 05/07/2013 15:08, Erik Helin wrote:

Hi all,

still looking for a review for this testfix. Looping in
hotspot-gc-...@openjdk.java.net as well.

It looks like okay to me and the comments make it clear the memory pools 
that it expects.


-Alan

RFR 8017447 Unmodifiable map entry becomes modifiable if taken from a stream of map entries

[Paul Sandoz]

Hi,

Please review a patch that fixes traversal of unmodifiable map entry set where 
entries could be set:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8017447-unmod-map/webrev/jdk.patch

This covers forEach, spliterator (splitting, tryAdvance, forEachRemaining), 
iterator forEachRemaining, stream/parallelStream forEach with instances of Map 
and SortedMap.

Note that there are other changes which will follow later on to Collections 
that update implementations with stream/parallelStream methods

Paul.

hg: jdk8/tl/jdk: 2 new changesets

[sean . mullan]

Changeset: 028ef97797c1
Author:mullan
Date:  2013-07-05 15:54 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/028ef97797c1

8011547: Update XML Signature implementation to Apache Santuario 1.5.4
Reviewed-by: xuelei

! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/Algorithm.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithmSpi.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizationException.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/InvalidCanonicalizerException.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/C14nHelper.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_OmitComments.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_WithComments.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclOmitComments.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclWithComments.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315OmitComments.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315WithComments.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java
+ 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerPhysical.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java
+ 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherData.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherValue.java
+ 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/DocumentSerializer.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedData.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedKey.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedType.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java
+ 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Serializer.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Transforms.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherInput.java
! 
src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherParameters.java
! 
src/share/classes/com/sun/org/apache/xml/internal/s

RFR: 8015317: Optional.filter, map, and flatMap

[Henry Jen]

Hi,

Please review the webrev at

http://cr.openjdk.java.net/~henryjen/ccc/8015317.0/webrev/

Which adds following method to Optional,

public static  Optional ofNullable(T value) {}
public Optional filter(Predicate predicate) {}
public Optional map(Function mapper) {}
public Optional flatMap(Function>
mapper) {}

Also included is some cleanup on javadoc.

Cheers,
Henry

hg: jdk8/tl/nashorn: 2 new changesets

[lana . steuck]

Changeset: da63a99481da
Author:cl
Date:  2013-07-04 01:01 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/da63a99481da

Added tag jdk8-b97 for changeset 1bf1d6ce3042

! .hgtags

Changeset: 542b7803f038
Author:lana
Date:  2013-07-05 11:05 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/542b7803f038

Merge

hg: jdk8/tl/langtools: 3 new changesets

[lana . steuck]

Changeset: 2364e94ae67b
Author:cl
Date:  2013-07-04 01:01 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2364e94ae67b

Added tag jdk8-b97 for changeset 6a11a81a8824

! .hgtags

Changeset: ce5a90df517b
Author:lana
Date:  2013-07-05 11:06 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ce5a90df517b

Merge


Changeset: 49654c9c705b
Author:lana
Date:  2013-07-05 13:29 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/49654c9c705b

Merge

hg: jdk8/tl/jaxp: 3 new changesets

[lana . steuck]

Changeset: c96691d84a7c
Author:katleman
Date:  2013-06-28 16:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c96691d84a7c

8019347: JDK8 b96 source with GPL header errors
Reviewed-by: iris, alanb, lancea

! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
! 
src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
! src/com

hg: jdk8/tl/jaxws: Added tag jdk8-b97 for changeset dcde7f049111

[lana . steuck]

Changeset: b1fb4612a2ca
Author:cl
Date:  2013-07-04 01:00 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b1fb4612a2ca

Added tag jdk8-b97 for changeset dcde7f049111

! .hgtags

hg: jdk8/tl/corba: Added tag jdk8-b97 for changeset 469995a8e974

[lana . steuck]

Changeset: 3370fb6146e4
Author:cl
Date:  2013-07-04 01:00 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/3370fb6146e4

Added tag jdk8-b97 for changeset 469995a8e974

! .hgtags

hg: jdk8/tl/hotspot: 26 new changesets

[lana . steuck]

Changeset: fc8a1a5de78e
Author:amurillo
Date:  2013-06-21 00:59 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fc8a1a5de78e

8017253: new hotspot build - hs25-b39
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 91acb82a8b7a
Author:dholmes
Date:  2013-06-19 13:14 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91acb82a8b7a

8014326: [OSX] All libjvm symbols are exported
Summary: Add support for a MacOS X compatible form of the libjvm mapfile.
Reviewed-by: dcubed, rdurbin, coleenp

! make/bsd/makefiles/build_vm_def.sh
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/mapfile-vers-debug
! make/bsd/makefiles/mapfile-vers-product

Changeset: b9f4c4ec0f50
Author:iklam
Date:  2013-06-19 20:51 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9f4c4ec0f50

8008964: NPG: Memory regression: Thread::_metadata_handles uses 1 KB per thread.
Summary: Reduce default size of Thread::_metadata_handles from 300 to 30
Reviewed-by: coleenp, sspitsyn

! src/share/vm/runtime/thread.cpp

Changeset: b3cd8b58b798
Author:mgronlun
Date:  2013-06-20 11:53 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b3cd8b58b798

8016735: Remove superfluous EnableInvokeDynamic warning from 
UnlockDiagnosticVMOptions check
Reviewed-by: sla, dholmes

! src/share/vm/runtime/globals.cpp

Changeset: 9ba41a4a71ff
Author:coleenp
Date:  2013-06-21 10:50 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ba41a4a71ff

8004124: Handle and/or warn about SI_KERNEL
Summary: Detect this crash in the signal handler and give a fatal error message 
instead of making us chase down bugs that don't reproduce
Reviewed-by: kvn, mgerdin, dholmes

! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: bed34a7a3b9b
Author:coleenp
Date:  2013-06-21 10:57 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bed34a7a3b9b

8017177: more explicit code location information in hs_err crash log
Summary: Add code pc location for compiled code
Reviewed-by: kvn, coleenp
Contributed-by: doug.si...@oracle.com

! src/share/vm/runtime/frame.cpp

Changeset: bb6c7f2f10fd
Author:dcubed
Date:  2013-06-21 08:18 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bb6c7f2f10fd

Merge


Changeset: b7bc7c94b4b5
Author:dcubed
Date:  2013-06-21 10:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7bc7c94b4b5

Merge

- src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp
- src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp

Changeset: d9eed26d638a
Author:iklam
Date:  2013-06-23 22:08 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d9eed26d638a

8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes
Summary: Added Atomic::inc(short*) to support this change.
Reviewed-by: coleenp, dcubed, dholmes, minqi

! src/share/vm/oops/symbol.cpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/runtime/atomic.cpp
! src/share/vm/runtime/atomic.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: e0c9a1d29eb4
Author:coleenp
Date:  2013-06-24 18:55 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0c9a1d29eb4

8016325: JVM hangs verifying system dictionary
Summary: Minimize redundant verifications of Klasses.
Reviewed-by: hseigel, jmasa

! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/code/debugInfo.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/compiledICHolder.cpp
! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/shark/sharkBuilder.cpp

Changeset: 01e10b366055
Author:sla
Date:  2013-06-25 14:11 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01e10b366055

8017561: Build errors caused by missing .PHONY
Reviewed-by: stefank, brutisso

! make/excludeSrc.make

Changeset: feae15578b2f
Author:tamao
Date:  2013-06-07 09:46 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/feae15578b2f

712: GC log is limited to 2G for 32-bit
Summary: Enable large file support for generated 32-bit ostream.o on Linux and 
Solaris (as only the two need this) by setting -D_FILE_OFFSET_BITS=64 in 
compilation
Reviewed-by: tbell, mgerdin, dcubed
Contributed-by: tamao 

! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! src/os/solaris/vm/os_

hg: jdk8/tl: 9 new changesets

[lana . steuck]

Changeset: f5eb23490e6a
Author:erikj
Date:  2013-06-27 09:27 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/f5eb23490e6a

8017047: Can't use --with-java-devtools and --with-devkit at the same time
Reviewed-by: tbell

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: e5cf1735638c
Author:erikj
Date:  2013-06-28 11:55 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/e5cf1735638c

8016605: New files dont apear in src.zip
Reviewed-by: tbell

! common/makefiles/JavaCompilation.gmk

Changeset: 0871b5799149
Author:erikj
Date:  2013-06-28 11:58 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/0871b5799149

8019229: Build Configuration Fail in Windows Platform
Reviewed-by: chegar, tbell, dxu

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: 0e533ceee717
Author:erikj
Date:  2013-06-28 12:00 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/0e533ceee717

8016303: make CONF= isn't working
Reviewed-by: tbell

! NewMakefile.gmk

Changeset: 78aaf5d3314d
Author:erikj
Date:  2013-06-28 12:02 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/78aaf5d3314d

8010385: build with LOG=trace broken on mac
Reviewed-by: dholmes, tbell, prr

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/MakeBase.gmk

Changeset: dd3b314f4471
Author:erikj
Date:  2013-07-01 15:40 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/dd3b314f4471

8009744: build-infra: REGRESSION: Publisher was NOT set for some JDK files
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: b2b87e9e8683
Author:erikj
Date:  2013-07-02 15:07 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/b2b87e9e8683

8019537: jdk8-build prebuild fails in source bundle generation, The path of 
TOOLS_DIR ... is not found
Reviewed-by: tbell

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh

Changeset: a1c1e8bf71f3
Author:katleman
Date:  2013-07-02 15:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/a1c1e8bf71f3

Merge


Changeset: 99ad803f8c4e
Author:cl
Date:  2013-07-04 01:00 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/99ad803f8c4e

Added tag jdk8-b97 for changeset a1c1e8bf71f3

! .hgtags

hg: jdk8/tl/jdk: 20 new changesets

[lana . steuck]

Changeset: 8339c83b16c6
Author:ehelin
Date:  2013-07-02 13:06 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8339c83b16c6

8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration
Reviewed-by: erikj, alanb

! test/ProblemList.txt

Changeset: 87cab043cb5e
Author:katleman
Date:  2013-06-28 16:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87cab043cb5e

8019347: JDK8 b96 source with GPL header errors
Reviewed-by: iris, alanb, lancea

! makefiles/sun/awt/ToBin.java
! src/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java
! test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java
! test/java/lang/ThreadGroup/Suspend.java

Changeset: 978a95239044
Author:katleman
Date:  2013-07-02 15:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/978a95239044

Merge


Changeset: 4b21dcfdcc3b
Author:cl
Date:  2013-07-04 01:00 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b21dcfdcc3b

Added tag jdk8-b97 for changeset 978a95239044

! .hgtags

Changeset: 5cfcd545ce4a
Author:vadim
Date:  2013-06-26 13:49 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5cfcd545ce4a

8016254: several sun/java2d/OpenGL tests failed with SIGFPE
Reviewed-by: prr, bae

! src/share/native/sun/java2d/opengl/OGLContext.c

Changeset: 3ffa38871143
Author:lana
Date:  2013-06-28 19:37 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ffa38871143

Merge

- make/sun/xawt/ToBin.java
- makefiles/sun/awt/X11/ToBin.java
- src/share/classes/sun/misc/FDBigInt.java
- src/share/classes/sun/misc/Hashing.java
- src/solaris/classes/sun/awt/X11/XIconInfo.java
- src/solaris/classes/sun/awt/X11/security-icon-bw16.png
- src/solaris/classes/sun/awt/X11/security-icon-bw24.png
- src/solaris/classes/sun/awt/X11/security-icon-bw32.png
- src/solaris/classes/sun/awt/X11/security-icon-bw48.png
- src/solaris/classes/sun/awt/X11/security-icon-interim16.png
- src/solaris/classes/sun/awt/X11/security-icon-interim24.png
- src/solaris/classes/sun/awt/X11/security-icon-interim32.png
- src/solaris/classes/sun/awt/X11/security-icon-interim48.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow16.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow24.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow32.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow48.png
- test/java/lang/invoke/7196190/MHProxyTest.java
- test/sun/misc/Hashing.java

Changeset: 6dda4a069a83
Author:prr
Date:  2013-07-01 12:39 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6dda4a069a83

8015144: Performance regression in ICU OpenType Layout library
Reviewed-by: srl, jgodinez

! make/sun/font/Makefile
! makefiles/CompileNativeLibraries.gmk
! src/share/native/sun/font/layout/GlyphIterator.cpp
! src/share/native/sun/font/layout/GlyphIterator.h
! src/share/native/sun/font/layout/LETableReference.h
! src/share/native/sun/font/layout/OpenTypeUtilities.cpp

Changeset: 6d2b5ec2ec79
Author:prr
Date:  2013-07-02 14:25 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d2b5ec2ec79

8019692: JDK build CC_OPT_HIGHEST setting isn't valid for Sun C++ compiler
Reviewed-by: jgodinez

! make/sun/font/Makefile
! makefiles/CompileNativeLibraries.gmk

Changeset: 1c607ebfc180
Author:leonidr
Date:  2013-06-20 18:50 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c607ebfc180

8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in 
java console once click drop-down check box.
Reviewed-by: art, anthony, serb

! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XChoicePeer.java
! src/solaris/classes/sun/awt/X11/XListPeer.java

Changeset: b7b95b7ab2cb
Author:malenkov
Date:  2013-06-21 17:13 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7b95b7ab2cb

8016545: java.beans.XMLEncoder.writeObject output is wrong
Reviewed-by: alexsch

! src/share/classes/java/beans/XMLEncoder.java
+ test/java/beans/XMLEncoder/Test8016545.java

Changeset: eed321190272
Author:alitvinov
Date:  2013-06-21 21:30 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eed321190272

8007642: Media Names on Java Print Do Not Match the Printer’s and Confuse 
Users
Reviewed-by: prr, jgodinez

! src/windows/classes/sun/print/Win32PrintService.java

Changeset: e5bac76282f7
Author:pchelko
Date:  2013-06-27 13:56 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5bac76282f7

8019236: [macosx] Add javadoc to the handleWindowFocusEvent in CEmbeddedFrame
Reviewed-by: serb, ant

! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java

Changeset: 72f167edf630
Author:dmarkov
Date:  2013-06-28 18:32 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72f167edf630

8016534: javax/swing/text/View/8014863/bug8014863.java failed
Reviewed-by: alexp, alexsch

! test/javax/swing/text/View/8014863/bug8014863.java

Changese

RFR: 8015318: Extend Collector with 'finish' operation

[Henry Jen]

Hi,

Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8015318.0/webrev/

This webrev refactor java.util.Collector interface to allow an
intermediate type used for accumulation and then produce final result
type with a 'finished' function.

Collectors are updated to reflect the changes, and quite a few API changes,

toStringJoiner -> joining
Return type becoming Optional when appropriate
sumBy -> a set of summing[Int,Long,Double]
average[Int,Long,Double]

I'll put specdiff up later for those interested in API changes.

Cheers,
Henry

Re: RFR: 8015318: Extend Collector with 'finish' operation

[Henry Jen]

Forgot to mention this patch depends on fix of bug 8012238[1], to enable
compile without fix, attached patch will help.

[1] http://bugs.sun.com/view_bug.do?bug_id=8012238

Cheers,
Henry


On 07/05/2013 05:11 PM, Henry Jen wrote:
> Hi,
> 
> Please review the webrev at
> http://cr.openjdk.java.net/~henryjen/ccc/8015318.0/webrev/
> 
> This webrev refactor java.util.Collector interface to allow an
> intermediate type used for accumulation and then produce final result
> type with a 'finished' function.
> 
> Collectors are updated to reflect the changes, and quite a few API changes,
> 
> toStringJoiner -> joining
> Return type becoming Optional when appropriate
> sumBy -> a set of summing[Int,Long,Double]
> average[Int,Long,Double]
> 
> I'll put specdiff up later for those interested in API changes.
> 
> Cheers,
> Henry
> 

hg: jdk8/tl/jdk: 8019341: Update CookieHttpsClientTest to use the newer framework.

[bradford . wetmore]

Changeset: 11c15607e43f
Author:wetmore
Date:  2013-07-05 18:22 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11c15607e43f

8019341: Update CookieHttpsClientTest to use the newer framework.
Reviewed-by: xuelei, smarks, michaelm

! 
test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java
! test/sun/security/ssl/templates/SSLEngineTemplate.java
! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java
! test/sun/security/ssl/templates/SSLSocketTemplate.java

Re: RFR: JAXP 1.5 for JDK8/7u40: 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown

[huizhe wang]

On 7/5/2013 1:32 AM, Alan Bateman wrote:

On 04/07/2013 21:25, huizhe wang wrote:


Reverted back to the original code: 
http://cr.openjdk.java.net/~joehw/jdk8/8016648/webrev/
The code split the version number and look at the 1st or 2nd element, 
it thus works for both the current format and the proposed one, e.g. 
for 1.7.0, it compares with the 2nd element, and for the proposed 
MAJOR.MINOR.FU.*, the 1st or MAJOR.
Thanks for dropping the dependency on javax.lang.model. What you now 
is probably okay although I'm a bit dubious about attempting to 
support an alternative format (I'm not aware of any proposal that 
changes the format of the java.version property as changing it would 
like cause a lot of breakage).


There was a survey from Iris last year, and the JPG site has a 
presentation from Aurelio. But you're right, I'll remove it. If there's 
any change in the future, that is if it happens at all, we can always 
add that back.


A minor point but isJDKOrAbove looks a bit odd to me, I'd probably go 
for something like isJavaVersionGTE or isJavaVersionAtLeast but as 
it's not part of the API then it doesn't matter of course.


isJavaVersionAtLeast is easy to understand. What does GTE stand for?



I think I mentioned it a while back but have warnings emitted with 
System.err can be problematic (gets mixed up with application messages 
to stderr). I realize the Xerces code seems to do this in places but 
we really need to see about eliminating these messages or getting 
consistent logging into this code.


I agree, this one is not particularly graceful. There were 88 matches of 
System.err in Xalan and 75 in Xerces, although some I believe are used 
for debugging. It could take quite some effort.


I mentioned that with a standalone release, we were trying to stay away 
from new JDK features. It's probably better to spend time/effort on some 
upgrades.





:

The last scenario to work on is if FSP is set on the Validator 
instead of SchemaFactory. With that, I'm looking at refactoring the 
way properties are represented so that they carry state. It would 
then be cleaner to pass them from SchemaFactory over to Schema and 
then Validator. It's a bit of work. Fortunately, we only have three 
of them to deal with.

So are you planning to send another webrev or do it as a separate issue?


Looking at affected code by this change, it doesn't seem to be too bad. 
I'll send another webrev.


Joe



-Alan