This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FYI: Linker & Verifier fixes (really GC mark procedures)


Andrew Haley wrote:
Tom Tromey writes:
> >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
> > Andrew> Indeed. I have a patch in the pipeline that causes all objects of
> Andrew> class Class to be properly allocated rather than statically allocated
> Andrew> by the linker. In turn, this has the potential to make _Jv_MarkObj
> Andrew> eventually go away.
> > I did a little work on the gcjx branch in this area. But it has
> never been tested. Anyway the idea was that the compiler could emit
> real mark descriptors for Class, by special-casing it a bit in
> boehm.c.
> > With your work we could just defer this to runtime like we do for
> interpreted classes. The goal would be to remove all the
> Class-specific code from _Jv_MarkObj.


Right.  I've been trying to get this done all year, but I keep getting
sidetracked to fix other things.  Sigh...

But yeah, my plan is to remove almost all knowledge of the shape of an
instance of Class from the compiler, and then the runtime can do
whatever is convenient.  I'm a bit worried that this might result in
long startup times, so I'm going to be cautious -- at least to begin
with.

I suspect it is actually possible to _improve_ startup time once this is fully implemented.


If the bulk of the class metadata is pointer-free and read-only, then we eliminate a vast number of relocations - so much less time ought to be spent in the dynamic linker. It should be possible to only create Class objects for classes which are actually used/referenced at runtime, so the added allocation overhead ought to be pretty minimal.

Bryce


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]