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

[Andrew Haley <aph at redhat dot com>]

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.