Re: Serialization bug fixes

[Bryce McKinlay <mckinlay at redhat dot com>]

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?

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

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.

Regards

Bryce