Fwd: Improve large array allocation / gc intrinsics
Please, could you give me your opinions on the following ideas for a JDK9 RFE ? Is it worth? Interesting or totally stupid with current hotspot / gc ? How hard / long would it be to study and make a prototype ? Any other ideas to improve array performance like improving again the array bound check elimination or fill / clear intrinsics ... Who would be interested by this topics ? Laurent -- Message transféré -- De : Laurent Bourgès bourges.laur...@gmail.com Date : 10 févr. 2014 10:24 Objet : Improve large array allocation / gc intrinsics À : core-libs-dev core-libs-dev@openjdk.java.net, discuss disc...@openjdk.java.net Cc : Dear all, I would like to propose a JDK9 RFE to improve JVM efficiency when dealing with large arrays (allocation + gc). In several scientific applications (and my patched java2d pisces), many large arrays are needed, created on the fly and it becomes very painful to recycle them using an efficient array cache (concurrency, cache size tuning, clear + cache eviction issues). In this case, the GC overhead leads to a big performance penalty (several hundred megabytes per seconds). As such array cache are very efficient in an application context, I am wondering if that approach could be promoted at the JDK level itself: - provide a new array allocator for large arrays that can return larger arrays than expected (size = 4 or 8 multiples) using array caches (per thread ?) stored in a dedicated JVM large memory area (GC aware) and providing efficient cache eviction policies - may support for both clean arrays (zero filled) or dirty arrays because some algorithms does not need zero-filled arrays. - improve JVM intrinsics (array clear, fill) to achieve maximum performance ie take into account the data alignment (4 or 8 multiples) - upgrade GC to recycle such 'cached' arrays (clean), update usage statistics and manage cache eviction policy (avoid wasting memory) Please give me your feedback opinion and evaluate if this feature seems possible to implement into the JDK (hotspot, gc, core-libs) ... What is the procedure to create such JDK9 RFE ? Best regards, Laurent Bourgès -- Message transféré -- De : Laurent Bourgès bourges.laur...@gmail.com Date : 10 févr. 2014 10:24 Objet : Improve large array allocation / gc intrinsics À : core-libs-dev core-libs-dev@openjdk.java.net, discuss disc...@openjdk.java.net Cc : Dear all, I would like to propose a JDK9 RFE to improve JVM efficiency when dealing with large arrays (allocation + gc). In several scientific applications (and my patched java2d pisces), many large arrays are needed, created on the fly and it becomes very painful to recycle them using an efficient array cache (concurrency, cache size tuning, clear + cache eviction issues). In this case, the GC overhead leads to a big performance penalty (several hundred megabytes per seconds). As such array cache are very efficient in an application context, I am wondering if that approach could be promoted at the JDK level itself: - provide a new array allocator for large arrays that can return larger arrays than expected (size = 4 or 8 multiples) using array caches (per thread ?) stored in a dedicated JVM large memory area (GC aware) and providing efficient cache eviction policies - may support for both clean arrays (zero filled) or dirty arrays because some algorithms does not need zero-filled arrays. - improve JVM intrinsics (array clear, fill) to achieve maximum performance ie take into account the data alignment (4 or 8 multiples) - upgrade GC to recycle such 'cached' arrays (clean), update usage statistics and manage cache eviction policy (avoid wasting memory) Please give me your feedback opinion and evaluate if this feature seems possible to implement into the JDK (hotspot, gc, core-libs) ... What is the procedure to create such JDK9 RFE ? Best regards, Laurent Bourgès
Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself
Hi Mike, as described in the bug comments, I still think that correctly handling a null Supplier is the cleanest and easiest solution. Without the change our VM will throw the following NPE: java.lang.NullPointerException: while trying to invoke the method java.util.function.Supplier.get() of a null object loaded from the second parameter of the method at java.util.Objects.requireNonNull(Objects.java:290) which is more descriptive and perfectly legal, but it may be not what the user expects (i.e. a NPE with a null message). Anyhow, I don't insist on my change. If everybody agrees that it would be better to change the documentation then please go ahead. But keep in mind that Joe also had some objections against the documentation changes in the bug comments. Regards, Volker On Tue, Feb 11, 2014 at 12:24 AM, Mike Duigou mike.dui...@oracle.com wrote: I would prefer to leave the implementation as is and amend the documentation. The difference in behaviour between the overloads seems OK since it will still be valid for the Supplier to return null. The String overload reasonably allows null since the Throwable(String) constructor allows null message. (See Throwable.getMessage()). It seems like ignoring/masking the likely error of passing a null Supplier isn't really being helpful. YMMV, Mike On Feb 10 2014, at 05:30 , Volker Simonis volker.simo...@gmail.com wrote: Hi, could you please review the following tiny change which fixes a problem in Objects.requireNonNull: http://cr.openjdk.java.net/~simonis/webrevs/8033909/ https://bugs.openjdk.java.net/browse/JDK-8033909 The problem is that Objects.requireNonNull(T, Supplier) does not check for the Supplier argument being null. Instead it relies on the fact, that the VM will implicitly throw a NullPointerException while trying to call .get on the Supplier argument during the creation of the explicit NullPointerException which is supposed to be thrown by Objects.requireNonNull(T, Supplier) for a null T argument. This makes the behavior of Objects.requireNonNull(T, Supplier) slightly different from the one of the overladed Objects.requireNonNull(T, String) version. The latter one always throws a NPE with a null message in the case where the String argument is null. For the first one, it depends on the implementation of the VM whether the trown NPE will have a null message or not (i.e. the VM is free to create a NPE with an arbitrary message). The bug report mentions that this behavior makes it hard to develop a conformance test for the scenario and suggests to tweak the JavaDoc of Objects.requireNonNull(T, Supplier) such that it allows NPE with an unspecified message. However, I think the easiest fix is to just check for the supplier object beeing null and explicitely creating a NPE with a null message in that case. This will align the behavior of Objects.requireNonNull(T, Supplier) with that of Objects.requireNonNull(T, String). Also notice that the extra null-check is only performed if the object argument T of Objects.requireNonNull(T, Supplier) is null, which should be the unusual case anyway. I therefore don't expect this change to have any negative performance impact. This webrev is for jdk9, but I think it should be also downported to jdk8. Thank you and best regards, Volker
8034175: Remove use of UseVMInterruptibleIO from tests
Interruptible I/O was a (mostly Solaris only) mis-feature that we've been eradicating over a number of releases. In JDK 6 the VM option UseVMInterruptibleIO was added to allow it be disabled, in JDK 7 it was switched to being disabled by default, in JDK 8 we removed the dependency from the libraries (except classic networking, meaning java.net, that still needs to be done). Now in JDK 9, Frederic Parain is removing the VM support as part of JDK-6546236 [1]. As part of that discussion, Frederic pointed out that we still have 3 tests in the jdk repository that use specify this option. The attached (trivial) patch removes the option from the 3 tests. In each case then I've removed the @run line as there isn't any obvious that requires a new VM be spun up for each test. -Alan [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010839.html diff --git a/test/java/nio/file/Files/InterruptCopy.java b/test/java/nio/file/Files/InterruptCopy.java --- a/test/java/nio/file/Files/InterruptCopy.java +++ b/test/java/nio/file/Files/InterruptCopy.java @@ -25,7 +25,6 @@ * @bug 4313887 6993267 * @summary Unit test for Sun-specific ExtendedCopyOption.INTERRUPTIBLE option * @library .. - * @run main/othervm -XX:-UseVMInterruptibleIO InterruptCopy */ import java.nio.file.*; diff --git a/test/java/util/concurrent/BlockingQueue/Interrupt.java b/test/java/util/concurrent/BlockingQueue/Interrupt.java --- a/test/java/util/concurrent/BlockingQueue/Interrupt.java +++ b/test/java/util/concurrent/BlockingQueue/Interrupt.java @@ -25,7 +25,6 @@ * @test * @bug 6384064 * @summary Check proper handling of interrupts - * @run main/othervm -XX:-UseVMInterruptibleIO Interrupt * @author Martin Buchholz */ diff --git a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java @@ -25,7 +25,6 @@ * @test * @bug 6450200 6450205 6450207 6450211 * @summary Test proper handling of tasks that terminate abruptly - * @run main/othervm -XX:-UseVMInterruptibleIO ThrowingTasks * @author Martin Buchholz */
Re: 8034175: Remove use of UseVMInterruptibleIO from tests
Looks good to me Alan. -Chris. On 11 Feb 2014, at 10:31, Alan Bateman alan.bate...@oracle.com wrote: Interruptible I/O was a (mostly Solaris only) mis-feature that we've been eradicating over a number of releases. In JDK 6 the VM option UseVMInterruptibleIO was added to allow it be disabled, in JDK 7 it was switched to being disabled by default, in JDK 8 we removed the dependency from the libraries (except classic networking, meaning java.net, that still needs to be done). Now in JDK 9, Frederic Parain is removing the VM support as part of JDK-6546236 [1]. As part of that discussion, Frederic pointed out that we still have 3 tests in the jdk repository that use specify this option. The attached (trivial) patch removes the option from the 3 tests. In each case then I've removed the @run line as there isn't any obvious that requires a new VM be spun up for each test. -Alan [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010839.html diff --git a/test/java/nio/file/Files/InterruptCopy.java b/test/java/nio/file/Files/InterruptCopy.java --- a/test/java/nio/file/Files/InterruptCopy.java +++ b/test/java/nio/file/Files/InterruptCopy.java @@ -25,7 +25,6 @@ * @bug 4313887 6993267 * @summary Unit test for Sun-specific ExtendedCopyOption.INTERRUPTIBLE option * @library .. - * @run main/othervm -XX:-UseVMInterruptibleIO InterruptCopy */ import java.nio.file.*; diff --git a/test/java/util/concurrent/BlockingQueue/Interrupt.java b/test/java/util/concurrent/BlockingQueue/Interrupt.java --- a/test/java/util/concurrent/BlockingQueue/Interrupt.java +++ b/test/java/util/concurrent/BlockingQueue/Interrupt.java @@ -25,7 +25,6 @@ * @test * @bug 6384064 * @summary Check proper handling of interrupts - * @run main/othervm -XX:-UseVMInterruptibleIO Interrupt * @author Martin Buchholz */ diff --git a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java @@ -25,7 +25,6 @@ * @test * @bug 6450200 6450205 6450207 6450211 * @summary Test proper handling of tasks that terminate abruptly - * @run main/othervm -XX:-UseVMInterruptibleIO ThrowingTasks * @author Martin Buchholz */
Re: 8034175: Remove use of UseVMInterruptibleIO from tests
On 11/02/2014 10:36, Chris Hegarty wrote: Looks good to me Alan. -Chris. I checked the jsr166 CVS and both of the j.u.concurrent tests also specify UseVMInterruptibleIO. I assume Martin will update these. -Alan
Re: 8034175: Remove use of UseVMInterruptibleIO from tests
On 11 Feb 2014, at 11:10, Alan Bateman alan.bate...@oracle.com wrote: On 11/02/2014 10:36, Chris Hegarty wrote: Looks good to me Alan. -Chris. I checked the jsr166 CVS and both of the j.u.concurrent tests also specify UseVMInterruptibleIO. I assume Martin will update these. Yes, I see this too. Martin, Can you please update the 166 CVS as per Alan’s patch? -Chris. -Alan
Time to remove sun.misc.Service?
It was never meant to be used by anything outside of the JDK and there has been a standard API (java.util.ServiceLoader) since JDK 6 (released in 2006). -Alan
Re: Time to remove sun.misc.Service?
+1 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Feb 11, 2014, at 6:19 AM, Alan Bateman alan.bate...@oracle.com wrote: It was never meant to be used by anything outside of the JDK and there has been a standard API (java.util.ServiceLoader) since JDK 6 (released in 2006). -Alan
Re: Time to remove sun.misc.Service?
On Feb 11, 2014, at 12:19 PM, Alan Bateman alan.bate...@oracle.com wrote: It was never meant to be used by anything outside of the JDK and there has been a standard API (java.util.ServiceLoader) since JDK 6 (released in 2006). Scrub it! AFAICT it is not widely used (looking at the use of s.m.Service static methods on grep code there are only a handful of dependent artifacts). And the upgrade is quite easy. Paul.
RFR(S): 8034087: XML parser may overwrite element content if that content falls onto the border of an entity scanner buffer
Hi, after opening this bug yesterday for an issue found by my colleague Steffen Schreiber we realized that this is actually a duplicate of 8027359: XML parser returns incorrect parsing results (https://bugs.openjdk.java.net/browse/JDK-8027359). While there's no need now to submit a patch anymore, we'd nevertheless like to contribute at least our test case for this issue: http://cr.openjdk.java.net/~simonis/webrevs/8034087/ The webrev is against jdk9-client but we'd like to also downport this test to jdk7 and jdk8 to track that the fix for 8027359 will be correctly downported to these releases as well. I will sponsor this change if somebody would be so kind to review it. Thank you and best regards, Volker
Re: 8034175: Remove use of UseVMInterruptibleIO from tests
On 11/02/2014 15:52, Martin Buchholz wrote: Thanks for doing this cleanup. ThrowingTasks fiddles with uncaught exception handlers and security managers, so should remain otherVM. Interrupt does not, but could use a tiny bit of cleanup hygiene: Probably best to create a separate issue for the cleanup. On tests setting a security manager then it's not strictly required tospin up a VM, jtreg does a better job at cleanup and restoring the environment. No problem keeping it for this test of course. -Alan
Java crypto libraries and large keys
I've been doing some upgrades on servers I run at home recently. One of the upgrades I'd planned was to increase the key size of my internal CA key and SSL keys to 8192 bits as a future-proofing measure (I use SSL with client certificates for all service-to-service communication). What I found was that apparently a number of server applications are not capable of handling keys of that size. I found a number of things stopped working, failing with error messages that suggest hard-coded limits (excessive message size, etc). I have not gotten to any of the Java-based services I run yet, but I think it's worth looking in to whether the Java security and crypto libraries suffer from similar limitations.
Re: RFR(S): 8034087: XML parser may overwrite element content if that content falls onto the border of an entity scanner buffer
On 11/02/2014 14:57, Volker Simonis wrote: Hi, after opening this bug yesterday for an issue found by my colleague Steffen Schreiber we realized that this is actually a duplicate of 8027359: XML parser returns incorrect parsing results (https://bugs.openjdk.java.net/browse/JDK-8027359). While there's no need now to submit a patch anymore, we'd nevertheless like to contribute at least our test case for this issue: http://cr.openjdk.java.net/~simonis/webrevs/8034087/ The webrev is against jdk9-client but we'd like to also downport this test to jdk7 and jdk8 to track that the fix for 8027359 will be correctly downported to these releases as well. I will sponsor this change if somebody would be so kind to review it. I'll leave it to Joe Wang to comment on the test but just to mention that jdk9/dev is probably a better forest to aim for because that is where the XML (and its tests) usually go. Also I wonder if it might be better to put it in the same directory as the test that Joe pushed with the change? If you are getting approval to push to jdk8u-dev and jdk7u-dev then it might be better to request a backport of Joe's change at the same time. -Alan.
Re: RFR(S): 8034087: XML parser may overwrite element content if that content falls onto the border of an entity scanner buffer
Hi Alan, you're right. I initially didn't saw the test because I just looked at the change in the jaxp repository. If it will be approved, I'll put the test in the same directory like the other test (i.e. test/javax/xml/jaxp/parsers/8027359). And yes, my plan was to get approval for both, the tests and the fix, when asking for the permission to downport to jdk8u-dev and jdk7u-dev. Thanks, Volker On Tue, Feb 11, 2014 at 5:44 PM, Alan Bateman alan.bate...@oracle.com wrote: On 11/02/2014 14:57, Volker Simonis wrote: Hi, after opening this bug yesterday for an issue found by my colleague Steffen Schreiber we realized that this is actually a duplicate of 8027359: XML parser returns incorrect parsing results (https://bugs.openjdk.java.net/browse/JDK-8027359). While there's no need now to submit a patch anymore, we'd nevertheless like to contribute at least our test case for this issue: http://cr.openjdk.java.net/~simonis/webrevs/8034087/ The webrev is against jdk9-client but we'd like to also downport this test to jdk7 and jdk8 to track that the fix for 8027359 will be correctly downported to these releases as well. I will sponsor this change if somebody would be so kind to review it. I'll leave it to Joe Wang to comment on the test but just to mention that jdk9/dev is probably a better forest to aim for because that is where the XML (and its tests) usually go. Also I wonder if it might be better to put it in the same directory as the test that Joe pushed with the change? If you are getting approval to push to jdk8u-dev and jdk7u-dev then it might be better to request a backport of Joe's change at the same time. -Alan.
Re: RFR (JAXP): 8033980 : Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl
Hi joe It looks like you changed the serialversionuid in Durationimpl, did it get changed incorrectly previously? Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Feb 10, 2014, at 6:53 PM, huizhe wang huizhe.w...@oracle.com wrote: Hi, This is an update from Xerces for two datatype classes XMLGregorianCalendarImpl and DurationImpl. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8033980 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8033980/webrev/ Tests included for: 1243, 1416, 1097 (Note that JDK did not have this bug) No test: 1343: remove unused code Existing tests: JAXP SQE and Unit tests passed. Thanks, Joe
Re: RFR (JAXP): 8033980 : Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl
On 2/11/14 5:55 PM, Lance @ Oracle wrote: Hi joe It looks like you changed the serialversionuid in Durationimpl, did it get changed incorrectly previously? I noticed that as well, but I'm not sure it matters since Duration uses writeReplace to serialize itself as an instance of SerializedDuration. Is that correct Joe? If I'm not mistaken it also means that the serialization forms (before after the change) are not compatible - but is that an issue for such internal classes? best regards, -- daniel Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Feb 10, 2014, at 6:53 PM, huizhe wang huizhe.w...@oracle.com wrote: Hi, This is an update from Xerces for two datatype classes XMLGregorianCalendarImpl and DurationImpl. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8033980 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8033980/webrev/ Tests included for: 1243, 1416, 1097 (Note that JDK did not have this bug) No test: 1343: remove unused code Existing tests: JAXP SQE and Unit tests passed. Thanks, Joe
Changeset rolled back: jdk8/tl/jdk: 7152892: some jtreg tests fail with permission denied
This changeset was erroneously pushed to jdk8/tl/jdk: Changeset: da4b0962ad11 Author:robm Date: 2014-02-10 14:35 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11 7152892: some jtreg tests fail with permission denied Reviewed-by: coffeys ! test/java/lang/ClassLoader/Assert.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/util/zip/ZipFile/ReadZip.java ! test/sun/net/www/protocol/jar/jarbug/run.sh It has been rolled back on the server and blacklisted in jcheck. If you have a clone of this repository then either strip this changeset or destroy the repository and re-clone it. - Mark
AtomicReference.compareAndSet allows multiple threads to succeed
If multiple threads call AtomicReference.compareAndSet with the same pair
of values, it appears that multiple threads may succeed. For example, if
multiple threads call compareAndSet(Alpha, Beta) then they may all
succeed. Is this the correct behaviour?
The documentation maybe should make this clear, as most developers and
tutorials seem to assume that the compareAndSet methods of the Atomic
classes guarantee that at most one thread will succeed.
I've included full demonstration code at the very bottom of this email. In
this demo, multiple threads are popping items from a stack and then pushing
items back on to the stack. I discovered that it was possible for two
threads to pop the same item from the stack, despite using compareAndSet to
modify the head of the stack. Specifically, this code did not work as
intended:
AtomicReferenceStackEntry stack = new AtomicReferenceStackEntry();
...
// Pop an entry from the top of the queue
StackEntry entry;
while (true) {
entry = stack.get();
if (entry == null)
break;
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry, entry.next))
break;
}
Peter.
Full demo code below:
--
public class AtomicReferenceTest {
private static final class StackEntry {
volatile Thread owner;
volatile StackEntry next;
}
private static final AtomicReferenceStackEntry stack = new
AtomicReferenceStackEntry();
private static class MyThread extends Thread {
@Override
public void run() {
while (true) {
/*
* Pop an entry off the top of the stack. The only way to exit
* this loop is to have found an empty stack, or to have
* ATOMICALLY replaced the head of the stack with the next item
* on the stack. In theory, no two threads should be able to
* exit this loop with the SAME entry...
*/
StackEntry entry;
while (true) {
entry = stack.get();
if (entry == null)
break;
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry, entry.next))
break;
}
/*
* If there was nothing on the stack, make a new entry.
* Otherwise, just set the 'next' to null. This isn't required
* but is good practice.
*/
if (entry == null)
entry = new StackEntry();
else
entry.next = null;
/*
* Check if the entry really was exclusively claimed. In theory,
* no two threads should ever have a reference to the same
* entry...
*/
Thread owner = entry.owner;
if (owner != null)
System.err.println(ALREADY CLAIMED BY + owner);
entry.owner = Thread.currentThread();
/* Push the entry back on to the queue. */
entry.owner = null;
while (true) {
entry.next = stack.get();
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry.next, entry))
break;
}
}
}
};
public static void main(String[] args) {
Thread[] threads = new Thread[8];
for (int i = 0; i threads.length; i++)
threads[i] = new MyThread();
for (int i = 0; i threads.length; i++)
threads[i].start();
}
}
--
*Actenum Corporation*
Peter Harvey | Cell: 780.729.8192 | har...@actenum.com |
www.actenum.com
Re: RFR (JAXP): 8033980 : Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl
On 2/11/2014 9:05 AM, Daniel Fuchs wrote: On 2/11/14 5:55 PM, Lance @ Oracle wrote: Hi joe It looks like you changed the serialversionuid in Durationimpl, did it get changed incorrectly previously? I noticed that as well, but I'm not sure it matters since Duration uses writeReplace to serialize itself as an instance of SerializedDuration. Is that correct Joe? Yes, it's serialized as an instance of SerializedDuration, similar to the calendar where it's SerializedXMLGregorianCalendar. If I'm not mistaken it also means that the serialization forms (before after the change) are not compatible - but is that an issue for such internal classes? Indeed, it's probably an issue since the binary is not compatible. It looks like this change should be rolled back. -Joe best regards, -- daniel Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Feb 10, 2014, at 6:53 PM, huizhe wang huizhe.w...@oracle.com wrote: Hi, This is an update from Xerces for two datatype classes XMLGregorianCalendarImpl and DurationImpl. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8033980 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8033980/webrev/ Tests included for: 1243, 1416, 1097 (Note that JDK did not have this bug) No test: 1343: remove unused code Existing tests: JAXP SQE and Unit tests passed. Thanks, Joe
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: AtomicReference.compareAndSet allows multiple threads to succeed
On 02/11/2014 01:41 PM, Peter Harvey wrote:
If multiple threads call AtomicReference.compareAndSet with the same pair
of values, it appears that multiple threads may succeed. For example, if
multiple threads call compareAndSet(Alpha, Beta) then they may all
succeed. Is this the correct behaviour?
Your example has an ABA problem.
See http://en.wikipedia.org/wiki/ABA_problem
(that uses a variant of this example to illustrate).
And/or try commenting out the
//if (entry == null)
entry = new StackEntry();
//else
//entry.next = null;
-Doug
The documentation maybe should make this clear, as most developers and
tutorials seem to assume that the compareAndSet methods of the Atomic
classes guarantee that at most one thread will succeed.
I've included full demonstration code at the very bottom of this email. In
this demo, multiple threads are popping items from a stack and then pushing
items back on to the stack. I discovered that it was possible for two
threads to pop the same item from the stack, despite using compareAndSet to
modify the head of the stack. Specifically, this code did not work as
intended:
AtomicReferenceStackEntry stack = new AtomicReferenceStackEntry();
...
// Pop an entry from the top of the queue
StackEntry entry;
while (true) {
entry = stack.get();
if (entry == null)
break;
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry, entry.next))
break;
}
Peter.
Full demo code below:
--
public class AtomicReferenceTest {
private static final class StackEntry {
volatile Thread owner;
volatile StackEntry next;
}
private static final AtomicReferenceStackEntry stack = new
AtomicReferenceStackEntry();
private static class MyThread extends Thread {
@Override
public void run() {
while (true) {
/*
* Pop an entry off the top of the stack. The only way to exit
* this loop is to have found an empty stack, or to have
* ATOMICALLY replaced the head of the stack with the next item
* on the stack. In theory, no two threads should be able to
* exit this loop with the SAME entry...
*/
StackEntry entry;
while (true) {
entry = stack.get();
if (entry == null)
break;
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry, entry.next))
break;
}
/*
* If there was nothing on the stack, make a new entry.
* Otherwise, just set the 'next' to null. This isn't required
* but is good practice.
*/
if (entry == null)
entry = new StackEntry();
else
entry.next = null;
/*
* Check if the entry really was exclusively claimed. In theory,
* no two threads should ever have a reference to the same
* entry...
*/
Thread owner = entry.owner;
if (owner != null)
System.err.println(ALREADY CLAIMED BY + owner);
entry.owner = Thread.currentThread();
/* Push the entry back on to the queue. */
entry.owner = null;
while (true) {
entry.next = stack.get();
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry.next, entry))
break;
}
}
}
};
public static void main(String[] args) {
Thread[] threads = new Thread[8];
for (int i = 0; i threads.length; i++)
threads[i] = new MyThread();
for (int i = 0; i threads.length; i++)
threads[i].start();
}
}
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. On 2/11/2014 11:14 AM, roger riggs wrote: Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
On 11/02/2014 19:57, Phil Race wrote: Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. If you hg export the change sets for 8030875 and 8031737 then do they hg import cleanly into 8u? That might be preferable to taking patches from webrevs. -Alan.
Re: AtomicReference.compareAndSet allows multiple threads to succeed
Thanks all for the responses. It is an ABA problem.
I changed my code so that it creates new StackEntries if multiple threads
attempt to pop the stack at the same time. This relies on getAndSet to
obtain exclusive access to the stack contents, rather than using
compareAndSet to update the stack.
I'll look into educating myself more on lock-free programming when I can.
For now, I'll be a lot more cautious when using compareAndSet.
Thanks again.
On Tue, Feb 11, 2014 at 11:41 AM, Peter Harvey har...@actenum.com wrote:
If multiple threads call AtomicReference.compareAndSet with the same pair
of values, it appears that multiple threads may succeed. For example, if
multiple threads call compareAndSet(Alpha, Beta) then they may all
succeed. Is this the correct behaviour?
The documentation maybe should make this clear, as most developers and
tutorials seem to assume that the compareAndSet methods of the Atomic
classes guarantee that at most one thread will succeed.
I've included full demonstration code at the very bottom of this email. In
this demo, multiple threads are popping items from a stack and then pushing
items back on to the stack. I discovered that it was possible for two
threads to pop the same item from the stack, despite using compareAndSet to
modify the head of the stack. Specifically, this code did not work as
intended:
AtomicReferenceStackEntry stack = new AtomicReferenceStackEntry();
...
// Pop an entry from the top of the queue
StackEntry entry;
while (true) {
entry = stack.get();
if (entry == null)
break;
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry, entry.next))
break;
}
Peter.
Full demo code below:
--
public class AtomicReferenceTest {
private static final class StackEntry {
volatile Thread owner;
volatile StackEntry next;
}
private static final AtomicReferenceStackEntry stack = new
AtomicReferenceStackEntry();
private static class MyThread extends Thread {
@Override
public void run() {
while (true) {
/*
* Pop an entry off the top of the stack. The only way to exit
* this loop is to have found an empty stack, or to have
* ATOMICALLY replaced the head of the stack with the next item
* on the stack. In theory, no two threads should be able to
* exit this loop with the SAME entry...
*/
StackEntry entry;
while (true) {
entry = stack.get();
if (entry == null)
break;
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry, entry.next))
break;
}
/*
* If there was nothing on the stack, make a new entry.
* Otherwise, just set the 'next' to null. This isn't required
* but is good practice.
*/
if (entry == null)
entry = new StackEntry();
else
entry.next = null;
/*
* Check if the entry really was exclusively claimed. In theory,
* no two threads should ever have a reference to the same
* entry...
*/
Thread owner = entry.owner;
if (owner != null)
System.err.println(ALREADY CLAIMED BY + owner);
entry.owner = Thread.currentThread();
/* Push the entry back on to the queue. */
entry.owner = null;
while (true) {
entry.next = stack.get();
// Atomic, right? Only one thread can succeed...
if (stack.compareAndSet(entry.next, entry))
break;
}
}
}
};
public static void main(String[] args) {
Thread[] threads = new Thread[8];
for (int i = 0; i threads.length; i++)
threads[i] = new MyThread();
for (int i = 0; i threads.length; i++)
threads[i].start();
}
}
--
*Actenum Corporation*
Peter Harvey | Cell: 780.729.8192 | har...@actenum.com |
www.actenum.com
--
*Actenum Corporation*
Peter Harvey | Cell: 780.729.8192 | har...@actenum.com |
www.actenum.com
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
Roger, That later one seems to be using the macros. I don't see any update to the macros. So I'm not sure why I'm need it .. since I'm not using those calls and neither are the macros. -phil. On 2/11/14 12:28 PM, roger riggs wrote: Hi Phil, Yes, it ended up in two change sets in jdk 9, you should take both to be up to date. changeset: 9245:a09982d91fab user:rriggs date:Wed Feb 05 10:59:53 2014 -0500 files: src/share/native/common/jni_util.c description: 8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions changeset: 9229:fb89dc4fe8da date:Mon Feb 03 16:58:02 2014 -0500 files: src/share/native/common/jni_util.h src/share/native/sun/misc/Version.c interrupted! description: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Thanks, Roger On 2/11/2014 2:57 PM, Phil Race wrote: Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. On 2/11/2014 11:14 AM, roger riggs wrote: Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
hg: jdk8/tl/langtools: 7 new changesets
Changeset: 9a4dbfe11ed1 Author:katleman Date: 2014-01-22 12:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9a4dbfe11ed1 Added tag jdk8-b125 for changeset 436176151e85 ! .hgtags Changeset: ba24b6304362 Author:katleman Date: 2014-01-22 14:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ba24b6304362 Merge ! .hgtags Changeset: 305b97f4651b Author:katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/305b97f4651b Added tag jdk8-b126 for changeset ba24b6304362 ! .hgtags Changeset: bb69217ed812 Author:lana Date: 2014-01-29 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb69217ed812 Merge Changeset: 09cdd3b493c0 Author:katleman Date: 2014-01-30 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09cdd3b493c0 Added tag jdk8-b127 for changeset bb69217ed812 ! .hgtags Changeset: 8fe7202d3c38 Author:katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8fe7202d3c38 Added tag jdk8-b128 for changeset 09cdd3b493c0 ! .hgtags Changeset: 9d81ae1c417a Author:katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d81ae1c417a Added tag jdk8-b129 for changeset 8fe7202d3c38 ! .hgtags
hg: jdk8/tl/corba: 7 new changesets
Changeset: 18c4d03cf516 Author:katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/18c4d03cf516 Added tag jdk8-b125 for changeset 7b45151c7a05 ! .hgtags Changeset: 8ceb68fd9e10 Author:katleman Date: 2014-01-22 14:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8ceb68fd9e10 Merge ! .hgtags Changeset: cfa04e69b115 Author:katleman Date: 2014-01-24 15:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cfa04e69b115 Added tag jdk8-b126 for changeset 8ceb68fd9e10 ! .hgtags Changeset: b8c71dae0557 Author:lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b8c71dae0557 Merge Changeset: 113e7569b49b Author:katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/113e7569b49b Added tag jdk8-b127 for changeset b8c71dae0557 ! .hgtags Changeset: 5c72d74c6805 Author:katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5c72d74c6805 Added tag jdk8-b128 for changeset 113e7569b49b ! .hgtags Changeset: eea0d7dfcbe2 Author:katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/eea0d7dfcbe2 Added tag jdk8-b129 for changeset 5c72d74c6805 ! .hgtags
hg: jdk8/tl/jaxp: 7 new changesets
Changeset: 6a5af8a36aaf Author:katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6a5af8a36aaf Added tag jdk8-b125 for changeset 83bb924238f8 ! .hgtags Changeset: 390cc275c04c Author:katleman Date: 2014-01-22 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/390cc275c04c Merge ! .hgtags Changeset: 573c261a2025 Author:katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/573c261a2025 Added tag jdk8-b126 for changeset 390cc275c04c ! .hgtags Changeset: b68cdb63a70b Author:lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b68cdb63a70b Merge Changeset: b1839922f10c Author:katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b1839922f10c Added tag jdk8-b127 for changeset b68cdb63a70b ! .hgtags Changeset: b7752cea7c81 Author:katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b7752cea7c81 Added tag jdk8-b128 for changeset b1839922f10c ! .hgtags Changeset: 0cb0cd015218 Author:katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0cb0cd015218 Added tag jdk8-b129 for changeset b7752cea7c81 ! .hgtags
hg: jdk8/tl/jaxws: 7 new changesets
Changeset: c0040f0b75e2 Author:katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c0040f0b75e2 Added tag jdk8-b125 for changeset ef71ecbcd7bc ! .hgtags Changeset: 7193a007a159 Author:katleman Date: 2014-01-22 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7193a007a159 Merge ! .hgtags Changeset: 3f682f2ea376 Author:katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3f682f2ea376 Added tag jdk8-b126 for changeset 7193a007a159 ! .hgtags Changeset: 8e46fe36e175 Author:lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8e46fe36e175 Merge Changeset: de172acc095b Author:katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/de172acc095b Added tag jdk8-b127 for changeset 8e46fe36e175 ! .hgtags Changeset: aabc90596123 Author:katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/aabc90596123 Added tag jdk8-b128 for changeset de172acc095b ! .hgtags Changeset: 4195c0956930 Author:katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/4195c0956930 Added tag jdk8-b129 for changeset aabc90596123 ! .hgtags
hg: jdk8/tl/nashorn: 8 new changesets
Changeset: d336209a0e45 Author:katleman Date: 2014-01-22 12:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d336209a0e45 Added tag jdk8-b125 for changeset 7346abe2ea03 ! .hgtags Changeset: 095263db862d Author:katleman Date: 2014-01-22 14:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/095263db862d Merge ! .hgtags Changeset: e2522604c7c9 Author:katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e2522604c7c9 Added tag jdk8-b126 for changeset 095263db862d ! .hgtags Changeset: fdfbb745caf0 Author:lana Date: 2014-01-29 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fdfbb745caf0 Merge Changeset: 7dfde83426d1 Author:katleman Date: 2014-01-30 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7dfde83426d1 Added tag jdk8-b127 for changeset fdfbb745caf0 ! .hgtags Changeset: 73cbad0c5d28 Author:lana Date: 2014-01-31 13:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/73cbad0c5d28 Merge Changeset: 9cc3fd32fbab Author:katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9cc3fd32fbab Added tag jdk8-b128 for changeset 73cbad0c5d28 ! .hgtags Changeset: f87eba70e9ee Author:katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f87eba70e9ee Added tag jdk8-b129 for changeset 9cc3fd32fbab ! .hgtags
hg: jdk8/tl/hotspot: 23 new changesets
Changeset: 16e0c6c84a91 Author:amurillo Date: 2014-01-13 16:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16e0c6c84a91 8031553: new hotspot build - hs25-b67 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 12ad8db39f76 Author:roland Date: 2014-01-14 09:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12ad8db39f76 8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a Summary: C1 generates code to encode compressed oop into tmp register before runtime call for patching where GC may happen Reviewed-by: iveresov, twisti, kvn Contributed-by: mgerdin mikael.ger...@oracle.com ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 8b81451dc7f7 Author:twisti Date: 2014-01-16 16:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b81451dc7f7 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 3585183c191a Author:amurillo Date: 2014-01-17 20:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3585183c191a Merge Changeset: 5df2666e4573 Author:amurillo Date: 2014-01-17 20:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5df2666e4573 Added tag hs25-b67 for changeset 3585183c191a ! .hgtags Changeset: 55ff9170e27d Author:katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55ff9170e27d Added tag jdk8-b125 for changeset df333ee12bba ! .hgtags Changeset: c8218f1072a0 Author:katleman Date: 2014-01-22 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8218f1072a0 Merge ! .hgtags Changeset: 9a11d5e679cf Author:katleman Date: 2014-01-24 15:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a11d5e679cf Added tag jdk8-b126 for changeset c8218f1072a0 ! .hgtags Changeset: c2106608358b Author:amurillo Date: 2014-01-17 20:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c2106608358b 8032015: new hotspot build - hs25-b68 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 709018897c81 Author:vlivanov Date: 2014-01-23 01:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/709018897c81 8031695: CHA ignores default methods during analysis leading to incorrect code generation Reviewed-by: jrose, acorn, hseigel, lfoltan ! src/share/vm/code/dependencies.cpp + test/compiler/inlining/DefaultAndConcreteMethodsCHA.java Changeset: f970454708b8 Author:iveresov Date: 2014-01-17 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f970454708b8 8032207: C2: assert(VerifyOops || MachNode::size(ra_) = (3+1)*4) failed: bad fixed size Summary: Fix the sizing of loadUS2L_immI16 and loadI2L_immI Reviewed-by: kvn, azeemj ! src/cpu/sparc/vm/sparc.ad + test/compiler/codegen/LoadWithMask.java Changeset: 984401824c5e Author:iveresov Date: 2014-01-21 20:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/984401824c5e 8031743: C2: loadI2L_immI broken for negative memory values Summary: Restrict loadI2L_imm optimizations to positive values of mask Reviewed-by: kvn, dlong ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + test/compiler/codegen/LoadWithMask2.java Changeset: d45454002494 Author:amurillo Date: 2014-01-23 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d45454002494 Merge Changeset: 2c564e329c87 Author:amurillo Date: 2014-01-23 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c564e329c87 Added tag hs25-b68 for changeset d45454002494 ! .hgtags Changeset: 58879cd9f8df Author:amurillo Date: 2014-01-28 09:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58879cd9f8df Merge ! .hgtags Changeset: 7e412f95e310 Author:amurillo Date: 2014-01-23 13:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e412f95e310 8032608: new hotspot build - hs25-b69 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 2185d483f5f8 Author:kvn Date: 2014-01-27 10:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2185d483f5f8 8032566: Crash in JIT when running Scala compiler (and compiling Scala std lib) Summary: Switch off EliminateAutoBox flag by default in jdk8 release. Reviewed-by: iveresov ! src/share/vm/opto/c2_globals.hpp Changeset: 32f017489ba5 Author:amurillo Date: 2014-01-28 15:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32f017489ba5 Merge Changeset: 1d8728efc05f Author:amurillo Date: 2014-01-28 15:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d8728efc05f Added tag hs25-b69 for changeset 32f017489ba5 ! .hgtags Changeset: 35038da7bb9d Author:lana Date:
hg: jdk8/tl/jdk: 14 new changesets
Changeset: 75cf17ceb6d1 Author:katleman Date: 2014-01-22 12:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75cf17ceb6d1 Added tag jdk8-b125 for changeset ae303640bc1c ! .hgtags Changeset: 95410515ba5f Author:katleman Date: 2014-01-22 14:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95410515ba5f Merge ! .hgtags Changeset: 91bce40d0347 Author:alexsch Date: 2014-01-23 20:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91bce40d0347 8032063: javax.swing.plaf.metal.MetalFileChooserUI$FilterComboBoxModel extends non-standard API Reviewed-by: pchelko, serb ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java - src/share/classes/sun/swing/AbstractFilterComboBoxModel.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 6935e7a3a7c9 Author:amurillo Date: 2014-01-23 14:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6935e7a3a7c9 Merge Changeset: a9088d517f2f Author:amurillo Date: 2014-01-23 14:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a9088d517f2f Merge Changeset: a635c394328c Author:katleman Date: 2014-01-24 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a635c394328c Added tag jdk8-b126 for changeset a9088d517f2f ! .hgtags Changeset: fbf251b8ef8a Author:lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbf251b8ef8a Merge Changeset: f777d83e0433 Author:katleman Date: 2014-01-30 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f777d83e0433 Added tag jdk8-b127 for changeset fbf251b8ef8a ! .hgtags Changeset: f644211c59fd Author:lana Date: 2014-01-31 13:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f644211c59fd Merge Changeset: 3c9473004f38 Author:katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c9473004f38 Added tag jdk8-b128 for changeset f644211c59fd ! .hgtags Changeset: ab6e7bb8ff9f Author:pchelko Date: 2014-01-22 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab6e7bb8ff9f 7155984: Security problems in regression test java/awt/PrintJob/Security/SecurityDialogTest.java Reviewed-by: anthony, serb ! src/macosx/classes/apple/laf/JRSUIUtils.java Changeset: eef10feca8ca Author:lana Date: 2014-02-06 13:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eef10feca8ca Merge Changeset: 80568a19aab7 Author:lana Date: 2014-02-06 13:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80568a19aab7 Merge Changeset: 43386cc9a017 Author:katleman Date: 2014-02-06 17:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43386cc9a017 Added tag jdk8-b129 for changeset 80568a19aab7 ! .hgtags
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
Hi Phil, The later changeset picked up the recommended style of implementing the macros but I don't think it was substantive. You can probably do without it. Version.c had some changes in a different changeset to address the omission of checking for exceptions after some JNI calls. Roger On 2/11/2014 4:39 PM, Phil Race wrote: Roger, That later one seems to be using the macros. I don't see any update to the macros. So I'm not sure why I'm need it .. since I'm not using those calls and neither are the macros. -phil. On 2/11/14 12:28 PM, roger riggs wrote: Hi Phil, Yes, it ended up in two change sets in jdk 9, you should take both to be up to date. changeset: 9245:a09982d91fab user:rriggs date:Wed Feb 05 10:59:53 2014 -0500 files: src/share/native/common/jni_util.c description: 8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions changeset: 9229:fb89dc4fe8da date:Mon Feb 03 16:58:02 2014 -0500 files: src/share/native/common/jni_util.h src/share/native/sun/misc/Version.c interrupted! description: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Thanks, Roger On 2/11/2014 2:57 PM, Phil Race wrote: Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. On 2/11/2014 11:14 AM, roger riggs wrote: Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: RFR(S): 8034087: XML parser may overwrite element content if that content falls onto the border of an entity scanner buffer
Hi Volker,
I agree with the approach below and jdk9/dev is the better forest.
For the test itself, I would suggest reducing the following loop to 1 or
2 cases:
for (int i = 0; i testString.length(); i++) {
test(createDocument(testString.toString(), i), + i);
}
when i=7, the problem starts to show. It's sufficient to demonstrate the
issue then by just entering 7. It's unnecessary to run the test 43 times.
Thanks,
Joe
On 2/11/2014 9:00 AM, Volker Simonis wrote:
Hi Alan,
you're right. I initially didn't saw the test because I just looked at
the change in the jaxp repository.
If it will be approved, I'll put the test in the same directory like
the other test (i.e. test/javax/xml/jaxp/parsers/8027359).
And yes, my plan was to get approval for both, the tests and the fix,
when asking for the permission to downport to jdk8u-dev and jdk7u-dev.
Thanks,
Volker
On Tue, Feb 11, 2014 at 5:44 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 11/02/2014 14:57, Volker Simonis wrote:
Hi,
after opening this bug yesterday for an issue found by my colleague
Steffen Schreiber we realized that this is actually a duplicate of
8027359: XML parser returns incorrect parsing results
(https://bugs.openjdk.java.net/browse/JDK-8027359).
While there's no need now to submit a patch anymore, we'd
nevertheless like to contribute at least our test case for this issue:
http://cr.openjdk.java.net/~simonis/webrevs/8034087/
The webrev is against jdk9-client but we'd like to also downport this
test to jdk7 and jdk8 to track that the fix for 8027359 will be
correctly downported to these releases as well.
I will sponsor this change if somebody would be so kind to review it.
I'll leave it to Joe Wang to comment on the test but just to mention that
jdk9/dev is probably a better forest to aim for because that is where the
XML (and its tests) usually go. Also I wonder if it might be better to put
it in the same directory as the test that Joe pushed with the change?
If you are getting approval to push to jdk8u-dev and jdk7u-dev then it might
be better to request a backport of Joe's change at the same time.
-Alan.
hg: jdk8/tl: 8 new changesets
Changeset: 950921234b10 Author:katleman Date: 2014-01-22 12:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/950921234b10 Added tag jdk8-b125 for changeset 790bbd46b201 ! .hgtags Changeset: 1b5d578f93ef Author:katleman Date: 2014-01-22 14:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1b5d578f93ef Merge ! .hgtags Changeset: 9ccce5bf1b0e Author:katleman Date: 2014-01-24 04:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9ccce5bf1b0e Merge Changeset: 4f8fa4724c14 Author:katleman Date: 2014-01-24 15:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4f8fa4724c14 Added tag jdk8-b126 for changeset 9ccce5bf1b0e ! .hgtags Changeset: 2e2ffb9e4b69 Author:lana Date: 2014-01-29 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2e2ffb9e4b69 Merge Changeset: 101e42de4686 Author:katleman Date: 2014-01-30 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/101e42de4686 Added tag jdk8-b127 for changeset 2e2ffb9e4b69 ! .hgtags Changeset: 1e5fe8654913 Author:katleman Date: 2014-02-01 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1e5fe8654913 Added tag jdk8-b128 for changeset 101e42de4686 ! .hgtags Changeset: 839546caab12 Author:katleman Date: 2014-02-06 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/839546caab12 Added tag jdk8-b129 for changeset 1e5fe8654913 ! .hgtags
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
Are we talking about the same changesets ? a09982d91fab/8030993 has no change to the macros fb89dc4fe8da/8031737 is the one that reimplemented the macros and is the version I'd want. Its the last 'edit' of those macros in that file. c58c6b0fbe34/8030875 is the original addition of these :- ... changeset: 9229:fb89dc4fe8da user:rriggs date:Mon Feb 03 16:58:02 2014 -0500 summary: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup changeset: 9051:c58c6b0fbe34 user:rriggs date:Fri Jan 10 10:45:56 2014 -0500 summary: 8030875: Macros for checking and returning on exceptions ... -phil. On 2/11/14 1:48 PM, roger riggs wrote: Hi Phil, The later changeset picked up the recommended style of implementing the macros but I don't think it was substantive. You can probably do without it. Version.c had some changes in a different changeset to address the omission of checking for exceptions after some JNI calls. Roger On 2/11/2014 4:39 PM, Phil Race wrote: Roger, That later one seems to be using the macros. I don't see any update to the macros. So I'm not sure why I'm need it .. since I'm not using those calls and neither are the macros. -phil. On 2/11/14 12:28 PM, roger riggs wrote: Hi Phil, Yes, it ended up in two change sets in jdk 9, you should take both to be up to date. changeset: 9245:a09982d91fab user:rriggs date:Wed Feb 05 10:59:53 2014 -0500 files: src/share/native/common/jni_util.c description: 8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions changeset: 9229:fb89dc4fe8da date:Mon Feb 03 16:58:02 2014 -0500 files: src/share/native/common/jni_util.h src/share/native/sun/misc/Version.c interrupted! description: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Thanks, Roger On 2/11/2014 2:57 PM, Phil Race wrote: Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. On 2/11/2014 11:14 AM, roger riggs wrote: Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
Hi Phil, On 2/11/2014 5:09 PM, Phil Race wrote: Are we talking about the same changesets ? a09982d91fab/8030993 has no change to the macros right (I didn't think this was topic of this conversation) fb89dc4fe8da/8031737 is the one that reimplemented the macros and is the version I'd want. Its the last 'edit' of those macros in that file. yes, c58c6b0fbe34/8030875 is the original addition of these :- Yes. Roger ... changeset: 9229:fb89dc4fe8da user:rriggs date:Mon Feb 03 16:58:02 2014 -0500 summary: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup changeset: 9051:c58c6b0fbe34 user:rriggs date:Fri Jan 10 10:45:56 2014 -0500 summary: 8030875: Macros for checking and returning on exceptions ... -phil. On 2/11/14 1:48 PM, roger riggs wrote: Hi Phil, The later changeset picked up the recommended style of implementing the macros but I don't think it was substantive. You can probably do without it. Version.c had some changes in a different changeset to address the omission of checking for exceptions after some JNI calls. Roger On 2/11/2014 4:39 PM, Phil Race wrote: Roger, That later one seems to be using the macros. I don't see any update to the macros. So I'm not sure why I'm need it .. since I'm not using those calls and neither are the macros. -phil. On 2/11/14 12:28 PM, roger riggs wrote: Hi Phil, Yes, it ended up in two change sets in jdk 9, you should take both to be up to date. changeset: 9245:a09982d91fab user:rriggs date:Wed Feb 05 10:59:53 2014 -0500 files: src/share/native/common/jni_util.c description: 8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions changeset: 9229:fb89dc4fe8da date:Mon Feb 03 16:58:02 2014 -0500 files: src/share/native/common/jni_util.h src/share/native/sun/misc/Version.c interrupted! description: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Thanks, Roger On 2/11/2014 2:57 PM, Phil Race wrote: Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. On 2/11/2014 11:14 AM, roger riggs wrote: Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
So since hg export/import doesn't apply cleanly and the dependency chain seems, long and in order to have some consistency across the releases, I think I should prepare a webrev which essentially backports 8031737 including its small changes to Version.c, if only because otherwise I'd have to have a new bug ID that would not be forwarded ported (one source of confusion) or even worse re-use 8031737 but not fully implement it Agreed ? -phil. On 2/11/2014 2:20 PM, roger riggs wrote: Hi Phil, On 2/11/2014 5:09 PM, Phil Race wrote: Are we talking about the same changesets ? a09982d91fab/8030993 has no change to the macros right (I didn't think this was topic of this conversation) fb89dc4fe8da/8031737 is the one that reimplemented the macros and is the version I'd want. Its the last 'edit' of those macros in that file. yes, c58c6b0fbe34/8030875 is the original addition of these :- Yes. Roger ... changeset: 9229:fb89dc4fe8da user:rriggs date:Mon Feb 03 16:58:02 2014 -0500 summary: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup changeset: 9051:c58c6b0fbe34 user:rriggs date:Fri Jan 10 10:45:56 2014 -0500 summary: 8030875: Macros for checking and returning on exceptions ... -phil. On 2/11/14 1:48 PM, roger riggs wrote: Hi Phil, The later changeset picked up the recommended style of implementing the macros but I don't think it was substantive. You can probably do without it. Version.c had some changes in a different changeset to address the omission of checking for exceptions after some JNI calls. Roger On 2/11/2014 4:39 PM, Phil Race wrote: Roger, That later one seems to be using the macros. I don't see any update to the macros. So I'm not sure why I'm need it .. since I'm not using those calls and neither are the macros. -phil. On 2/11/14 12:28 PM, roger riggs wrote: Hi Phil, Yes, it ended up in two change sets in jdk 9, you should take both to be up to date. changeset: 9245:a09982d91fab user:rriggs date:Wed Feb 05 10:59:53 2014 -0500 files: src/share/native/common/jni_util.c description: 8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions changeset: 9229:fb89dc4fe8da date:Mon Feb 03 16:58:02 2014 -0500 files: src/share/native/common/jni_util.h src/share/native/sun/misc/Version.c interrupted! description: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Thanks, Roger On 2/11/2014 2:57 PM, Phil Race wrote: Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. On 2/11/2014 11:14 AM, roger riggs wrote: Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
yes On 2/11/2014 5:28 PM, Phil Race wrote: So since hg export/import doesn't apply cleanly and the dependency chain seems, long and in order to have some consistency across the releases, I think I should prepare a webrev which essentially backports 8031737 including its small changes to Version.c, if only because otherwise I'd have to have a new bug ID that would not be forwarded ported (one source of confusion) or even worse re-use 8031737 but not fully implement it Agreed ? -phil. On 2/11/2014 2:20 PM, roger riggs wrote: Hi Phil, On 2/11/2014 5:09 PM, Phil Race wrote: Are we talking about the same changesets ? a09982d91fab/8030993 has no change to the macros right (I didn't think this was topic of this conversation) fb89dc4fe8da/8031737 is the one that reimplemented the macros and is the version I'd want. Its the last 'edit' of those macros in that file. yes, c58c6b0fbe34/8030875 is the original addition of these :- Yes. Roger ... changeset: 9229:fb89dc4fe8da user:rriggs date:Mon Feb 03 16:58:02 2014 -0500 summary: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup changeset: 9051:c58c6b0fbe34 user:rriggs date:Fri Jan 10 10:45:56 2014 -0500 summary: 8030875: Macros for checking and returning on exceptions ... -phil. On 2/11/14 1:48 PM, roger riggs wrote: Hi Phil, The later changeset picked up the recommended style of implementing the macros but I don't think it was substantive. You can probably do without it. Version.c had some changes in a different changeset to address the omission of checking for exceptions after some JNI calls. Roger On 2/11/2014 4:39 PM, Phil Race wrote: Roger, That later one seems to be using the macros. I don't see any update to the macros. So I'm not sure why I'm need it .. since I'm not using those calls and neither are the macros. -phil. On 2/11/14 12:28 PM, roger riggs wrote: Hi Phil, Yes, it ended up in two change sets in jdk 9, you should take both to be up to date. changeset: 9245:a09982d91fab user:rriggs date:Wed Feb 05 10:59:53 2014 -0500 files: src/share/native/common/jni_util.c description: 8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions changeset: 9229:fb89dc4fe8da date:Mon Feb 03 16:58:02 2014 -0500 files: src/share/native/common/jni_util.h src/share/native/sun/misc/Version.c interrupted! description: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Thanks, Roger On 2/11/2014 2:57 PM, Phil Race wrote: Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. On 2/11/2014 11:14 AM, roger riggs wrote: Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup
Here's a JDk8u webrev : -http://cr.openjdk.java.net/~prr/8031737.8u/ -phil. On 2/11/14 2:28 PM, Phil Race wrote: So since hg export/import doesn't apply cleanly and the dependency chain seems, long and in order to have some consistency across the releases, I think I should prepare a webrev which essentially backports 8031737 including its small changes to Version.c, if only because otherwise I'd have to have a new bug ID that would not be forwarded ported (one source of confusion) or even worse re-use 8031737 but not fully implement it Agreed ? -phil. On 2/11/2014 2:20 PM, roger riggs wrote: Hi Phil, On 2/11/2014 5:09 PM, Phil Race wrote: Are we talking about the same changesets ? a09982d91fab/8030993 has no change to the macros right (I didn't think this was topic of this conversation) fb89dc4fe8da/8031737 is the one that reimplemented the macros and is the version I'd want. Its the last 'edit' of those macros in that file. yes, c58c6b0fbe34/8030875 is the original addition of these :- Yes. Roger ... changeset: 9229:fb89dc4fe8da user:rriggs date:Mon Feb 03 16:58:02 2014 -0500 summary: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup changeset: 9051:c58c6b0fbe34 user:rriggs date:Fri Jan 10 10:45:56 2014 -0500 summary: 8030875: Macros for checking and returning on exceptions ... -phil. On 2/11/14 1:48 PM, roger riggs wrote: Hi Phil, The later changeset picked up the recommended style of implementing the macros but I don't think it was substantive. You can probably do without it. Version.c had some changes in a different changeset to address the omission of checking for exceptions after some JNI calls. Roger On 2/11/2014 4:39 PM, Phil Race wrote: Roger, That later one seems to be using the macros. I don't see any update to the macros. So I'm not sure why I'm need it .. since I'm not using those calls and neither are the macros. -phil. On 2/11/14 12:28 PM, roger riggs wrote: Hi Phil, Yes, it ended up in two change sets in jdk 9, you should take both to be up to date. changeset: 9245:a09982d91fab user:rriggs date:Wed Feb 05 10:59:53 2014 -0500 files: src/share/native/common/jni_util.c description: 8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions changeset: 9229:fb89dc4fe8da date:Mon Feb 03 16:58:02 2014 -0500 files: src/share/native/common/jni_util.h src/share/native/sun/misc/Version.c interrupted! description: 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Thanks, Roger On 2/11/2014 2:57 PM, Phil Race wrote: Roger, Yes, I can do that. I see here http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ that 1) There was a previous version of these macros. Looks like no need to worry about that I just need the latest version. 2) There was also a change to Version.c. I can include that if you think it appropriate .. or omit it if you think its not essential. -phil. On 2/11/2014 11:14 AM, roger riggs wrote: Hi Phil, I see your point, there is nothing in the changes unique to 9. Do you want to take care of the back point? Roger On 2/11/2014 2:04 PM, Phil Race wrote: Roger, Why not JDK 8u ? I've got a lot of changes that utilise these that will backport cleanly to JDK 8u only if 8u includes these macros. And since the changes are all over the place I don't fancy copy/pasting them everywhere. I suspect I am not the only one who would like these in 8u .. -phil. On 02/03/2014 01:48 PM, roger riggs wrote: Hi Lance, The convenience macros are only intended for JDK 9. Roger On 2/1/2014 1:58 PM, Lance @ Oracle wrote: Looks fine Which releases are you think of including this in if any besides 9? http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Feb 1, 2014, at 1:03 PM, roger riggs roger.ri...@oracle.com mailto:roger.ri...@oracle.com wrote:
Re: RFR for JDK-8030844:sun/rmi/rmic/classpath/RMICClassPathTest.java timeout in same binaries run
Hi, yes, I'll take this one. It's slightly odd that this is creating filenames that already have / in them (as opposed to File.separator) but since these files don't actually have to exist, I suppose it doesn't really matter. I'm not convinced that we actually have any evidence that /home/~user is really causing the hang/timeout (either caused by the automounter hanging on /home or LDAP or other nameservice lookup on ~user), but this is harmless, and it'll fix the problem on the off chance that this really is the root cause. Tristan, please update the test's @bug tag to add 8030844, create a changeset, and create a webrev with the changeset in it (as opposed to a bare patch). I'll then push it for you. s'marks On 2/10/14 4:08 AM, Alan Bateman wrote: On 10/02/2014 10:57, Tristan Yan wrote: Ping: Can anyone give a review on this. Thank you Tristan Changing the test so that it doesn't try to /home/~user seems reasonable to me. Stuart - I see you've been sponsoring Tristan's updates to the RMI tests. Are you going to take this one too? -Alan On Feb 6, 2014, at 5:13 PM, Tristan Yantristan@oracle.com wrote: Hi All Please help to review a simple fix for https://bugs.openjdk.java.net/browse/JDK-8030844 http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.00/. Description: Change replace a “/home/~user folder with an test source path. Folder “/home/~user” cause some problem whenever something wrong with the automount filesystem or an username lookup problem. Thank you Tristan
Re: RFR for JDK-8030844:sun/rmi/rmic/classpath/RMICClassPathTest.java timeout in same binaries run
Thank you Stuart http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.01/ Regards Tristan On Feb 12, 2014, at 10:06 AM, Stuart Marks stuart.ma...@oracle.com wrote: Hi, yes, I'll take this one. It's slightly odd that this is creating filenames that already have / in them (as opposed to File.separator) but since these files don't actually have to exist, I suppose it doesn't really matter. I'm not convinced that we actually have any evidence that /home/~user is really causing the hang/timeout (either caused by the automounter hanging on /home or LDAP or other nameservice lookup on ~user), but this is harmless, and it'll fix the problem on the off chance that this really is the root cause. Tristan, please update the test's @bug tag to add 8030844, create a changeset, and create a webrev with the changeset in it (as opposed to a bare patch). I'll then push it for you. s'marks On 2/10/14 4:08 AM, Alan Bateman wrote: On 10/02/2014 10:57, Tristan Yan wrote: Ping: Can anyone give a review on this. Thank you Tristan Changing the test so that it doesn't try to /home/~user seems reasonable to me. Stuart - I see you've been sponsoring Tristan's updates to the RMI tests. Are you going to take this one too? -Alan On Feb 6, 2014, at 5:13 PM, Tristan Yantristan@oracle.com wrote: Hi All Please help to review a simple fix for https://bugs.openjdk.java.net/browse/JDK-8030844 http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.00/. Description: Change replace a “/home/~user folder with an test source path. Folder “/home/~user” cause some problem whenever something wrong with the automount filesystem or an username lookup problem. Thank you Tristan
Re: RFR (JAXP): 8033980 : Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl
Hi Lance, Daniel, I suggest we take this incompatibility and document it in the release notes (we'll likely have more). I reversed DurationImpl and then realized why the Xerces engineers made the incompatibility change when I started on XMLGregorianCalendarImpl. It was because XMLGregorianCalendarImpl did not implement what was recommended, using the lexical form for serialization. In the original implementation therefore, the impl between XMLGregorianCalendarImpl and DurationImpl was not consistent. Keeping this Xerces revision makes the serialization consistent in both classes and adds the benefit of having the same source as that of Xerces. Thanks, Joe On 2/11/2014 10:56 AM, huizhe wang wrote: On 2/11/2014 9:05 AM, Daniel Fuchs wrote: On 2/11/14 5:55 PM, Lance @ Oracle wrote: Hi joe It looks like you changed the serialversionuid in Durationimpl, did it get changed incorrectly previously? I noticed that as well, but I'm not sure it matters since Duration uses writeReplace to serialize itself as an instance of SerializedDuration. Is that correct Joe? Yes, it's serialized as an instance of SerializedDuration, similar to the calendar where it's SerializedXMLGregorianCalendar. If I'm not mistaken it also means that the serialization forms (before after the change) are not compatible - but is that an issue for such internal classes? Indeed, it's probably an issue since the binary is not compatible. It looks like this change should be rolled back. -Joe best regards, -- daniel Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Feb 10, 2014, at 6:53 PM, huizhe wang huizhe.w...@oracle.com wrote: Hi, This is an update from Xerces for two datatype classes XMLGregorianCalendarImpl and DurationImpl. For details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8033980 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8033980/webrev/ Tests included for: 1243, 1416, 1097 (Note that JDK did not have this bug) No test: 1343: remove unused code Existing tests: JAXP SQE and Unit tests passed. Thanks, Joe
Re: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently
Thank you for your thorough mail. This is very educational. I took you advice and generated a new webrev for this. http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.03/ I appreciate you can review this again. Regards Tristan On Feb 11, 2014, at 8:32 AM, Stuart Marks stuart.ma...@oracle.com wrote: Hi Tristan, Sorry about my recurring delays. Several comments on these changes. JavaVM.java -- The waitFor(timeout) method is mostly ok. The new thread started at line 208 and following seems unnecessary, though. This code is reached when a timeout occurs, so throwing TimeoutException is the only thing necessary in this case. Should the code to start the new thread be removed? There should be a similar check for vm == null as in the waitFor() [no args] method. ShutdownGracefully.java -- The condition that's checked after calling rmid.waitFor(SHUTDOWN_TIMEOUT) is incorrect. It's testing the exit status against zero. Offhand, when and if rmid exits, it might exit with a nonzero exit status. If rmid has exited at this point, then the test should succeed. Instead of testing against zero, the code should catch TimeoutException, which means that rmid is still running. It's probably reasonable to catch TimeoutException, print a message, and then let the finally-block destroy the rmid. Calling TestLibrary.bomb() from within the try-block is confusing, since that method throws an exception, which is then caught by the catch-block, when then calls TestLibrary.bomb() again. We should also make sure to test the success case properly. If rmid.waitFor() returns in a timely fashion without throwing TimeoutException, it doesn't matter what the exit status is. (It might be worth printing it out.) At that point we know that rmid *has* exited gracefully, so we need to set rmid to null so that the finally-block doesn't attempt to destroy rmid redundantly. Some additional messages about rmid having exited and the test passing are also warranted for this case. Some additional cleanup can be done here as well, over and above the changes you've proposed. (This stuff is left over from earlier RMI test messes.) In order to shut down an active object, the code here spawns a new thread that sleeps for a while and then deactivates this object. This isn't necessary. (It might have been necessary in the past.) It's sufficient simply to unexport this object and then deactivate it, directly within the shutdown() method. See test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java for an example of this. In addition, the run() method can be removed, and the implements Runnable declaration can also be removed from the ShutdownGracefully test class. Finally, revisiting some code farther up in the test, the try-block at lines 135-140 issues a registration request that the test expects to fail. If it succeeds, the message at line 139 isn't very clear; it should say that the registration request succeeded unexpectedly. This should cause the test to fail. We still probably want to go through the waitFor(timeout) path and eventual rmid cleanup, but a flag should be set here to ensure that the test indeed fails if the registration succeeds unexpectedly, and the messages should clearly indicate that this is going on. A good way to test this last case is to change rmid's security manager to the normal security manager java.lang.SecurityManager instead of TestSecurityManager. Thanks, s'marks On 2/10/14 2:59 AM, Tristan Yan wrote: Hi Stuart Could you help to review this. Thank you Tristan On Jan 31, 2014, at 4:36 PM, Tristan Yan tristan@oracle.com mailto:tristan@oracle.com wrote: Thank you for fixing JDK-8023541. Then I leave ActivationLibrary.java for now. I still did some clean up following your suggestion. 1. I changed waitFor(long timeout) method, this method is going to use code like Process.waitFor(timeout, unit). This can be backported to JDK7. Also exitValue is kept as a return value. For making sure there is no Pipe leak, a cleanup thread will start when timeout happens. 2. Change in ShutdownGracefully is a little tricky. I think we should just destroy JVM once exception is thrown. So I move the wait logic into try block instead keep them in finally block. Can you receive it again. http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.02/ Thank you Tristan On 01/29/2014 03:16 PM, Stuart Marks wrote: Hi Tristan, I don't want to put the workaround into ActivationLibrary.rmidRunning() for a null return from the lookup, because this is only a workaround for an actual bug in rmid initialization. See the review I just posted for JDK-8023541. Adding JavaVM.waitFor(timeout) is something that would be useful in general, but it needs to be handled carefully. It uses the new Process.waitFor(timeout, unit) which is new in Java SE 8; this makes
