On Tue, Jul 25, 2017 at 1:41 AM, Kirk Brooks via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> I want to make sure my understanding about how c-objects are handled in 4D
> memory. Mainly because it seems this understanding is cobbled together from
> a number of different sources few of which I can easily find again. So...
>
>
Kirk,
Here is how I understand objects. Not sure if it is correct, and while I
use object a bit, I cannot claim I tested all my assertions, so they can be
wrong. Anyway, it may be interesting to compare our views:
> 1) c-objects are created within the 3 4D scopes: IP, process or local.
>
As I understand it, there is one 'heap' of objects, what means all objects
are IP (where by object I mean here data structures containing data).
Object variables are local, process or IP, but they are just references to
this global object heap.
You mention that variables are something like pointers, I prefer to
consider them a references (like 'fifth object from the right') for the
following reason:
Objects are ref-counted. This means that each (global) object keeps count
how many variables (local, process and IP) is referencing this object. When
that count get to 0, object is deleted.
>
> 2) but they share some characteristics with hLists and menuRefs in that
> once created they can be referred to by different instances. For example,
> if I create an process object called "prosObj" as:
>
> { obj1: {name: Kirk, ID: 1234},
>
> obj2: {name: Joe, ID: 5678}}
>
> In this case, object heap will contain three objects, each with refcount
of 1:
{name: Kirk, ID: 1234}
{name: Joe, ID: 5678}
{obj1: reference to first object, obj2: reference to second object}
>
> I can create a local obj as:
>
> $obj:=OB GET(prosObj;"obj1")
>
you create a local (object) variable referencing first object, and refcount
of this object is increased to 2.
3) My first point of clarification is that $obj is simply referencing
> prosObj so it's not significantly increasing the amount of memory used.
>
yes, object variables are just references to objects (data structures
containing object data.)
>
> 4) Conversely if I created $obj using the copy command it would. So
>
> $obj:=OB COPY(OB GET(prosObj;obj1))
>
> would create a full copy of obj1 and take up more memory.
>
More interesting case is what happens if you copy the main object
containing references to other objects. I believe references are not
coppied, it means you will get another object with object references to
original objects (And refcounts of original objects will be increased.
>
> 5) This referencing feature also applies to objects in arrays. It's easy to
> discover this inadvertently:
>
> ARRAY OBJECT($aObjs;0)
>
> OB SET($obj;key;"new value")
>
> APPEND TO ARRAY($aObjs;$obj)
> APPEND TO ARRAY($aObjs;$obj)
> APPEND TO ARRAY($aObjs;$obj)
>
> $aObjs has 3 element each containing: {key;"new Value"}.
>
As I understand it, you have only one object {key;"new value"} with for
variables referencing it: $obj, $aObjs{1}; $aObjs{2} and $aObjs{3}.
> If I modify $obj:
>
> OB SET($obj;key;"defined value")
>
> each element of $aObjs is now
> {key;"new Value"}
>
you mean {key;"defined value"}?
> Again, I'm assuming $obj only exists in memory one time with each element
> of $aObjs referring to it.
>
Yes, this is my understanding as well.
> 6) I can clear $obj without erasing the referenced values by calling:
>
> $obj:=JSON PARSE("{}")
>
yes, this creates a new (empty) object storage and stores reference to it
into $obj, and decreases refcount to original object by one. In this
example, original object data are still references by three array elements.
When method ends and local array $aObjs is cleared, the data will be
cleared.
> 7) And unlike menus and hLists the memory occupied by $obj is released
> when the process end.
>
No, objects are released - in the sense the memory occupied by it is
cleared - when their refcount is 0. Ending method clears references from
local object variables, ending process clears references from process
variables. But if you have
C_OBJECT($obj)
OB SET($obj;key;"value")
<>ipObj:=$obj
object {key;"value"} will not be cleared when method or process ends.
>
> 8) Passing objects as parameters is essentially equivalent to passing
> pointers to c-obj vars EXCEPT when working with a method called with
> Execute on server - object references don't propagate when moving between
> the twin and local process. So let's say myMethod
> does this:
>
Yes, when you pass object to server process or method executed on server,
object is serialized, send to other side and there recreated.
The same seems to hold if you pass object to worker, but this I have not
tested (but if it would not be true, we would have values shared with
workers.)
>
> SET($1->;"name";"Kirk")
>
> then myMethod will work the same way on the client or EOS. However I
> suspect the time to dereference a pointer adds some time on the client side
> that wouldn't be required by simply accessing the object directly.
>
This is something I would like to test. In fact, I never tried to pass
pointer to EOS method and do not have clue if it will be working (or is
allowed.)
HTH,
--
Peter Bozek
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
