[DGD] Memory and compilation

[Gary]

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