Bug 547827 - The Change for Bug 541864 is in theory not complete
Summary: The Change for Bug 541864 is in theory not complete
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.12   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-31 11:45 EDT by Roman Fischer CLA
Modified: 2023-05-18 12:47 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Fischer CLA 2019-05-31 11:45:44 EDT
It is "in theory", because such concurrency-Problems are not good testable so some Test can only fail on some Operationsystem, java vm types or after long run. 

http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=ff39809ae9a6095793e47bc5e9a7e26a302ad7f5

But the Problem is very real and describe in the Book from Joshua Bloch's "Effective Java (2nd Edition)" (he wrote the JMM (java memory model) spec):

The part Topic is "lacy initialization"  (item 71). The code in InnerClassInfo is similar to the "racy single-check idiom" but follow things are not equal:

1) there is no single-check so reordering and other optimizations could occur 
2) the initialised (shared) variable is not a primitive typ other than long or double and also it is not an imutable (with final instanz variable) Object Type. It ist an char[] so there is no "happends before" rule for the content of this Objekt if one Thread has create this and the referenz of this Object can access from other Thread without memory model "synchronization". 

So the NullPointerException is still possible, but also wrong computed Data without Exception.

so hier an suggestion (without test) for an solution (it could similar use for getEnclosingTypeName(), getModifiers() and getName() ):
-------------
private volatile char[] innerName;
//remove: private boolean readInnerClassName = false; 

public char[] getSourceName() {
	
    char[] tmp = this.innerName; //single check for maximum performance
    if (this.innerNameIndex != 0 
            && tmp == null) {
	int utf8Offset = this.constantPoolOffsets[this.innerNameIndex] - this.structOffset;
	this.innerName = tmp = utf8At(utf8Offset + 3, u2At(utf8Offset + 1));
	
    }
    return tmp; 
}
---
there is still an other Topic:
if on the shared point of the reference for the new created Object from InnerClassInfo is no JMM "synchronization" then innerNameIndex is also  not safe for use. One solution is to make innerNameIndex  final and initialize only in the Constructor -> this create also an happends before rule. 
https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5
But think so, also the super class ClassFileStruct has to review about construction
Comment 1 Andrey Loskutov CLA 2019-05-31 12:56:44 EDT
Thanks Roman. Do you want to provide a Gerrit patch? 

Regarding innerNameIndex: if I see it right, it is already set in constructor only? What should be unsafe here? If object is constructed, the value never changes, so all reads will always see same value.
Comment 2 Eclipse Genie CLA 2021-05-21 11:33:09 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 3 Eclipse Genie CLA 2023-05-18 12:47:48 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.