Mono Shared Memory

[agentronin]

A benefit of Mono is that multiple instances of the same script share the same memory in the server, with consequence that each additional instance of a rezzed object that contains the Mono script is not an additional burden on the sever in regard to script memory.

Would the same be true if the same script were in different inventory objects that were rezzed? In this case how would the server recognize that the different objects, which are not instances of the same object, have an identical script in common with them?

[Quistess Alpha]

a "script" object is (as I have osmosed from people who know more than I) actually a bundle of 3 things,

1. a compiled executable for the script
2. the memory the script uses during execution (all the variables and stuff. . .)
3. a copy of the source-code used to compile the script.

I assume the server can set up 1 and 3 as refference links, so when you copy a script, all copies point to the same data for 1 and 3. if you recompile the script, the server will create new data for 1 and 3, even if they're identical to the other copies.

[Fenix Eldritch]

2 hours ago, agentronin said:

Would the same be true if the same script were in different inventory objects that were rezzed? In this case how would the server recognize that the different objects, which are not instances of the same object, have an identical script in common with them?

Yes. The server would see multiple instances of the compiled script with the same uuid and thus would use mono's bytecode sharing feature. Even so, they each have their own runtime memory for state and variables. How exactly the server keeps them separate, I do not know, but it certainly does manage to do so.

 

You can demonstrate this by rezzing a cube, creating a new script and supplying this code:

integer count = 0;

default
{
    touch_start(integer total_number)
    {
        string name = llGetInventoryName(INVENTORY_SCRIPT, 0);
        if (name)        // if it exists ...
        {
            key uuid = llGetInventoryKey(name);
            if (uuid)    // if the uuid is valid ...
                llOwnerSay( "The UUID of '" + name + "' is " + (string) uuid);
            else         // item was not full-perm
                llOwnerSay( "The UUID of '" + name + "' could not be determined");
        }
        
        count++;
        llOwnerSay("This object has been clicked  "+(string)count+" times");
    }
}

Save it, then click the cube. It will speak the uuid of the script and how many times it's been clicked.

For demonstration purposes, name this object something like "first". After clicking it a few more times, duplicate the object (Ctrl+D). Rename that new object to something like "second" and click on it. Notice that both objects report their scripts have the exact same uuid, but they maintain their own memory of how many times they've been clicked (with the second object starting fresh).

Take a copy of the first object into your inventory, making sure to leave the original and duplicate still rezzed. Click on both still rezzed objects a few more times. Rename the copy you took into inventory to something like "third" and rez it. When clicked, this third object will also report its script having the same uuid as the other two. Since this was taken as a copy, its own memory will be a clone of the first at the time you took it into inventory.

Finally, take a copy of the script from the first object (drag it to your inventory). Rez a new cube, name it "fourth" and drag the copy of the script into it. Clicking this object will report the script have the same uuid as the other scripts from before, though this will be initialized like when we used Ctrl+D to duplicate the first object.

In all cases, each script retains its own block of memory for variables and thus is distinct from the others despite sharing the same script uuid and as such, the same bytecode.

Edited to add: You can even drop multiple instances of the script from inventory into the same prim. When clicked, both scripts will run, each reporting the same uuid, but also each reporting their own number of clicks.

 

Edited October 15, 2021 by Fenix Eldritch

[animats]

Scripts in Second Life don't just run. They get bundled into objects, which can be rezzed, taken back into inventory, copied, and moved from one sim to another. The state of the script survives all that. It's rather clever, and somewhat different from normal program behavior.