RE: [concurrency-interest] RFR: 8065804:JEP171:Clarifications/corrections for fence intrinsics
Can you expand on that please. All previous discussion of IRIW I have seen indicated that the property, while a consequence of existing JMM rules, had no practical use. Thanks, David -Original Message- From: Roman Elizarov [mailto:eliza...@devexperts.com] Sent: Wednesday, 26 November 2014 6:49 PM To: dhol...@ieee.org; Hans Boehm Cc: concurrency-inter...@cs.oswego.edu; core-libs-dev Subject: RE: [concurrency-interest] RFR: 8065804:JEP171:Clarifications/corrections for fence intrinsics There is no conceivable way to kill IRIW consistency requirement while retaining ability to prove correctness of large software systems. If IRIW of volatile variables are not consistent, then volatile reads and writes are not linearizable, which breaks linearizabiliy of all higher-level primitives build on top of them and makes formal reasoning about behavior of concurrent systems practically impossible. There are many fields where this is not acceptable. /Roman From: concurrency-interest-boun...@cs.oswego.edu [mailto:concurrency-interest-boun...@cs.oswego.edu] On Behalf Of David Holmes Sent: Wednesday, November 26, 2014 5:11 AM To: Hans Boehm Cc: concurrency-inter...@cs.oswego.edu; core-libs-dev Subject: Re: [concurrency-interest] RFR: 8065804: JEP171:Clarifications/corrections for fence intrinsics Hi Hans, Given IRIW is a thorn in everyone's side and has no known useful benefit, and can hopefully be killed off in the future, lets not get bogged down in IRIW. But none of what you say below relates to multi-copy-atomicity. Cheers, David -Original Message- From: hjkhbo...@gmail.com [mailto:hjkhbo...@gmail.com]On Behalf Of Hans Boehm Sent: Wednesday, 26 November 2014 12:04 PM To: dhol...@ieee.org Cc: Stephan Diestelhorst; concurrency-inter...@cs.oswego.edu; core-libs-dev Subject: Re: [concurrency-interest] RFR: 8065804: JEP171:Clarifications/corrections for fence intrinsics To be concrete here, on Power, loads can normally be ordered by an address dependency or light-weight fence (lwsync). However, neither is enough to prevent the questionable outcome for IRIW, since it doesn't ensure that the stores in T1 and T2 will be made visible to other threads in a consistent order. That outcome can be prevented by using heavyweight fences (sync) instructions between the loads instead. Peter Sewell's group concluded that to enforce correct volatile behavior on Power, you essentially need a a heavyweight fence between every pair of volatile operations on Power. That cannot be understood based on simple ordering constraints. As Stephan pointed out, there are similar issues on ARM, but they're less commonly encountered in a Java implementation. If you're lucky, you can get to the right implementation recipe by looking at only reordering, I think. On Tue, Nov 25, 2014 at 4:36 PM, David Holmes davidchol...@aapt.net.au wrote: Stephan Diestelhorst writes: David Holmes wrote: Stephan Diestelhorst writes: Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm: I'm no hardware architect, but fundamentally it seems to me that load x acquire_fence imposes a much more stringent constraint than load_acquire x Consider the case in which the load from x is an L1 hit, but a preceding load (from say y) is a long-latency miss. If we enforce ordering by just waiting for completion of prior operation, the former has to wait for the load from y to complete; while the latter doesn't. I find it hard to believe that this doesn't leave an appreciable amount of performance on the table, at least for some interesting microarchitectures. I agree, Hans, that this is a reasonable assumption. Load_acquire x does allow roach motel, whereas the acquire fence does not. In addition, for better or worse, fencing requirements on at least Power are actually driven as much by store atomicity issues, as by the ordering issues discussed in the cookbook. This was not understood in 2005, and unfortunately doesn't seem to be amenable to the kind of straightforward explanation as in Doug's cookbook. Coming from a strongly ordered architecture to a weakly ordered one myself, I also needed some mental adjustment about store (multi-copy) atomicity. I can imagine others will be unaware of this difference, too, even in 2014. Sorry I'm missing the connection between fences and multi-copy atomicity. One example is the classic IRIW. With non-multi copy atomic stores, but ordered (say through a dependency) loads in the
[7u-dev] Request for Review + Request for Approval to Backport: 8064391: More thread safety problems in core reflection
Hello! Would you please approve the (almost) direct backport from jdk 8u to 7u? The difference, comparing to 8u changeset, is due to change in Class.java, (which is already there in 8) and in GenericDeclRepository.java due to genericification. The patch is essentially the same as the one proposed by Martin in the bug summary. Bug: https://bugs.openjdk.java.net/browse/JDK-8064391 Webrev: http://cr.openjdk.java.net/~igerasim/8064391/0/webrev/ Sincerely yours, Ivan
RFR: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section
Hi, Please find below a patch for: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section https://bugs.openjdk.java.net/browse/JDK-8065991 Webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8065991/webrev.00/ Note: https://bugs.openjdk.java.net/browse/JDK-8065709 shows a thread dump where this is causing a deadlock between AWT and LogManager. However - fixing this particular deadlock may require more than modifying LogManager. The fix proposed here should hopefully make JDK-8065709 less likely - but will not guarantee that the issue discribed in JDK-8065709 is fully fixed. I have included a testcase that replaces the implementation of JavaAWTAccess and emulates AppContext.getAppContext(). The test fails in deadlock without the change, and passes with it (though only because LogManager is pre-initilized in main()). best regards, -- daniel
NIO question: Path.toFile()
NIO folk, java.nio.file.Path.toFile() is specified to throw UnsupportedOperationException if this Path is not associated with the default provider. UOE seems a somewhat strange choice here. IllegalStateException or a custom exception might be seen as more obvious alternatives. (It's also somewhat weird that UOE is explicitly documented as being a member of the Java Collections Framework.) So, if there any background rationale of why UOE was chosen here? I'm not looking to change the spec for Path.toFile() in any way, but I am looking to design a higher level API that may encounter the same underlying problem, that a Path may not be associated with the default provider. At my higher level, I need to decide whether to go with UOE, just because that is what Path.toFile() does, or whether to convert it into some other exception. -- Jon
Re: Lower overhead String encoding/decoding
Hi gents, Here are some comments regarding the updated webrev. (1) String(ByteBuffer, String) needs @throw UEE. (2) It should be default replacement byte array not replace string for all getBytes() methods when malformed/unmappable (3) for decoding (new String) from ByteBuffer, since it is guaranteed that all bytes in the input ByteBuffer will be decoded, it might be desirable to clearly specify that the position of the buffer will be advanced to its limit ? (4) ln#1137 has an extra * (5) StringCoding.decode(cs, bb), why do you want to allocate a direct buffer here for untrusted? Basically the output buffer ca will always be a wrapper of a char[], all our charset implementation will have better performance if both input and output are array based (decode on array directly, instead of the slow ByteBuffer) Overall I think this is looking quite good and I think Sherman has captured the main issues. On #3 then wording such as .. the position will be updated isn't clear enough to allow the method be tested, it needs to make it clear that the position is advanced by the number of bytes that were decoded. Thanks for looking at this patch and agreeing to sponsor - I've pushed fixes for these issues at: http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-10/ regards, Richard Warburton http://insightfullogic.com @RichardWarburto http://twitter.com/richardwarburto
Re: RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
Martin, On 25/11/2014 6:56 AM, Martin Buchholz wrote: Hi folks, Review carefully - I am trying to learn about fences by explaining them! I have borrowed some wording from my reviewers! https://bugs.openjdk.java.net/browse/JDK-8065804 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intrinsics/ Please explain why you have changed the defined semantics for storeFence. You have completely reversed the direction of the barrier. Thanks, David
Re: RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
On Wed, Nov 26, 2014 at 5:08 PM, David Holmes david.hol...@oracle.com wrote: Please explain why you have changed the defined semantics for storeFence. You have completely reversed the direction of the barrier. Yes. I believe the current spec of storeFence was a copy-paste typo, and it seems others feel likewise.
Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
On Tue, Nov 25, 2014 at 6:04 AM, Paul Sandoz paul.san...@oracle.com wrote: Hi Martin, Thanks for looking into this. 1141 * Currently hotspot's implementation of a Java language-level volatile 1142 * store has the same effect as a storeFence followed by a relaxed store, 1143 * although that may be a little stronger than needed. IIUC to emulate hotpot's volatile store you will need to say that a fullFence immediately follows the relaxed store. Right - I've been groking that. The bit that always confuses me about release and acquire is ordering is restricted to one direction, as talked about in orderAccess.hpp [1]. So for a release, accesses prior to the release cannot move below it, but accesses succeeding the release can move above it. And that seems to apply to Unsafe.storeFence [2] (acting like a monitor exit). Is that contrary to C++ release fences where ordering is restricted both to prior and succeeding accesses? [3] So what about the following? a = r1; // Cannot move below the fence Unsafe.storeFence(); b = r2; // Can move above the fence? I think the hotspot docs need to be more precise about when they're talking about movement of stores and when about loads. // release. I.e., subsequent memory accesses may float above the // release, but prior ones may not float below it. As I've said elsewhere, the above makes no sense without restricting the type of access.
Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
On Tue, Nov 25, 2014 at 1:41 PM, Andrew Haley a...@redhat.com wrote: On 11/24/2014 08:56 PM, Martin Buchholz wrote: + * Currently hotspot's implementation of a Java language-level volatile + * store has the same effect as a storeFence followed by a relaxed store, + * although that may be a little stronger than needed. While this may be true today No - it was very wrong, since it doesn't give you sequential consistency! , I'm hopefully about to commit an AArch64 OpenJDK port that uses the ARMv8 stlr instruction. I don't think that what you've written here is terribly misleading, but bear in mind that it may be there for some time.
RE: [concurrency-interest] RFR: 8065804: JEP 171:Clarifications/corrections for fence intrinsics
Martin Buchholz writes: On Wed, Nov 26, 2014 at 5:08 PM, David Holmes david.hol...@oracle.com wrote: Please explain why you have changed the defined semantics for storeFence. You have completely reversed the direction of the barrier. Yes. I believe the current spec of storeFence was a copy-paste typo, and it seems others feel likewise. Can whomever wrote that original spec please confirm that. Thanks, David
RE: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
Can I make an observation about acquire() and release() - to me they are meaningless when considered in isolation. Given their definitions they allow anything to move into a region bounded by acquire() and release(), then you can effectively move the whole program into the region and thus the acquire() and release() do not constrain any reorderings. acquire() and release() only make sense when their own movement is constrained with respect to something else - such as lock acquisition/release, or when combined with specific load/store actions. David Martin Buchholz writes: On Tue, Nov 25, 2014 at 6:04 AM, Paul Sandoz paul.san...@oracle.com wrote: Hi Martin, Thanks for looking into this. 1141 * Currently hotspot's implementation of a Java language-level volatile 1142 * store has the same effect as a storeFence followed by a relaxed store, 1143 * although that may be a little stronger than needed. IIUC to emulate hotpot's volatile store you will need to say that a fullFence immediately follows the relaxed store. Right - I've been groking that. The bit that always confuses me about release and acquire is ordering is restricted to one direction, as talked about in orderAccess.hpp [1]. So for a release, accesses prior to the release cannot move below it, but accesses succeeding the release can move above it. And that seems to apply to Unsafe.storeFence [2] (acting like a monitor exit). Is that contrary to C++ release fences where ordering is restricted both to prior and succeeding accesses? [3] So what about the following? a = r1; // Cannot move below the fence Unsafe.storeFence(); b = r2; // Can move above the fence? I think the hotspot docs need to be more precise about when they're talking about movement of stores and when about loads. // release. I.e., subsequent memory accesses may float above the // release, but prior ones may not float below it. As I've said elsewhere, the above makes no sense without restricting the type of access. ___ Concurrency-interest mailing list concurrency-inter...@cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
On Wed, Nov 26, 2014 at 7:00 PM, David Holmes davidchol...@aapt.net.au wrote: Can I make an observation about acquire() and release() - to me they are meaningless when considered in isolation. Given their definitions they allow anything to move into a region bounded by acquire() and release(), then you can effectively move the whole program into the region and thus the acquire() and release() do not constrain any reorderings. acquire() and release() only make sense when their own movement is constrained with respect to something else - such as lock acquisition/release, or when combined with specific load/store actions. David, it seems you are agreeing with my argument below. The definitions in the hotspot sources should be fixed, in the same sort of way that I'm trying to make the specs for Unsafe loads clearer and more precise. David Martin Buchholz writes: I think the hotspot docs need to be more precise about when they're talking about movement of stores and when about loads. // release. I.e., subsequent memory accesses may float above the // release, but prior ones may not float below it. As I've said elsewhere, the above makes no sense without restricting the type of access.
RE: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
Martin writes: On Wed, Nov 26, 2014 at 7:00 PM, David Holmes davidchol...@aapt.net.au wrote: Can I make an observation about acquire() and release() - to me they are meaningless when considered in isolation. Given their definitions they allow anything to move into a region bounded by acquire() and release(), then you can effectively move the whole program into the region and thus the acquire() and release() do not constrain any reorderings. acquire() and release() only make sense when their own movement is constrained with respect to something else - such as lock acquisition/release, or when combined with specific load/store actions. David, it seems you are agreeing with my argument below. The definitions in the hotspot sources should be fixed, in the same sort of way that I'm trying to make the specs for Unsafe loads clearer and more precise. Please see: https://bugs.openjdk.java.net/browse/JDK-7143664 Though I'm not sure my ramblings there reflect my current thoughts on all this. I really think acquire/release are too confusingly used to be useful - by which I mean that the names do not reflect their actions so you will always have to remember/look-up exactly what *release* and *acquire* mean in that context, and hence talking about acquire semantics and release semantics becomes meaningless. In contrast the loadload|loadstore etc barriers are completely straight-forward to understand from their names. However it seems they are too strong compared to what recent hardware provides. Hotspot implementations in orderAccess are confusing - barriers with different semantics have been defined in terms of the other, but the low-level implementations provide a barrier that is stronger than the required semantics, so the high-level APIs are satisfied correctly, even if not implemented in a way that makes sense if you reason about what each barrier theoretically allows. David David Martin Buchholz writes: I think the hotspot docs need to be more precise about when they're talking about movement of stores and when about loads. // release. I.e., subsequent memory accesses may float above the // release, but prior ones may not float below it. As I've said elsewhere, the above makes no sense without restricting the type of access.
Re: RFR: 8062771: Core reflection should use final fields whenever possible
Hi! I can take care of jdk8 backport too, if you want. I've checked it, and the port seemed quite straight-forward (modulo unshuffling). Only changes to a few files [1] had to be skipped, as the changes appear to already be there in jdk8u. Here's the webrev of jdk8u backport for JDK-8062771: WEBREV: http://cr.openjdk.java.net/~igerasim/8062771/0/webrev/ [1] And here's the list of the files that needed to be excluded from the changeset: src/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java src/share/classes/sun/reflect/generics/reflectiveObjects/LazyReflectiveObjectGenerator.java src/share/classes/sun/reflect/generics/repository/AbstractRepository.java src/share/classes/sun/reflect/generics/scope/AbstractScope.java src/share/classes/sun/reflect/generics/tree/ClassSignature.java Sincerely yours, Ivan On 10.11.2014 12:00, Joel Borggrén-Franck wrote: That would be great cheers /Joel On 2014-11-09, Ivan Gerasimov wrote: Hi! I think I can handle the backport to jdk7, if you still need a volunteer. Sincerely yours, Ivan On 08.11.2014 1:48, Martin Buchholz wrote: Hi Joel, Thanks for volunteering. I foisted all I have in https://bugs.openjdk.java.net/browse/JDK-8064391 I volunteer to be your reviewer for the backports. On Fri, Nov 7, 2014 at 1:36 PM, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi Martin, Thanks for the clarification. On 6 nov 2014, at 20:51, Martin Buchholz marti...@google.com wrote: Hi Joel, On Thu, Nov 6, 2014 at 2:48 AM, Joel Borggrén-Franck joel.fra...@oracle.com wrote: Hi, I’m having a hard time following this thread, which webrev has been updated, for which release, fixing which issue? I am submitting the changeset for JDK-8062771, adding the finals and the (failed reproduction) test. Hopefully there will be followon changes to add even more thread safety. Great. Are we sure the accidental fix of making ClassRepository volatile is good on all platforms? I can’t establish the happens before relations that would prove the fix but then again I’m not an expert on concurrency. Martin, as far as I can see you are the only one of us who has replied to this thread who is a jdk7u committer (or reviewer). I am entirely in favor of having more reviewers. We are not planning to push these into jdk7u or jdk8u ourselves, but we are willing to help anyone who wants to take on that task. Joel, are you volunteering? We believe all versions of stock openjdk still have (rarely seen) thread safety issues in core reflection. We have applied changes locally at Google to fix those. I’ll take care of 8u, and I can hunt down someone to fix this in 7u if we can find a suitable reviewer (sigh). cheers /Joel
Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
On 11/27/2014 04:00 AM, David Holmes wrote: Can I make an observation about acquire() and release() - to me they are meaningless when considered in isolation. Given their definitions they allow anything to move into a region bounded by acquire() and release(), then you can effectively move the whole program into the region and thus the acquire() and release() do not constrain any reorderings. acquire() and release() only make sense when their own movement is constrained with respect to something else - such as lock acquisition/release, or when combined with specific load/store actions. ...or another acquire/release region? Regards, Peter David Martin Buchholz writes: On Tue, Nov 25, 2014 at 6:04 AM, Paul Sandoz paul.san...@oracle.com wrote: Hi Martin, Thanks for looking into this. 1141 * Currently hotspot's implementation of a Java language-level volatile 1142 * store has the same effect as a storeFence followed by a relaxed store, 1143 * although that may be a little stronger than needed. IIUC to emulate hotpot's volatile store you will need to say that a fullFence immediately follows the relaxed store. Right - I've been groking that. The bit that always confuses me about release and acquire is ordering is restricted to one direction, as talked about in orderAccess.hpp [1]. So for a release, accesses prior to the release cannot move below it, but accesses succeeding the release can move above it. And that seems to apply to Unsafe.storeFence [2] (acting like a monitor exit). Is that contrary to C++ release fences where ordering is restricted both to prior and succeeding accesses? [3] So what about the following? a = r1; // Cannot move below the fence Unsafe.storeFence(); b = r2; // Can move above the fence? I think the hotspot docs need to be more precise about when they're talking about movement of stores and when about loads. // release. I.e., subsequent memory accesses may float above the // release, but prior ones may not float below it. As I've said elsewhere, the above makes no sense without restricting the type of access. ___ Concurrency-interest mailing list concurrency-inter...@cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest
