 |
lua-l archive |
|
|
||
|
On Sep 5, 2013 5:51 PM, "Tim Hill" <drtimhill@gmail.com> wrote:
>
>
> On Sep 5, 2013, at 1:39 PM, Andres Perera <andres.p@zoho.com> wrote:
>
>> >
>> > Hmmm … i'd say the cost of ONE void* pointer in a Lua_State was pretty insubstantial, even if you spin up a LOT of them. it may even be free, since most heap managers round up allocated sizes to some power of 2 multiple, so the actual size of the allocated Lua_State may not change.
>>
>> 1. The minimal heap allocation is a multiple of page size in modern systems, not an arbitrary power of two.
>
> No way! .. If I allocate 18 bytes using malloc() it does NOT involve allocating an entire 4K (or whatever) page.
Sorry, but you're making assumptions on how malloc(), object sizes and minimal allocations relate. Take the pagesize and substract malloc overhead. That's the relevant number in i386's VM model. I'd want to know about contemporary systems that allow greater granularity.
You're probably confused with arena or bucket sizes, which are irrelevant intermediaries when determining the real cost of growing Lua_State. Not all allocators use size arbitrated buckets. For example, an allocator for short running routines whose access to the regular system allocator is difficult, like the dynamic linker's, have no need for size organization.
>> 2. The only relevant size constraint isn't heap bound. If you are eg. copying states, the possibly unused user pointer is going to touch a register.
>
> Well good luck copying a Lua_State (can you spell crash?), and why would placing an extra field in a structure touch an extra register?
>
> --Tim
>