Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 3.0.1
-
Fix Version/s: 3.1.3
-
Labels:None
Description
The annotation @Untraced is used in several places throughout JikesRVM for public fields - this conflicts with the specification of @Untraced that states fields must be declared private. Is this a typo in the definition of @Untraced or some sort of abuse?
Some potentially problematic files include:
MMTk/src/org/mmtk/vm/VM.java
rvm/src/org/jikesrvm/ppc/Registers.java
rvm/src/org/jikesrvm/ia32/Registers.java
rvm/src/org/jikesrvm/scheduler/ProcessorLock.java
rvm/src/org/jikesrvm/scheduler/RVMThread.java
rvm/src/org/jikesrvm/scheduler/Processor.java
rvm/src/org/jikesrvm/jni/JNIEnvironment.java
Apologies, this is something that is in need of some tidying up. The fundamental issue is that Untraced has implications for the code sequence compiled when accessing the field (it does not compile in read/write barriers). For that reason the field must be resolved whenever we compile code that uses it, as annotations are not visible for unresolved classes.
A simple way to deal with this is to ensure that all Untraced fields are private, as such fields are never accessed in an 'unresolved' manner. However, this was not the safety mechanism ulitimately used: the requirement was toned down to failing when an @Untraced field is resolved at runtime. This does catch all the problem cases, but only shows itself as a runtime (rather than compile/bootimage time) error.
I will leave this open to improve the code and/or update the documentation.