20,741
edits
User talk:Philosopher/Nasal introspection: Difference between revisions
Jump to navigation
Jump to search
m
User talk:Philosopher/Nasal introspection (view source)
Revision as of 21:19, 14 August 2013
, 14 August 2013→GC Issue: Too Many Objects!
Philosopher (talk | contribs) m (→August 14: explore.py) |
|||
| Line 117: | Line 117: | ||
== GC Issue: Too Many Objects! == | == GC Issue: Too Many Objects! == | ||
Looking at Garbage collector stats in the logging output from FlightGear, there's a lot of GC'ing happening when loading scripts, which is okay. Essentially my (console-based) measure of “starting” the simulator that I see is when I see “Animated jetways ... initialized” message. Environment init happens somewhere in the middle, and test.nas in between those two subsystems. In both a “normal” and a “extended-nasal” (maybe it’s Extreme Nasal by now?) run, the environment init message is printed between GC reference counts of 26000-31000 (I saw +2000 extra objects for the run with test.nas compared to the normal one). In a test.nas run, the number of GC-findable objects keeps climbing from after I see “Start thread” and “End thread” messages. At the animated jetways init (after test.nas) I see 30340 versus 703425 objects (¡that's a factor of over 20!). In a normal session, the object count might keep going up until 43000, and then it drops off to 15000 and stays there for the rest of the session (15049 +- 20 or so). In an example test.nas session it got to 5268045 objects and an astounding 10645602 references (>1e7!) before I killed it off (couldn't bare to watch…). At that point, all of the worker threads were done, so it's not like they could be clinging to lost objects; and I'm not storing an infinitely-growing list anywhere, I'm even freeing the sub-contexts as they return! Since I know the Nasal code fairly well, is it possible that I'm creating leaks in the C code? But it is basically under the same automatic memory management, so I would think that it is unlikely. I will have to go a dump sizes of objects sometime, and perhaps whole namespaces, so that I can check if there's something that I'm forgetting to free. (Wait, I thought it was Nasal, we aren't supposed to worry about memory — wink.) Any thoughts? [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 21:02, 14 August 2013 (UTC) | Looking at Garbage collector stats in the logging output from FlightGear, there's a lot of GC'ing happening when loading scripts, which is okay. Essentially my (console-based) measure of “starting” the simulator that I see is when I see “Animated jetways ... initialized” message. Environment init happens somewhere in the middle, and test.nas in between those two subsystems. In both a “normal” and a “extended-nasal” (maybe it’s Extreme Nasal by now?) run, the environment init message is printed between GC reference counts of 26000-31000 (I saw +2000 extra objects for the run with test.nas compared to the normal one). In a test.nas run, the number of GC-findable objects keeps climbing from after I see “Start thread” and “End thread” messages. At the animated jetways init (after test.nas) I see 30340 versus 703425 objects (¡that's a factor of over 20!). In a normal session, the object count might keep going up until 43000, and then it drops off to 15000 and stays there for the rest of the session (15049 +- 20 or so). In an example test.nas session it got to 5268045 objects and an astounding 10645602 references (>1e7!) before I killed it off (couldn't bare to watch…). At that point, all of the worker threads were done, so it's not like they could be clinging to lost objects; and I'm not storing an infinitely-growing list anywhere, I'm even freeing the sub-contexts as they return! Since I know the Nasal code fairly well, is it possible that I'm creating leaks in the C code? But it is basically under the same automatic memory management, so I would think that it is unlikely. I will have to go a dump sizes of objects sometime, and perhaps whole namespaces, so that I can check if there's something that I'm forgetting to free. (Wait, I thought it was Nasal, we aren't supposed to worry about memory — wink.) Any thoughts? [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 21:02, 14 August 2013 (UTC) | ||
:: As a crude workaround, you could expose the GC via an extension function, to explicitly trigger it in your code, and then watch the stats afterwards: IF the stats do not decrease after your explicit GC calls, objects are still somewhere referenced, i.e. cannot be reclaimed - maybe because of naTempSave() calls ? In general, memory isn't immediately reclaimed - but only after the GC could run, the amount of necessary GC work can be reduced by assigning nil and by delete()ing complex objects. Another thing worth trying would be associating naRefs with their origin (table of files and lines) using another naRef as a member, which would allow you to store the origin of naRefs directly inside them, and the dump everything to a file for inspection purposes. Adding an extension function that recursively dumps reachable naRefs (in a mark() fashion) should be straightforward and would tell us where the data came from that's still lingering around | |||