Sun May 22 20:14:00 GMT 2011
On Sun, May 22, 2011 at 03:27:05PM +0200, Corinna Vinschen wrote:
>On May 17 11:53, Ryan Johnson wrote:
>> On 17/05/2011 11:32 AM, Corinna Vinschen wrote:
>> >On May 17 07:12, Ryan Johnson wrote:
>> >>On 17/05/2011 4:19 AM, Corinna Vinschen wrote:
>> >>>What I'm observing is that even big apps like vim, emacs, octave don't
>> >>>use addresses beyond 0x03000000. Setting the heap to an address of
>> >>>0x20000000 appears to be a rather big waste of memory.
>> >>>So I'm planning to drop the bar to 0x08000000, which gives the heap
>> >>>a potential extra memory of 384 Megs. and still leaves a confortable
>> >>>cushion of 80 Megs for the OS.
>> >>On my machine, running 'emacs-X11 -nw', quite a bit of stuff appears
>> >>at 0x01????? (showing only allocation bases below for brevity):
>> >>Another bunch appears in the 0x19??????-0x1C?????? range (again,
>> >>allocation bases only):
>> >>>19A80000-19C7B000 ---p 00000000 0000:0000 0
>> >That's kind of annoying. I wouldn't have believed that the OS DLLs
>> >would take so much memory. I'll stick to 0x20000000 for now.
>I'm still puzzled. I used W7 32 bit and 2008 R2 64 bit for testing, and
>even using really big apps like emacs-x11, xemacs, or the X server, I
>can't reproduce that the OS uses memory beyond 0x04000000, on both
>systems. Are you sure that rebasing wouldn't fix this?
>Along these lines there's another problem.
>Apart from the fact that some of our Cygwin distro DLLs are still not
>auto-based (the DLLs from libopenldap2_3_0-2.3.43-1, for instance),
>what's really annoying is that Cygwin distro DLLs which have to be
>rebased on the fly due to collisions with other Cygwin DLLs are rebased
>to memory below 0x04000000, too. Rebasing helps a lot, but there's
>probably no way to avoid this entirely. That's really bad.
>Yes, we can't use a native fork mechanism, so we have to find another
>way. Three ideas come to mind:
>1 A more intelligent algorithm in rebase/rebaseall to place the various
> Cygwin distro DLLs so that they don't collide, perhaps together with a
> postinstall script which rebases automatically. This is a short-term
> way to deal with the problem.
>2 Figure out if and how we can hook the Windows loader so that rebasing
> a DLL on the fly at load time can be influenced in terms of the start
>3 Stop linking against Cygwin DLLs other than the Cygwin DLL itself.
> Instead, provide our own loader.
I think 1. and 2. are the only feasible ways to deal with the problem.
For 3, maybe we could port ld.so.
I've already asked for a more intelligent rebase/rebaseall in the cygwin
list but there wasn't much of a response. It's a short-term solution
but I think it would eliminate a lot of problems.
More information about the Cygwin-developers