 |
lua-l archive |
|
|
||
|
On Sep 6, 2013 2:08 AM, "Tim Hill" <drtimhill@gmail.com> wrote:
>
>
> On Sep 5, 2013, at 10:25 PM, Andres Perera <andres.p@zoho.com> wrote:
>
>> Sigh.
>>
>> Whether or not malloc() organizes objects into buckets sized n^2, malloc() can only acquire multiples of pagesize of virtual memory at a time. One page can hold multiple objects.
>>
>> In function ``f'',
>>
>> int f()
>> {
>> /*pa*/
>> z = malloc(x);
>> /*pb*/
>> }
>>
>> i
>> L
>> L
>> f at pa the process has allocated n bytes, and malloc(x) is successful, then at pb the process vm will be (n + x + PAGESIZE-1) & ~(PAGESIZE-1), in other words, rounded to the nearest greater pagesize multiple. Please show a system where this is false.
>>
>>
>
> Um, what?
> First, you are assuming a simple case where there are no free() calls in pa.
No. pa is immediately before malloc. If there are free() calls, ``n'' is synced.
> Second you are assuming that the heap manager has not over-allocated or pre-allocated pages (most do). Third you are assuming the heap manager makes no attempt at padding or leaving expansion space, or choosing different allocation strategies for differently sized blocks, or does anything beyond a simplistic linear allocation.
In a previous message during this exchange, I recall explaining how one must substract malloc overhead from the pagesize. Padding, preallocation--anything that increases vm usage from sizeof(Lua_State)--is malloc overhead by definition. That's a disclaimer best repeated, then.
> Almost no real-world system exhibits the linear allocation model your example assumes, and so I would assert that it is false in EVERY system I have ever used; most will have allocated significantly more pages than your model assumes.
Wait, so you disagree on the *number* of pages allocated? Or is it another alignment?
>
> And even if it were true, so what? We were discussing the overhead of adding a void* to either Lua_State or Lua globals, a trivial addition to either structure. Nothing in that discussion is even vaguely impacted by the relationship between the C runtime heap manager and the OS VM allocation mechanisms.
And the reason there's no impact is that even after growing Lua_State by sizeof(void *), the structure is well below the margin of a certain multiplier.
>
> --Tim
>