On 07 May 2006 21:36, Daniel Jacobowitz wrote:
> On Sun, May 07, 2006 at 10:26:20PM +0200, Laurynas Biveinis wrote:
>> - Cygwin's mmap() is still buggy. There was a lot of work on it
>> previously, the last message I could find on the subject was
>> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00521.html . It
>> suggested, that Cygwin's mmap() maybe could be un-blacklisted now.
>> Well, it cannot. Zone collector unearths the problem that
>> munmap(address, some_amount) actually unmaps 64KB when some_amount is
>> e.g. 20KB. I've tested both MMAP_ANON and /dev/zero. If anybody is
>> interested, I can provide the testcases. If nobody is, then maybe
>> someday I'll find time to make testcases directly against Cygwin libc.
>>
>> For GCC it means that any mmap'y collector, if it's to become a single
>> GCC collector, will need additional work here. It is possible to
>> implement a workaround (free only 64KB worth of adjacent free pages)
>> at cost of some memory expense, or use valloc(), or the malloc() code
>> from ggc-page. Of course, only the first option is viable for copying
>> collector. I wonder if cygwin's mprotect() has a set of similar
>> issues.
>
> Or just use 64K pages on Cygwin. It sounds like that's what's going
> on. We may be fetching the page size incorrectly from the system.
> In fact, see how bogus the code currently in ggc-zone.c is for the page
> size?
>
> I suspect Cygwin is blameless here.
It's reflecting the behaviour of the underlying Windows O/S: memory mapping
allocation has a granularity of 64kB and there's no way round it. I could
take a look at the page-size detection code and see if I can see any obvious
bugs or workarounds if you liked.
> The runtime page size detection would probably work better (but it's
slower).
I haven't read the code so I don't know what's involved here, but surely
that would only need to be done once per compilation at init time?
cheers,
DaveK
--
Can't think of a witty .sigline today....
