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?
2012-02-13 Janne Blomqvist<jb@gcc.gnu.org>
* io/unix.h (struct stream): Rename to stream_vtable.
(struct stream): New struct definition.
(sread): Dereference vtable pointer.
(swrite): Likewise.
(sseek): Likewise.
(struncate): Likewise.
(sflush): Likewise.
(sclose): Likewise.
* io/unix.c (raw_vtable): New variable.
(buf_vtable): Likewise.
(mem_vtable): Likewise.
(mem4_vtable): Likewise.
(raw_init): Assign vtable pointer.
(buf_init): Likewise.
(open_internal): Likewise.
(open_internal4): Likewise.
--
Janne Blomqvist