[DGD] COW arrays

[Raymond Jennings]

Also realized that this would add an expensive layer of dereferencing,
since I'd have to keep track of logical arrays (preserving byref and byval
semantics for LPC as required) and physical arrays (actually holding the
data, and doing the COW magic as needed).

If I get around to implementing it I'll wrap it in an ifdef and see how it
goes.


On Sun, Jun 30, 2013 at 10:17 PM, Raymond Jennings <shentino at gmail.com>wrote:

> Just realized I started arguing instead of asking.  If I want to spend the
> time to argue I'd be better off spending it implementing it myself.
>
>
>
> On Sun, Jun 30, 2013 at 6:23 PM, Raymond Jennings <shentino at gmail.com>wrote:
>
>>
>>
>>
>> On Sun, Jun 30, 2013 at 2:33 PM, Felix A. Croes <felix at dworkin.nl> wrote:
>>
>>> Raymond Jennings <shentino at gmail.com> wrote:
>>>
>>> > Speaking strictly from a perspective of merit (I plan to work out
>>> > implementation later if it's worth the trouble), would making
>>> duplicated
>>> > arrays copy on write be worthwhile?
>>> >
>>> > Use case:
>>> >
>>> > For security reasons, it's often wise to pass arrays by value, ala
>>> > array[..], to keep the callee from tampering with the contents of the
>>> > master version.
>>>
>>> It would mean a minor slowdown and would probably not save memory,
>>>
>>
>> Memory savings are only a fringe benefit here though.
>>
>> It's actually array copy overhead I'm targetting.
>>
>>
>>> since arrays copied in the manner you describe are usually exported
>>> to other objects, where they'll be copied anyway.
>>
>>
>> Only if they are persistently saved.  I'm talking more about live
>> tampering:
>>
>> arr = object->get_fragile_array();
>> arr[someindex] = tampervalue
>>
>> where arr is a local variable (which means it doesn't get exported)
>>
>> Here, security demands that get_fragile_array() return a copy to avoid
>> such tampering.
>> I was wondering if having arrays COW'ed could optimize for the general
>> case of well behaved callers that only read the array and don't write to it.
>>
>> Cases in point:  obj->query_inventory(), obj->query_archetypes()
>>
>> At least in my own codebase these are frequently called functions, and
>> naturally I have to guard them with [..]'s to prevent malicious callers
>> from tampering with them.  Though these arrays are rarely if ever modified
>> in place by the caller, which means the array copy is wasted overhead.
>>
>> My hope was to use COW to elide array copies when not required.
>>
>> I think it's the same sort of logic dgd already uses with strings
>>
>> The minor slowdown
>>> would come from the COW administration overhead, which of course would
>>> also have an impact on memory usage.
>>>
>>
>> Would this COW overhead be compensated for with a reduction in array
>> copying overhead?
>>
>> A more interesting approach would be to make arrays copy-on-write in
>>> all cases.  But that, of course, would be a change to LPC.
>>>
>>
>> I think there's code out there that actually relies on array/mapping
>> byref semantics anyway.
>>
>> Regards,
>>> Felix Croes
>>>
>>
>> I think the first think I'd do here is benchmark it as a configurable
>> option.
>>
>>> ____________________________________________
>>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>>
>>
>>
>