[DGD] Memory and compilation

[Raymond Jennings]

Also, what happens if you attempt to recompile an inheritable in a way that
would break a clonable?

On Mon, Aug 29, 2016 at 8:09 AM, <bart at wotf.org> wrote:

> 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/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd