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

Sat Mar 15 16:32:00 GMT 2003

Hello Andrew,
On Sat, 2003年03月15日 at 05:32, Andrew Haley wrote:
> > // ...
> > 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.

Sorry I copied the version I had modified, the version out of the gcc
3.3 branch does the following:
 gnu::gcj::runtime::MethodRef *ref
	 = new gnu::gcj::runtime::MethodRef 
 ((gnu::gcj::RawData *)meth, klass);
 map->put ((java::lang::Object*)(meth->ncode), ref);
Thre previous code contained already my changes.
> > 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?

The only reason why I had to encapsulate the non-Java object into the 
address holder is because each time there is a java field store or
an array store I have modified the compiler to emit a call to a 
function which checks the legality of the assignment:
	void 
	_Jv_CheckMemRef (jobject from, jobject to)
For RTSJ this is needed since objects can be allocated in memory region
that have different lifetime, and some of which are not under the
control of the GC (such as Scoped Memory). This check makes sure that
no object allocated in a memory area that has potentially a longer 
life time can ever refer to an object having a shorter lifetime.
For example objects allocated on the Heap cannot refer to objects
allocated in scoped memory.
That said, the problem of is that the map.put() involves something like:
 table[h] = key;
This store is checked, believing that key is an object, but it is not,
and this is a problem for me (i.e. I try to access a field on the to
object, and this clearly lead to segfaults).
Now you'd think that we have just moved the problem to the set field of
the AddressHolder class. But that is an easier problem to solve since I
can avoid to emit the check for that class at compile time. 
Does this make sense? 
Cheers,
 Angelo
-- 
Angelo Corsaro
Department of Computer Science
Washington University
One Brookings Drive, Box 1045
St. Louis, MO 63130
http://www.cs.wustl.edu/~corsaro