Date: Wed, 13 Mar 2002 23:23:39 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Greenman <dg@root.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, John Indra <maverick@office.naver.co.id>, freebsd-current@FreeBSD.ORG Subject: Re: malloc() and the stock Perl in -CURRENT (and -STABLE) Message-ID: <3C904FFB.690D15C@mindspring.com> References: <20020314104525.B8244@office.naver.co.id> <40628.1016085846@critter.freebsd.dk> <20020313222518.J27616@nexus.root.com> <3C904853.B89968B4@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > The remmap is a better idea. It > might be wedged into the exiting mmap for a malloc of the > same object with a larger size (e.g. remapping MAP_ANON > memory with a larger size and a non-zero address implies a > zero address, same pages, larger allocation, since mapping > over an existing mapping makes no sense). Actually, there are a lot of options for this. The first thing that mmap does is convert the len from a size_t into an ssize_t -- from unsigned to signed -- and then checks the sign bit, and disallows the request entirely. If it fit the profile, it could have the sign inverted, and the remmap semantics, instead. Similarly, there is a check for an fd != -1 in the MAP_ANON case, that disallows it if it's not -1. Any non -1 value could be interpreted as special. In addition, you could jam the remap semantics into the flags (e.g. adding a "MAP_REMAP"), or into the prot flag, if the flags bits were too "precious" (there're plenty available, actually). Validating that the existing mapping is present and anonymous would be a case of looking it up. Actually, vm_mmap uses NULL and 0 compares on a pointer value interchangalby... style violation, that. Probably, you would need to put the old size into the "fd" field, if you wanted to be sure that it didn't accidently do the wrong thing... it seems that differentiating one ANON mapping region form one contuguous and following it is rather difficult... depending on the implementaiton of phkmalloc, you might have to constrain the caller to even pages, if you want it to be able to work without perhaps taking a combined split region on a realloc of an alloc'ed area, and breaking it. You could get this information from the (noncontiguous) metadata area, but it would not be general, and would still need to be pushed into the kernel somehow. Given that the length is limited effectively to a signed int, even though the man page lists it as a size_t (unsigned int), passing the old size in the fd doesn't seem that abominable... In the worst case of many consecutive reallocations, you would probably want to check the region for the new mapping to see if it was clear, and do a map add, rather than a remap (technically), you would end uprotoring through three adjacent mapping sets, otherwise (looking for the hole in the map). For a very big allocation, this means that for an N->N+1 allocation delta, N could never exceed 1/3 of the user process address space after the process itself not including the realloc in question, was subtracted out.. plus one page. But that's really a micro-optimization that won't be hit (until the first time someone starts testing the speedup claims... 8-)). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C904FFB.690D15C>