Cool VL Viewer forum

In the upper right hand corner there's the three little bar graph thingies. The first one tracks memory %... is this texture memory or just overall memory?

I understand the viewer can use up to 4GB of RAM and according to my system monitors, it's currently using 1005MB of real memory and 630MB of virtual memory. The little bargraph thing is yellow and when I mouse over, it says memory usage is 89%.

The bar is always at least about 2/3 the way up, from the moment I log on, and it just gradually goes up from there. I just increased my system RAM today, from 4GB to 12GB as I was hoping this would maybe help... and maybe it helped a little bit as it did take several hours for the memory usage to creep up from 2/3 green to almost-full yellow.

Unfortunately I can't increase VRAM, the computer is an iMac. (my next computer will be upgradable!)

Anyhow, just curious what kind of memory that little bargraph thingy is referring to. And do I need to do anything to 'tell' the viewer that it can have the full 4GB if it wants it?

Thank you!

p.s. I am using the most recent version of the legacy viewer:

The memory checking algorithm for Macs has not been verified by me (I have no Mac to test it on). The memory usage functions for MacOS-X have been contributed by Kathrine Jansma.

If you think the viewer is being too pessimistic about the actual available memory, you can disable the memory checking feature in the "Advanced" -> "Memory" sub-menu (type CTRL ALT D to show the "Advanced" entry in the menu bar if it's not already there).
Note however that doing so will cause crashes whenever you hit the virtual address space limit: you may coarsely adjust the memory usage via the "Texture Memory" setting (in the floater opened via the "Preferences" floater, "Graphics" tab, "Hardware Options" button): at 512Mb, the viewer will use about 1Gb of memory for textures before it starts throttling the texture usage (by progressively reducing their resolution). Decreasing this setting will help prevent crashes when the memory safety checks feature is off.

Thank you Henri!

I'm familiar with the 'Texture Memory' setting, but I thought that was tied to video ram rather than system ram?

My Texture Memory setting is 96MB, and my system only has 256MB of video ram.

Cheers!

I'm still playing around with this and wanted to add, I'm not suggesting there's a problem with the memory algorithm -- but without knowing what exactly the NN% is a percentage of, I can't know what it's complaining about. I do know that my computer has lots of system RAM but is has little video ram.

To try and figure this out, I added three lines to the "Statistics Bar" floater to tell me what the viewer was looking at in terms of its max memory, available memory, and free memory that it was using to populate the little bar in the corner.

I've learned that the Memory Usage bar percentage is looking at Virtual memory, and that the viewer was maxing out at 3GB memory instead of 4GB.... apparently it does this when the OS is not a 64bit OS but Mac OS 10.6.8 is 64bit?

I'm poking around to figure that out... now that I have 12GB physical ram I don't see why the viewer shouldn't address the 4GB it's capable of.

I still don't fully understand the relationship between "texture memory", the texture memory slider, system RAM and video RAM but hopefully I'll get that sorted too.

Cheers!

I often find my memory bar gets "stuck" in red and stays there until I log off and back on, regardless of moving to an empty area, adjusting draw distance etc. I know the viewer is supposed to "time out" textures to free up memory, but either this does not happen (the Texture Console suggests that it does) or the memory-meter does not recognise it.

Alas, the MacOS-X release doesn't have the ability to force-release the "freed" virtual memory back to the OS memory pool (the normal behaviour for programs is to just flag the memory as freed in the heap they allocated for themselves so that they can reuse it later without having to claim memory to the OS: the problem is that there is no way to check for what amount of "freed" memory is available in the heap, and seen from the OS, the memory usage of the program simply keeps growing over time)...
Under Linux, the function available and used to do that is malloc_trim() and under Windows it's _heapmin() (which is alas far from being as efficient as Linux' malloc_trim()...), but there is apparently no equivalent function under MacOS-X: if a MacOS-X coder could tell me how to perform the equivalent task, or to know how much "freed" memory is available in the program heap, then I would be able to add the missing bits to the MacOS-X release...

Like I explained above, you can disable memory safety checks in this case...

Hi Henri,

Thank you for explaining about the growing heap, that explains some of the problems I've seen.

I'm not really a Mac coder, I just play around with the xcode tools here and there. There must be a way to force release the freed memory though - I will dig deeper and see if I can find out what the process is.

Cheers!

Hi,

probably i should revert the virtual memory warning code again. It kind of works, but measures the wrong thing and OS X gives some really weird and unstable results from that API (e.g. claiming 16TB of used virtual memory sometimes, which is obviously bogus).

Kathrine

I've got another observation to add to this. I normally use the Legacy version because I've found it to be most stable, but I've never really looked into why that is.

Yesterday I started off using the Stable version (1.26.6.12) to see how it would go. It worked well at first, then at one point I left my avatar idle in an enclosed room in a quiet region. After about 30 minutes the viewer popped up the low memory warning, saying I was about to crash. The message says it's resetting my camera but I had not been camming arround, I was literally staring at a wall for 30 minutes as I'd been afk.

Memory usage in the viewer showed as 100% (4096MB). Textures around me were cycling very rapidly, including my avatar's baked textures. According to the debug texture console there were about a dozen textures loading over and over.

I waited a while more and it didn't crash. I tried to force it to crash by teleporting around a bit, but that didn't work, so I did finally log out. (I have on prior occasions had the Stable version crash after receiving the low memory warning, which is why I stopped using it.)

Here are all the display_stats: MEMORY messages from the log for this sesson:(full log attached below)

This is two wierd things: First the warning of impending crash happened when memory was less than half used according to the log, while the viewer was reporting the used memory at 100%. Second, the log shows that memory just goes up and up and up seemingly for no reason at all.

Up until the warning, I had spent the entire time in a relatively quiet region. From 2013-02-27T20:49:27Z till about 2013-02-27T21:24:28Z I was motionless in an enclosed workshop under water, draw distance 64m, with very little in 'view' and no other avatars around. After that, I tried to force a crash by teleporting a few times and visiting a crowded area.

By contrast, using the legacy viewer, I can stay logged in for hours and hours (I've had 16 hour sessions without incident) and looking at the log of my most-recent legacy session, the display_stats: MEMORY message shows what I'd call a normal fluctuating usage - it goes up and down through the session, and does not seem to exceed about 700MB. (in the viewer itself the memory indicator tends to hover around 50% to 60%, aka around 2000-2100MB).

So I have two questions from all this:

1, The display_stats: MEMORY message in the log does not correspond with the memory bar / warnings (in both legacy and stable) in the viewer - so are the log messages correct, or is the display in the viewer correct?

2, There seems to be an issue in the Stable branch (but not the Legacy branch) where memory is continually gobbled up. Is this something we can try and track down and fix? I would love to be able to help with testing or providing logs etc., I'm not that experienced in c++ or mac programming, but I am a programmer and not shy about poking at source code or compiling & testing patches etc.

Thank you Henri and Katherine!

As I explained above, the memory check is not reliable for MacOS-X builds, due to the impossibility to force-release the "freed" memory back to the OS and/or to check for the "freed" (but not released back to the OS) memory available in the program heap. Simply disable the memory safety checks from the Advanced -> Memory menu.