[DGD] happycode in DGD

[Raymond Jennings]

So here's the roles I have in mind

Master object
Clone object
Happycode object
Closure lwo

The master object is the clone's master object and its control block,
ostensibly, knows about variables.  The master object's control block is
monitored during recompiles of the master object, and this is where removal
of variables is caught and outlawed via a runtime error during compilation.

The clones hold the object global variables.

The happycode object just contains the bytecode snipped off of the master
object, so it's kinda a hybrid between a clone and a master.  It has a
reference to the master object so that it can monitor the master object for
invalid variable removals.  The happycode object is created when the master
is compiled, there is one for each snippet of happycode.  To avoid conflict
with in place recompilations, happycode itself cannot be recompiled.

The closure LWO's have references to both the happycode object it executes,
as well as the clone object it is attached to.  It uses the reference to
the clone object to know which object's global variables to tinker with,
and it uses the reference to the happycode object to know what code to run
when it is invoked.  THe closure LWO also contains any closure local
variables.

One more thing I have in mind:  Obviously, you can't have happycode objects
sitting around forever, otherwise you could DoS the server with infinite
compilations.  So I think of two things:

First, happycode objects are created as "virgin", and remain so until they
are referenced by a closure.  If a master is recompiled, any happycode
objects that are virgin are simply destroyed since once the master's old
program goes poof, they cannot possibly be referenced again as they are
orphaned.

The second bit of garbage collection happens once per full snapshot.  Once
a snapshot is made, everything is pushed out, and we mark all happycode
objects as dormant.  As objects are swapped in, closures are detected, and
we kick the happycode object it points to and mark it as active.  On the
next snapshot, every closure in existence will have been combed through,
and any happycode object still dormant is reclaimed since anything that
could have referred to it has been eliminated.


On Sun, Sep 8, 2013 at 12:16 PM, Raymond Jennings <shentino at gmail.com>wrote:

> So basically, happycode objects are like parsers and user objects, marked
> as special.  They have handles both to the object they are tied to and the
> master object providing their code.
>
>
>
>
> On Fri, Sep 6, 2013 at 5:34 PM, Raymond Jennings <shentino at gmail.com>wrote:
>
>> On Fri, Sep 6, 2013 at 5:12 PM, <bart at wotf.org> wrote:
>>
>>> 2 comments at first glance:
>>>
>>> On Fri, 6 Sep 2013 16:55:49 -0700, Raymond Jennings wrote
>>> > thanks to an enlightening chitchat with aidil, I think I have a basic
>>> > gameplan for implmeenting happycode in DGD
>>> >
>>> > First off, each happycode snippet is compiled on the spot along with
>>> > the rest of the source code it is with.
>>> >
>>> > Second, happycode snippets are split off into their own heavyweight
>>> objects
>>> > after being morphed into bytecode for the vm.
>>> >
>>> > Third, code in the defining object that emits function pointers is
>>> tagged
>>> > with a reference to the happycode object in question.
>>> >
>>> > Fourth, function pointers use that tag to know which happycode
>>> > object to execute when they are referenced.
>>> >
>>> > Fifth, happycode objects are garbage collected similiarly to kfuns, and
>>> > automatically nuked when they are proven to be orphaned.
>>> >
>>> > Sixth, destructing a  source object also nils out any happycode objects
>>> > built from it.
>>> >
>>> > Seventh, it is an error to recompile an object in such a way that
>>> happycode
>>> > objects refering to it lose track of variables.  So if you have
>>> happycode
>>> > refering to object scope variables, you can't remove those vars in
>>> > the new program.
>>>
>>> How do you intend to enforce this beyond saying "don't do that" ?
>>>
>>
>> A control block with outstanding happycode objects will require checking
>> against every associated happycode object before a variable removal is
>> permitted.  I'll probably be checking the varmap.  It's a similiar process
>> to upgrading clones after a master is recompile din place.
>>
>> If I detect any variables vanishing that a happycode blob depends on, the
>> compilation is aborted.
>>
>> > Eighth, new happycode objects are generated as needed each time a source
>>> > object is recompiled.  I decided to avoid the entire conhjflict between
>>> > closures and recompiling by "freezing" the bytecode inside the
>>> happycode
>>> > object when it's compiled.  So happycode never recompiles.  I tjust
>>> floats
>>> > until it becomes unreferenced.
>>>
>>> How to provide access to inherited code, and ensure the sniplet does get
>>> recompiled (based on the same lpc code it had when it was initially
>>> compiled)
>>> when those inherits get recompiled? Not doing so will result in old
>>> versions
>>> of this inherited code staying around until all objects referencing it
>>> will be
>>> gone.
>>>
>>
>> Similiarly, by checking the new control block and making sure that no
>> functions disappear that are needed by the happycode objects.  Local
>> function calls remain, and continue to point to whatever functions replace
>> the ones that they referred to.  Kinda like undefined function resolution
>> during runtime.  In fact, if I treat it as a call to an undefined function,
>> I might not even need to check this during recompile.  It might be a good
>> debug tool though.
>>
>> Also, happycode snippets are NEVER recompiled, ever.  When I recompile a
>> master object, I generate brand new happycode objects, and leave the old
>> ones behind for outstanding fp's to point to.
>>
>> Of course, everything would be much simpler if happycode blocked
>> recompiles outright, but then where's the advantage in porting to dgd?
>>
>> Bart.
>>>
>>> --
>>> http://www.flickr.com/photos/mrobjective/
>>> http://www.om-d.org/
>>>
>>> ____________________________________________
>>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>>
>>
>>
>