It's a bit more complicated - after all we are talking about the memory
model and class loading.
There are some shared secrets that can be loaded later (e.g. AWT), when
Threads are there.
The field is only set in one single place inside the JDK, so we are
talking about 3 scenarios:
* The
Hans' assessment seems about right in the generic case he's describing.
But consider:
1. There is no concurrent setting of anything here - it's done in a
static initializer which will happen exactly once by the thread
initializing the class ($ 12.2.4 item 9).
2. While there is a data race on
That would also be my understanding of the current situation, though this
contradicts what
Claes wrote.
Maybe the JVM behaves in a way which does not allow reordering, but the JLS
definitely seems
to allow it. Section § 12.2.4 [0] only mentions that for the class to be
initialized there
has to
What guarantees that if the first read does not see null, the second read
will not see null?
Sections 4.2 and 4.4 of Aleksey’s “Close Encounters of the JMM Kind” seem
to show that such scenario is possible in face of concurrent setting of
non-volatile variable.
> Hello, I feel like this was previously discussed in
> https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot
> find original mail I post this here.
>
> Currently `Collections.addAll()` is implemented and documented as:
> /**
> * ...
> * The behavior of this
On Tue, 29 Dec 2020 10:56:02 GMT, Peter Levart wrote:
>> Hint: you could use
>> `java.util.ImmutableCollections#listFromTrustedArrayNullsAllowed` if only
>> this method would allow other types of arrays, not just Object[]... I really
>> don't know why this restriction couldn't be lifted as
On 29/12/2020 7:15 pm, Florian Weimer wrote:
* David Holmes:
More accurately soft-references will be cleared before throwing an OOME
due to Java heap exhaustion. There are other things that can throw OOME
(like your array example, or "throw new OutOfMemoryError();") that don't
correspond to
Depends on what `initialize()` is.
If it (at least) reads a volatile field, then the compiler can't reorder
the second read before the first.
- Johannes
On 29-Dec-20 14:42, some-java-user-99206970363698485...@vodafonemail.de
wrote:
Hello,
the class `jdk.internal.access.SharedSecrets`
* some-java-user:
> However, neither the static fields are `volatile` nor are the getter
> methods synchronized. So if my understanding of the Java Memory
> Model is correct, the compiler is free to reorder the two static
> field reads. So it is in theory possible that the first read yields
> a
All the shared secrets are injected as a side effect of loading the
class the getter ensures is initialized - which should provide the
necessary constraints to ensure there is no way for a reordering to
happen where the access object returned can be observed to be null.
E.g.
if
Hello,
the class `jdk.internal.access.SharedSecrets` provides getter methods which all
look similar to this:
```
if (static_field == null) {
initialize();
}
return static_field;
```
However, neither the static fields are `volatile` nor are the getter methods
synchronized. So if my
On Tue, 29 Dec 2020 10:42:18 GMT, Peter Levart wrote:
>> Hi,
>> Sorry for joining late to this discussion, but I think that changing this
>> method to delegate to c.addAll(Arrays.asList(...)) might not be the best
>> thing to do here. Why?
>> - This might look as a convenience method, but it
On Tue, 29 Dec 2020 10:21:07 GMT, Peter Levart wrote:
>> "This message" referred to the entirety of that very comment of mine
>> https://github.com/openjdk/jdk/pull/1764#issuecomment-748926986
>>
>> I prepended that message with that clause (that is, the wording to the left
>> of the colon)
On Mon, 21 Dec 2020 15:23:06 GMT, Pavel Rappo wrote:
>> @pavelrappo also see this not very old comment:
>> https://github.com/spring-projects/spring-framework/pull/24636#pullrequestreview-370684078
>
> "This message" referred to the entirety of that very comment of mine
>
* David Holmes:
> More accurately soft-references will be cleared before throwing an OOME
> due to Java heap exhaustion. There are other things that can throw OOME
> (like your array example, or "throw new OutOfMemoryError();") that don't
> correspond to heap exhaustion and and so
15 matches
Mail list logo
