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 Fri, Feb 17, 2012 at 12:44 PM, Janne Blomqvist
<> wrote:
> 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 cache line thing had crossed my mind, too. I'm not sure if that's
a performance blocker for I/O in the end, though.

> 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.

Fair enough, that's a good reason to make this change.

>> 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.

Heh, I did not mean to be unreasonable. I really appreciate all the
work you're doing on gfortran! :-)


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