Bryce McKinlay writes:
> Andrew Haley wrote:
> > That would be nice. It's fairly easy to patch call sites (that's what
> > ld.so does) to remove all the Jv_initClass calls but hard to do it
> > portable because of problems with locking.
>
> ld.so doesn't patch call sites themselves, just the PLT entries.
Of course not, because the text section isn't usually writable.
However, the technique of overwriting instructions is indeed used by
ld.do.
> It should to be possible for libgcj's linker to make atable entries
> initially point to trampolines. The trampoline would call
> _Jv_InitClass, and _Jv_InitClass would update all the atable
> entries for that class, substituting the trampolines for real
> functions. Because class initialization acquires the class lock,
> there shouldn't be any locking issues except perhaps on arch's with
> very weak memory ordering.
When you jumped to a static method for the first time, you'd hit the
stub. That stub would jump to a routine for initializing the class
and then rewriting all the stubs for that class. At that point, there
are potentially several threads in progress. One of these threads
would "win", and the others would have to wait until the class
initialization was complete. So far, so good.
Once the class was initialized, you'd need to rewrite the instructions
in the trampolines to point to the static methods that don't do class
initialization. While all this was going on, there still would be
threads jumping to these trampolines. However, these trampolines are
not themseolves protected by locks, and there's no guarantee that you
can rewrite the instructions atomically. So, you'd run the risk of a
partially rewritten instruction being executed. If you can rewrite
the trampolines atomically then I think you might be OK.