This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: [Patch, libfortran] RFC: Shared vtables, constification


On Mon, Feb 13, 2012 at 7:20 PM, Janne Blomqvist
<blomqvist.janne@gmail.com> wrote:
> Hi,
>
> the attached patch changes the low-level libgfortran IO dispatching
> mechanism to use shared vtables for each stream type, instead of all
> the function pointers being replicated for each unit. This is similar
> to e.g. how the C++ frontend implements vtables. The benefits are:
>
> - Slightly smaller heap memory overhead for each unit as only the
> vtable pointer needs to be stored, and slightly faster unit
> initialization as only the vtable pointer needs to be setup instead of
> all the function pointers in the stream struct.
>
> - Looking at unix.o with readelf, one sees
>
> Relocation section '.rela.data.rel.ro.local.mem_vtable' at offset
> 0x15550 contains 8 entries:
>
> and similarly for the other vtables; according to
> http://www.airs.com/blog/archives/189 this means that after relocation
> the page where this data resides may be marked read-only.
>
> The downside is that the sizes of the .text and .data sections are
> increased. Before:
>
> ? text ? ?data ? ? bss ? ? dec ? ? hex filename
> 1116991 ? ?6664 ? ? 592 1124247 ?112797
> ./x86_64-unknown-linux-gnu/libgfortran/.libs/libgfortran.so
>
> After:
>
> ? text ? ?data ? ? bss ? ? dec ? ? hex filename
> 1117487 ? ?6936 ? ? 592 1125015 ?112a97
> ./x86_64-unknown-linux-gnu/libgfortran/.libs/libgfortran.so
>
>
> The data section increase is due to the vtables, the text increase is,
> I guess, due to the extra pointer dereference when calling the IO
> functions.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk, or 4.8?

Certainly not for trunk at this stage.

For 4.8: So the trade-off is between faster initialization and smaller
heap vs. fewer pointer dereferences? Does this patch fix an actual
problem? Does it bring a killer feature? Otherwise, I'd say "if it
ain't broke, don't fix it!"

Ciao!
Steven


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