This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Eliminating static roots from gcj
- From: Andrew Haley <aph at redhat dot com>
- To: David Daney <ddaney at avtrex dot com>
- Cc: "Boehm, Hans" <hans dot boehm at hp dot com>, java at gcc dot gnu dot org
- Date: Tue, 14 Mar 2006 18:56:16 +0000
- Subject: Re: Eliminating static roots from gcj
- References: <65953E8166311641A685BDF71D8658266C1C5F@cacexc12.americas.cpqcorp.net> <17430.55504.270949.558440@zapata.pink> <44170D91.3020002@avtrex.com>
David Daney writes:
> Andrew Haley wrote:
> > Hans,
> >
> > I have a problem before merging this code to the trunk.
> >
> > Accesses to String and Class constants is now slower than before.
> > Previously, such an access was simply
> >
> > _CD_<class>[N]
> >
> > where _CD_<class> was an array in the initialized data section. With
> > PIC, this simply generated a PC+offset fetch instruction:
> >
> > movq 8+_CD_q(%rip), %rax
> >
> > Now that we aren't scanning the data sections of objects, we have to
> > do something like
> >
> > class$->constants.data[i]
> >
>
> Why is this? For a shared object, the relative position of different
> parts of the object are not going to be moving around, are they?
Because instances of Class and constant pools are no longer in shared
objects, but in the heap. That's what my patch does.
My plan is eventually only to have read-only data in the shared
objects, and place all read/write data in the heap. This means the
garbage collector doesn't have to scan shared libraries, and this
makes garbage collection a great deal faster. It also has the
potential greatly to reduce startup time, because we won't have to
process a vast number of relocs before starting an app.
Of course, there are some additional memory allocation costs
associated with this change, but you can rest assured that I don't
intend to do anything that will make gcj slower.
Andrew.