Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
This patch is from a series of patches to rename EAPI symbols to
specific library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: jptiz, lucas, vtorri, woohyun
Reviewed By: jptiz, lucas, vtorri
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12203
please note, not the return type, but the function.
When appending __attribute__((const)) to a function, the compiler is
told that its enough to call this function once in a function.
This is quite often happening when we are efl_data_scope_get and
efl_super in a function that is different from a implemented function.
The compiler now starts to remove the calls that aggressivly that we
need to ensure that these calls are not removed, which means, the static
function calls, and the eo init are now checking the return value of
these functions, to ensure that they are called.
Please note that you now have to be carefull when your app calls
eo_shutdown, if it does so, you *must* call it at the end of a function,
or never call class_get after that anymore.
Overall this improves elm test runs 0.1s which is fair i guess, the main
thing that is faster is textrendering, where is also the point where
this is the most beneficial.
Please note, this replaces 42 occurences of double _class_get() ... THAT
is a sign!
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D12057
Summary:
do not take over complete vtables.
This might fix wrong vtable settings when a type is not in the
inheritance of another type, but the function is implemented.
Reviewers: woohyun
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11657
we should prefetch the func pointer here.
Later on we are accessing the func pointer in a streak, after that, we
do not use it anymore.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11593
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
that is usefull esp. on parts.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11462
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
if a object is ownable, then there is one free reference. If not, a
error will be printed.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9332
Add a new function in the Eo API in order to provide more options on object
instantiation for binding creators.
For the Eo lib to be able to construct objects that inherit from bindings in
many languages we should provide a way for bindings to call different kinds of
constructors, in a way that simply overriding the `efl_constructor` method is
not enough.
We need a way to differentiate at construction time if the Eo is being
constructed from C or from the binding, because if it is the
former we need too call the inherited object constructor from C and instantiate
a new object, and if it is the later we need to avoid instantiating a
new object because we are already in the middle of the process of creating
a new one.
`efl_constructor` alone does not provide any way of distinguishing between
those situations, so, being able to pass additional information for
efl_add_start (like a custom constructor pointer) is necessary to make the
right distinction.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9070
Some user code may want to track an object ownership in regard to whether it is
kept by just one owner or shared between many owners.
This is specially true for code provided by bindings to other programming
languages, where different kinds of resource management may take place.
The event `ownership,unique` is triggered whenever the object refcount goes
from two to one, as a signal that it has just one owner from now on.
The event `ownership,shared` is triggered whenever the object refcount goes
from one to two, as a signal that it has multiple owners from now on.
It will not trigger when further increasing the refcount to any value beyond
two.
We also add benchmarks for sharing (i.e. increasing the refcount) and them
unsharing objects, in order to evaluate the performance impact of this patch.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8678
This bring no functional change to Eo and efl_part.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8357
This allow for the safe use of efl_ref/efl_unref around an efl_part
without calling any function on that part.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8358
Summary:
Coverity reports that va_end is never called for p_list when we error
out of this function. This patch adds a missing va_end before we error
out of here.
Fixes Coverity CID1399080
@fix
Depends on D8315
Reviewers: raster, cedric, q66, zmike, bu5hm4n, stefan
Reviewed By: q66
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8316
Getter are usually not modifying there object. This is going to put a strong
limit on what a getter property for MVVM is, as it will prevent any side
effect on getting a property from a View.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7969
Summary:
the DFS tree walk was accidently stopped by a too early return
statement. We should only return if we found a reflection entry, if not,
then we should continue our search
Depends on D7996
Reviewers: cedric, zmike, q66, segfaultxavi
Reviewed By: cedric, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7997
As in the previous commit explained, we want to get rid of class
functions in eo, and make them just c functions right away.
This commit removes the class parameter from the eo_class_function_set
call, and adjusts the tests to not depend on class functions anymore.
Class functions are now not tested anymore, tests that used them as a
way to test *things* are adjusted to test them now with object
functions, tests that just tested the working of class functions are
dropped.
This fixes T7675.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7902
this is important, as basically every single class etc. can be a
EFL_OVERRIDE_CLASS. This makes efl_override work with eo_debug.
Differential Revision: https://phab.enlightenment.org/D7910
this adds support in eo to generate a reflection API. To get the actaul
reflection to the klass, the API efl_class_reflection_table_set needs to
be called, the table in the end can be generated by eolian. Reflection
API is inherited by the extended class. This means, if you have two
reflection tables, first, the most upperst is called, then the next
lower one is called.
For now this API accepts NULL setter or getter, and will ignore them
silently when they are called.
fix T7681
Differential Revision: https://phab.enlightenment.org/D7879
The next commit will bring support for something like reflection. This
commit prepares the whole tree for getting another argument in
efl_class_functions_set.
ref T7681
Differential Revision: https://phab.enlightenment.org/D7882
this enables an app or a platform to add an override for a given class,
then return a different object when that class is created. the benefit is
that a class can be internally customized by the app without needing to
modify upstream versions of that class
@feature
fix T7516
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7702
mro only contains special interfaces, not in general all, in order to
have a working function, while NOT having a bad performance. In order to
achive that we just copy the code that is done on efl_isa for a object.
which is a linear walk of a list
ref D7857
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7860
Memory allocation is checked for the given domain's table data like
other cases for main and shared table data.
Differential Revision: https://phab.enlightenment.org/D7810
Felipe Magno de Almeida
Marcel Hollerbach
Vincent Torri
Yeongjong Lee
Carsten Haitzler
Stefan Schmidt
Cedric Bail
Boris Faure
Vitor Sousa
Christopher Michael
Jaehyun Cho
Mike Blumenkrantz