[
https://issues.apache.org/jira/browse/OAK-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453809#comment-17453809
]
Thomas Mueller commented on OAK-9634:
-------------------------------------
Why did it work reliably in the past? Not because of the Java memory model: it
was because we relied on the x86 memory model. And with ARM, the x86 memory
model is not used: https://www.infoq.com/news/2020/11/rosetta-2-translation/
"The biggest hurdle was "memory-ordering", the order in which two CPUs see
modifications in memory by each other."
https://news.ycombinator.com/item?id=14318877 "x86 has a much stronger memory
model than ARM" and "memory order. How CPU is allowed to reorder normal
unsynchronized loads and stores. X86 has strong order, but ARM CPUs can reorder
loads and stores significantly more."
> CacheLIRS: test failure with ARM processor
> ------------------------------------------
>
> Key: OAK-9634
> URL: https://issues.apache.org/jira/browse/OAK-9634
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Priority: Major
> Fix For: 1.42.0
>
>
> In a ARM machine (MacBook with M1 chip) I get a "somewhat" reproducible
> failure as follows:
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.304
> s <<< FAILURE! - in org.apache.jackrabbit.oak.cache.ConcurrentTest
> [ERROR] testRandomOperations(org.apache.jackrabbit.oak.cache.ConcurrentTest)
> Time elapsed: 1.068 s <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.find(CacheLIRS.java:1323)
> at org.apache.jackrabbit.oak.cache.CacheLIRS.peek(CacheLIRS.java:263)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS.entrySet(CacheLIRS.java:545)
> at
> org.apache.jackrabbit.oak.cache.CacheLIRS$1.entrySet(CacheLIRS.java:1731)
> at
> org.apache.jackrabbit.oak.cache.ConcurrentTest$3.run(ConcurrentTest.java:210)
> {noformat}
> If I slightly change the code (e.g. add try-catch in the find method), then
> it no longer fails. I think the problem is the different memory model of ARM
> chips, and so e.key is assigned a bit after the entry is added to the array.
> Making the key final resolved the issue for me.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
