[DGD] Object upgrading

[Raymond Jennings]

On Tue, Jul 3, 2018 at 4:34 AM <bart at wotf.org> wrote:
>
> On Mon, 2 Jul 2018 23:55:28 -0700, Raymond Jennings wrote
> >
> > After doing the paperwork for patchers, when a non inheritable object
> > is compiled, the next thing I do is atomically enter a loop to
> > call_touch the object and all of its clones so that the next attempt
> > to access them will get it pulled over for a JIT patch.
> >
> > Once the clones are marked, the last thing I do before I end the task
> > is suspend the system and arrange to have the object's upgrade
> > function called, after which the system releases itself.
>
> I do not understand this particular step, wouldn't this be triggered due to
> the object that needs a call to its upgrade function also getting handled by
> call_touch?

Yes, but this is an acceptable situation.

The call to upgrade() is reserved only for the master object.  It is
*not* called on clones.

And yes, I fully intend for the object's patchers to be triggered by
the attempted call to upgrade() and preempt it before it is allowed to
proceed.

> Second question, why suspend the system here, and not at the beginning of this
> entire process?

The suspend is merely intended to protect the upgrade() call from
being preempted by regular activity.

In order to actually use the new program's version of upgrade(), I
have to make the call happen after the task that actually recompiles
the object.  I suspend the system to push back anything else from
preempting it.

The suspension is only to sandbox the upgrade() call.  Particularly if
it might otherwise be preempted by competing callouts elsewhere.

As for the "entire process", the loop that call_touch'es all the
clones takes place in one task, the same task that actually recompiles
the object.

> <snip>
>
> >
> > My own concern is that the most obstructive part of the process is
> > the loop that marks all the clones.  Actually finding all the clones
> > is a bit of a chore.  For the time being I'm using a loop that does
> > a find_object sweep through the object table.
>
> I've looked at this approach, and use it as a fallback to reconstruct object
> and clone data. The advantage of this approach is of course not ending up
> pulling in all clones, which my current alternative does, as it uses a linked
> list which is maintained in the objects/clones, hence it has to call a clone
> to find the pointer to the next clone if any. I use a loop that only pulls in
> a limited number of objects/clones, and after this, uses a call_out to itself
> for the next batch. (note that the object handling this is excluded from
> call_out blocking while the system is suspended).
>
> Obviously the above loop first gets the next clone pointer before doing a
> call_touch on the current clone.
>
> I considered using this setup to just call the appropriate upgrade functions,
> but that did not work out very well, those functions can be relatively
> expensive and can fail.
>
> But.. that solution is not exactly perfect as it ends up pulling in all
> objects and clones affected by the recompile.

I used to store a database of clones in CloneD, however since a tight
loop using find_object can get them anyway I decided that it was
redundant.

> Being able to find all clones relatively quickly is something I also use
> elsewhere, and it does not require a global data structure for keeping track
> of this.
>
> Bart.
> --
> https://www.bartsplace.net/
> https://wotf.org/
> https://www.flickr.com/photos/mrobjective/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd