[Fwd: Missing merge for 8014890: Reference queues may return more entries than expected]
Hi all, could somebody take care of the missing merge for the fix below? Thanks, Thomas Forwarded Message From: Thomas Schatzl thomas.scha...@oracle.com To: mandy.ch...@oracle.com Subject: Missing merge for 8014890: Reference queues may return more entries than expected Date: Wed, 07 Aug 2013 09:47:30 +0200 Hi Mandy, while checking out latest sources, I saw that the commit for that patch has not been merged to the default branch in the repository. It represents its own head. Could you fix this? Here's the relevant hg output: $ hg heads changeset: 7764:8ed8e2b4b90e tag: tip parent: 7763:0741b19835b0 parent: 7692:b52a2ecdb803 user:lana date:Tue Aug 06 10:10:39 2013 -0700 summary: Merge changeset: 7605:2c04ce2f782c user:mchung date:Mon Jul 08 14:05:59 2013 +0200 summary: 8014890: (ref) Reference queues may return more entries than expected
Re: [Fwd: Missing merge for 8014890: Reference queues may return more entries than expected]
Mandy is just back from vacation and might not have got to your mail yet. However it's not clear to me that there is an actual problem as it looks like you've just ended up with two heads, maybe a hg fetch when you had changes where you forgot to merge? As I understand, the hg server is setup to limit the heads to 1 so it's not possible for any of us to push changes that would result in a new head. Maybe start with a fresh clone of jdk8/tl or jdk8/jdk8? -Alan. On 14/08/2013 10:19, Thomas Schatzl wrote: Hi all, could somebody take care of the missing merge for the fix below? Thanks, Thomas Forwarded Message From: Thomas Schatzlthomas.scha...@oracle.com To: mandy.ch...@oracle.com Subject: Missing merge for 8014890: Reference queues may return more entries than expected Date: Wed, 07 Aug 2013 09:47:30 +0200 Hi Mandy, while checking out latest sources, I saw that the commit for that patch has not been merged to the default branch in the repository. It represents its own head. Could you fix this? Here's the relevant hg output: $ hg heads changeset: 7764:8ed8e2b4b90e tag: tip parent: 7763:0741b19835b0 parent: 7692:b52a2ecdb803 user:lana date:Tue Aug 06 10:10:39 2013 -0700 summary: Merge changeset: 7605:2c04ce2f782c user:mchung date:Mon Jul 08 14:05:59 2013 +0200 summary: 8014890: (ref) Reference queues may return more entries than expected
Re: [Fwd: Missing merge for 8014890: Reference queues may return more entries than expected]
Hi, On Wed, 2013-08-14 at 10:43 +0100, Alan Bateman wrote: Mandy is just back from vacation and might not have got to your mail yet. However it's not clear to me that there is an actual problem as it looks like you've just ended up with two heads, maybe a hg fetch when you had changes where you forgot to merge? As I understand, the hg server is setup to limit the heads to 1 so it's not possible for any of us to push changes that would result in a new head. Maybe start with a fresh clone of jdk8/tl or jdk8/jdk8? I had the impression that I had a fresh checkout at that time, and did not recheck right now. A fresh checkout is okay. Sorry for the noise, Thomas
Re: RFR 8022898 java/util/Spliterator/SpliteratorCollisions.java fails in HashableIntSpliteratorWithNull data provider
On 13/08/2013 14:46, Paul Sandoz wrote: Hi, This patch fixes a bug in the data provider of the SpliteratorCollisions.java test, which was attempting to add an element to an unmodifable map. Interestingly although this caused the data provider to barf, and therefore tests using such a provider were not run, it did not result in jtreg reporting the test-infrastructure failure. Good catch, I often wonder how often we have cases where a test fails but is reported as passed. Anyway, the change looks fine to me too. -Alan.
Re: Possible HashMap update
On Aug 14, 2013, at 12:18 PM, Alan Bateman alan.bate...@oracle.com wrote: On 13/08/2013 22:18, Joe Darcy wrote: Have you seen the patch from Dan Smith which would revolve all the javac lint warnings in HashMap? http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019618.html My preference would be to get Doug's update in as soon as we can, mostly because the changes are significant and it would be good to get them well exercised (and the performance/memory characterized too) before jdk8 starts to get locked down. I know the javac lint warnings are important but it's lower risk and at least some of the code in the lint patch will be replaced. I would expect it would be straight-forward to sort out any remaining issues later. +1 If no one else volunteers i can try and sort this out and sync up stuff from the current HashMap/LinkedHashMap (e.g. forEachRem. as reported by Remi) and the lint warnings in one go, and submit for review. I do have a vested interest since it fixes another bug related to the incorrect reporting of splitrerator characteristics in LInkedHashMap (they should report ORDERED). Paul.
Re: Possible HashMap update
On 08/13/13 17:18, Joe Darcy wrote: While I haven't touched it lately (I've been distracted with a lot of other things), last I left it, it seemed integratable. I haven't seen any list traffic that seems applicable, except for Remi's, that I ought to reply to... Have you seen the patch from Dan Smith which would revolve all the javac lint warnings in HashMap? I don't think any of these apply. Courtesy of Martin, we now screen every build/commit for lint and doclint warnings. I just reran with current version and doclint picked up a in a pre. Now fixed. Aside: What's up with doclint complaining about no comments on package declarations? Who puts doc comments on package declarations? [javac] /home/dl/concurrent/src/main/java/util/HashMap.java:26: warning: no comment [javac] package java.util; -Doug
Re: Possible HashMap update
On 08/13/13 16:56, Remi Forax wrote: And that the iterators on entrySet, keySet and values doesn't have their method forEachRemaining overriden (unlike java.util.ArrayList). Are you saying that all iterators should define forEachRemaining? Seems excessive. All iterators for ArrayList, HashMap and their views should have forEachRemaining, I don't care about the other collections :) forEachRemaining internally use local variables instead of fields as the traditional iterator does, so it may be faster than a plain old iterator loop. Moreover, the call to the Consumer inside the default method defined in Iterable can be megamorphic, if each iterator's view have they own implementation, you create a several of different callsites (I know, I know, it's a kind of poor's man optimization) that mitigates the profile pollution problem. Could you explain exactly when these trigger? Most Stream-related operations should pick up spliterator, not iterator, so won't encounter this. I resist this a bit because it would require 6 more methods, each redundant with a spliterator method. (The HashMap view ones must be overridden in LinkedHashMap.) But if the situation is common, it might be worthwhile. -Doug
8022921: Remove experimental Profile attribute
As part of the Compact Profiles [1] solution we updated the JAR File specification to define a new attribute named Profile to allow both main application and library JAR files specify the minimum subset Profile of Java SE that the code in the JAR file requires. The Profile attribute has been in for more than 6 months now and on reflection it may not be the right thing to do. For starters there has been push-back from folks that have license or other reasons that prevent them from updating the manifest of main application JAR files. Another issue is that the value of the attribute is the minimum subset Profile so there isn't a way to specify that the code requires the full Java SE platform. Another concern is that it might conflict with future direction where we have a way to require standard Java SE or JDK modules. So overall I think the best thing is to remove this attribute, even though it means the solution doesn't no longer has a way to catch mis-matches between the compile time and runtime environments. The webrev with the changes to remove this attribute are here: http://cr.openjdk.java.net/~alanb/8022921/webrev/ It should be easy to remove because it's code deletion. I plan to update the JEP so that it reflects the updated solution. Thanks, Alan. [1] http://openjdk.java.net/jeps/161
Re: Possible HashMap update
On 14/08/2013 12:02, Doug Lea wrote: : Aside: What's up with doclint complaining about no comments on package declarations? Who puts doc comments on package declarations? [javac] /home/dl/concurrent/src/main/java/util/HashMap.java:26: warning: no comment [javac] package java.util; I think Jon fixed this one recently: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1476d54fdc61 -Alan.
Re: RFR 8022898 java/util/Spliterator/SpliteratorCollisions.java fails in HashableIntSpliteratorWithNull data provider
I fixed a jtreg bug a while back when I had a problem with exceptions in dataProviders. I don't know if it has propagated into the latest promotion. Roger changeset: 37:ec890bad20b5 user:jjg date:Tue Jul 09 13:16:13 2013 +0100 description: 7900130: Test summary does not show TestNg dataProvider arguments 7900165: Exception in TestNG DataSource does not result in a reported test failure 7900112: don't print unnecessary stack traces Summary: Added formatted parameters to test title reporting; If a test is skipped due to an exception report it as a failure Skip printing of exception if the test result is success Contributed-By roger.ri...@oracle.com On 08/14/2013 06:21 AM, Alan Bateman wrote: On 13/08/2013 14:46, Paul Sandoz wrote: Hi, This patch fixes a bug in the data provider of the SpliteratorCollisions.java test, which was attempting to add an element to an unmodifable map. Interestingly although this caused the data provider to barf, and therefore tests using such a provider were not run, it did not result in jtreg reporting the test-infrastructure failure. Good catch, I often wonder how often we have cases where a test fails but is reported as passed. Anyway, the change looks fine to me too. -Alan.
Re: Possible HashMap update
On 08/14/2013 01:16 PM, Doug Lea wrote: On 08/13/13 16:56, Remi Forax wrote: And that the iterators on entrySet, keySet and values doesn't have their method forEachRemaining overriden (unlike java.util.ArrayList). Are you saying that all iterators should define forEachRemaining? Seems excessive. All iterators for ArrayList, HashMap and their views should have forEachRemaining, I don't care about the other collections :) forEachRemaining internally use local variables instead of fields as the traditional iterator does, so it may be faster than a plain old iterator loop. Moreover, the call to the Consumer inside the default method defined in Iterable can be megamorphic, if each iterator's view have they own implementation, you create a several of different callsites (I know, I know, it's a kind of poor's man optimization) that mitigates the profile pollution problem. Could you explain exactly when these trigger? Most Stream-related operations should pick up spliterator, not iterator, so won't encounter this. Yes, it's not related to Stream. I see two obvious scenarios when forEachRemaining should be used. The first one is bug 6360734 [1], for(:) doesn't support Iterator but there are plenty of methods in the wild that returns an Iterator. In the JDK, at least BeanContextServices.getCurrentServiceClasses(), BenContextSupport.bcsChildren() or ServiceRegistry.getCategories(), all return something like map.[views()].iterator() The second scenario is when you have an algorithm that do something for first value and do something else for the other value, in that case, you need to get the iterator, calls next to get the first value and calls forEachRemaining for processing the remaining values. I resist this a bit because it would require 6 more methods, each redundant with a spliterator method. (The HashMap view ones must be overridden in LinkedHashMap.) But if the situation is common, it might be worthwhile. I suppose that it depends on what is your definition of common :) -Doug [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6360734
hg: jdk8/tl/langtools: 8007517: DefaultMethodRegressionTests.java fail in TL
Changeset: 3ab468194f11 Author:ksrini Date: 2013-08-14 07:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ab468194f11 8007517: DefaultMethodRegressionTests.java fail in TL Reviewed-by: jjg, vromero - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: cb74d71fd02f Author:hseigel Date: 2013-08-13 10:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb74d71fd02f 8022259: MakeClasslist is buggy and its README is out of date. Summary: Fixed bug in FOR loop and updated comments and README Reviewed-by: dholmes, alanb ! make/tools/sharing/README.txt ! make/tools/src/build/tools/makeclasslist/MakeClasslist.java Changeset: f9cf6ecf596c Author:coleenp Date: 2013-08-14 10:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9cf6ecf596c Merge
Re: RFR: JDK-4858457 -- File.getCanonicalPath() throws IOException when invoked with nul (win)
On 08/08/2013 21:44, Dan Xu wrote: Hi All, Windows platforms have reserved a few names for device usages, and nul is one of them. And Windows API, such as _wfullpath() and GetFullPathNameW, returns its full path with the prefix \\.\, which represents win32 device namespaces. For example, nul, whose full path name is \\.\nul, is a valid device name. But our current Canonicalization logicfails to generate its canonicalpath and throws an IOException. This fix is going to address the problem. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/4858457/webrev.00/ Bug: http://bugs.sun.com/view_bug.do?bug_id=4858457 -Dan The change looks okay to me, I just wonder if it might make sense to combine the test with WinDeviceName so that there is only one set of inputs to test. -Alan
hg: jdk8/tl/jdk: 8022547: [verifier] move DefaultMethodRegressionTests.java to jdk
Changeset: bc3cafb17c09 Author:ksrini Date: 2013-08-14 08:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc3cafb17c09 8022547: [verifier] move DefaultMethodRegressionTests.java to jdk Reviewed-by: acorn + test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java + test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java
Re: [Fwd: Missing merge for 8014890: Reference queues may return more entries than expected]
Thomas, I haven't got to your mail as Alan suspects. I'm happy that you confirmed this is no longer an issue. Mandy On 8/14/2013 2:56 AM, Thomas Schatzl wrote: Hi, On Wed, 2013-08-14 at 10:43 +0100, Alan Bateman wrote: Mandy is just back from vacation and might not have got to your mail yet. However it's not clear to me that there is an actual problem as it looks like you've just ended up with two heads, maybe a hg fetch when you had changes where you forgot to merge? As I understand, the hg server is setup to limit the heads to 1 so it's not possible for any of us to push changes that would result in a new head. Maybe start with a fresh clone of jdk8/tl or jdk8/jdk8? I had the impression that I had a fresh checkout at that time, and did not recheck right now. A fresh checkout is okay. Sorry for the noise, Thomas
Re: RFR: JDK-8022178: System.console() throws IOE on some Windows
On 14/08/2013 19:35, Xueming Shen wrote: Hi, Please help review the trivial change for 8022178. http://cr.openjdk.java.net/~sherman/console/webrev System.console() is not specified to throw an IOE. It is supposed to return a null silently if there is no system console or anything goes wrong to get one. The Windows implementation obviously has some leftover code from the old/original implementation to throw a IOE if it fails to get the std in/out handler in certain use scenario. The proposed change is to simply remove the IOE throwing code and return silently. It does look like left over code, the change looks fine to me. -Alan
Re: RFR: JDK-8022178: System.console() throws IOE on some Windows
Looks good to me. -Dan On 08/14/2013 11:35 AM, Alan Bateman wrote: On 14/08/2013 19:35, Xueming Shen wrote: Hi, Please help review the trivial change for 8022178. http://cr.openjdk.java.net/~sherman/console/webrev System.console() is not specified to throw an IOE. It is supposed to return a null silently if there is no system console or anything goes wrong to get one. The Windows implementation obviously has some leftover code from the old/original implementation to throw a IOE if it fails to get the std in/out handler in certain use scenario. The proposed change is to simply remove the IOE throwing code and return silently. It does look like left over code, the change looks fine to me. -Alan
hg: jdk8/tl/jdk: 8022990: Fix dep_ann lint warnings in swing code
Changeset: 444a7edcf367 Author:darcy Date: 2013-08-14 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/444a7edcf367 8022990: Fix dep_ann lint warnings in swing code Reviewed-by: alexsch ! src/share/classes/com/sun/java/swing/Painter.java ! src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java
RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException
Hi, Please help review the change to document the AIOBE exception for CRC32/Adler32.update() methods (may need a followup CCC). This has been the behavior probably from day one, but the exception is just not explicitly listed. Ideally it probably should be in Checksum.update(), but that probably is too late for a public interface that has been there for so many years. http://cr.openjdk.java.net/~sherman/7154662/webrev/ Thanks! -Sherman
Please review Meiji era tidyup
The issue 8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate Observes a minor discrepancy between the java.util.Calendar Japanese implementation and the java.time JapaneseEra. This fix aligns the start dates of the Meiji Era to avoid the inconsistency. http://cr.openjdk.java.net/~rriggs/webrev-meiji-start-8019185/ Thanks, Roger
Re: RFR: JDK-4858457 -- File.getCanonicalPath() throws IOException when invoked with nul (win)
Hi Alan, Thanks for pointing out. I have updated my fix in the new webrev, http://cr.openjdk.java.net/~dxu/4858457/webrev.01/. Please take a look! -Dan On 08/14/2013 08:22 AM, Alan Bateman wrote: On 08/08/2013 21:44, Dan Xu wrote: Hi All, Windows platforms have reserved a few names for device usages, and nul is one of them. And Windows API, such as _wfullpath() and GetFullPathNameW, returns its full path with the prefix \\.\, which represents win32 device namespaces. For example, nul, whose full path name is \\.\nul, is a valid device name. But our current Canonicalization logicfails to generate its canonicalpath and throws an IOException. This fix is going to address the problem. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/4858457/webrev.00/ Bug: http://bugs.sun.com/view_bug.do?bug_id=4858457 -Dan The change looks okay to me, I just wonder if it might make sense to combine the test with WinDeviceName so that there is only one set of inputs to test. -Alan
hg: jdk8/tl/jdk: 8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math
Changeset: 17dfbb3f60d3 Author:bpb Date: 2013-08-12 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17dfbb3f60d3 8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math Summary: Add the methods for parameter types int and long. Reviewed-by: mduigou Contributed-by: Brian Burkhalter brian.burkhal...@oracle.com ! src/share/classes/java/lang/Math.java ! test/java/lang/Math/ExactArithTests.java
Re: 8022921: Remove experimental Profile attribute
On 8/14/2013 5:30 AM, Alan Bateman wrote: As part of the Compact Profiles [1] solution we updated the JAR File specification to define a new attribute named Profile to allow both main application and library JAR files specify the minimum subset Profile of Java SE that the code in the JAR file requires. The Profile attribute has been in for more than 6 months now and on reflection it may not be the right thing to do. For starters there has been push-back from folks that have license or other reasons that prevent them from updating the manifest of main application JAR files. Another issue is that the value of the attribute is the minimum subset Profile so there isn't a way to specify that the code requires the full Java SE platform. Another concern is that it might conflict with future direction where we have a way to require standard Java SE or JDK modules. So overall I think the best thing is to remove this attribute, even though it means the solution doesn't no longer has a way to catch mis-matches between the compile time and runtime environments. The webrev with the changes to remove this attribute are here: http://cr.openjdk.java.net/~alanb/8022921/webrev/ This change looks fine and I also think removing this attribute is the best thing to do. Mandy It should be easy to remove because it's code deletion. I plan to update the JEP so that it reflects the updated solution. Thanks, Alan. [1] http://openjdk.java.net/jeps/161
Re: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException
On 14/08/2013 20:10, Xueming Shen wrote: Hi, Please help review the change to document the AIOBE exception for CRC32/Adler32.update() methods (may need a followup CCC). This has been the behavior probably from day one, but the exception is just not explicitly listed. Ideally it probably should be in Checksum.update(), but that probably is too late for a public interface that has been there for so many years. http://cr.openjdk.java.net/~sherman/7154662/webrev/ This looks fine to me. -Alan
Re: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException
* @throws ArrayIndexOutOfBoundsException
* if the {@code off} is negative, or the {@code len} is
* negative, or the {@code off+len} is greater than the
* length of the array {@code b}
I agree that specifying this in CRC32 and Adler32 is the right thing to
do. Trivially I'd drop the 'the' before the arguments, or maybe take the
working from InputStream.read(byte[],int,int) :
If off is negative, len is negative, or len is greater than b.length
- off
Either is ok with me. Is it worth adding a test? or will JCK be updated
to catch this.
-Chris.
On 14/08/2013 20:10, Xueming Shen wrote:
Hi,
Please help review the change to document the AIOBE exception
for CRC32/Adler32.update() methods (may need a followup CCC).
This has been the behavior probably from day one, but the exception
is just not explicitly listed. Ideally it probably should be in
Checksum.update(),
but that probably is too late for a public interface that has been there
for so many years.
http://cr.openjdk.java.net/~sherman/7154662/webrev/
Thanks!
-Sherman
Re: 8022921: Remove experimental Profile attribute
The code changes look ok to me. -Chris. On 14/08/2013 13:30, Alan Bateman wrote: As part of the Compact Profiles [1] solution we updated the JAR File specification to define a new attribute named Profile to allow both main application and library JAR files specify the minimum subset Profile of Java SE that the code in the JAR file requires. The Profile attribute has been in for more than 6 months now and on reflection it may not be the right thing to do. For starters there has been push-back from folks that have license or other reasons that prevent them from updating the manifest of main application JAR files. Another issue is that the value of the attribute is the minimum subset Profile so there isn't a way to specify that the code requires the full Java SE platform. Another concern is that it might conflict with future direction where we have a way to require standard Java SE or JDK modules. So overall I think the best thing is to remove this attribute, even though it means the solution doesn't no longer has a way to catch mis-matches between the compile time and runtime environments. The webrev with the changes to remove this attribute are here: http://cr.openjdk.java.net/~alanb/8022921/webrev/ It should be easy to remove because it's code deletion. I plan to update the JEP so that it reflects the updated solution. Thanks, Alan. [1] http://openjdk.java.net/jeps/161
Re: RFR: JDK-7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException
Thanks Chris!
the removed.
I would assume the jck team probably will add a unit test for it. They filed the
bug originally.
-Sherman
On 08/14/2013 02:33 PM, Chris Hegarty wrote:
* @throws ArrayIndexOutOfBoundsException
* if the {@code off} is negative, or the {@code len} is
* negative, or the {@code off+len} is greater than the
* length of the array {@code b}
I agree that specifying this in CRC32 and Adler32 is the right thing to do.
Trivially I'd drop the 'the' before the arguments, or maybe take the working
from InputStream.read(byte[],int,int) :
If off is negative, len is negative, or len is greater than b.length
- off
Either is ok with me. Is it worth adding a test? or will JCK be updated to
catch this.
-Chris.
On 14/08/2013 20:10, Xueming Shen wrote:
Hi,
Please help review the change to document the AIOBE exception
for CRC32/Adler32.update() methods (may need a followup CCC).
This has been the behavior probably from day one, but the exception
is just not explicitly listed. Ideally it probably should be in
Checksum.update(),
but that probably is too late for a public interface that has been there
for so many years.
http://cr.openjdk.java.net/~sherman/7154662/webrev/
Thanks!
-Sherman
RFR FJ parallelism zero
Source changes that follow Doug's mail on lambda-libs-spec-observers
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-August/002361.html
These changes are already in the jsr166 CVS, and there is a test in
OpenJDK that verifies the change.
diff --git a/src/share/classes/java/util/concurrent/ForkJoinPool.java
b/src/share/classes/java/util/concurrent/ForkJoinPool.java
--- a/src/share/classes/java/util/concurrent/ForkJoinPool.java
+++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java
@@ -144,7 +144,8 @@ import java.util.concurrent.TimeUnit;
* Upon any error in establishing these settings, default parameters
* are used. It is possible to disable or limit the use of threads in
* the common pool by setting the parallelism property to zero, and/or
- * using a factory that may return {@code null}.
+ * using a factory that may return {@code null}. However doing so may
+ * cause unjoined tasks to never be executed.
*
* pbImplementation notes/b: This implementation restricts the
* maximum number of running threads to 32767. Attempts to create
@@ -3303,8 +3304,8 @@ public class ForkJoinPool extends Abstra
}
if (parallelism 0 // default 1 less than #cores
-(parallelism = Runtime.getRuntime().availableProcessors() -
1) 0)
-parallelism = 0;
+(parallelism = Runtime.getRuntime().availableProcessors() -
1) = 0)
+parallelism = 1;
if (parallelism MAX_CAP)
parallelism = MAX_CAP;
return new ForkJoinPool(parallelism, factory, handler, LIFO_QUEUE,
-Chris.
RFR ConcurrentHashMap typo
Typo that crept in during a refactoring.
http://cs.oswego.edu/pipermail/concurrency-interest/2013-August/011695.html
This change is already in the jsr166 CVS.
diff --git
a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
--- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
+++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
@@ -2785,7 +2785,7 @@ public class ConcurrentHashMapK,V exte
return;
}
}
-else if ((s | WAITER) == 0) {
+else if ((s WAITER) == 0) {
if (U.compareAndSwapInt(this, LOCKSTATE, s, s |
WAITER)) {
waiting = true;
waiter = Thread.currentThread();
-Chris.
Re: RFR FJ parallelism zero
Looks fine.
Mike
On Aug 14 2013, at 14:59 , Chris Hegarty wrote:
Source changes that follow Doug's mail on lambda-libs-spec-observers
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-August/002361.html
These changes are already in the jsr166 CVS, and there is a test in OpenJDK
that verifies the change.
diff --git a/src/share/classes/java/util/concurrent/ForkJoinPool.java
b/src/share/classes/java/util/concurrent/ForkJoinPool.java
--- a/src/share/classes/java/util/concurrent/ForkJoinPool.java
+++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java
@@ -144,7 +144,8 @@ import java.util.concurrent.TimeUnit;
* Upon any error in establishing these settings, default parameters
* are used. It is possible to disable or limit the use of threads in
* the common pool by setting the parallelism property to zero, and/or
- * using a factory that may return {@code null}.
+ * using a factory that may return {@code null}. However doing so may
+ * cause unjoined tasks to never be executed.
*
* pbImplementation notes/b: This implementation restricts the
* maximum number of running threads to 32767. Attempts to create
@@ -3303,8 +3304,8 @@ public class ForkJoinPool extends Abstra
}
if (parallelism 0 // default 1 less than #cores
-(parallelism = Runtime.getRuntime().availableProcessors() - 1)
0)
-parallelism = 0;
+(parallelism = Runtime.getRuntime().availableProcessors() - 1)
= 0)
+parallelism = 1;
if (parallelism MAX_CAP)
parallelism = MAX_CAP;
return new ForkJoinPool(parallelism, factory, handler, LIFO_QUEUE,
-Chris.
Re: RFR ConcurrentHashMap typo
Looks correct.
mike
On Aug 14 2013, at 15:08 , Chris Hegarty wrote:
Typo that crept in during a refactoring.
http://cs.oswego.edu/pipermail/concurrency-interest/2013-August/011695.html
This change is already in the jsr166 CVS.
diff --git a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
--- a/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
+++ b/src/share/classes/java/util/concurrent/ConcurrentHashMap.java
@@ -2785,7 +2785,7 @@ public class ConcurrentHashMapK,V exte
return;
}
}
-else if ((s | WAITER) == 0) {
+else if ((s WAITER) == 0) {
if (U.compareAndSwapInt(this, LOCKSTATE, s, s | WAITER)) {
waiting = true;
waiter = Thread.currentThread();
-Chris.
hg: jdk8/tl/langtools: 8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages
Changeset: 14faef2b51eb Author:jjg Date: 2013-08-14 16:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/14faef2b51eb 8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java + test/com/sun/javadoc/testSeeTag/TestSeeTag.java + test/com/sun/javadoc/testSeeTag/pkg/Test.java
hg: jdk8/tl/langtools: 6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException
Changeset: fac0d1bb87f2 Author:ksrini Date: 2013-08-14 18:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fac0d1bb87f2 6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException Reviewed-by: jjg ! src/share/classes/javax/tools/JavaCompiler.java
hg: jdk8/tl/langtools: 8016921: Change the profiles table on overview-summary.html page to a list
Changeset: 3d4f0fa2ad05 Author:bpatel Date: 2013-08-14 21:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d4f0fa2ad05 8016921: Change the profiles table on overview-summary.html page to a list Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java
hg: jdk8/tl/jdk: 8023075: JDK-5049299 has broken old make in jdk8
Changeset: f8af3499c1fb Author:wetmore Date: 2013-08-14 19:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8af3499c1fb 8023075: JDK-5049299 has broken old make in jdk8 Reviewed-by: katleman ! make/java/java/Makefile
