[DGD] Memory and compilation

[bart at wotf.org]

For what I can tell, your idea of when dataspace is allocated is correct.

Regarding the need to destruct an inheritable to recompile it, there is
something else to keep in mind:

Lets assume you have an inheritable a, and 2 objects b and c.
Now, you recompile a to introduce new code, after which you should compile b
and c to have both use the new code in a.

Lets assume you initially only recompile b and not c. You now have a situation
where b needs the new code block from a, where as c needs the old (before you
recompiled it) code block from a.

This means that after recompilation of a, and until *EVERY* object using code
from the old version of a has also been recompiled, DGD needs to keep both the
old and new versions of a available. 

The way this is acomplished is by destructing the old instance of a to ensure
the next time a gets compiled, it gets a new 'issue' (that is, a new position
in the object table, you can verify this by using the status() kfun). The old
version will no longer be available for any new uses, but, it will be kept
around until the last user of it got recompiled (you will notice the driver
object gets called when the last user of it has been recompiled).

So, while I cannot answer if the technical reason results from the design or
the other way around, the reason for having to destruct the inheritable to
recompile it is to ensure it gets a new issue and hence new place in the
object table, such that both the old and the new version can coexist for as
long as needed to finish rebuilding everything that depends on it.

Just introducing the new code from a into every object that inherits it cannot
work because your code changes to a may require changes to objects using a.
This can only work if you actually recompile all those objects.

Hope this helps.
Bart.

On Sun, 28 Aug 2016 19:35:13 +0100, Gary wrote
> Hi all,
> 
> I'm trying to get my head around how LPC programs relate to clones 
> and inheritables when it comes to memory layout (conceptually) and 
> compilation (whether running under the kernel library or not)
> 
> Apologies in advance for the long winded email, but I've read enough
> documentation and code over the last few days that I feel I almost
> understand this but there's this little nagging voice telling me I'm
> still overlooking something. I'm just not quite sure at which point
> my understanding is flawed in order to ask a more concise question.
> 
> # Clones
> 
> Based on reading posts from the list archive and phantasmal site, my
> current understanding is that an LPC program foo.c can be compiled at
> which point a "master object" now exists in memory containing both code
> and data variable storage.
> 
> A clone can be made from a master object which will cause only 
> storage space for data variables to be allocated [*1]. Code will be referenced
> in the master object instead.
> 
> iiuc both the master object and each of its clones may contain their 
> own unique data but all will share the same code on the master 
> object. This code can then be upgraded in-place using compile_object 
> on the master object, data will be retained in the master object and 
> all clones (which will be now use the new version of the code)
> 
> # Inheritables
> 
> Where my understanding breaks down a little is with regards to programs
> that are used for inheritance.
> 
> For example /lib/A is inherited by both /obj/B and by /obj/C how 
> would the memory be allocated for code/data for A, B and C?
> 
> My current understanding is that when B is compiled it will be a master
> object that has enough storage allocated to contain B's data as well 
> as the inherited A's data plus B's code, but it will reference A's code.
> 
> When C is compiled, it too will be allocated storage for C's code as
> well as A and C's data? but again would point to A's code.
> 
> Is any memory allocated for data storage for /lib/A other than for 
> A's code?
> 
> # Confusion
> 
> The reason the above has confused me is that with clonables, for example
> if /obj/D had 5 bytes worth of variables and is cloned twice. The two
> clones would have 10 bytes in total allocated for variable storage 
> but /obj/D itself as a master object will also have 5 bytes 
> allocated giving a total of 15 bytes used.
> 
> For inheritables however, if /lib/A had 5 bytes of variables and was
> inherited by /obj/B and /obj/C would 10 bytes be allocated or 15 (to
> include /lib/A even though kernel prevents calls direct on /lib/A or
> accessing its data/using it as a master object)
> 
> # Driver Recompile
> 
> The reason I'm trying to get a clear picture of the above is that there
> exists a way via compile_object to in-place upgrade a master object
> which will result in a new master object that retains the data from the
> old but is now running new code. All cloned objects thus use the new
> code as they refer to the same master object.
> 
> Why is the same not possible with the driver for programs used in
> inheritance?
> 
> It seems inherited programs have instead to be destroyed[*2] and then
> the program that inherited them needs to be compiled which in turn will
> then compile the library.
> 
> I'm aware of the restrictions the kernel library imposes to ensure a
> program cannot be used both as a library and as a master object for
> cloning due to this but what I can't quite figure out, is why when
> in-place upgrading exists for master objects, it does not exist for
> libraries?
> 
> I'm assuming there's either a technical issue or a design decision
> behind this which is why the driver requires a library be destroyed and
> then the objects that inherited it be recompiled to upgrade the library
> and objects that use it. Rather than an in-place compile of the library
> and then an in-place compile of each object inheriting that library.
> 
> Does anyone know what that may be?
> 
> All that said, my main question is whether my understanding of the
> memory layout for programs that are compiled and end up used as 
> master objects, clones, libraries and objects inheriting a library,
>  was correct in the general case ignoring limitations the kernel 
> library imposes. In particular with regards to programs used as libraries.
> 
> [*1]: Ignoring any space DGD allocates for code pointer and any other
> misc items.
> [*2]: Thus the reason the kernel library places restrictions on
> /lib and /obj to avoid an object being used as a library and cloneable.
> 
> Regards,
> 
> Gary
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/