Yes. Core library code close to the JVM in OpenJDK (that in the java.base
module, commonly that in java.lang.* close to that in hotspot) often assumes
implementation specifics of the JVM. The two are closely coupled. There are
other such implementation-specific contracts like @Stable, or “final
On Mon, Aug 10, 2020 at 2:19 PM Doug Lea wrote:
> Catching up...
>
> As implied in other posts, the minimal fix is to add a trailing release
> fence (using Unsafe?) to the constructor.
FYI I have sent an RFR with the proposed fix ^
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-Augu
On 17/08/2020 15:24, Peter Levart wrote:
>
> On 8/16/20 7:35 PM, Andrew Haley wrote:
>> On 15/08/2020 10:13, Peter Levart wrote:
>>> https://github.com/openjdk/jdk/pull/9
>>>
>>>
>>> Sorry for abusing GitHub pull request mechanism but I don't have
>>> bandwidth currently to clone the mercurial repo
On 8/16/20 7:35 PM, Andrew Haley wrote:
On 15/08/2020 10:13, Peter Levart wrote:
https://github.com/openjdk/jdk/pull/9
Sorry for abusing GitHub pull request mechanism but I don't have
bandwidth currently to clone the mercurial repository ;-)
That's a lot of work to avoid a simple fence.
Tw
On 15/08/2020 10:13, Peter Levart wrote:
> https://github.com/openjdk/jdk/pull/9
>
>
> Sorry for abusing GitHub pull request mechanism but I don't have
> bandwidth currently to clone the mercurial repository ;-)
That's a lot of work to avoid a simple fence.
--
Andrew Haley (he/him)
Java Plat
On 8/15/20 10:37 AM, Peter Levart wrote:
https://github.com/openjdk/jdk/pull/7
Oops, I forgot to remove the redundant initialization of cacheArray
field in constructor, which revealed another place in code where the
check for null value has to be made. Here's a modified patch:
https://gi
Hi,
There might be a way to fix this NPE without adding additional memory
fences. The CacheValueMap.cacheArray field is not final because it can
change during lifetime of CacheValueMap - it holds an array of entries
which can get resized (replaced with bigger array) which is performed
while
On 11/08/2020 18:06, Hans Boehm wrote:
> I think the relevant statement is:
>
> "An address dependency between two reads generated by SVE vector load
> instructions does not contribute to the Dependency-ordered-before relation."
>
> This is only an issue if BOTH loads are SVE loads. In particular
On 11/08/2020 12:03, Andrew Dinn wrote:
> You ought to look at the pdf Ningsheng linked in the RFR that was posted
> with the SVE patch. The pdf is available here:
>
>https://developer.arm.com/docs/ddi0584/latest
>
> The relevant text is in section 4.4. Memory Ordering.
That looks better than
On 11/08/2020 11:47, Andrew Haley wrote:
> On 09/08/2020 18:55, Hans Boehm wrote:
>> There is no guarantee that the address dependency enforces ordering
>> if there is no final field involved. This may matter in the future,
>> since ARM's Scalable Vector Extension does not guarantee ordering
>> for
On 09/08/2020 18:55, Hans Boehm wrote:
> There is no guarantee that the address dependency enforces ordering
> if there is no final field involved. This may matter in the future,
> since ARM's Scalable Vector Extension does not guarantee ordering
> for address-dependent loads, if both loads are ve
Catching up...
As implied in other posts, the minimal fix is to add a trailing release
fence (using Unsafe?) to the constructor. Or less delicately, to access
only using acquire/release (which will cost a bit on ARM/Power, but
probably not noticeable on x86), or most simply (but expensively) t
Hi,
I'm David's colleague. I'm the one who's spotted this issue twice while
GraalVM is doing its points-to analysis with jdk11u-dev. The fuller
exception is here:
Caused by: java.lang.NullPointerException
at
java.base/java.lang.ClassValue$ClassValueMap.loadFromCache(ClassValue.java:535)
On 8/7/20 10:35 PM, John Rose wrote:
> (Here’s a tidbit of JMM politics: I once heard Doug Lea considering
> whether maybe all fields should be treated more like final fields.
> I don’t know if this is still a live idea, but it would make this
> bug go way, since nearly all constructors would the
For DCL to be correct Class.classValueMap should be declared volatile.
Final field guarantees are there to support unsafe publication in
special cases. In this case we should be using safe publication.
Cheers,
David
On 8/08/2020 9:22 am, Paul Sandoz wrote:
Here’s some pertinent information f
On Aug 7, 2020, at 2:35 PM, John Rose wrote:
>
> (Here’s a tidbit of JMM politics: I once heard Doug Lea
> considering whether maybe all fields should be treated
> more like final fields. I don’t know if this is still a live
> idea, but it would make this bug go way, since nearly all
> construc
Here’s some pertinent information from Doug’s excellent document of memory
order modes [1]:
"As a delicate (but commonly exploited) special case of the above
considerations, acquire-style reads of immutable fields of newly constructed
objects do not require an explicit fence or moded access --
On Aug 7, 2020, at 9:52 AM, Andrew Haley wrote:
>
> On 8/7/20 4:39 PM, David Lloyd wrote:
>
> > However, I'm wondering if this isn't a side effect of what appears
> > to be an incorrect double-checked lock at lines 374-378 of
> > ClassValue.java [1]. In order for the write to the non-volatile
>
On 8/7/20 4:39 PM, David Lloyd wrote:
> However, I'm wondering if this isn't a side effect of what appears
> to be an incorrect double-checked lock at lines 374-378 of
> ClassValue.java [1]. In order for the write to the non-volatile
> `cache` field of ClassValueMap, it is my understanding that
Hi David,
This is subtle. ClassValue extends from WeakHashMap that has a few final
fields. In such cases, for HotSpot at least, the compiler will place fence
between the stores to the fields of ClassValue and the store to publish in the
field of Class. So it should not be possible to observe a
20 matches
Mail list logo
