this improves the cache performance a lot. Caches are only invalidated
once, and not multiple times.
Reviewed-by: Carsten Haitzler (Rasterman) <rasterman.com>
Differential Revision: https://phab.enlightenment.org/D11592
calls to classes are not needed anymore, since class inheritance is not
a thing anymore. After removing is_obj from the function the compile can
optimize the code better, since assignments to fields are not
conditionally anymore.
Reviewed-by: Carsten Haitzler (Rasterman) <rasterman.com>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11591
if there is a error when settings API to the vtable, free the vtable
instead of leaking it.
CID 1422015
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11580
as coverity points out, _obj_is_override is already dereferencing
obj->opt so this was the wrong spot to check this.
CID 1422014
CID 1422013
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11579
otherwise we are allocating a 0 sized memory element, which is
pointless.
ASAN would report a 0 sized allocated but not freed element as a leak.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11577
sometimes there is the chance that we need to allocate memory depending
on the functions that are defined, not on the types that are available.
However, even if this should only happen in error cases and on mixins,
we should ensure that this is all correctly freed flagged.
Due to the correct flagging here, we are not copying the memory later on
in a wrong way.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11576
allocating 0 sized elements here is pointless.
This here was doing that, so ensure that we are only allocating vtable
nodes that have more than 0 function pointers.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11575
otherwise we would not free it in the next run over the vtable. Which
would result in a leak.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11574
the free methods here accidently took the top of the mro into account,
which is the class itself, which NULLed out the wrong classes.
After this, we are finally freeing the mixin vtables.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11573
when handoverwriting function on a object, only existing API can be
overwritten, but not newer ones. Thats why its enough to pass the size
of the klass, and not the size of the globally defined classes.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11571
Revert "eo: redo vtable mro creation"
This reverts commit b05110609b.
Revert "eo: add a generic memory allocation tracking method"
This reverts commit 44071e3102.
Revert "eo: rework vtable allocation scheme"
This reverts commit 3bd16a46f1.
Revert "eo: do not allocate extension if deleting"
This reverts commit 64f7edc7fc.
This seems to breal vector rendering in lottie:
From: Hermet Park <hermetpark@gmail.com>
To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
Subject: Re: [E-devel] [EGIT] [core/efl] master 02/05: eo: rework
vtable allocation scheme
This patch occurs memory corruption, vector crashes :(
Here is a sample if you'd like to see it.
https://phab.enlightenment.org/F3858944
Summary:
up to now we have created the vtable of a class by walking the mro from
the most upper element to the klass itself. To give a broader view, the
mro of a klass X that extends the class Y and implements A,B,C,D
The mro of X is then equal to [A,B,C,D] + the mro of Y. Which means, we
can simply copy over the vtables of Y, and start walking at D, which
will result in the same vtable.
The sideeffect of doing that is, that we do not allocate that much
memory anymore. Reason for this is quite simple:
For every mixin that is part of the mro, we are copying the vtable node,
to insert new API implemented by the mixin. However, the resulting new
vtable is every time the same. Which means, we could actaully copy them.
The same messurements as in the previous commits are taken:
malloc tracking:
new: 452128
old: 556656
Safeup: ~102 KB
pmap:
new: 542884K
old: 542168K
Safeup: ~716 KB
Depends on D11538
Reviewers: zmike, stefan_schmidt, tasn, raster, woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11539
Summary:
this is super usefull when checking memory allocations. Esp. when
checking out new memory allocation schemes.
Depends on D11535
Reviewers: zmike, stefan_schmidt, tasn, raster, woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11538
Summary:
with this commit a new way of allocating vtables arrived.
The old mechnism was to allocate a table big enough to carry *all*
functions at once, in order to not allocate that much memory for
functions that are not implemented on a specific klass, dichchains have
been used, which can be seens as a 2D matrix, where columns are only
allocated if min 1 entry needs to be written, this may have been a good
way to allocate back in the day when all this with eo started, however,
it showed to not pay off.
With this new way, we allocate a array of arrays. the first lvl array is
carrying enough slots, that *all* up to the time defined
interfaces/classes/abstracts/mixins can be implemented. The second lvl
array then has exactly the size of the defined APIs. The second lvl
array is obviously only allocated if needed.
When comparing the two methods, i messured two things, the usage based
on memory allocation for vtable-way-1 and vtable-way-2. Additionally, i
checked the overall memory usage of elementary_test using pmap. The
first messurement is a little bit more exact. The second messurement is
more biased, but captures the whole picture.
Memory allocation tracking:
vtable-way-1 - vtable-way-2 = 74680 Byte
Pmap memory tracking:
vtable-way1 - vtable-way-2 = 217088 Byte
The second messurement shows a bigger impact, likely because this is
also showing off all the sideeffects that we are taking place due to
fewer allocations.
Depends on D11524
Reviewers: zmike, tasn, stefan_schmidt, woohyun, cedric, raster
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11535
Summary:
->ext is getting freed during invalidate. If we unregister during
destruction (which is something that might happen) we should not
allocate the extension again.
Reviewers: woohyun, zmike, eagleeye
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11524
Including Eina.Content
And a typo/bugfix in ecore_evas_x.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11204
the previous commits introduced a abstraction for drag in drop which can
be now used for this here. With this commit all the direct protocol
handling in efl.ui is removed, and only the ecore evas API is used.
Additionally, this lead to a giant refactor of how APIs do work. All
Efl.Ui. interfaces have been removed except Efl.Ui.Selection and
Efl.Ui.Dnd, these two have been restructored.
A small list of what is new:
- In general no function pointers are used anymore. They feel very
uncompftable in bindings and in C. For us its a lot easier to just
listen to a event when a drop enters or leaves, there is no need to
register custom functions for that.
- Asynchronous data transphere is handled via futures, which proved to
be more error safe.
- Formats and actions are handled as mime types / strings.
- 0 is the default seat if you do not know what else to take.
- Content is in general passes as a content container from eina, this
also allows applications to pass custom types
The legacy dnd and cnp API is implemented based on that.
All cnp related things are in elm_cnp.c the dnd parts are in elm_dnd.c
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11190
that is usefull esp. on parts.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11462
When a get and/or set from property is defined to return, explicitly,
a Eina.Success_Flag, the mono generator will check the return value
and generate an exception if the call fails.
Resolves T8383.
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11281
the alignbment logic was wrong. we have to use the worst case. that
means 8 or 16 byte alignment. eina mempool alignment logic is wrong
for this as it assumes an array of typoes of all the same size...
this fixes crashes seen on armv7 with sigbus in new gesture code which
got unlucky.
@fix
this is needed in order to get text stable.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11074
This limit long chain of useless event forwarding when nobody is listening
at the end of the pipe.
Differential Revision: https://phab.enlightenment.org/D10813
This seems to have been gone a long time ago and only references left
that have not been disturbing the build. Time to clean up!
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10793
we are going to add this description anyways, no need to count here
again. I think this is not really making anything really faster, its
more keeping things consistance.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10689
This should slightly improve speed in theory. In practice, I have not seen
a benchmark which would budge by 5%, so I am not sure it improve speed that
much.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10660
Today I started experiencing mysterious hanging of edje_cc
during build. "The French are at it again" I thought, and
after spending a while bisecting, I found the culprit.
It's 7f53d91583.
So, what is happening in here?
The idea here was fundamentally sound; compute a special
hash value for event descriptors, taking range between 0
and 63 (on 64-bit systems) and 0 and 31 (on 32-bit systems),
then use a mask sized 32-bit or 64-bit (depending on your
system) and check early if to bail out from callback_call,
saving some resources. So far so good.
The problem is in the way the mask is handled. We're applying
the hash as the shift value like, `x |= (1 << hash)`. On 32-bit
systems this is okay, but on 64-bit systems, C's dumb silent
coercion rules kick in, since the left side of the expression
is 1, a literal with type signed int; that means our shifting
range is limited to 31 and what we get is... undefined behavior.
This is obviously not what we want, so take a 1ULL value as a
base. The previous thing seemingly worked on x86_64 (nobody
reported any issues) and interestingly it worked for me too
for a while (on ppc64le), but undefined behavior can be
unpredictable, so...
This shouldn't need a commit message as long as this, but I'm
making it proportional to the amount of time I wasted on this.
EINA_FALSE is to be returned only if one of the callback did call
efl_event_callback_stop not if their was no callback called.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10620
Summary:
this cannot be evalulated in compile time, so this must be evalulated in
runtime, at the first call.
This should fix OSX build.
Co-authored-by: Cedric Bail <cedric.bail@free.fr>
Reviewers: zmike, cedric, raster
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10582
This patch introduce a small hash (64 or 32bits) that cache all existing
Efl_Event_Description callback handler registered on an object. It slightly
reduce the time needed to do an unecessary call and cost just a few bytes
per object.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10475
Summary:
this should be handled like the rest of eo internal events
ref T8321
Depends on D10353
Reviewers: bu5hm4n, cedric
Reviewed By: bu5hm4n, cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10354
Marcel Hollerbach
Carsten Haitzler
Xavi Artigas
Felipe Magno de Almeida
Jérémy Zurcher
Wonki Kim
junsu choi
Ali Alzyod
Cedric BAIL
Stefan Schmidt
Daniel Kolesa
Mike Blumenkrantz