This is the mail archive of the mailing list for the GCC 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 23:04, Steven Bosscher <> wrote:
> On Mon, Feb 13, 2012 at 7:20 PM, Janne Blomqvist
> <> 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 '' at offset
>> 0x15550 contains 8 entries:
>> and similarly for the other vtables; according to
>> 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/
>> After:
>>  text  Âdata   bss   dec   hex filename
>> 1117487 Â Â6936 Â Â 592 1125015 Â112a97
>> ./x86_64-unknown-linux-gnu/libgfortran/.libs/
>> 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.

Fair enough.

> For 4.8: So the trade-off is between faster initialization and smaller
> heap vs. fewer pointer dereferences?

From a performance perspective, yes. Also, a multi-threaded program
may benefit slightly from fewer cacheline ping-pongs due to the
read-only vtables being separated from the RW data in the stream
struct. That being said, while there are a few performance issues
lurking here and there in libgfortran, virtual function dispatch isn't
one of them. I think you'd be hard pressed to come up with a benchmark
where you could see a difference.

The other advantage is that by putting the vtables in read-only pages,
the chance of a buggy program getting a SIGSEGV instead of corrupting
the library state is slightly increased.

> Does this patch fix an actual
> problem? Does it bring a killer feature?

No, it's certainly not a "killer feature". In general, considering the
maturity of gfortran, I think it's unreasonable to expect that a
bordering-on-trivial patch would bring a killer feature.

The patch came about as a small experiment I did, and as I considered
the result an overall improvement (even if admittedly quite a minor
one), I added a ChangeLog and submitted it.

Janne Blomqvist

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