Summary:
recursive writes are not inherently bad, so long as the pointer is
consistently re-set (handled automatically by macros), and they are nearly
unavoidable in some places such as eo/evas internals
issues may arise in a specific corner case of recursive writes when a pointer
has been hashed for garbage collection, so adjust the checks to watch for this
specific case instead of crashing on every case
fix T7005
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7005
Differential Revision: https://phab.enlightenment.org/D6284
Summary:
ecore_evas: remove debug
eina: unregister log level when done with
Fixes a constant memory leak.
eina: introduce EINA_HOT and EINA_COLD
These attributes respectivelly expand to __attribute__ ((hot)) and
__attribute__ ((cold)) when available. They allow to mark functions are
being hot/cold (frequently used or not) as well as to qualify labels
within a function (likely/unlikely branches).
eo: speed-up generated calls by removing call cache
The call cache needed to by thread-local, to avoid concurrency issues.
Problem with TLS is that is adds an extra overhead, which appears to be
greater than the optimization the cache provides.
Op is naturally atomic, because it is an unsigned integer. As such, it
cannot be tempered with while another thread is reading it. When
entering the generated function, the first operation done is reading
'op'. If we have concurrency, we will have access sequences returning
either EFL_NOOP or a VALID op, because 'op' is not set until the very
end of the function, when everything has been computed. As such, we now
use the 'op' atomic integer to instore a lock-free/wait-free mechanism,
which allows to drop the TLS nature of the cache, speeding up the access
to the cache, and therefore making functions execute faster.
We don't test anymore the generation count. This can be put as a
limitation. If means that if you call efl_object_shutdown() and
re-initialize it later with different data, opcodes will be invalid.
I am not sure there is any usecase for this to ever happen.
We could move all the caches in a dedicated section, that can be
overwritten after a call to efl_object_shutdown(), but I am not sure it
will be very portable.
Benchmark: mean over 3 executions of
ELM_TEST_AUTOBOUNCE=100 time elementary_test -to genlist
```
BEFORE AFTER
------------------------------------------------------------
time (ns) 11114111647.0 9147676220.0
frames 2872.3333333333335 2904.6666666666665
time per frame (ns) 3869364.6666666665 3149535.3333333335
user time (s) 11.096666666666666 9.22
cpu (%) 22.666666666666668 18.333333333333332
```
Ref T6580
Reviewers: raster, cedric
Subscribers: cedric, jpeg
Maniphest Tasks: T6580
Differential Revision: https://phab.enlightenment.org/D5738
This is not perfect, it will just limit the propagation of the problem
for some time. Yes, it does hide it under the carpet, but that's better
than having a crash. Problem seems to be in Eina_Hash, but is really
difficult to reproduce and fix for the moment.
* Use an Eina_Hash for the garbage collector list.
* Turn off garbage collection on object that are unlikely to match.
This patch make 1.8 as fast as 1.7 again.
* Use Eina_Hash instead of Eina_List to remember what memory did change.
* Turn off Eina_Cow use of Eina_Magic when doing a release as it is only
used internaly and we should not make any mistake there.
- Add valgrind macro arround Eina_Cow internal data.
- Add a #define for Eina_Magic on Eina_Cow returned pointer.
- Fix a bug done during free on a mempool data (Need to improve
mempool to catch this one more easily next time).
SVN revision: 83191
Mike Blumenkrantz
Jean Guyomarc'h
Cedric Bail
Carsten Haitzler
Boris Faure
Cedric BAIL
Cedric Bail
Sebastian Dransfeld
Galatsanos 'godfath3r' Panagiotis
Tom Hacohen
Stefan Schmidt