Flash Player is a language runtime. We process code written by other people and execute it. That code causes Flash Player to consume resources like memory, as required to execute the given application.
In this instance, Flash Player isn't leaking memory, it's using memory. Once the Flash Player process terminates, we release the memory in use, which will become available to the system again. If we never released the memory back to the system, that would be a leak.
ActionScript (the language that Flash content is developed in) is a garbage-collected language, which means that unused objects in the program's code will be periodically scanned for and culled. The garbage collection process is CPU intensive, so in games, you want to control when it happens. You're seeing lags in gameplay in Opera because garbage collection is happening more aggressively. My guess is that you'd see similar behavior in Chrome.
In the IE case, is it actually crashing, or is it showing the out of memory icon (grey circle with ! in the center)?
If it's actually crashing, a crash dump would be really helpful:
https://helpx.adobe.com/flash-player/kb/report-flash-player-crash.html
That said, in general, this is going to come down to a problem that the content developer needs to solve. It's not uncommon for modern Flash games to take 1-2GB or more. Most of that is caching various assets (textures, rendered objects, etc), and there's a direct trade-off between performance and memory usage, but writing games for the web platform in general is far less effiicient than writing a native game. There's a lot of overhead from the browser, and native games don't need to worry about security or the potential for loading malicious content.
In terms of the caching behavior, if you have to keep rebuilding objects because you're not caching them, then the game will require more CPU time, the moment when that additional CPU time is required might not be convenient (lots of other stuff is happening in real-time during gameplay), and ultimately, that means that performance will be bad. On the other hand (and this is where the content developer comes in), if you're not releasing objects that are no longer needed, they can't be garbage-collected, so memory usage will grow.
We do force garbage collection to happen periodically (thresholds are defined by the available resources on your system), but if the program allocates a really large block, we may not get a chance to proactively garbage collect, and will instead throw an out of memory abort and exit safely.
So, we release a performance profiling tool called Adobe Scout that would help the game developer understand what in their code is consuming large amounts of memory and/or CPU time, so that they can identify opportunities for optimization. That's really the first step that needs to be taken with any complex application like a game. If, during that exercise, the developer identifies a language-level problem that requires a generic fix, they'll be able to provide us with actionable detail on what that granular issue might be; however, it's unlikely that will be the outcome.
As an end-user, your options are fairly limited. Close all of the other applications on the machine and run the game in a single open tab to maximize available resources, experiment with and choose the browser that works the best for you -- IE, Firefox and Chrome/Opera use significantly different variants of the Flash Player plugin, so you might find relief (although in general, memory allocation is in common code, so they should behave consistently under identical conditions), or you can add additional RAM to the machine and use a 64-bit operating system and browser to maximize the amount of RAM actually available to the browser and plugin processes.
Hope that helps.
3
Replies
AdChoices