Most scripts allocate space (add items to lists) based on events. How would the number of events be estimated? Seriously, this requires more than an oracle. It requires clairvoyance. Unless the coder specically codes a limit on the number of list elements added, there is no way to predict.
Lear On Tue, Mar 9, 2010 at 5:57 PM, Michael Schlenker <schl...@uni-oldenburg.de> wrote: > > Am 09.03.2010 um 02:54 schrieb Lear Cale: > >> huh? Can you point to existing technology for this analyzer? Seems >> to me like it would require an oracle. > > It might require an oracle to reach 100%, but if you go for the easy part, > its not that hard (assuming a sane GC). LSL is a pretty simple language > without many of the problems you have with C like pointers and memory > aliasing and stuff like that. Not sure if one could reuse parts of the LLVM > analyzers/optimizers for Mono to do this (Mono 2.6 can compile for a LLVM > backend). > > 1. All scripts that only handle integer, float, vector, key and rotation > variables without recursive calls can be handled easily. > --> The memory size for those types is fixed. > --> One could probably compute a complete callgraph and add up the maximum > number of used locals too. > > 2. If the script uses recursion, it depends. If the compiler can figure out > the maximum depth, works as 1, if it can eliminate tailcalls, it can do 1. > too. If it cannot, its a lost cause and it must assume the worst aka 64kB. > > 3. If the script uses strings, it depends what operations are used on those > strings. The only critical operation is appending strings to other strings, > comparing, getting substrings etc. could all be done in constant memory. As > all functions that can provide strings to a script have an upper bound on > parameter size one could calculate a 'worst case' scenario in many cases. > Just assume any LSL function or event that returns/provides a string provides > a unique string of maximum size. Sum up and you have a worst case limit. > > 4. If the script uses lists of other data types use similar techniques as for > strings. As LSL does not have any reference types and you cannot nest lists > this is not too hard to do because list are essentially flat like strings. > > This of course assumes some small glitches are allowed like the overhead of > copying a string/list, because the gc can free that memory at once if needed. > > For simple scripts, e.g. the ugly 100s of 'resizer' scripts you find in > hairs, shoes etc. this could work pretty well, as those are usually just one > link_message handler with trivial code and one or two functions that call > llSetPrimitiveParams(). You might overestimate by one or two kB, because you > don't know how big the link_message string and key parameters are, but other > than that it should work pretty well. > > Michael > >> >> On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker >> <schl...@uni-oldenburg.de> wrote: >>> >>> Am 08.03.2010 um 18:46 schrieb Kelly Linden: >>> >>>> We are not out to write a new malloc for mono. What we have is a system >>>> that throws an exception when the memory used by the script hits a certain >>>> threshold (64k currently). This exception is caught so we can "crash" the >>>> script. The future small scripts and big scripts projects will add new >>>> functions to set and get this threshold value, allowing scripters to >>>> effectively control how much memory is reserved for their script. We will >>>> continue to use mono's default memory management within the reserved >>>> memory thresholds. It is a much simpler problem to solve. >>>> >>> While your at it, how about a static analyzer for mono/LSL that determines >>> guaranteed lowest memory consumption for a script and sets the threshold >>> there. >>> >>> That would have the benefit of easing scripters work by providing useful >>> defaults for all the easy cases without them having to do anything at all. >>> >>> The scheme should only break down if the mono GC behaves weird. In that >>> case scripters have a huge problem anyway as they cannot set any threshold >>> without being crashed at random by a lazy GC. >>> >>> Michael >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> > > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
