This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Serialization bug fixes
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.