Re: [opensource-dev] Script Memory Management Algorithm

2010-03-11 Thread Lear Cale
Fine, don't waste your time responding. Go do better things. On Thu, Mar 11, 2010 at 6:39 AM, Carlo Wood wrote: > It makes little sense to me to put time into convincing a random non-Linden. > And since LL is going to ignore the whole discussion/idea anyway, I have > better things to do. Sorry.

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-11 Thread Carlo Wood
It makes little sense to me to put time into convincing a random non-Linden. And since LL is going to ignore the whole discussion/idea anyway, I have better things to do. Sorry. On Wed, Mar 10, 2010 at 11:56:36AM -0500, Lear Cale wrote: > If it were a simple change, I'm sure it would be considered

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-10 Thread Lear Cale
If it were a simple change, I'm sure it would be considered. What you're suggesting sounds like would require a massive rewrite. I agree that a dynamic system would be much better, easier to code and less wasted memory. But without detailed knowledge of how the system is currently implemented, i

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-10 Thread Lear Cale
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

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-09 Thread Michael Schlenker
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.ed

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-09 Thread 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. 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 lan

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-09 Thread Erik Anderson
onecutter > Sent: Tuesday, March 09, 2010 9:06 AM > To: Carlo Wood > Cc: server-b...@lists.secondlife.com; opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] Script Memory Management Algorithm > > On 2010-03-09, at 07:26, Carlo Wood wrote: > > This is exactly the kind of rea

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-09 Thread Dickson, Mike (ISS Software)
.secondlife.com] On Behalf Of Argent Stonecutter Sent: Tuesday, March 09, 2010 9:06 AM To: Carlo Wood Cc: server-b...@lists.secondlife.com; opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Script Memory Management Algorithm On 2010-03-09, at 07:26, Carlo Wood wrote: > This is e

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-09 Thread Argent Stonecutter
On 2010-03-09, at 07:26, Carlo Wood wrote: > This is exactly the kind of reaction that drives me away from here. > > I propose a simple way get FOUR times the memory for all the > scripts, at > no other cost than adding some malloc code to your mono engine. I don't think you have established tha

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-09 Thread Morgaine
Carlo +1. Explicit pre-allocation of memory by users has to be one of the silliest and most regressive "improvements" appearing in SL for a long time. It's a waste of memory, it takes us back decades, and it's a burden on users. So why do it? "Because we've decided to, full stop." -- seems to b

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-09 Thread Carlo Wood
This is exactly the kind of reaction that drives me away from here. I propose a simple way get FOUR times the memory for all the scripts, at no other cost than adding some malloc code to your mono engine. And you simply say, "This is what we ARE doing, we're not going to change that". Why this i

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-09 Thread Marine Kelley
I'm naive here, I don't know the server side of it. But how can a sim know when a script hits a threshold, and not be able to report the actual memory used ? Since it can check it against a threshold... On 8 mars 2010, at 18:46, Kelly Linden wrote: We are not out to write a new malloc for

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-08 Thread Lear Cale
Please tell me how to register for this list. I was registered for sldev, but don't remember how. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep un

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-08 Thread Lear Cale
huh? Can you point to existing technology for this analyzer? Seems to me like it would require an oracle. On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker 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 >>

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-08 Thread Michael Schlenker
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 futur

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-08 Thread 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 func

Re: [opensource-dev] Script Memory Management Algorithm

2010-03-07 Thread Argent Stonecutter
On 2010-03-07, at 07:50, Carlo Wood wrote: > Lets assume that the *average* script uses > 8 to 16 kB of real memory. LL's design allocates > 64 kB regardless, leading to an overhead of > 400 to 800% (meaning they need to buy 5 to > 9 times the memory that is theoretically needed). This is not the

[opensource-dev] Script Memory Management Algorithm

2010-03-07 Thread Carlo Wood
Lets assume that the *average* script uses 8 to 16 kB of real memory. LL's design allocates 64 kB regardless, leading to an overhead of 400 to 800% (meaning they need to buy 5 to 9 times the memory that is theoretically needed). In that light, I gave it some more thought, and think something as co