We want to introduce a new mechanism concerning the data of the Eo
objects.
The goal is to improve the memory management by defragmenting the memory
banks used by the Eo objects. The first phase has been done by raster
and consists in allocating the objects into a separate memory region
that the one used by malloc. So now, we know where our objects are
located.
Now, moving objects means moving data of objects. The issue we have here
is that a lot of data pointers are stored into data of other objects,
e.g Evas Object data into lists for rendering...
We need a way to reference the data and eo_data_get doesn't provide us
that. So we need to improve the API for data extraction by requesting
from the developer if the data will be stored or not. Five functions are
supplied:
- eo_data_scope_get: no referencing, the data pointer is no more used after
exiting the function.
- eo_data_ref: reference the data of the object. It means that while the
data is referenced, the object cannot be moved.
- eo_data_xref: reference the data of the object but for debug purpose,
we associate the objects that references. Same behavior as eo_data_ref
for non-debug.
- eo_data_unref: unreference the data of an object.
- eo_data_xunref: unreference the data of an object previously
referenced by another object.
I deprecated the eo_data_get function. Most of the time,
eo_data_scope_get needs to be used.
In the next patches, I changed the eo_data_get to the corresponding
functions, according to the usage of the data pointer.
The next step is to find all the places in the code where the data is
stored but not yet referenced. This will be done by:
- requesting from every object to unreference all data to other objects.
- moving all the objects from one region to another
- requesting from every object to rerefenrence the data.
- debugging by hunting the segmentation faults and other weird
creatures.
Summary: This feature replaces Eo pointers with ids to prevent bad usage
or reuse of these pointers. It doesn't change API.
The mechanism uses tables storing the real pointers to the objects.
See the src/lib/eo/eo_ptr_indirection.c file for more details on the
mechanism.
Because of the way eo is dispatching method calls of objects the usual
error log you get if you mix up objects or try to call non-existent
methods is:
ERR<12404>:eo lib/eo/eo.c:362 _eo_dov_internal() Can't find func for op
0x24 (ecore_audio_obj_in:ECORE_AUDIO_OBJ_IN_SUB_ID_SPEED_GET) for class
'ecore_audio_obj_out_pulse'. Aborting.
Of course the problem is not really in lib/eo/eo.c, but in the function
calling eo_do()
Now the macros pass source file and line number on to the _internal
functions so we can log where the error originally happened:
ERR<1938>:eo lib/eo/eo.c:362 _eo_dov_internal() in
lib/ecore_audio/ecore_audio_obj_out_pulse.c:119: Can't find func for op
0x24 (ecore_audio_obj_in:ECORE_AUDIO_OBJ_IN_SUB_ID_SPEED_GET) for class
'ecore_audio_obj_out_pulse'. Aborting.
This makes debugging with eo a lot easier.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
We now need to pass the current class to eo_do_super. This is faster and
more memory efficient and generally lets us do things better.
Using the eo_benchmarks we get ~20% speed-up.
From now, classes implementing the Eo function with id
EO_BASE_SUB_ID_DBG_INFO_GET will be able to show in Clouseau their own
specific information.
Information contents is controlled by the class itself and no more
by Clouseau. Basic types and lists are supported..
Signed-off-by: Aharon Hillel <a.hillel@samsung.com>
SVN revision: 83410
This was stupid from the start, but now it casuse even more issues.
We'll have to just add a configure option to it when the time comes.
SVN revision: 82989
Daniel Zaoui
Tom Hacohen
Daniel Willmann
Cedric Bail
Daniel Juyung Seo
Cedric BAIL
Aharon Hillel
Leandro Dorileo
Sebastian Dransfeld
Vincent Torri