Am 09.03.2010 um 23:57 schrieb Michael Schlenker: > > 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.
For an example of such a technique for Java bytecodes: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.1873 > > 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 _______________________________________________ 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
