[mat-dev] ClassImpl representation of static fields

[Andrew Johnson <andrew_johnson@xxxxxxxxxx>]

I'm looking at ClassImpl as part of 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=268458
- stack frame information, and also considering how we might represent 
native memory.

Is there a reason the classloader link is a NamedReference rather than a 
PseudoReference? Compare this with the '<class>' link, which is a 
PseudoReference.

I think there should be a link to the superclass in the same way in 
getOutboundReference and getReferences, so add a PseudoReference 
'<super>'. This link is important because if a class is alive then its 
superclass must be alive, and relying on a link via the class loaders may 
not be obvious if the parent class loader link is not maintained in the 
Java heap.

The DTFJ adapter creates some pseudo static fields for constant pool 
references and for Java 6 when the java.lang.Class object itself has 
instance fields. The adapter converts these instance fields in the 
java.lang.Class object to static fields with '<' to avoid confusion with 
real static fields in the actual class.
<vmRef>
<classLoader>
<protectionDomain>
<classNameString>

Should those fields be marked as PseudoReferences?

All these pseudo static fields with '<' in the name look a little 
confusing in the inspector view of the class. I think that the statics tab 
should show the real static fields and for a class object the attributes 
tab should show the pseudo static fields, including '<class'>, '<super>', 
'<classloader>' as these conceptually are more like instance fields on the 
class object, as they vary down the class hierarchy.

Does anyone object to these changes?

Andrew Johnson







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU