data and bss tests in dll_list::alloc
Wed Feb 8 16:39:00 GMT 2012
On Wed, Feb 08, 2012 at 11:33:10AM -0500, Ryan Johnson wrote:
>On 08/02/2012 11:26 AM, Christopher Faylor wrote:
>> On Wed, Feb 08, 2012 at 04:41:52PM +0100, Corinna Vinschen wrote:
>>> On Feb 8 10:21, Christopher Faylor wrote:
>>>> On Wed, Feb 08, 2012 at 03:54:19PM +0100, Corinna Vinschen wrote:
>>>>> I just fixed a typo in the fabort calls in dll_list::alloc. But in
>>>>> fact I'm wondering if we really need the extensive data_start/data_end/
>>>>> bss_start/bss_end tests. The reason is simple. All DLL segments are
>>>>> always loaded into adjacent addresses, always in the order given by the
>>>>> DLL segement information.
>>>> If that is the case can we simplify the child_copy operation? That
>>>> would speed up fork slightly.
>>> I'm not sure, but if you're asking if we can only give a single address
>>> to child_copy, then the answer is probably no. You can't rely on the
>>> fact that data and bss segments are adjacent segments in the DLL, just
>>> that adjacent segments in the DLL will be loaded into adjacent addresses
>>> in the processes VM.
>> I thought you were implying that data/bss load order was always the same.
>> It is isn't it?
>My understanding is that the bss and data segments usually don't occupy
>the same positions in the dll-as-file that they do in the
>dll-as-mmaped-entity (what Corinna said), but that any two mapped
>instances of a dll would put data/bss in consistent positions relative
>to the dll's base (what CGF wonders). However, we'd want to confirm that
>data/bss were actually adjacent before firing off a single memcpy.
Ok. So a simple optimization would be to detect when copied sections
were adjacent and coalesce them into one copy operation. I'll take a
look into doing that.
>Does that make sense or am I misunderstanding the issue?
Makes sense. Thanks.
More information about the Cygwin-developers