This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, libfortran] RFC: Shared vtables, constification
On Fri, Feb 17, 2012 at 12:44 PM, Janne Blomqvist
<blomqvist.janne@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 23:04, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> 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.
>
> 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! :-)
Ciao!
Steven