User:Babbage Linden/Office Hours/2009 01 28

From Second Life Wiki
Jump to navigation Jump to search

Transcript of Babbage Linden's office hours:

[8:11] Jor3l Boa: hola muchachoss !!

[8:11] Jor3l Boa: Hola muchachooossss!!!

[8:11] MarkByron Falta: hi babbage

[8:11] Nock Forager: Hi Babbage

[8:11] Babbage Linden: morning

[8:11] Fake Fitzgerald: hi Babbage

[8:12] Jor3l Boa: oh !!!

[8:12] Babbage Linden: or whatever other time it might be for you ;-)

[8:12] Siann Beck: Hi Babbage!

[8:12] beli Vella: hi

[8:12] Babbage Linden: lots of scripting news today

[8:12] Jor3l Boa: you need a less danger plat

[8:12] Siann Beck loves scripting news

[8:12] MarkByron Falta: great

[8:12] Babbage Linden: we've been working on a number of scripting issues with 1.25.4

[8:13] Babbage Linden: a number of them were caused by changes to the scheduler

[8:13] Babbage Linden: it turns out that memory accounting was coupled to the scheduler

[8:13] Babbage Linden: as we measure used memory when scripts aren't running

[8:14] Babbage Linden: by summing the sizes of all the objects reachable from the script object when it's not running

[8:14] Babbage Linden: because we can't easily find out how much memory the script is using while it's running

[8:14] Babbage Linden: (as we can't easily ask Mono for the size of its stack)

[8:15] Babbage Linden: it was possible to briefly use more memory than should have been allowed while your script was running

[8:15] Babbage Linden: as long as it reduced its memory usage below 64KB before the script stopped running

[8:15] Babbage Linden: when we changed the scheduler, scripts started yielding at different places

[8:16] Babbage Linden: which broke some of the scripts that relied on being able to use more than 64KB at certain points

[8:17] Babbage Linden: so, we've coded a fix which decouples memory accounting from scheduling

[8:17] WolfPup Lowenhar: so basicly it was posible for soem one to overload the script memory for a time as long as ewhen the script was done it went back to its 64 alocation

[8:17] Babbage Linden: what will happen is that if a script could potentially be using more than 64KB, we now stop it running and check its used memory immediately

[8:18] Babbage Linden: rather than when the scheduler wants to stop the script

[8:18] Babbage Linden: this change is important going forward

[8:19] Babbage Linden: as it means that if we need to change the scheduler again, we won't break any more scripts

[8:19] Babbage Linden: but, this change itself will break all scripts that rely on using more than 64KB

[8:19] WolfPup Lowenhar: that is good cause it would help pervent people from makeing scripts that could potentualy crash a sim

[8:19] Babbage Linden: not just the ones that were unlucky enough to be broken by the scheduler changes in 1.25.4

[8:19] Babbage Linden: so, the plan is to get that fix on to a region on aditi

[8:20] Babbage Linden: so people can test their scripts there before we roll it on to agni

[8:20] Babbage Linden: so we don't break scripts running on agni

[8:20] Babbage Linden: we plan to leave it running on aditi for long enough for people to test their scripts and have fixes coded and deployed on agni before the change

[8:20] Babbage Linden: so it will be at least a month or so

[8:20] Babbage Linden: and we will try to message this as widely as possible

[8:21] Siann Beck: That;s good.

[8:21] Babbage Linden: in the meantime we will revert the scheduler changes we made in 1.25

[8:21] Babbage Linden: which broke some scripts on agni

[8:21] Babbage Linden: and caused other scripts to run very slowly

[8:22] Babbage Linden: so, that's the big news this week

[8:22] Babbage Linden: we've also fixed a crash bug caused when attaching a mono script caused existing scripts to detach

[8:23] Babbage Linden: that fix should be in 1.25.5 along with the reversion of the 1.25.4 scheduler changes

[8:24] Siann Beck: Are there plans for a better solution for the exploit which brought about https://jira.secondlife.com/browse/SVC-3725

[8:25] Babbage Linden looks

[8:26] Babbage Linden: hmm, i'm not sure siann, i wasn't aware of this problem

[8:26] Siann Beck: OK

[8:28] Babbage Linden: so, that's what we've been up to this week, any other things you'd like to talk about?

[8:29] [BT]_CBSys: PrescenceUnit.0.6 [script:[BT]_CBSys: AgentTracker.0.4]: Script run-time error

[8:29] [BT]_CBSys: PrescenceUnit.0.6 [script:[BT]_CBSys: AgentTracker.0.4]: Stack-Heap Collision

[8:29] Darling Brody: hay babbage.

[8:29] Jor3l Boa: lag

[8:29] Babbage Linden: hi darling

[8:29] Babbage Linden: thanks for your help the other week

[8:30] Darling Brody: anytime

[8:30] Siann Beck: What aout https://jira.secondlife.com/browse/SVC-2741 ? Any idea when that will get into the lineup?

[8:30] Darling Brody: i have noticed some strange memory behaviour with LSL since mono came out. seems to be a leak somewhere. i'll cobble together a demo for you later.

[8:31] Babbage Linden: i think we have the measure of it darling

[8:31] Babbage Linden: we're going to be deploying a fix to aditi soon

[8:31] Babbage Linden: and i encourage you to test your scripts on the test region there

[8:31] Babbage Linden: as it might break any scripts which use more than 64KB between yields

[8:31] Darling Brody: youw ant to dump one onto one of my open space regions too.... then i can break it for you. i know how you love that :p

[8:34] Jor3l Boa: ....

[8:34] Babbage Linden: not sure about SVC-2741 siann, i'd ask andrew

[8:34] Babbage Linden: it sounds like a physics issue

[8:34] Darling Brody: i was late... 3:30am here... so exceus me if this has been mentioned. but it seems that veriables are not assigned memory until you use them, as apposed to when you declare them. so if you have a integer defeined and not used until later inthe script, it's memory is not assigned. this makes checking memory usage very hard.

[8:34] Siann Beck: OK :)

[8:34] Siann Beck: Thanks for looking.

[8:34] WolfPup Lowenhar: i might check my venders there but i do not know if they will comunicat with servers on the main grid

[8:35] Babbage Linden: darling, memory is measured when scripts aren't running

[8:35] Babbage Linden: so, you might find it helpful to do:

[8:35] Babbage Linden: llSleep(1.0); llGetFreeMemory();

[8:35] Darling Brody: that might explain it.

[8:35] Babbage Linden: the sleep will cause the script to yield

[8:36] Darling Brody: is that in the wiki?

[8:36] Babbage Linden: actually, that might not help you

[8:36] Babbage Linden: the sleep will cause the script to yield

[8:36] Babbage Linden: but we'll only measure the exact amount of memory used if you might be using over 64KB

[8:37] Babbage Linden: we start off with the size of the script bytecode

[8:37] Babbage Linden: which is always at least 4KB

[8:37] Darling Brody: the troule i am having is that old LSL scripts seem to be running out of memory since mono. when i tried to track it i docovered the extra-whackyness of the llGetFreeMemory

[8:37] Darling Brody: i'm talking LSL not mono.

[8:37] Babbage Linden: then, when the script allocates memory we add the size of the allocations to 4KB

[8:38] Babbage Linden: when the memory use is over 64KB we wait until the script stops running

[8:38] Babbage Linden: then measure it's non running footprint to find the exact memory use

[8:38] Babbage Linden: if that is still over 64KB the script has used too much memory

[8:38] Babbage Linden: if it's not over 64KB, we reset the used memory to the measured amount

[8:39] Darling Brody: how abotu you give us 128kb and just document it as 64k :)

[8:39] Babbage Linden: and start adding allocation sizes to that value until the script is over 64KB again

[8:39] Babbage Linden: the LSL memory tracking just keeps track of a high tide value I think

[8:40] Babbage Linden: i'm not sure of the details

[8:40] Jor3l Boa: oh

[8:40] Babbage Linden: you should ask cory ;-)

[8:40] WolfPup Lowenhar: is there a way to tell if a script in running on mono or the orginal LSL

[8:40] Babbage Linden: i've been mulling over adding a new library function that returns the allocated memory value for mono scripts

[8:40] Babbage Linden: which would make this process much more transparent

[8:41] Babbage Linden: and make it much easier to manage memory for mono scripts

[8:41] Babbage Linden: the problem is, it wouldn't be able to work on lsl scripts

[8:41] Babbage Linden: and i'm loath to add an incompatibility

[8:41] Darling Brody: I work with a lot of lists and i find the names = lllist2List(names,x,y) type stuff appears to be holding the list twice in memory during the operation.

[8:41] Jor3l Boa: what about http response limit :/

[8:41] Babbage Linden: darling, yes, lsl uses value semantics

[8:42] Darling Brody: oh yes. a longer httpresponce and email too would be very nice.

[8:42] Babbage Linden: so l = llSomeFunc(l) will have 2 copies of l in existance until the expression is fully evaluated

[8:43] Darling Brody: yes Babbage. i'm wondering if that is sucha good idea?

[8:43] Babbage Linden: i don't think we'll be re-evaluating script resource limits until we work on script limits

[8:43] Babbage Linden: darling, it makes it much easier for newbies

[8:44] Darling Brody: i'm noobie!

[8:44] Babbage Linden: as integers, vectors, lists etc. all behave in the same way

[8:44] Jor3l Boa: thats true

[8:44] Darling Brody: rude!

[8:44] Babbage Linden: if you allow pass by reference, functions can have side effects

[8:45] Babbage Linden: so things like l = []; doSomething(l); llSay(0, (string)l);

[8:45] Babbage Linden: become harder to debug

[8:45] Darling Brody: i understand. i jsut want the script engine to eat the overhead of the operation instead of my script which is cramped for space.

[8:45] Babbage Linden: with pass by reference, doSomething can change the version of l in the calling function

[8:45] Babbage Linden: well, the LSO engine just can't do that

[8:46] Babbage Linden: it allocates all memory from the 16KB block it has

[8:46] Darling Brody: if we can have some non-volitive memory space in a prim, that would sold a lot of problems.

[8:46] beli Vella: bye

[8:46] Darling Brody: previously we could store lots of usefull stuff in the description, but that was broken to fix an exploit.

[8:46] Babbage Linden: you can have read only non-volotile memory in notecards ;-)

[8:46] Darling Brody: *sold=solve

[8:47] Siann Beck: Amen, Darling!

[8:47] Darling Brody: read only :(

[8:47] Jor3l Boa: aios lokita

[8:47] Babbage Linden: the best way to have read/write memory is in a database you talk to via http

[8:47] Babbage Linden: which is actually the model you'd use for web applications anyway

[8:48] Darling Brody: I run an SQL server for that very reason. however for speed reasons you need to have some information close at hand. also the bandwidth costs!

[8:48] Jor3l Boa: with the httplimit we have to work with php to reduce a lot of bites

[8:48] Darling Brody: jor3l is correct.

[8:48] Jor3l Boa: also remotedata limit we need more :)

[8:48] Jor3l Boa: 512 chars or more

[8:48] Babbage Linden: jor3l it makes sense to have bigger http limits now mono scripts have more memory

[8:49] Siann Beck has been fighting with resopnse caching for the past week

[8:49] Darling Brody: email too.

[8:49] Babbage Linden: but as i said, these limits aren't likely to be revisited until we do script limits

[8:49] Darling Brody: please stop saying script limits. you are scaring me.

[8:49] Babbage Linden: which should be happening in the next few months

[8:49] Jor3l Boa: lets say lsl limits :)

[8:50] Darling Brody: i may have missed this before. how are they going to calculate them?

[8:50] Darling Brody: liek prims?

[8:50] Arawn Spitteler: They should apply to C# also

[8:50] Babbage Linden: yes

[8:50] Babbage Linden: like prims

[8:50] Babbage Linden: N KB/m ^ 2

[8:50] Darling Brody: so a bigger parcel gets more script time than a smaller one.

[8:50] Babbage Linden: yes

[8:50] Babbage Linden: plus a fixed size pool per avatar for attachments

[8:50] Morgaine Dinova: 'Morning, early birds ;-)

[8:51] Babbage Linden: well, more script memory in the first instance

[8:51] Babbage Linden: CPU rationing may come later

[8:51] Darling Brody: what if you have a full region and you cut out a parcel with the same owner. will it all script time like prim limits too, or will you have one laggy parcel?

[8:51] Babbage Linden: but we need to limit script memory to stop sim hosts from swapping

[8:52] Darling Brody: that being said, i gues your not open to putting more memory into prims, ie. non volitile.

[8:52] Babbage Linden: indeed

[8:52] Babbage Linden: we're more likely to put more memory in to scripts

[8:52] Jor3l Boa: about new functions, when textbox should be working

[8:52] Babbage Linden: once we have script limits, allowing a single script to use 1MB if available makes sense

[8:52] Babbage Linden: look at the http in API for details

[8:52] Darling Brody: the trouble I am having is keeping a list of the UUID for everyone in a region in one script, and being able to add/delete keys are people com a god without blowing out the limit.

[8:53] Darling Brody: the more avatars we let into regions the harder it is to track them all.

[8:53] Babbage Linden: ok, i need to go in a few minutes, any last thoughts?

[8:54] Jor3l Boa: :s

[8:54] Jor3l Boa: we need textbox workins :)

[8:54] Morgaine Dinova: Maybe the need for large datasets suggests that there should be an indexed storage facility available, separate from scripts, for use as a service?

[8:54] Jor3l Boa: working

[8:54] Babbage Linden: you should suggest that to T as a new product morgaine

[8:55] Arawn Spitteler: TextBox would be good, and for friend requests, if you've the code open.

[8:55] Babbage Linden: i think he'd tell you that we don't want to compete with web hosting companies though

[8:55] Darling Brody: but you are a web hosting company. it is jsut your webpage is in 3D

[8:55] Babbage Linden: ok, i'm off

[8:55] Jor3l Boa: i mean llTextBox

[8:55] Babbage Linden: thanks for coming everybody

[8:55] Jor3l Boa: well bye

[8:55] Siann Beck: Thanks, Babbage!

[8:56] Darling Brody: thanks Babbage.

[8:56] Jor3l Boa: :)

[8:56] MarkByron Falta: l8r

[8:56] Morgaine Dinova: Thanks Babbage

[8:56] Nock Forager: Thanks for your time. see you in next week.

[8:56] Fake Fitzgerald: thanks Babbage
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Babbage_Linden/Office_Hours/2009_01_28&oldid=225603"