Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes
1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)" to correctly handle IdentitityHashMap.values()? The instanceof List seems like safe choice but it is too bad we can still fool that check by wrapping List as an unmodifiableCollection. If splitIterator().characteristics() could tell us that the collection used identity comparisons I think we would be able to determine if it was safe to swap the ordering in the general case as we could check for IDENTITY, SORTED, and comparator equality. 2. Should code applied to HashSet.removeAll also be applied to HashMap.keySet().removeAll and HashMap.entrySet().removeAll? Collections::newSetFromMap will end up having different behavior if it is not consistently applied. 3. Not to derail this thread but do think we need a new JIRA ticket to address Collections.disjoint? Seems like it has similar sins of calling size and using "!(c2 instanceof Set)" but I don't want to muddy the waters by covering any solutions to that method in this thread. Jason From: core-libs-dev on behalf of Stuart Marks Sent: Friday, May 1, 2020 3:01 PM To: core-libs-dev Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes Hi all, I'm taking another swing at this one. I've taken a minimal approach compared to my previous proposals. Briefly, AbstractSet.removeAll switches from iterating this collection and calling contains() on its argument, to iterating the argument and calling this.contains(), if the argument collection is smaller than this collection. This attempt at optimization is incorrect, because this collection and the argument collection might have different semantics for contains(). There is a confounding performance problem, which is that if the argument is a List, contains() is generally linear, which can result in pathologically slow (O(m*n)) performance. Because of the iteration-switching above, this performance problem can appear and disappear based on the relative sizes, which is startling. The fix for the semantic problem is simply to remove the attempted optimization from AbstractSet. This comports with the specification of Collection.removeAll and Set.removeAll, which imply that contains() is called on the argument collection. This allows sets to inherit the implementation in AbstractCollection.removeAll. In addition, this ensures that removeAll is now always the complement of retainAll (as it should be), which it sometimes was not when the optimization was in place. IdentityHashMap's keySet and entrySet views were broken by this optimization, so they had to override removeAll with copies of the implementation from AbstractCollection. Since they can now inherit from AbstractCollection, these overrides have been removed. This leaves a potential performance problem with removeAll when the argument is a List. To mitigate this, HashSet.removeAll switches to iterating the argument if the argument is a List. This is safe, as both HashSet and List use the same semantics for contains() (at least, as far as I know). I've opted not to pursue size-based optimizations at this time, since they provide only incremental benefit, whereas the pathological performance problem mentioned above is the primary issue. Also, it's actually quite difficult to determine when it's safe to switch iteration. Finally, I've added performance notes to the specifications of containsAll(), removeAll(), and retainAll(), warning about potential performance problems that can occur with repeated calls to contains() made by these methods. Bug: https://bugs.openjdk.java.net/browse/JDK-6394757 Webrev: http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.2/ Previous discussions: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060007.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060147.html Thanks, s'marks
Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes
On 5/1/20 5:55 PM, Viswanathan, Sandhya wrote: Hi Vladimir, Thanks a lot for the feedback. We used an old existing separate branch to share the code for review and to track changes. We didn’t know how to change the name of the branch from vector-unstable to vector-stable. Good to know that it does not mean that code is "unstable" ;) Katya filed today new bug [1]. Please look. Regards, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8244269 Best Regards, Sandhya -Original Message- From: Vladimir Kozlov Sent: Friday, May 01, 2020 5:32 PM To: Viswanathan, Sandhya ; hotspot-compiler-...@openjdk.java.net; core-libs-dev@openjdk.java.net; hotspot-dev Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes Changes seems fine. Nice work. Why it is called "vector-unstable branch"? Thanks, Vladimir K On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote: Hi, Following up on review requests of API [0], Java implementation [1] and General Hotspot changes[3] for Vector API, here's a request for review of x86 backend changes required for supporting the API: JEP: https://openjdk.java.net/jeps/338 JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ Complete implementation resides in vector-unstable branch of panama/dev repository [3]. Looking forward to your feedback. Best Regards, Sandhya [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html [3] https://openjdk.java.net/projects/panama/ $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable
RE: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes
Hi Vladimir, Thanks a lot for the feedback. We used an old existing separate branch to share the code for review and to track changes. We didn’t know how to change the name of the branch from vector-unstable to vector-stable. Best Regards, Sandhya -Original Message- From: Vladimir Kozlov Sent: Friday, May 01, 2020 5:32 PM To: Viswanathan, Sandhya ; hotspot-compiler-...@openjdk.java.net; core-libs-dev@openjdk.java.net; hotspot-dev Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes Changes seems fine. Nice work. Why it is called "vector-unstable branch"? Thanks, Vladimir K On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote: > Hi, > > > Following up on review requests of API [0], Java implementation [1] and > > General Hotspot changes[3] for Vector API, here's a request for review > > of x86 backend changes required for supporting the API: > > > > JEP: https://openjdk.java.net/jeps/338 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 > > Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ > > > > Complete implementation resides in vector-unstable branch of > > panama/dev repository [3]. > > Looking forward to your feedback. > > Best Regards, > Sandhya > > > [0] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html > > > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html > > > > [2] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html > > > > [3] https://openjdk.java.net/projects/panama/ > > $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable > > > > >
Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes
Changes seems fine. Nice work. Why it is called "vector-unstable branch"? Thanks, Vladimir K On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote: Hi, Following up on review requests of API [0], Java implementation [1] and General Hotspot changes[3] for Vector API, here's a request for review of x86 backend changes required for supporting the API: JEP: https://openjdk.java.net/jeps/338 JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ Complete implementation resides in vector-unstable branch of panama/dev repository [3]. Looking forward to your feedback. Best Regards, Sandhya [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html [3] https://openjdk.java.net/projects/panama/ $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable
Re: RFR: JDK-8244220 : Compiler error in jpackage with VS2019
OK. Approved.
-phil.
On 5/1/20, 4:18 PM, Alexey Semenyuk wrote:
Evaluation:
Code snippet at memory(1871):
---
~unique_ptr() noexcept {
if (_Mypair._Myval2) {
_Mypair._Get_first()(_Mypair._Myval2);
}
}
---
Where '_Myval2' is of type jni::JniObjWithEnv defined in JniUtils.h.
JniObjWithEnv is a struct wrapping two pointers: JNIEnv* and jobject.
It requires user defined bool operator to make code in ~unique_ptr()
compile. By some reason vs2017 didn't complain on missing bool operator.
I've added the evaluation in the comments section of the bug report as
well.
- Alexey
On 5/1/2020 6:21 PM, Philip Race wrote:
It may be self-evident but I really like to see a RFR include an
evaluation
and explanation of the fix and the same in the bug report.
Please do both.
-phil.
On 5/1/20, 1:00 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Fix vs2019 compliation error.
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8244220
[2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00
Re: RFR: JDK-8244220 : Compiler error in jpackage with VS2019
Evaluation:
Code snippet at memory(1871):
---
~unique_ptr() noexcept {
if (_Mypair._Myval2) {
_Mypair._Get_first()(_Mypair._Myval2);
}
}
---
Where '_Myval2' is of type jni::JniObjWithEnv defined in JniUtils.h.
JniObjWithEnv is a struct wrapping two pointers: JNIEnv* and jobject. It
requires user defined bool operator to make code in ~unique_ptr()
compile. By some reason vs2017 didn't complain on missing bool operator.
I've added the evaluation in the comments section of the bug report as well.
- Alexey
On 5/1/2020 6:21 PM, Philip Race wrote:
It may be self-evident but I really like to see a RFR include an
evaluation
and explanation of the fix and the same in the bug report.
Please do both.
-phil.
On 5/1/20, 1:00 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Fix vs2019 compliation error.
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8244220
[2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00
Re: Collections.synchronizedXXX() and internal mutex (aka SyncRoot)
On 5/1/20 2:02 AM, dmytro sheyko wrote: The checked, synchronized and unmodifiable wrappers in some cases store backing collection in more than one fields. Thus `UnmodifiableList` has 1. its own field `List list` and 2. `Collection c`, which it inherits from `UnmodifiableCollection`. Also `UnmodifiableNavigableSet` has even 3 duplicated fields: 1. its own `NavigableSet ns`, 2. `SortedSet ss` from `UnmodifiableSortedSet` and 3. `Collection c` from `UnmodifiableCollection`. Isn't it worth to get rid of such duplication? (at least for unmodifiable collections). This may affect serialization, but I believe it's still possible preserve serialization backward compatible, if it's necessary. Or is it done intentionally? Interesting. I went through some of the history here, in particular the core-libs-dev review threads of JDK-7129185 [1] which was the last time significant work was done on the wrappers. There was no mention of the duplicate references in any of the reviews. I suspect the wrappers introduced in this changeset (e.g., UnmodifiableNavigableSet) copied the style from existing wrappers, which also used this style. I was able to look through the old (non open source) history of the JDK, and I found that this style of having a redundant field in a wrapper subtype was introduced in JDK 1.2 in 1998 along with the original collections implementation. I suspect it was done this way for convenience. Certainly the wrapper subclasses have access to the field from the superclass. But to use it they there would have to be a cast at every call site that wanted to use a subclass method. This would certainly make the wrapper code more verbose, and it might even slow things down a bit with checkcast bytecodes and such. While trying to save space is laudable, compatibility with existing serial forms needs to be preserved. Doing this would require adding serialPersistentFields arrays and readObject() and writeObject() methods to every one of the wrapper classes. This is fairly tedious and error-prone. I'm not sure it's worth it. s'marks [1] https://bugs.openjdk.java.net/browse/JDK-7129185
Re: RFR: JDK-8244220 : Compiler error in jpackage with VS2019
It may be self-evident but I really like to see a RFR include an evaluation and explanation of the fix and the same in the bug report. Please do both. -phil. On 5/1/20, 1:00 PM, Alexey Semenyuk wrote: Please review fix [2] for jpackage bug [1]. Fix vs2019 compliation error. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8244220 [2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00
Re: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable
I’ll push it for you, Paul. > On May 1, 2020, at 2:13 PM, Jorn Vernee wrote: > > The CSR for this patch is now Approved, so it looks like this patch is ready > to be sponsored. > > Here are the relevant links again. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 > CSR: https://bugs.openjdk.java.net/browse/JDK-8241667 > Patch: http://cr.openjdk.java.net/~jvernee/8241100/webrev.04/ > > Thanks, > Jorn > > On 18/03/2020 15:08, Jorn Vernee wrote: >> Hi, >> >> Can someone please sponsor this patch that makes Boolean, Character, Byte, >> and Short implement Constable? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 >> Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/ >> >> Having the other box types implement Constable makes them easier to use with >> APIs that accept any Constable. Though I'm mostly interesting in boolean, >> for which I'm currently falling back to "true" & "false" strings, but the >> downside is that this also requires parsing the string again and having to >> deal with random other strings. >> >> This patch also adds the ConstantBootstraps::convert method that is used to >> facilitate the conversion from int to (short|char|byte). This currently >> takes a source type explicitly. In practice, it seems that Object can always >> be used as a source type for the same behavior, but explicitly specifying >> source and destination types seems more robust to me in case this behavior >> ever changes, or we want to expand on the supported kinds of conversion. >> (for instance it is currently not possible to convert from an int to a Long >> directly, or from Short to Integer, but maybe those cases could be supported >> in the future as well). >> >> Testing: tier1-3 & downstream testing for my particular use case >> >> Thanks, >> Jorn >>
Re: RFR: JDK-8244220 : Compiler error in jpackage with VS2019
Hi Alexey, Looks fine. Thanks, Alexander On 5/1/20 1:00 PM, Alexey Semenyuk wrote: Please review fix [2] for jpackage bug [1]. Fix vs2019 compliation error. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8244220 [2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00
Re: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable
The CSR for this patch is now Approved, so it looks like this patch is ready to be sponsored. Here are the relevant links again. Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 CSR: https://bugs.openjdk.java.net/browse/JDK-8241667 Patch: http://cr.openjdk.java.net/~jvernee/8241100/webrev.04/ Thanks, Jorn On 18/03/2020 15:08, Jorn Vernee wrote: Hi, Can someone please sponsor this patch that makes Boolean, Character, Byte, and Short implement Constable? Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/ Having the other box types implement Constable makes them easier to use with APIs that accept any Constable. Though I'm mostly interesting in boolean, for which I'm currently falling back to "true" & "false" strings, but the downside is that this also requires parsing the string again and having to deal with random other strings. This patch also adds the ConstantBootstraps::convert method that is used to facilitate the conversion from int to (short|char|byte). This currently takes a source type explicitly. In practice, it seems that Object can always be used as a source type for the same behavior, but explicitly specifying source and destination types seems more robust to me in case this behavior ever changes, or we want to expand on the supported kinds of conversion. (for instance it is currently not possible to convert from an int to a Long directly, or from Short to Integer, but maybe those cases could be supported in the future as well). Testing: tier1-3 & downstream testing for my particular use case Thanks, Jorn
Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException
Thanks Roger.
I figure I could have gotten away without an additional reviewer. :-) However, I
asked for a review because I wanted someone to cross-check my decision not to
file a CSR for this, despite most specification changes requiring a CSR. I also
wanted to model behavior for new community members.
s'marks
On 5/1/20 7:57 AM, Roger Riggs wrote:
+1,
BTW, Stuart you are a Reviewer, no need for a 2nd.
Roger
On 5/1/20 12:02 AM, Stuart Marks wrote:
Hi Jay,
OK, welcome! I'll sponsor this changeset for you. It's pretty simple, so I'll
just paste the exported changeset below. (For complicated changesets, you'll
have to ask a sponsor to host a webrev on cr.openjdk.java.net for you.) Please
check the Contributed-by line in the changeset to make sure the attribution is
correct. I just copied the From: line from your email, but if you want it to
be different, please let me know.
I'll update the bug report with a pointer to this email thread.
https://bugs.openjdk.java.net/browse/JDK-6415694
Could I get a Reviewer to review this? Thanks.
(I noticed that the anachronistic markup is used here instead of the
preferred {@code ...} javadoc tag. However, is used all over this
package, so I didn't think that changing it in just one place would be helpful.)
I'll also note again that since this is merely an editorial wording change to
the specification, I don't think it needs a CSR request.
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 1588290431 25200
# Thu Apr 30 16:47:11 2020 -0700
# Node ID 1f5b3876d1500a2e77d6e39d079649964ba6dd26
# Parent fe6548dc92de4c875467c968ee37e7c9bbee1697
6415694: Clarification in Javadoc for java.rmi.AlreadyBoundException
Reviewed-by: XXX
Contributed-by: Jayashree Sk1
diff -r fe6548dc92de -r 1f5b3876d150
src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
--- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr
30 15:21:15 2020 -0700
+++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr
30 16:47:11 2020 -0700
@@ -26,8 +26,8 @@
/**
* An AlreadyBoundException is thrown if an attempt
- * is made to bind an object in the registry to a name that already
- * has an associated binding.
+ * is made to bind an object to a name that already
+ * has an associated binding in the registry.
*
* @since 1.1
* @author Ann Wollrath
On 4/29/20 10:24 PM, Jayashree Sk1 wrote:
Thanks for the review comment Stuart. Yes, I will need a sponsor, this is my
first time here in OpenJDK.
Regards!
Jay
-Stuart Marks wrote: -
To: Jayashree Sk1
From: Stuart Marks
Date: 04/30/2020 09:22AM
Cc: core-libs-dev@openjdk.java.net
Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for
java.rmi.AlreadyBoundException
The change looks fine. Although this is in a normative portion of the
specification, the nature of the change is purely editorial, so I don't think it
needs a CSR.
Do you need a sponsor?
s'marks
On 4/29/20 2:57 AM, Jayashree Sk1 wrote:
Hi All,
Please find the below changes for the issues
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=OXEC-w1xTWoJUyw_sRivRwIGmkHIUc3DllMsA_N3qIk&s=iesFFcE4NSOreLmf8vwdKzcdnFgjGE_SEERICPUFef4&e=
.
It is a description change, which was already approved by the reviewer.
Thanks!
diff -r 59b5bd9a7168
src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
--- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar
16 02:16:49 2020 -0400
+++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar
30 15:45:43 2020 +0530
@@ -26,8 +26,8 @@
/**
* An AlreadyBoundException is thrown if an attempt
- * is made to bind an object in the registry to a name that already
- * has an associated binding.
+ * is made to bind an object to a name that already
+ * has an associated binding in the registry.
*
* @since 1.1
* @author Ann Wollrath
Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests
Hi Remi,
Thanks for the feedback. I am gonna need to go over this with John. Some
comments inline.
> On Apr 20, 2020, at 6:31 AM, Remi Forax wrote:
>
> Hi Paul,
> about the API part (not the implementation),
> there are location where the same concept is described with a different names
> which doesn't help to understand how thing work
> - vector length <=> vector lane count
> - vector shape <=> vector bits size
> - element size <=> lane size
>
> "size" should never be used (VectorSpecies.elementSize() by example ) because
> it's never clear if it's the byte size or the bits size, using byteSize and
> bitsSize as used several times in the API should be used everywhere.
I agree with being explicit here e.g.
s/Vector.elementSize/Vector.elementBitSize and other usages.
I would prefer to consistently use length in methods to refer to the lane
count, it matches more closely to an array and for thinking about bounds
checking.
How about on Vector:
/**
* Returns number of vector lanes ({@code VLENGTH}), commonly referred to as
the lane count.
*
* @return the number of vector lanes
*/
public abstract int length();
And then change VectorShape.laneCount to VectorShape.laneLength.
?
>
> Initially, having VectorSpecies and VectorShape confuse me, it's not the
> shape of the vector but only it's bits size,
> renaming VectorShape to VectorBitsSize will help, i think.
>
Shape is quite a fundamental concept specified and used in the API,
representing the information capacity of a vector.
I think it would be misleading to refer to it only as VectorBitSize and
unwieldy to change the specification accordingly. In this sense it serves as a
useful abstraction to talk about vectors of the same bit size, and operations
that change that size or not (such as shape-changing or shape-invariant).
> You have the same values defined at several places in the API (sometimes with
> different names), usually it's aliases but it makes the API bigger that it
> should.
> I think all the reference to the element type, vector byte size, vector bit
> size, element byte size, element byte size, vector lane count should not
> appear on Vector because they are accessible from Species,
> and to go from a vector to the corresponding species, species() is enough.
>
But it also makes it less usable, esp. for length().
> You have also the same methods defined at several places, on VectorSpecies
> and as a static method taking a species as parameter,
> all the methods of VectorSpecies that takes or return a vector/mask/shuffle
> should be static in vector/mask/shuffle.
>
It’s a little more nuanced, but I agree there is some duplication e.g.
VectorSpecies.fromByteArray compared to the richer set of methods defined on
[E]Vector. I think we can remove that method from VectorSpecies. Then I think
we are dealing with the more “erased/reflective” and long carrier accepting
methods for general operation without appealing to E.
> I think Binary and Associative should be merged to one VectorOperation, given
> that the difference is subtle and the whole point of this API is that if the
> hardware do not provide a way to reduce a binary op, it can be done in Java.
Not quite true, ARM/x86 implementations do provide intrinsic implementations
(leveraging a sequence of instructions) for some reduction operations e.g.
min/max. I cannot recall there current state of the ARM/x86 implementations for
other reductive operations but the plan is to optimize all of them at some
point. Further, hardware may evolve in the future.
>
> I have no idea what a Conversion.rangeType() is ?
>
It’s the element type of the resulting output vector,
Doc on VectorOperators.Operator:
/**
* Reports the special return type of this operator.
* If this operator is a boolean, returns {@code boolean.class}.
* If this operator is a {@code Conversion},
* returns its {@linkplain Conversion#rangeType range type}.
*
* Otherwise, the operator's return value always has
* whatever type was given as an input, and this method
* returns {@code Object.class} to denote that fact.
* @return the special return type, or {@code Object.class} if none
*/
Class rangeType();
> More specially:
> - VectorSpecies.loopbound() is not used in the example ?
In the package-info? Yes, we should update that.
> - VectorSpecies.arrayType()/genericElementType() are more for implementers
> than users , no ? at least arrayType should be arrayElementType.
I don’t think we need to expose genericElementType in the API.
I suspect arrayType may have been added before it was added to Class in 12 for
the constable support. I think we can remove it.
> - VectorSpecies.withLanes() => withElementType()
>
> - VectorMask.check* are implementer methods ?
The intent is to provide abstractions so the developer can perform “reflective"
checks on vector, mask, or shuffle.
> - VectorMask.equal(VectorMask) => equiv
>
Because it’s too close to the name “e
RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes
Hi all, I'm taking another swing at this one. I've taken a minimal approach compared to my previous proposals. Briefly, AbstractSet.removeAll switches from iterating this collection and calling contains() on its argument, to iterating the argument and calling this.contains(), if the argument collection is smaller than this collection. This attempt at optimization is incorrect, because this collection and the argument collection might have different semantics for contains(). There is a confounding performance problem, which is that if the argument is a List, contains() is generally linear, which can result in pathologically slow (O(m*n)) performance. Because of the iteration-switching above, this performance problem can appear and disappear based on the relative sizes, which is startling. The fix for the semantic problem is simply to remove the attempted optimization from AbstractSet. This comports with the specification of Collection.removeAll and Set.removeAll, which imply that contains() is called on the argument collection. This allows sets to inherit the implementation in AbstractCollection.removeAll. In addition, this ensures that removeAll is now always the complement of retainAll (as it should be), which it sometimes was not when the optimization was in place. IdentityHashMap's keySet and entrySet views were broken by this optimization, so they had to override removeAll with copies of the implementation from AbstractCollection. Since they can now inherit from AbstractCollection, these overrides have been removed. This leaves a potential performance problem with removeAll when the argument is a List. To mitigate this, HashSet.removeAll switches to iterating the argument if the argument is a List. This is safe, as both HashSet and List use the same semantics for contains() (at least, as far as I know). I've opted not to pursue size-based optimizations at this time, since they provide only incremental benefit, whereas the pathological performance problem mentioned above is the primary issue. Also, it's actually quite difficult to determine when it's safe to switch iteration. Finally, I've added performance notes to the specifications of containsAll(), removeAll(), and retainAll(), warning about potential performance problems that can occur with repeated calls to contains() made by these methods. Bug: https://bugs.openjdk.java.net/browse/JDK-6394757 Webrev: http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.2/ Previous discussions: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060007.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060147.html Thanks, s'marks
RFR: JDK-8244220 : Compiler error in jpackage with VS2019
Please review fix [2] for jpackage bug [1]. Fix vs2019 compliation error. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8244220 [2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00
Re: jpackage signing fails with Mac jdk-14.0.1+7
Redirecting to core-libs-dev (with a Bcc to code-tools-dev) Code signing for macOS, along with the addition of notarization, has been improved for JDK 15. You might want to try the EA builds of JDK 15, which are available here: https://jdk.java.net/15/ -- Kevin On 5/1/2020 8:13 AM, Adam Carroll wrote: Using JDK 14.0.1 on the Mac, jpackage fails when signing is requested. This problem was observed using AdoptOpenJDK. I reported the problem to that project and they suggested that I report the problem here. Platform: Mac OS Catalina v10.15.4 Architecture: x86 Description: This problem was seen using AdoptOpenJDK 14.0.1+7. Using the Mac signing option for jpackage ... --mac-sign ... I see the following error (extra path information removed): /var/folders/rh/./HelloFX.app: is already signed However, if the --mac-sign option is removed, the build works without a problem. Reproducing the problem: I've created a minimal, single-class JavaFX application along with the necessary scripts to reproduce the problem: https://github.com/AdamCarroll/jdk14-jpackage-mac First clone the repo: $ git clone g...@github.com:AdamCarroll/jdk14-jpackage-mac.git Checkout the tag: $ git checkout 1.0.0 Run the build (very fast as there's only one class): $ ./gradlew clean build Now run the jpackage command with the --mac-sign option as follows (this is included in the file bin/create-signed-dmg.sh): $ jpackage \ --type dmg \ --module-path 'build/modules' \ --verbose \ --add-modules javafx.controls \ --input 'build/libraries' \ --dest "build/bundle" \ --name HelloFX \ --main-jar 'jdk14-jpackage-mac.jar' \ --main-class 'demo.HelloFX' \ --mac-sign You will now see a long error that includes the following: /var/folders/rh/...jdk.incubator.jpackage/HelloFX.app: is already signed java.io.IOException: Command [codesign, -s, Developer ID Application: Your Name Here (XX), -, /var/folders/rh/...jdk.incubator.jpackage.../HelloFX.app] exited with 1 code at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:73) at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:179) at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:150) ... If you now run the same command but without the --mac-sign option (or alternatively use the script bin/create-unsigned-dmg.sh), everything works without problems. You can find the original issue report to the AdoptOpenJDK repository here: https://github.com/AdoptOpenJDK/openjdk-build/issues/1718
Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)
On 01/05/2020 15:36, Maurizio Cimadamore wrote: in which case close() will fail and acquire() will fail. I meant close() will fail and segment will be acquired
Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException
+1,
BTW, Stuart you are a Reviewer, no need for a 2nd.
Roger
On 5/1/20 12:02 AM, Stuart Marks wrote:
Hi Jay,
OK, welcome! I'll sponsor this changeset for you. It's pretty simple,
so I'll just paste the exported changeset below. (For complicated
changesets, you'll have to ask a sponsor to host a webrev on
cr.openjdk.java.net for you.) Please check the Contributed-by line in
the changeset to make sure the attribution is correct. I just copied
the From: line from your email, but if you want it to be different,
please let me know.
I'll update the bug report with a pointer to this email thread.
https://bugs.openjdk.java.net/browse/JDK-6415694
Could I get a Reviewer to review this? Thanks.
(I noticed that the anachronistic markup is used here instead
of the preferred {@code ...} javadoc tag. However, is used all
over this package, so I didn't think that changing it in just one
place would be helpful.)
I'll also note again that since this is merely an editorial wording
change to the specification, I don't think it needs a CSR request.
Thanks,
s'marks
# HG changeset patch
# User smarks
# Date 1588290431 25200
# Thu Apr 30 16:47:11 2020 -0700
# Node ID 1f5b3876d1500a2e77d6e39d079649964ba6dd26
# Parent fe6548dc92de4c875467c968ee37e7c9bbee1697
6415694: Clarification in Javadoc for java.rmi.AlreadyBoundException
Reviewed-by: XXX
Contributed-by: Jayashree Sk1
diff -r fe6548dc92de -r 1f5b3876d150
src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
--- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
Thu Apr 30 15:21:15 2020 -0700
+++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
Thu Apr 30 16:47:11 2020 -0700
@@ -26,8 +26,8 @@
/**
* An AlreadyBoundException is thrown if an attempt
- * is made to bind an object in the registry to a name that already
- * has an associated binding.
+ * is made to bind an object to a name that already
+ * has an associated binding in the registry.
*
* @since 1.1
* @author Ann Wollrath
On 4/29/20 10:24 PM, Jayashree Sk1 wrote:
Thanks for the review comment Stuart. Yes, I will need a sponsor,
this is my first time here in OpenJDK.
Regards!
Jay
-Stuart Marks wrote: -
To: Jayashree Sk1
From: Stuart Marks
Date: 04/30/2020 09:22AM
Cc: core-libs-dev@openjdk.java.net
Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for
java.rmi.AlreadyBoundException
The change looks fine. Although this is in a normative portion of the
specification, the nature of the change is purely editorial, so I
don't think it
needs a CSR.
Do you need a sponsor?
s'marks
On 4/29/20 2:57 AM, Jayashree Sk1 wrote:
Hi All,
Please find the below changes for the issues
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=OXEC-w1xTWoJUyw_sRivRwIGmkHIUc3DllMsA_N3qIk&s=iesFFcE4NSOreLmf8vwdKzcdnFgjGE_SEERICPUFef4&e=
.
It is a description change, which was already approved by the reviewer.
Thanks!
diff -r 59b5bd9a7168
src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
--- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
Mon Mar 16 02:16:49 2020 -0400
+++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java
Mon Mar 30 15:45:43 2020 +0530
@@ -26,8 +26,8 @@
/**
* An AlreadyBoundException is thrown if an attempt
- * is made to bind an object in the registry to a name that already
- * has an associated binding.
+ * is made to bind an object to a name that already
+ * has an associated binding in the registry.
*
* @since 1.1
* @author Ann Wollrath
Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)
On 01/05/2020 15:31, Peter Levart wrote: So WDYT? Is it ok to propose this for panama? How do I proceed? You can do a pull request against this branch: https://github.com/openjdk/panama-foreign/tree/foreign-memaccess Cheers Maurizio
Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)
Hi Peter, this does look better yes. I suspect this doesn't affect performance negatively right? (in most cases, when acquiring, state will be OPEN). Now there's dup(). I think implementing dup() on a root scope is not too hard - for the child you probably need some trick, but probably not too bad - in the sense that in a Child scope, the cleanup action is really the increment of the root exit scope. So you could have a: close(boolean doCleanup) like we do now, and avoid the cleanup on dup (which in the case of the Child will avoid the adder increment). I *believe* this should be functionally equivalent to what we have now. One question: the more I look at the code, the less I'm sure that a close vs. access race cannot occur. I'm considering this situation: * thread 1 does acquire, and find state == OPEN * thread 2 does close, set state to CLOSING, then checks if the adders match But, how can we be sure that the value we get back from the adder (e.g. acquires.sum()) is accurate and reflects the fact that thread (1) has entered already? The API doesn't seem to provide any such guarantee: " The returned value is /NOT/ an atomic snapshot; invocation in the absence of concurrent updates returns an accurate result, but concurrent updates that occur while the sum is being calculated might not be incorporated." I guess perhaps the trick is in that "while" ? E.g. there's no guarantee only if the concurrent update occurs _while_ sum() is called. Now I think this is ok - because when acquire races with close we can have two cases: 1) "state" has been set to CLOSING _before_ it is read inside acquire() 2) "state" has been set to CLOSING _after_ it is read inside acquire() In the case (1), acquire will start spinning, so nothing can harmful can really happen here. Either the read of "state" from acquire() happened when "state" is about to transition to CLOSED (in which case it will fail soon after) - or the read happened before close() had a chance to look at the counter - in which case there might be a chance that the counter will be updated concurrently (e.g. acquire() thread calls increment() while close() thread calls sum()). But there will be two outcomes here: either the adder has missed the update, in which case the segment will be close, and acquire() will fail; or the adder got the update, in which case close() will fail and acquire() will fail. In the case (2) we have an happen before edge between the "state" read performed by acquire() and the "state" write performed by close(). Which means that, by the time we get to calling acquires.sum() we are guaranteed that the thread doing the close() will have seen the adder update from the thread doing the acquire (since the update comes _before_ the volatile read in the acquire() method). So, for this case we have that: * [acquire] acquires.increment() happens before * [acquire] state > OPEN happens before * [close] state = CLOSING happens before * [close] acquires.sum() Which, I think, proves that the thread performing the acquire cannot possibly have assumed that the scope is OPEN and also updating the adder concurrently with the call to sum() in the close thread. Maurizio On 01/05/2020 14:00, Peter Levart wrote: On 4/30/20 8:10 PM, Maurizio Cimadamore wrote: On 30/04/2020 01:06, Peter Levart wrote: Think differently: what if the client succeeded in closing the segment, just because it did it in a time window when no thread in the thread pool held an open scope (this is entirely possible with parallel stream for example since threads periodically acquire and close scopes). This would have the same effect on threads in the thread pool - they would not be able to continue their work... What I'm trying to say is that this is just a mechanism to make things safe, not to coordinate work. If program wants to avoid trouble, it must carefully coordinate work of threads. This appear to me to be a bit of a slippery slope? Sure, if somebody prematurely calls close() on a segment while other threads are accessing it, it could be seen as undefined behavior (a la C specifications ;-) ), but then, if you pull on the same string, why even bother with confinement in the first place? If you call close() prematurely and you get a VM crash that's on you? Luckily, I think I have fixed this shortcoming in the alternative MemoryScope: http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java The trick is in using a 'state' with 3 values: OPEN, CLOSING, CLOSED ... The acquiring thread does the following in order: - increments the 'acquires' scalable counter (volatile write) - reads the 'state' (volatile read) and then enters a spin-loop: - if state == STATE_OPEN the acquire succeeded (this is fast path); else - if state == STATE_CLOSING it spin-loops re-reading 'state' in each iteration; else - if state == STATE_CLOSED it increments 'releases' sc
Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)
Hi Maurizio, On 5/1/20 3:00 PM, Peter Levart wrote: Luckily, I think I have fixed this shortcoming in the alternative MemoryScope: http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java I added support for dup() (modified above file in-place) and also the last missing part: MemoryScope.GLOBAL. So WDYT? Is it ok to propose this for panama? How do I proceed? Regards, Peter
Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)
On 4/30/20 8:10 PM, Maurizio Cimadamore wrote: On 30/04/2020 01:06, Peter Levart wrote: Think differently: what if the client succeeded in closing the segment, just because it did it in a time window when no thread in the thread pool held an open scope (this is entirely possible with parallel stream for example since threads periodically acquire and close scopes). This would have the same effect on threads in the thread pool - they would not be able to continue their work... What I'm trying to say is that this is just a mechanism to make things safe, not to coordinate work. If program wants to avoid trouble, it must carefully coordinate work of threads. This appear to me to be a bit of a slippery slope? Sure, if somebody prematurely calls close() on a segment while other threads are accessing it, it could be seen as undefined behavior (a la C specifications ;-) ), but then, if you pull on the same string, why even bother with confinement in the first place? If you call close() prematurely and you get a VM crash that's on you? Luckily, I think I have fixed this shortcoming in the alternative MemoryScope: http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java The trick is in using a 'state' with 3 values: OPEN, CLOSING, CLOSED ... The acquiring thread does the following in order: - increments the 'acquires' scalable counter (volatile write) - reads the 'state' (volatile read) and then enters a spin-loop: - if state == STATE_OPEN the acquire succeeded (this is fast path); else - if state == STATE_CLOSING it spin-loops re-reading 'state' in each iteration; else - if state == STATE_CLOSED it increments 'releases' scalable counter and throws exception The closing thread does the following in order: - writes STATE_CLOSING to 'state' (volatile write) - sums the 'releases' scalable counter (volatile reads) - sums the 'acquires' scalable counter (volatile reads) - compares both sums and: - if they don't match then it writes back STATE_OPEN to 'state' (volatile write) and throws exception; else - it writes STATE_CLOSED to 'state' (volatile write) and executes cleanup action This, I think, is better, isn't it? Regards, Peter Maurizio
Re: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)
Latest iteration - the follow issues were addressed: * fix a bug with alignment of native segments triggering spurious failures (contributed by Jorn) * fix javadoc and tests for access modes (contributed by Chris) * added benchmarks for Stream::findAny using segment spliterator (contributed by Peter) * addressed CSR comments Webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev Delta webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev_delta/ Javadoc: http://cr.openjdk.java.net/~mcimadamore/8243491_v3/javadoc Specdiff: http://cr.openjdk.java.net/~mcimadamore/8243491_v3/specdiff/overview-summary.html Cheers Maurizio On 27/04/2020 13:13, Maurizio Cimadamore wrote: Another iteration, which addresses the following issues: * wrong copyright headers in certain tests * issue with TestNative when running in debug mode caused by mismatched malloc/os::free (contributed by Jorn) * clarify javadoc of MemoryHandles::withStride * improved implementation of MemoryAccessVarHandleGenerator to use hidden classes rather than Unsafe.dAC (contributed by Mandy) Webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev Delta webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev_delta/ Javadoc: http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc Specdiff: http://cr.openjdk.java.net/~mcimadamore/8243491_v2/specdiff/overview-summary.html Cheers Maurizio On 23/04/2020 21:33, Maurizio Cimadamore wrote: Hi, time has come for another round of foreign memory access API incubation (see JEP 383 [3]). This iteration aims at polishing some of the rough edges of the API, and adds some of the functionalities that developers have been asking for during this first round of incubation. The revised API tightens the thread-confinement constraints (by removing the MemorySegment::acquire method) and instead provides more targeted support for parallel computation via a segment spliterator. The API also adds a way to create a custom native segment; this is, essentially, an unsafe API point, very similar in spirit to the JNI NewDirectByteBuffer functionality [1]. By using this bit of API, power-users will be able to add support, via MemorySegment, to *their own memory sources* (e.g. think of a custom allocator written in C/C++). For now, this API point is called off as "restricted" and a special read-only JDK property will have to be set on the command line for calls to this method to succeed. We are aware there's no precedent for something like this in the Java SE API - but if Project Panama is to remain true about its ultimate goal of replacing bits of JNI code with (low level) Java code, stuff like this has to be *possible*. We anticipate that, at some point, this property will become a true launcher flag, and that the foreign restricted machinery will be integrated more neatly into the module system. A list of the API, implementation and test changes is provided below. If you have any questions, or need more detailed explanations, I (and the rest of the Panama team) will be happy to point at existing discussions, and/or to provide the feedback required. Thanks Maurizio Webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v1/webrev Javadoc: http://cr.openjdk.java.net/~mcimadamore/8243491_v1/javadoc Specdiff: http://cr.openjdk.java.net/~mcimadamore/8243491_v1/specdiff/overview-summary.html CSR: https://bugs.openjdk.java.net/browse/JDK-8243496 API changes === * MemorySegment - drop support for acquire() method - in its place now you can obtain a spliterator from a segment, which supports divide-and-conquer - revamped support for views - e.g. isReadOnly - now segments have access modes - added API to do serial confinement hand-off (MemorySegment::withOwnerThread) - added unsafe factory to construct a native segment out of an existing address; this API is "restricted" and only available if the program is executed using the -Dforeign.unsafe=permit flag. - the MemorySegment::mapFromPath now returns a MappedMemorySegment * MappedMemorySegment - small sub-interface which provides extra capabilities for mapped segments (load(), unload() and force()) * MemoryAddress - added distinction between *checked* and *unchecked* addresses; *unchecked* addresses do not have a segment, so they cannot be dereferenced - added NULL memory address (it's an unchecked address) - added factory to construct MemoryAddress from long value (result is also an unchecked address) - added API point to get raw address value (where possible - e.g. if this is not an address pointing to a heap segment) * MemoryLayout - Added support for layout "attributes" - e.g. store metadata inside MemoryLayouts - Added MemoryLayout::isPadding predicate - Added helper function to SequenceLayout to rehape/flatten sequence layouts (a la NDArray [4]) * MemoryHandles - add support for general VarHandle combinators
Re: Collections.synchronizedXXX() and internal mutex (aka SyncRoot)
Thank you, I got it. I have one more a bit unrelated question.
The checked, synchronized and unmodifiable wrappers in some cases store
backing collection in more than one fields.
Thus `UnmodifiableList` has
1. its own field `List list` and
2. `Collection c`, which it inherits from
`UnmodifiableCollection`.
Also `UnmodifiableNavigableSet` has even 3 duplicated fields:
1. its own `NavigableSet ns`,
2. `SortedSet ss` from `UnmodifiableSortedSet` and
3. `Collection c` from `UnmodifiableCollection`.
Isn't it worth to get rid of such duplication? (at least for unmodifiable
collections). This may affect serialization, but I believe it's still
possible preserve serialization backward compatible, if it's necessary.
Or is it done intentionally?
Thank you,
Dmytro
On Fri, May 1, 2020 at 1:20 AM Stuart Marks wrote:
> The general rule in the collections that wrappers and views don't divulge
> their
> backing collections. The reason is fairly obvious for things like the
> checked
> wrappers and unmodifiable wrappers, but it's equally important for various
> view
> collections like those of Lists, Sets, and Maps. If there were something
> like
> getSyncRoot() it could be used to break encapsulation. For example:
>
> Map map = Collections.synchronizedMap(...);
> someMethod(map.values());
>
> Currently, the caller is assured that someMethod() can only see the values
> of
> the map. Also, as you observe, someMethod() can't safely iterate that
> collection
> using an iterator or stream. If getSyncRoot() were introduced to address
> that issue,
>
> void someMethod(Collection values) {
> @SuppressWarnings("unchecked")
> var map = (Map) Collections.getSyncRoot(values);
> // I now have access to map's keys and can put new entries,
> mwahaha!
> }
>
> Undoubtedly there are ways we can avoid this, but the cost is designing
> yet more
> complicated APIs in an area where it provides little value. I think it's
> pretty
> unlikely that we'll do anything like this, or variants that allow the
> caller to
> provide an external lock at creation time, such as proposed in
> JDK-4335520.
> There's a pretty fundamental clash between external locking and
> encapsulation,
> and the platform has shifted to pursuing other approaches for concurrency.
>
> Legacy code that needs to iterate collection views might find some luck
> replacing iterator loops with bulk methods like forEach() or removeIf().
>
> s'marks
>
>
> On 4/30/20 1:34 AM, dmytro sheyko wrote:
> > Hi Stuart,
> >
> > In general I agree with you regarding synchronized collections. But
> nevertheless
> > there is a lot of legacy code that still uses synchronized wrappers. And
> > sometimes synchronization is done on wrong lock object, which leads to
> > relatively rare but extremely hard to reproduce and troubleshoot errors.
> > Reworking whole this legacy stuff is risky. But if we had means to get
> the right
> > lock object for given synchronized collections, this would help us to
> make the
> > fixes more localized and hence safe. That's why I would like to know the
> reason,
> > why this has not been done earlier, and is there hope/plan this will be
> done in
> > near future.
> >
> > Thank you,
> > Dmytro
> >
> > On Thu, Apr 30, 2020 at 6:36 AM Stuart Marks > > wrote:
> >
> > Hi Dmytro,
> >
> > Callers of an API performing explicit synchronization, along with the
> > synchronized collections wrappers, have mostly fallen into disuse
> since the
> > introduction of the java.util.concurrent collections.
> >
> > Multiple threads can either interact directly on a concurrent
> collection, or
> > the
> > developer can provide an intermediate object (not a collection) that
> does
> > internal locking, and that exports the right set of thread-safe APIs
> to
> > callers.
> > I'm thus skeptical of the utility of enhancing these wrapper classes
> with
> > additional APIs.
> >
> > Do you have a use case that's difficult to handle any other way?
> >
> > s'marks
> >
> >
> >
> > On 4/29/20 12:58 AM, dmytro sheyko wrote:
> > > Hello,
> > >
> > > Have you ever discussed to make field mutex in synchronized
> collections
> > > accessible?
> > >
> > > Javadoc for Collections#synchronizedSortedSet suggest to iterate
> collection
> > > this way:
> > >
> > >SortedSet s = Collections.synchronizedSortedSet(new TreeSet());
> > >SortedSet s2 = s.headSet(foo);
> > >...
> > >synchronized (s) { // Note: s, not s2!!!
> > >Iterator i = s2.iterator(); // Must be in the synchronized
> block
> > >while (i.hasNext())
> > >foo(i.next());
> > >}
> > >
> > > I.e. in order to iterate subset, we also need a reference to the
> whole set,
> > > which is not really convenient. How about to make it possible to
> write:
> > >
> > >
