[PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Mon Apr 1 14:57:00 GMT 2019
On Apr 1 16:28, Michael Haubenwallner wrote:
> Hi Corinna,
> On 3/28/19 9:30 PM, Corinna Vinschen wrote:
> > can you please collect the base addresses of all DLLs generated during
> > the build, plus their size and make a sorted list? It would be
> > interesting to know if the hash algorithm in ld is actually as bad
> > as I conjecture.
> Please find attached the output of rebase -i for the dlls after bootstrap
> on Cygwin 3.0.4, each built with ld from binutils-2.31.1.
> > If we can improve on the distribution within the 8 Gigs area by changing
> > ld's address generation(*), we may improve situations like these without
> > too much hassle. As always, not a foolproof way out, but heck, 8 Gigs
> > is a lot of space for a couple 100 DLLs.
> Feels like I need some Cygwin rebase step in Gentoo Prefix anyway, as there
> are ~250 dlls right after bootstrap - without any application yet.
For comparison, I have 1835 system DLLs installed, and they only take
a bit less than 30% of the 8 Gigs.
I'm surprised to see 7 collisions, one of them even using the exact
same address. So the hash algorithm might be improvable.
In hindsight, we also might have been better off with a bit more space
for DLLs than 8 + 8 Gigs, I guess, given the size of the 64 bit address
space. We can still get to that by updating Cygwin, rebase and
binutils. For instance, assuming 32 Gigs + 32 Gigs, rebased DLLs would
start at 0x2:00000000, non-rebased DLLs would start at 0xa:00000000 and
the heap would start at 0x12:00000000. Still lots of room in the VM.
However, that would probably not fix the exact collision between
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Cygwin-patches