I've been working on a library, and have run into a problem with application memory.
I created a class called FileManager which allows the user to call a function called loadNewFiles - this function opens a multi-file selection dialog and stores each FileReferenceList in a vector. I can call the removeList function at any time and remove that list and clear any memory and listeners allocated to that list, so all's well there.
I created another class called UploadManager, which takes an array of FileReference objects and uploads them to a URL via the uploadFiles function. The memory leak appears to be here. When you call this function, it adds the appropriate event listeners and calls the upload function. If the upload fails or the upload is finished, it removes the listeners and clears the vector it has been waiting in.
after the upload manager finishes uploading the files, I call the removeFiles function in FileManager (which, remember, worked perfectly before) and... Nothing happens. The files are removed from both vectors, the listeners are removed from both files, but the memory stays allocated. This obviously has potential to cause problems along the road, as there's no limit to the number of files, uploads, etc. available through the library.
classes:
FileManager
UploadManager
Implementation
It sounds like from your example that the UploadManager still has a reference to the files either from the vector passed into uploadFiles, or some other object in the game still has a reference.
Also note, System.gc() only works on the debug version of the flash player.
So you can't depend on it for an architectural design choice. It works for unit testing memory intensive operations when you need to see the consumption of ActionScript memory "on demand".
In a production product, the ActionScript Virtual Machine is very active in detecting when and where to garbage collect. Most would say it happens right when you don't want it to.
Try profiling the application and looking at the "cumulative instances" vs. "instances", as well as the "cumulative memory" vs. "memory" for the objects in question (i.e. FileReference).
You can force garbage collection during runtime in the Profile View to get a realistic idea of how much memory is actually freed when garbage collection takes place in the Release version.
Related
I'm working with an STM32F469 chip with a Micron MT25Q Quad_SPI Flash. To program the Flash, there needs to be an external loader program developed. That's all working, but the problem is that verification of the QSPI Flash is extremely slow.
Looking in the log file, it shows that the Flash is being programmed in 150K byte blocks. However, the verification is being done in 1K byte blocks. In addition, the chip is re-initialized before each block check. I've tried this with both through STM32cubeIDE and in STM32cubeProgrammer directly.
The external programmer program include the correct chip configuration information and specifies a 64K page size. I don't see how to get the programmer to use a larger block size. It looks like it understands what part of the SRAM is used and is using the balance of the 256K in the on-board SRAM for programming the QSPI Flash. It could use the same size for reading the data back or use the Verify() function in the external loader. It's calling Read() and then checking the data itself.
Any thought or hints?
Let me add some observations on creating a new external loader. The first observation is "Don't." If you can pick a supported external chip and pin it out to use an existing loader, then do that. STM provides just 4 example programs but they must have 50 external loaders. If the hardware design copies the schematic for a demo board that has an external loader, you should be fine and avoid doing the development work.
The external loader is not a complete executable. It provides a set of functions to do basic operations like Init(), Erase(), Read() and Write(). The trick is that there is no main() and no start-up code is run when the program starts.
The external loader is an ELF file, renamed to "*.stldr". The programming tool looks into the debug information to find the location of the functions. It then sets the registers to provide the parameters, the PC to run the function, and then let's it run. There's some super-clever work going on to make this work. The programmer looks at the returned value (R0) to see if things pass or not. It can also figure out if the function has crashed the core or otherwise timed-out.
What makes writing the external super fun is that the debugger is running the program so there's no debugger available to see what the code is doing. I settled on outputting errors, and encoded information, on the return() from the called functions to give hints as to what was happening.
The external loader isn't a "full" program. Without the startup code, lots of on-chip stuff isn't set up and some just isn't going to work. At least I couldn't figure it out. I'm not sure if it wasn't configured right or the debugger was blocking its use. Looking at the example external loaders, they are written in a very simple way and do not call the HAL or use interrupts. You'll need to provide core set-up functions to configure the clock chains. That Hal_Delay() method will never return as the timers and/or interrupts aren't working. I could never make them work and suspect the NVIC was somehow being disabled. I ended up replacing the HAL_delay() function with a for loop that spun based on core clock rate and a the instruction cycles per loop.
The app note suggests developing a stand-alone program to debug the basic capabilities. That's a good idea but a challenge. Prior to starting the external loader, I had the QSPI doing the needed operations but from a C++ application calling the HAL. Creating an external loader from that was a long exercise in stripping out and replacing functionality. A hint is that the examples are written at a register level. I'm not that good to deal directly with the QuadSPI peripheral and the chip's instruction set at the same time.
The normal start-up of a program is eliminated. Everything that's done before the main() is called (E.g., in startup_stm32f469nihx.s) is up to you. This includes setting the clock chains to boost the core clock and get the peripheral buses working. The program runs in the on-chip SRAM so any initialized variables are loaded correctly. There's no moving data needed but the stack and uninitialized data areas could/should still be zeroed.
I hope this helps someone!
Today I've faced the same issue.
I was able to improve the Verify speed with two simple steps, but Verify still much slower than programming and this is strange...
If anyone find a way to change the 1KB block read of STM32CubeProgrammer I would like to know =).
Follow the changes I made to improve a bit the performance.
Add a kind of lock in the Init Function to avoid multiple initializations. This was the most significant change because I'am checking the Flash ID in my initialization proccess. Other aproachs could be safer but this simple code snippet worked to me.
int Init(void)
{
static uint32_t lock;
if(lock != 0x43213CA5)
{
lock = 0x43213CA5;
/* Init procedure goes here */
}
return(1);
}
Cache a page instead of reading the external memory for each call. This will help more if your external memory page read has too much overhead, otherwise this idea won't give relevant results.
My application connects to a SignalR-hub, and it receives about 15 json-files per minute. For every json-file with a geolocation, a marker gets placed on a sphere in the 3D WebGL-scene, and gets stored in an object {}. When the objectlist reaches 100 items, the application deletes the first item in the objectlist, and deletes the corresponding marker from the scene.
But still, there is a huge memory leak, and when I hit about 200 events, the application crash.
Are the json-files being stored somewhere, and are causing the memory leak?
Though this is not the solution, but I will suggest you to use Ants Profiler to see if there is any memory leak issues in your application.
I will suggest you to derefernce all the listitem in the generic list after it is no use. This is the major cause of memory leaking.
Beware of concatenating strings, use stringbuilder as much as possible.
I am working on the same issue. I had no memory leaks before implementing signalr and now have a fairly significant one. I can disable the signalr in my app and the leak goes away. I'm on version 2.2.0 of signalr (the most current version from Nuget. The only thing that could be hanging up in memory from my code point of view is the event handler. At least that's the only thing I'm creating on the client side.
I'm building an Air application, which, due to the workflow of the animators, needs to load a lot of external swf files.
I load them all via FileStream / Loader Objects at the boot process and then store them in an object for further use.
The instant they get loaded, I use a gotoAndStop(1) command to make them stop looping (the original files have no scripts whatsoever).
After the load process I can see the system memory go slowly but consistently up.
When I manually invoke Garbage Collection with the System.gc() command,
the memory gets cleared again.
If I let the application run for hours it seems the Garbage Collector does not run.
Any ideas what the problem might be? Or should I just forget about it and just occasionally run System.gc() manually?
Thanks a lot!
The Garbage Collector will only run when it needs to, so it is entierly possible that it would go a very long time before running (especially if you have a lot of RAM available).
The important thing is the memory is cleared when it is run. This tells me that you don't have a leak, as it can be cleared up.
Also, how are you measuring the system memory? If you are doing it through Task Manager those numbers aren't really to be relied upon.
I recommend Process Explorer . Monitor the 'Private Bytes' column instead.
Is flash smart enough to "hide" PIXELS that aren't on the stage, in order to decrease memory usage? Or I must do it manually, if it decreases the memory usage at all?
Flash does not render objects that aren't on the stage (as per http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e3e.html).
However I think you may be mixing up two different issues.
One issue is CPU/GPU performance - for this there is no need to worry about off-stage objects as Flash does not waste time rendering display objects that are outside the stage bounds.
The other issue is memory usage. Every object that you create takes up some memory whether or not it is visible on the screen. Flash has a garbage collector that will periodically dispose of unused objects, however "unused objects" means an object that isn't referenced by any other object so if you are having memory issues you will have to manually clean up objects by removing event listeners, nulling references etc.
There's nothing like that available to decrease memory usage. If it's visible on your monitor, it needs to be rendered by Flash and have a place in memory storing the pixel colour.
Although Flash is very fast these days, especially with hardware acceleration. So you shouldn't worry too much about performance, there's a lot of bang for your virtual buck with AS3. I'd bet all of my virtual dollars on it.
Flash will store all bitmaps, movieclips in fact all objects in memory as expected. If you have a large bitmap which is larger than the stage, it still occupies memory regardless of you only showing a portion of it.
If you have multiple bitmaps or movieclips that may move off the stage and no part of them are visible, then the only way to recover memory is to make sure the object is dereferenced and set to null.
myMovieClip = null;
Prior to setting to null you would also have to make sure that nothing else is referencing the object, for example it can't be stored in an array or have any event listeners attached to it so therefore:
myMovieClip.removeEventListener(Event.WHATEVER, eventHandler);
For bitmapdata objects you would need to call dispose first before setting to null:
myBitmapdata.dispose();
myBitmapdata = null;
This then allows the GC to recover memory when it chooses, unless you are using AIR which means you may request a gc call yourself:
System.gc();
If you are developing in Flash Builder, the best practice is to regularly profile your application and hit the button to force a gc call. You can then see which objects are persisting in memory and locate the references which are causing the memory leaks.
Here is the case: I have created a test application which simply loops to load a same url for 1000 times by using HTMLLoader class from Adobe AIR. What I found is that the memory of this app keeps rising.
So is this expected? I mean it's the same URL although it get loaded for 1000 times. Does the AVM create 1000 objects behind the scene?
It would depend on how many of the objects you keep references to, and on how many of them are available for garbage collection. It can also depend on whether or not the player decides to trigger a mark-sweep of the garbage collector (which sometimes depends on external issues like how much total memory is available from the OS).
What if you used the component and just set the url parameter to "" followed by the url again in a callLater?
Pretty sure memory wouldn't build up that way.