Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Vir Campestris Newsgroups: comp.lang.c Subject: Re: realloc() - frequency, conditions, or experiences about relocation? Date: Thu, 20 Jun 2024 21:08:00 +0100 Organization: A noiseless patient Spider Lines: 29 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 20 Jun 2024 22:08:00 +0200 (CEST) Injection-Info: dont-email.me; posting-host="9122310e68364567a00773b3a65b23ce"; logging-data="2872904"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+PrEi4oroMgJ/VLfgx4Gd2BZs9WWjcvj4=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:KbtTignfMsWpZhaL6PE+xFScNHM= In-Reply-To: Content-Language: en-GB Bytes: 2319 On 17/06/2024 10:22, Bonita Montero wrote: > > realloc() is just a convenience funciton. Usually the reallocation > can't happen in-place and a second malloc() followed by a copy and > a free() does the same. > For large data it would be nice if the pages being deallocated later > would be incrementally marked as discardable after copying a portion. > This would result in only a small portion of additional physical > memory being allocated since the newly allocated pages become asso- > ciated with phyiscal pages when they're touched first. Windows has > VirtualAlloc() with MEM_RESET for that, Linux has madvise() with > MADV_DONTNEED. "Usually can't happen in place"? Really? It's not something I use a lot, but when it's appropriate I will. It's got the advantage over doing this myself that for some portion of calls all the run time library needs to do is change the size field in the structure. Nothing else. No copying, and no duplicate allocations. What proportion of calls can be managed by changing the size field alone depends on your workload and the platform. But I doubt there are many cases where it is 0%. Andy