Proposed Change to gnu/gcj/runtime/StackTrace.java

Sat Mar 15 11:32:00 GMT 2003

Angelo Corsaro writes:
 > Hello All,
 > 
 > I am extending the GCJ compiler to support the Real-Time 
 > Specification for Java (RTSJ), and recently while finishing up the
 > implementation of memory reference checking I found out that the
 > <update> method in gnu/gcc/runtime/natStackTrace.cc did the following:
 > 
 > // ...
 > gnu::gcj::runtime::MethodRef *ref
 > = new gnu::gcj::runtime::MethodRef 
 > ((gnu::gcj::RawData *)meth, klass);
 > gnu::gcj::runtime::AddressHolder *holder
 > = new gnu::gcj::runtime::AddressHolder
 > ((gnu::gcj::RawData *)(meth->ncode));
Not in my version it doesn't. What version are you looking at? It
looks like 1.1, and things have changed greatly since then.
 > 
 > map->put (holder, ref);
 > 
 > // ...
 > 
 > This fragment of code adds a reference to a method to an
 > IdentityHashMap, using meth->ncode as key. The issues I had to struggle
 > with is that meth->ncode is not a "real" Java object, and this caused
 > check on the store for the array used by map to fail.
That's right. The idea behind using an IdentityHashMap is that it is
a very fast mapping between a key and an object.
 > The change seems to work fine, and avoids the nastiness of adding a non
 > Java object inside a map. I guess that the additional new in the update 
 > method should not be an issue since there are already two allocations.
 > 
 > 
 > Does anyone see any problem with this? Should the StackTrace class be
 > changed to use this scheme?
I don't really understand how this helps. You move from an
IdentityHashMap that has a reference to a non-Java object to an
AddressHolder that has a reference to a non-Java object. Surely that
violates the rules just the same. Can you explain a bit more?
Andrew.