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

Andrew Haley aph@redhat.com
Sun Mar 16 08:40:00 GMT 2003


Angelo Corsaro writes:
 > 
 > >  > 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.

Got it, thanks.

 > 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.

You would.  :-)

 > 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? 

It does.  Now I'm trying to think of a way to do this with no overhead -- 
the run time speed of this method is important.

I'm thinking of a native method that does 

    table[h] = key;

with no checking.  So we could have two private native methods that do
an array assignment, one with the check and one without.  Or maybe we
could find some way to make the compiler not emit the _Jv_CheckMemRef
when it's compiling some code.

Andrew.



More information about the Java mailing list