Re: [E-devel] eina freeq?

[The Rasterman]

On Thu, 10 Nov 2016 15:14:11 + Mike Blumenkrantz
 said:

> I see that this has been pushed and is already being used despite some
> objections being raised? I guess I probably missed IRC discussions.

did you read the responses to the objections? in fact just one objection. it
was "dont like" and under valgrind frees are now asynchronous - read the code.
it was misunderstanding that this is a replacement of valgrind where it is not.
it's a stability measure for average users when valgrind is not in use by
delaying pointer re-use. it also can defer any work involved in freeing to
'when idle'. and if under valgrind the frees are done synchronously without
being queued so it catches everything as it does right now leaving it to
valgrind. so the issue was addressed if you read the code.

> The reasoning for needing this sounds like we should probably just use
> jemalloc (
> https://www.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919/
> ), which does more, has more people actively devoted to improving/developing
> it, and has been widely tested and benchmarked so we know it will
> definitely have the effect that we want while also reducing our
> maintenance+development overhead.

which actually is entirely orthogonal. and i've proposed a more extensive way
of having an allocator with multiple allocation domains - it could be jemalloc
WITH modifications. did you read the mail?

Subject: [E-devel] memory allocation perf

but freeq works WITHOUT pulling in jemalloc. it enforces a purgatory for
pointers put in the freeq irrespective of malloc implementation. it's simple
and easy to work with. it actually does hat people THOUGHT eina_trash should do
but doesn't. freeq enables us to debug core dumps when people dont use valgrind
- which they don't. valgrind does not even work on openbsd, so proposing it as
a solution to help debug there is pointless. and people doing Qa dont use
valgrind. they dont even know how to AND it makes things so slow that they
never would even if it was just a checkbox. yes there is MALLOC_PERTURB_ but it
as no upper limit (free 1mb of data and 1mb is filled with pattern data), so it
has a pretty hefty impact. it's also glibc only.

malloc replacement is a far deeper topic. JUST blindly using jemalloc can't be
done as it'd replace all *alloc/free funcs, so the method to do that is an
LD_PRELOAD. to use it without a preload means wrapping it in some calls and
then replacing one thing at a time with this "eina_alloc" api (memory blob by
blob). i do not want to do that with JUST a plain void * replacement. it's not
as much of a win as it could be. if we have to go replace things pointer by
pointer, let's do better. with a custom alloc impl we can:

1. have allocation domains that separate memory out like:

domain1 = eina_alloc_domain_new();
ptr = eina_alloc(domain1, size);
eina_alloc_free(domain1, ptr);

whereas having a NULL domain be like malloc/free as an implicit global:

ptr = eina_alloc(NULL, size);

this allows the back-end to be a single pool or BETTER multiple
address-separated pools meaning we can ensure the pointers for one kind of data
don't rub shoulders with another which means use-after-free within code segment
A is LESS likely to corrupt data from code segment B if the memory they use
come from different domains.

2. do small pointers. 32bit ptrs on 64bit machines halving our memory footprint
for pointers (and we use a LOT of pointers). this may actually even sped things
up as we pollute our caches less. a single 32bit domain for almost all of efl's
allocations "should be enough for everything" as if we 16 byte align we
actually have access to up to 64gb of allocated memory, and 32gb if we 8 byte
align which would be necessary anyway (probably a good call given simd
implementations can do 128bit types these days, and maybe 32byte align on
systems with 256 bit type support). i am not proposing we use 32bit ptrs for
allocating audio data or video or images - the large blobs. just "data
structures". we can then ALSO do 16bit pointers too (each domain could allocate
up to 1m of data with 16byte alignment, 512k with 8). so if we use domains
carefully we can drop pointer sizes down even more for certain special cases
(assuming the whole workload of memory use for that domain would always remain
small enough to fit inside the domain max pool of eg 512k or 1m). yes. now
access to these small ptrs requires resolving them like:

   realptr = domain->base + (ptr << 4);

likely a macro or static inline would do this. yes. it requires KNOWING the
domain the ptr comes from. we COULD have the NULL domain be a special "global
domain" like malloc/free do and so domain is a known global var
(eina_alloc_domain, eina_alloc_domain_32, eina_alloc_domain_16 - with plain
domain and 32 domain maybe being #defined to be the same thing on a 32bit
machine).

either way this requires more than just 

Re: [E-devel] eina freeq?

[Mike Blumenkrantz]

I see that this has been pushed and is already being used despite some
objections being raised? I guess I probably missed IRC discussions.

The reasoning for needing this sounds like we should probably just use
jemalloc (
https://www.facebook.com/notes/facebook-engineering/scalable-memory-allocation-using-jemalloc/480222803919/),
which does more, has more people actively devoted to improving/developing
it, and has been widely tested and benchmarked so we know it will
definitely have the effect that we want while also reducing our
maintenance+development overhead.

On Fri, Nov 4, 2016 at 10:08 AM Carsten Haitzler 
wrote:

> On Fri, 4 Nov 2016 10:18:33 -0200 Gustavo Sverzut Barbieri <
> barbi...@gmail.com>
> said:
>
> > On Thu, Nov 3, 2016 at 9:27 PM, Carsten Haitzler 
> wrote:
> > > On Thu, 3 Nov 2016 11:24:14 -0200 Gustavo Sverzut Barbieri
> > >  said:
> > >
> > >> I guessed mempool and eina_trash did that
> > >
> > > nah - mempool i don't think has a "purgatory" for pointers.
> > > they are released back into the pool.
> >
> > well, it could... OTOH it's just for "empty blocks", since if it's in
> > a mempool that has memory blocks and they're still in use, it will
> > just flag as unused.
> >
> > also, it simplifies bookkeeping of the memory if they are all of the
> > same size, like you said Eina_List, it knows the size of each entry,
> > thus just need to mark each position that is usable, not try to
> > allocate based on size or similar -- much more efficient.
>
> yah. that's what mempool does... but it doesnt have 2 states for an
> allocation.
> it doesnt have "in use" "freed but not able to be reused yet" and "free and
> able to be re-used". it just has 1. in use or not.
>
> > > trash is actually a cache for storing ptrs but it never
> > > actually frees anything. it doesn't know how to. you have to manually
> clean
> > > trash yourself and call some kind of free func when you do the clean.
> trash
> > > doesn't store free funcs at all.
> >
> > I don't see why it couldn't.
>
> but it doesn't, and eina_trash is all static inlines with structs exposed
> so
> we'd break struct definition, memory layout and api to do this. if an
> eina_trash is exposed from a lib compiled against efl 1.18 against other
> code
> compiled against 1.19 - it'd break. even worse eina_trash is a single
> linked
> list so walking through it is scattered through memory thus basically
> likely a
> cache miss each time.
>
> > but I find this is trying to replace malloc's internal structures,
> > which is not so nice. As you know, malloc implementation can
> > postpone/defer actual flushes, it's not 1:1 with brk() and munmap()
> > since like our mempools the page or stack may have used bits that
> > prevents that to be given back to the kernel.
>
> i know. but it's out of our control. we can't change what and how malloc
> does
> this. we can't do smarter overwrite detection. malloc has options for
> filling
> freed memory with a pattern - but it will do it to any sized allocation. 1
> byte
> or 1 gigabyte. with a custom implementation WE can decide eg only fill in
> up to
> 256 bytes as this is what might be sued for small objects/list nodes but
> leave
> big allocations untouched or .. only fill in the FIRST N bytes of an
> allocation with a pattern. if the pattern has been overwritten between
> submission to a free queue AND when it is actually freed then we have a
> bug in
> code somewhere scribbling over freed memory. at least we know it and know
> what
> to be looking for. malloc is far more limited in this way.
>
> also we can defer freeing until when WE want. e.g. after having gone idle
> and
> we would otherwise sleep. malloc really doesnt have any way to do this
> nicely.
> it's totally non-portable, libc specific (eg glibc) etc. and even then very
> "uncontrollable". a free queue of our own is portable AND controllable.
>
> > what usually adds overhead are mutexes and the algorithms trying to
> > find an empty block... if we say freeq/trash are TLS/single-thread,
> > then we could avoid the mutex (but see malloc(3) docs on how they try
> > to minimize that contention), but adding a list of entries to look for
> > a free spot is likely worse than malloc's own tuned algorithm.
>
> no no. i'm not talking about making a CACHE of memory blocks. simply a
> fifo.
> put a ptr on the queue with a free func. it sits there for some time and
> then
> something walks this from beginning to end actually freeing. e.g. once we
> have
> reached and idle sleep state. THEN the frees really happen. once on the
> free
> queue there is no way off. you are freed. or to be freed. only a question
> of
> when.
>
> if there is buggy code that does something like:
>
> x = malloc(10);
> x[2] = 10;
> free(x);
> y = malloc(10);
> y[2] = 10;
> x[2] = 5;
>
> ... there is a very good chance y is a recycled pointer - same mem
> location as
> x. when we do x[2] = 5 we overwrite y[2] with 5 

Re: [E-devel] eina freeq?

[The Rasterman]

On Fri, 4 Nov 2016 10:18:33 -0200 Gustavo Sverzut Barbieri 
said:

> On Thu, Nov 3, 2016 at 9:27 PM, Carsten Haitzler  wrote:
> > On Thu, 3 Nov 2016 11:24:14 -0200 Gustavo Sverzut Barbieri
> >  said:
> >
> >> I guessed mempool and eina_trash did that
> >
> > nah - mempool i don't think has a "purgatory" for pointers.
> > they are released back into the pool.
> 
> well, it could... OTOH it's just for "empty blocks", since if it's in
> a mempool that has memory blocks and they're still in use, it will
> just flag as unused.
> 
> also, it simplifies bookkeeping of the memory if they are all of the
> same size, like you said Eina_List, it knows the size of each entry,
> thus just need to mark each position that is usable, not try to
> allocate based on size or similar -- much more efficient.

yah. that's what mempool does... but it doesnt have 2 states for an allocation.
it doesnt have "in use" "freed but not able to be reused yet" and "free and
able to be re-used". it just has 1. in use or not.

> > trash is actually a cache for storing ptrs but it never
> > actually frees anything. it doesn't know how to. you have to manually clean
> > trash yourself and call some kind of free func when you do the clean. trash
> > doesn't store free funcs at all.
> 
> I don't see why it couldn't.

but it doesn't, and eina_trash is all static inlines with structs exposed so
we'd break struct definition, memory layout and api to do this. if an
eina_trash is exposed from a lib compiled against efl 1.18 against other code
compiled against 1.19 - it'd break. even worse eina_trash is a single linked
list so walking through it is scattered through memory thus basically likely a
cache miss each time.

> but I find this is trying to replace malloc's internal structures,
> which is not so nice. As you know, malloc implementation can
> postpone/defer actual flushes, it's not 1:1 with brk() and munmap()
> since like our mempools the page or stack may have used bits that
> prevents that to be given back to the kernel.

i know. but it's out of our control. we can't change what and how malloc does
this. we can't do smarter overwrite detection. malloc has options for filling
freed memory with a pattern - but it will do it to any sized allocation. 1 byte
or 1 gigabyte. with a custom implementation WE can decide eg only fill in up to
256 bytes as this is what might be sued for small objects/list nodes but leave
big allocations untouched or .. only fill in the FIRST N bytes of an
allocation with a pattern. if the pattern has been overwritten between
submission to a free queue AND when it is actually freed then we have a bug in
code somewhere scribbling over freed memory. at least we know it and know what
to be looking for. malloc is far more limited in this way.

also we can defer freeing until when WE want. e.g. after having gone idle and
we would otherwise sleep. malloc really doesnt have any way to do this nicely.
it's totally non-portable, libc specific (eg glibc) etc. and even then very
"uncontrollable". a free queue of our own is portable AND controllable.

> what usually adds overhead are mutexes and the algorithms trying to
> find an empty block... if we say freeq/trash are TLS/single-thread,
> then we could avoid the mutex (but see malloc(3) docs on how they try
> to minimize that contention), but adding a list of entries to look for
> a free spot is likely worse than malloc's own tuned algorithm.

no no. i'm not talking about making a CACHE of memory blocks. simply a fifo.
put a ptr on the queue with a free func. it sits there for some time and then
something walks this from beginning to end actually freeing. e.g. once we have
reached and idle sleep state. THEN the frees really happen. once on the free
queue there is no way off. you are freed. or to be freed. only a question of
when.

if there is buggy code that does something like:

x = malloc(10);
x[2] = 10;
free(x);
y = malloc(10);
y[2] = 10;
x[2] = 5;

... there is a very good chance y is a recycled pointer - same mem location as
x. when we do x[2] = 5 we overwrite y[2] with 5 even tho it now should be 10.
yes. valgrind can catch these... but you HAVE to catch them while running.
maybe it only happens in certain logic paths. yes. coverity sometimes can find
these too through static analysis. but not always. and then there are the cases
where this behaviour is split across 2 different projects. one is efl, the
other is some 3rd party app/binary that does something bad. the "y" malloc is
in efl. the c one is in an app. the app now scribbles over memory owned by efl.
this is bad. so efl now crashes with corrupt data structures and we can never
fix this at all as the app is a 3rd party project simply complaining that a
crash is happening in efl.

we can REDUCE these issues by ensuring the x pointer is not recycled so
aggressively by having a free queue. have a few hundred or a few thousand
pointers sit on that queue for a 

Re: [E-devel] eina freeq?

[Gustavo Sverzut Barbieri]

On Thu, Nov 3, 2016 at 9:27 PM, Carsten Haitzler  wrote:
> On Thu, 3 Nov 2016 11:24:14 -0200 Gustavo Sverzut Barbieri 
> 
> said:
>
>> I guessed mempool and eina_trash did that
>
> nah - mempool i don't think has a "purgatory" for pointers.
> they are released back into the pool.

well, it could... OTOH it's just for "empty blocks", since if it's in
a mempool that has memory blocks and they're still in use, it will
just flag as unused.

also, it simplifies bookkeeping of the memory if they are all of the
same size, like you said Eina_List, it knows the size of each entry,
thus just need to mark each position that is usable, not try to
allocate based on size or similar -- much more efficient.


> trash is actually a cache for storing ptrs but it never
> actually frees anything. it doesn't know how to. you have to manually clean
> trash yourself and call some kind of free func when you do the clean. trash
> doesn't store free funcs at all.

I don't see why it couldn't.

but I find this is trying to replace malloc's internal structures,
which is not so nice. As you know, malloc implementation can
postpone/defer actual flushes, it's not 1:1 with brk() and munmap()
since like our mempools the page or stack may have used bits that
prevents that to be given back to the kernel.

what usually adds overhead are mutexes and the algorithms trying to
find an empty block... if we say freeq/trash are TLS/single-thread,
then we could avoid the mutex (but see malloc(3) docs on how they try
to minimize that contention), but adding a list of entries to look for
a free spot is likely worse than malloc's own tuned algorithm.


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina freeq?

[The Rasterman]

On Thu, 3 Nov 2016 11:24:14 -0200 Gustavo Sverzut Barbieri 
said:

> I guessed mempool and eina_trash did that 

nah - mempool i don't think has a "purgatory" for pointers. they are released
back into the pool. trash is actually a cache for storing ptrs but it never
actually frees anything. it doesn't know how to. you have to manually clean
trash yourself and call some kind of free func when you do the clean. trash
doesn't store free funcs at all.

> --
> Gustavo Sverzut Barbieri
> 
> > Em 3 de nov de 2016, às 05:53, Carsten Haitzler (The Rasterman)
> >  escreveu:
> > 
> > On Thu, 03 Nov 2016 09:35:21 +0200 Daniel Zaoui 
> > said:
> > 
> >> Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous?
> > 
> > this isn't async. it's just deferred. we already do this for evas objects
> > with delete_me. we do it for timers/animators and mark them for deletion
> > later. it's nothing new. this is just more generic/extensive
> > 
> >>> From my point of view, seems to be like a hack cause some problems (e.g
> >>> Eo) are hard to solve.
> >> 
> >> My comments below.
> >> 
> >> On Thu, 03 Nov 2016 16:11:24 +0900
> >> Carsten Haitzler  (The Rasterman) wrote:
> >> 
> >>> here's an idea. it's very very very very simple
> >>> 
> >>> create an eina_freeq(). instead of calling free() or whatever free
> >>> function on something immediately, call:
> >>> 
> >>>fq = eina_freeq_main_get();
> >>>eina_freeq_ptr_add(fq, pointer, size, free);
> >>> 
> >>> or
> >>> 
> >>>fq = eina_freeq_global_get();
> >>>eina_freeq_ptr_add(fq, l, sizeof(Eina_List),
> >>> _eina_list_mempool_list_free);
> >>> 
> >>> etc.
> >>> 
> >>> and the free queue will "add this to the end" to be freed some time
> >>> later. the idea of size is so it could make intelligent choice like
> >>> to free very large chunks earlier than smaller allocations. the
> >>> mainloop would drive this actual freeing. or more specifically your
> >>> LOCAL loop would. need to add some kind of loop method that returns
> >>> the "free queue" FOR your loop/thread. or wherever you want it
> >>> actually freed. probably have a main free queue driven by the
> >>> mainloop (and cleared up on eina_shutdown) etc.
> >>> 
> >>> why?
> >>> 
> >>> 1. move overhead of doing actual frees out of critical code into idle
> >>> time
> >>> 2. improve stability by keeping memory eg for eo objects or eina
> >>> list nodes in a "free queue purgatory" for a while so if someone does
> >>> bad things like "use after free" the IMPACT is far smaller as they
> >>> mess with memory in the free queue not being used.
> >> 
> >> Stability has to be improved with refs and other design technics, not with
> >> delay. More, we can't use anymore Valgrind. And this will be PITA to debug.
> >> The same kind of debug with async events where the frame before is
> >> ecore_loop...
> > 
> > we can use valgrind. just have freeq free immediately. env vars can switch
> > behavior around. :) so valgrind - can work trivially.
> > 
> >> btw, the third point didn't leave your head ;-)
> > 
> > oh yeah.. it got lost on the way to the kbd. :)
> > 
> >>> 4. be able to fill memory about to be freed with patterns (eg 0x55 or
> >>> 0xaa) so after free the memory is guaranteed to have a pattern to
> >>> know it was freed (optional debug only for mem regions of size > 0
> >>> and maybe less than some max size).
> >> 
> >> meow (I think this is what you say when you don't know if it is a good
> >> feature or not :-).
> >> 
> >>> 5. optional - checksum the memory when added to free queue then check
> >>> checksum on actual free to warn of some code "being bad" and
> >>> scribbling over freed memory. at least we get warnings of lurking
> >>> bugs if we turn this on...
> >> 
> >> Valgrind does it better.
> > 
> > the problem is we have people who will NOT RUN STUFF UNDER VALGRIND.
> > 
> > 1. for example valgrind doesnt work on openbsd. at all.
> > 2. good luck with valgrind on something like an rpi ... go and make lunch
> > while you wait for your app to start. make coffee in between clicks.the bug
> > you were looking for likely disappeared because timing changed so
> > drastically you cant catch it. i've seen this happen before.
> > 3. people run/test and they do not want to slow things down to 1/50th of the
> > speed. they CAN'T, so having a pattern means its a very low cost and
> > coredumps can tell us far more information on what is going on. you cant
> > force testers in qa to "run it under valgrind". they dont even know what it
> > is, nor can they even do it. the speed impact along vetoes it. the impact
> > of memset() for smallish things (eg < 1k) is going to be MASSIVELY less.
> > 4. this doesn't replace valgrind. it augments it for when valgrind is just
> > not viable. it at least gives us a CLUE. JP just was telling me of an issue
> > where a Eina_List * ptr in an evas object is 0x1 ... it should never be

Re: [E-devel] eina freeq?

[Gustavo Sverzut Barbieri]

I guessed mempool and eina_trash did that 

--
Gustavo Sverzut Barbieri

> Em 3 de nov de 2016, às 05:53, Carsten Haitzler (The Rasterman) 
>  escreveu:
> 
> On Thu, 03 Nov 2016 09:35:21 +0200 Daniel Zaoui  
> said:
> 
>> Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous?
> 
> this isn't async. it's just deferred. we already do this for evas objects with
> delete_me. we do it for timers/animators and mark them for deletion later. 
> it's
> nothing new. this is just more generic/extensive
> 
>>> From my point of view, seems to be like a hack cause some problems (e.g Eo)
>>> are hard to solve.
>> 
>> My comments below.
>> 
>> On Thu, 03 Nov 2016 16:11:24 +0900
>> Carsten Haitzler  (The Rasterman) wrote:
>> 
>>> here's an idea. it's very very very very simple
>>> 
>>> create an eina_freeq(). instead of calling free() or whatever free
>>> function on something immediately, call:
>>> 
>>>fq = eina_freeq_main_get();
>>>eina_freeq_ptr_add(fq, pointer, size, free);
>>> 
>>> or
>>> 
>>>fq = eina_freeq_global_get();
>>>eina_freeq_ptr_add(fq, l, sizeof(Eina_List),
>>> _eina_list_mempool_list_free);
>>> 
>>> etc.
>>> 
>>> and the free queue will "add this to the end" to be freed some time
>>> later. the idea of size is so it could make intelligent choice like
>>> to free very large chunks earlier than smaller allocations. the
>>> mainloop would drive this actual freeing. or more specifically your
>>> LOCAL loop would. need to add some kind of loop method that returns
>>> the "free queue" FOR your loop/thread. or wherever you want it
>>> actually freed. probably have a main free queue driven by the
>>> mainloop (and cleared up on eina_shutdown) etc.
>>> 
>>> why?
>>> 
>>> 1. move overhead of doing actual frees out of critical code into idle
>>> time
>>> 2. improve stability by keeping memory eg for eo objects or eina
>>> list nodes in a "free queue purgatory" for a while so if someone does
>>> bad things like "use after free" the IMPACT is far smaller as they
>>> mess with memory in the free queue not being used.
>> 
>> Stability has to be improved with refs and other design technics, not with
>> delay. More, we can't use anymore Valgrind. And this will be PITA to debug.
>> The same kind of debug with async events where the frame before is
>> ecore_loop...
> 
> we can use valgrind. just have freeq free immediately. env vars can switch
> behavior around. :) so valgrind - can work trivially.
> 
>> btw, the third point didn't leave your head ;-)
> 
> oh yeah.. it got lost on the way to the kbd. :)
> 
>>> 4. be able to fill memory about to be freed with patterns (eg 0x55 or
>>> 0xaa) so after free the memory is guaranteed to have a pattern to
>>> know it was freed (optional debug only for mem regions of size > 0
>>> and maybe less than some max size).
>> 
>> meow (I think this is what you say when you don't know if it is a good
>> feature or not :-).
>> 
>>> 5. optional - checksum the memory when added to free queue then check
>>> checksum on actual free to warn of some code "being bad" and
>>> scribbling over freed memory. at least we get warnings of lurking
>>> bugs if we turn this on...
>> 
>> Valgrind does it better.
> 
> the problem is we have people who will NOT RUN STUFF UNDER VALGRIND.
> 
> 1. for example valgrind doesnt work on openbsd. at all.
> 2. good luck with valgrind on something like an rpi ... go and make lunch 
> while
> you wait for your app to start. make coffee in between clicks.the bug you were
> looking for likely disappeared because timing changed so drastically you cant
> catch it. i've seen this happen before.
> 3. people run/test and they do not want to slow things down to 1/50th of the
> speed. they CAN'T, so having a pattern means its a very low cost and coredumps
> can tell us far more information on what is going on. you cant force testers 
> in
> qa to "run it under valgrind". they dont even know what it is, nor can they
> even do it. the speed impact along vetoes it. the impact of memset() for
> smallish things (eg < 1k) is going to be MASSIVELY less.
> 4. this doesn't replace valgrind. it augments it for when valgrind is just not
> viable. it at least gives us a CLUE. JP just was telling me of an issue where 
> a
> Eina_List * ptr in an evas object is 0x1 ... it should never be 0x1. it should
> be some valid ptr value or NULL. something scribbled to this memory when it
> should not have. LIKELY something like using a ptr after free and that ptr
> HAPPENED to point to this object memory. we have no clue who did it and
> valgrind can't catch this as its not freed ... YET. but if that memory WAS
> handled by a free queue this would be far less likely to happen as the "write
> to unused memory" would be less likely to affect a live real object. you want
> things to be as robust as possible with minimal if not zero cost when you are
> NOT running under valgrind. in fact i can detect if 

Re: [E-devel] eina freeq?

[The Rasterman]

On Thu, 03 Nov 2016 09:35:21 +0200 Daniel Zaoui  said:

> Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous?

this isn't async. it's just deferred. we already do this for evas objects with
delete_me. we do it for timers/animators and mark them for deletion later. it's
nothing new. this is just more generic/extensive

> >From my point of view, seems to be like a hack cause some problems (e.g Eo)
> >are hard to solve.
> 
> My comments below.
> 
> On Thu, 03 Nov 2016 16:11:24 +0900
> Carsten Haitzler  (The Rasterman) wrote:
> 
> > here's an idea. it's very very very very simple
> > 
> > create an eina_freeq(). instead of calling free() or whatever free
> > function on something immediately, call:
> > 
> > fq = eina_freeq_main_get();
> > eina_freeq_ptr_add(fq, pointer, size, free);
> > 
> > or
> > 
> > fq = eina_freeq_global_get();
> > eina_freeq_ptr_add(fq, l, sizeof(Eina_List),
> > _eina_list_mempool_list_free);
> > 
> > etc.
> > 
> > and the free queue will "add this to the end" to be freed some time
> > later. the idea of size is so it could make intelligent choice like
> > to free very large chunks earlier than smaller allocations. the
> > mainloop would drive this actual freeing. or more specifically your
> > LOCAL loop would. need to add some kind of loop method that returns
> > the "free queue" FOR your loop/thread. or wherever you want it
> > actually freed. probably have a main free queue driven by the
> > mainloop (and cleared up on eina_shutdown) etc.
> > 
> > why?
> > 
> > 1. move overhead of doing actual frees out of critical code into idle
> > time
> > 2. improve stability by keeping memory eg for eo objects or eina
> > list nodes in a "free queue purgatory" for a while so if someone does
> > bad things like "use after free" the IMPACT is far smaller as they
> > mess with memory in the free queue not being used.
> 
> Stability has to be improved with refs and other design technics, not with
> delay. More, we can't use anymore Valgrind. And this will be PITA to debug.
> The same kind of debug with async events where the frame before is
> ecore_loop...

we can use valgrind. just have freeq free immediately. env vars can switch
behavior around. :) so valgrind - can work trivially.

> btw, the third point didn't leave your head ;-)

oh yeah.. it got lost on the way to the kbd. :)

> > 4. be able to fill memory about to be freed with patterns (eg 0x55 or
> > 0xaa) so after free the memory is guaranteed to have a pattern to
> > know it was freed (optional debug only for mem regions of size > 0
> > and maybe less than some max size).
> 
> meow (I think this is what you say when you don't know if it is a good
> feature or not :-).
> 
> > 5. optional - checksum the memory when added to free queue then check
> > checksum on actual free to warn of some code "being bad" and
> > scribbling over freed memory. at least we get warnings of lurking
> > bugs if we turn this on...
> 
> Valgrind does it better.

the problem is we have people who will NOT RUN STUFF UNDER VALGRIND.

1. for example valgrind doesnt work on openbsd. at all.
2. good luck with valgrind on something like an rpi ... go and make lunch while
you wait for your app to start. make coffee in between clicks.the bug you were
looking for likely disappeared because timing changed so drastically you cant
catch it. i've seen this happen before.
3. people run/test and they do not want to slow things down to 1/50th of the
speed. they CAN'T, so having a pattern means its a very low cost and coredumps
can tell us far more information on what is going on. you cant force testers in
qa to "run it under valgrind". they dont even know what it is, nor can they
even do it. the speed impact along vetoes it. the impact of memset() for
smallish things (eg < 1k) is going to be MASSIVELY less.
4. this doesn't replace valgrind. it augments it for when valgrind is just not
viable. it at least gives us a CLUE. JP just was telling me of an issue where a
Eina_List * ptr in an evas object is 0x1 ... it should never be 0x1. it should
be some valid ptr value or NULL. something scribbled to this memory when it
should not have. LIKELY something like using a ptr after free and that ptr
HAPPENED to point to this object memory. we have no clue who did it and
valgrind can't catch this as its not freed ... YET. but if that memory WAS
handled by a free queue this would be far less likely to happen as the "write
to unused memory" would be less likely to affect a live real object. you want
things to be as robust as possible with minimal if not zero cost when you are
NOT running under valgrind. in fact i can detect if running under valgrind and
switch behaviour to insta-free thus changing nothing when running under
valgrind vs today, but buying more debug/tracking info when not.

what if the bug is not something WE can fix? some app using efl uses a ptr
after free? the crashes happen in efl code as 

Re: [E-devel] eina freeq?

[Daniel Zaoui]

Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous?

>From my point of view, seems to be like a hack cause some problems (e.g Eo) 
>are hard to solve.

My comments below.

On Thu, 03 Nov 2016 16:11:24 +0900
Carsten Haitzler  (The Rasterman) wrote:

> here's an idea. it's very very very very simple
> 
> create an eina_freeq(). instead of calling free() or whatever free
> function on something immediately, call:
> 
> fq = eina_freeq_main_get();
> eina_freeq_ptr_add(fq, pointer, size, free);
> 
> or
> 
> fq = eina_freeq_global_get();
> eina_freeq_ptr_add(fq, l, sizeof(Eina_List),
> _eina_list_mempool_list_free);
> 
> etc.
> 
> and the free queue will "add this to the end" to be freed some time
> later. the idea of size is so it could make intelligent choice like
> to free very large chunks earlier than smaller allocations. the
> mainloop would drive this actual freeing. or more specifically your
> LOCAL loop would. need to add some kind of loop method that returns
> the "free queue" FOR your loop/thread. or wherever you want it
> actually freed. probably have a main free queue driven by the
> mainloop (and cleared up on eina_shutdown) etc.
> 
> why?
> 
> 1. move overhead of doing actual frees out of critical code into idle
> time
> 2. improve stability by keeping memory eg for eo objects or eina
> list nodes in a "free queue purgatory" for a while so if someone does
> bad things like "use after free" the IMPACT is far smaller as they
> mess with memory in the free queue not being used.

Stability has to be improved with refs and other design technics, not with 
delay.
More, we can't use anymore Valgrind. And this will be PITA to debug. The same 
kind of debug with async events where the frame before is ecore_loop...

btw, the third point didn't leave your head ;-)

> 4. be able to fill memory about to be freed with patterns (eg 0x55 or
> 0xaa) so after free the memory is guaranteed to have a pattern to
> know it was freed (optional debug only for mem regions of size > 0
> and maybe less than some max size).

meow (I think this is what you say when you don't know if it is a good feature 
or not :-).

> 5. optional - checksum the memory when added to free queue then check
> checksum on actual free to warn of some code "being bad" and
> scribbling over freed memory. at least we get warnings of lurking
> bugs if we turn this on...

Valgrind does it better.

> 
> this doesn't solve everything, but it is an improvement and it's easy
> to slide in and begin using very quickly - eg eo object data, eina
> lists and a few other things. the free queue itself would be a very
> very very low overhead buffer - not a linked list. maybe a mmaped or
> malloced buffer/array (ring buffer) with a start and end point so we
> dont do anything but write the above ptr, free ptr and maybe size to
> the next array slot and move the ring buffer next slot one down.
> 
> adding the freeq code in eina is a cakewalk. i'd spend more time
> writing docs and tests than the code itself. :( adding usage of it
> should be trivial.
> 
> any comments?
> 


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel