Serialization bug fixes

Thu Jun 17 18:52:00 GMT 2004

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > > > It seems to me that basically all user programs must be compiled
 > > > without sibcalls.
 > >
 > >I was just about ready to come to that conclusion.
 > >
 > > > Maybe we'd like to compile parts of libgcj itself with sibcalls
 > > > enabled, though figuring out which parts are safe and would benefit
 > > > might be tricky.
 > >
 > >It's not so hard, really: anything that needs to walk the stack to
 > >find its caller must not be called via a sibcall.
 > 
 > And also, presumably, must not be inlined?
Well, we can only inline in fairly limited circumstances anyway: I
don't think this changes anything.
 > > > I would suggest that we simply disable sibcalls in the front end and
 > > > let the user explicitly enable them with a command-line option, but
 > > > from the manual it looks like some -O options enable sibcalls.
 > >
 > >I guess we just turn sibcalls off lin libgcj.spec.
 > 
 > That seems a bit extreme to me. Its only a small set of functions that 
 > need to find their caller. These functions are all presumably public, so 
 > isn't it reasonable to assume that they would never be subject to 
 > sibcall/inlining optimizations?
That's true. I added java_decl_ok_for_sibcall() to the compiler, which
prevents sibcalls across class boundaries for just this reason.
 > btw - I am planning to add a calling-class check interface that looks 
 > something like this:
 > 
 > /* Find the class which called thisClass, ie the class below thisClass 
 > on the call stack. */
 > jclass _Jv_GetCallingClass(jclass thisClass)
 > By looking for thisClass on the stack and then returning the class below 
 > it, this will avoid the fragility we currently have due to taking the 
 > class at a fixed stack frame index. ie: things like the number of calls 
 > on the stack, inlining, and sibcall optimizations within the class doing 
 > the check shouldn't matter, as long as the call into the class itself 
 > wasn't optimized.
Yeah, that's where I came adrift: I needed to know my caller's class
loader. Whether I needed to start two frames up or one frame up
depended on whether I was compiling with optimization or not!
I suppose the idea of_Jv_GetCallingClass is to scan backwards, looking
for the first frame that is not a method of thisClass. (Or one of its
superclasses?) That sounds like it would work reliably, and ought to
solve the problem.
Andrew.