This is the mail archive of the cygwin-developers mailing list for the Cygwin 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: data and bss tests in dll_list::alloc


On Wed, Feb 08, 2012 at 11:39:02AM -0500, Christopher Faylor wrote:
>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.

Just to close the record on this:  I did reimplement child_copy to do
this but I never saw it actually work.  This was apparently due to
section alignment since there would be a few bytes between the end
of data and the beginning of bss.  So, rather than go to more effort
to figure this out, I just dropped the idea.

cgf


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