On 06/18/2018 06:53 PM, Claes Redestad wrote:
Plain write that follows in program a volatile write, can in theory
float before the volatile write. So if you publish a Properties
instance via data race (via plain write), the observer may still see
uninitialized 'map' and 'defaults' fields.
On Mon, Jun 18, 2018 at 10:19 PM, David Holmes
wrote:
>
> I'm unsure why we're trying to make this particular class
> unsafe-publication-proof, but I guess it's generally a good thing.
The particular field we're changing is a """final""" field, and it would be
pretty embarrassing to grab a stal
On 19/06/2018 3:08 PM, Martin Buchholz wrote:
Latest version looks like this:
public Object clone() {
try {
@SuppressWarnings("unchecked")
CopyOnWriteArrayList clone =
(CopyOnWriteArrayList) super.clone();
clone.resetLoc
Latest version looks like this:
public Object clone() {
try {
@SuppressWarnings("unchecked")
CopyOnWriteArrayList clone =
(CopyOnWriteArrayList) super.clone();
clone.resetLock();
+// Unlike in readObject, here we can
On 19/06/2018 6:01 AM, Doug Lea wrote:
On 06/18/2018 11:22 AM, Martin Buchholz wrote:
Or better, lockField.set in resetLock could instead be setRelease.
Except it is using reflection, not VarHandles. So it could be preceded
with VarHandle.releaseFence(), although it is hard to th
On 06/18/2018 11:22 AM, Martin Buchholz wrote:
> Or better, lockField.set in resetLock could instead be setRelease.
> Except it is using reflection, not VarHandles. So it could be preceded
> with VarHandle.releaseFence(), although it is hard to think of a
> scenario in which it cou
On 2018-06-18 18:09, Peter Levart wrote:
On 06/18/2018 04:47 PM, Claes Redestad wrote:
On 2018-06-18 16:23, Peter Levart wrote:
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile rea
On 06/18/2018 04:47 PM, Claes Redestad wrote:
On 2018-06-18 16:23, Peter Levart wrote:
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.ne
On Mon, Jun 18, 2018 at 7:21 AM, Doug Lea wrote:
> On 06/18/2018 10:05 AM, Martin Buchholz wrote:
> > There's a long history of cheating and setting final fields in
> > pseudo-constructors readObject and clone, which is well motivated since
> > Java should really support pseudo-constructors in a
On 2018-06-18 16:23, Peter Levart wrote:
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.net/~redestad/8199435.00/
Then file a follow-up RF
Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.net/~redestad/8199435.00/
Then file a follow-up RFE to investigate if we can make these fields
On 06/18/2018 10:05 AM, Martin Buchholz wrote:
> There's a long history of cheating and setting final fields in
> pseudo-constructors readObject and clone, which is well motivated since
> Java should really support pseudo-constructors in a better way..
> Cheating has used Unsafe or reflection with
There's a long history of cheating and setting final fields in
pseudo-constructors readObject and clone, which is well motivated since
Java should really support pseudo-constructors in a better way..
Cheating has used Unsafe or reflection with setAccessible
(CopyOnWriteArrayList.resetLock()).
I ha
I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.net/~redestad/8199435.00/
Then file a follow-up RFE to investigate if we can make these fields
non-volatile, e.g. using careful fencing as suggested
by
On 2018-06-18 13:06, Peter Levart wrote:
Adding a volatile read on every read through Properties is likely to
have some performance impact,
On non-Intel architectures in particular. On intel it would just
inhibit some JIT optimizations like hoisting the read of field out of
loop...
Righ
Hi Claes,
On 06/18/2018 12:02 PM, Claes Redestad wrote:
On 2018-06-18 05:45, David Holmes wrote:
Making it "final" to fix unsafe publication only works with actual
publication after construction. You're making it "final" but then not
setting it at construction time and instead using UNSAFE.p
On 2018-06-18 05:45, David Holmes wrote:
Making it "final" to fix unsafe publication only works with actual
publication after construction. You're making it "final" but then not
setting it at construction time and instead using UNSAFE.putVolatile
to get around the fact that it is final! The
Hi Brent,
On 16/06/2018 1:44 AM, Brent Christian wrote:
Hi,
In JDK 9, 8029891[1] refactored java.util.Properties to store its values
in an internal ConcurrentHashMap, and removed synchronization from
"reader" methods in order to avoid potential hangs/deadlocks during
classloading.
Claes ha
Hi Brent,
If 'map' field could be observed as null (which I think is only
possible, if Properties object is unsafely published), then so can
'defaults' field. You could make it final as well if it was not protected.
So I'm thinking what kind of memory fences would make those fields
behave so
Yes, like that, thanks,
Paul.
> On Jun 15, 2018, at 11:01 AM, Brent Christian
> wrote:
>
> On 6/15/18 10:35 AM, Paul Sandoz wrote:
>> I would also publish the map in readHashtable after you have placed in the
>> keys/values.
>
> Like this?
>
> // create CHM of appropriate capacity
>
On 6/15/18 10:35 AM, Paul Sandoz wrote:
I would also publish the map in readHashtable after you have placed in the
keys/values.
Like this?
// create CHM of appropriate capacity
-map = new ConcurrentHashMap<>(elements);
+ConcurrentHashMap tmpMap = new
ConcurrentHash
> On Jun 15, 2018, at 8:44 AM, Brent Christian
> wrote:
>
> Hi,
>
> In JDK 9, 8029891[1] refactored java.util.Properties to store its values in
> an internal ConcurrentHashMap, and removed synchronization from "reader"
> methods in order to avoid potential hangs/deadlocks during classloadi
Hi,
In JDK 9, 8029891[1] refactored java.util.Properties to store its values
in an internal ConcurrentHashMap, and removed synchronization from
"reader" methods in order to avoid potential hangs/deadlocks during
classloading.
Claes has noticed that there is the possibility of the new 'map' f
23 matches
Mail list logo
