09-28-2011 09:12 AM - edited 09-28-2011 09:14 AM
Pre-Release Software for Smartphones
Hi everyone. We have made available a very EARLY pre-release version of the WebWorks SDK for Smartphones v2.2 to allow the community to test out the memory leak fixes to ensure they resolve the problems found with earlier WebWorks SDK releases that had memory issues on BlackBerry 6.0+ WebKit enabled devices.
THE SINGLE PURPOSE OF THIS PRE-RELEASE IS FOR THOSE EXPERIENCING MEMORY ISSUES TO VERIFY THAT THE NEW FIXES SOLVE THEIR ISSUES
Installation will require you to uninstall your previous version of the WebWorks SDK in order to use this new pre-release version. The RTM (Release To Market) installer for v2.2 will allow you to perform a side-by-side installation which will no longer require you to uninstall your previous version. But for this version you will have to replace your existing install.
THIS SOFTWARE HAS ONLY BEEN TESTED FOR MEMORY LEAK FIXES. ALL OTHER FEATURES HAVE ONLY BEEN SMOKE TESTED FOR TOP LEVEL FUNCTIONALITY. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Memory Leak Fix #1
The root cause of this leak, was that the Java and Native sides of the IPC bridge were getting out of sync. When the root URL of the document changed, the Native side of the IPC channel did not release the memory of the document because it believed that the Java side still had a reference pointer for it. Thus, when you changed from URL to URL the device would eventually run out of memory. The bigger the DOM and the more images/resources loaded into it, the quicker you would run out of memory.
Basically Java side is not aware of the Native memory footprint. GC kicks in when memory is low. Shadow objects take almost no memory in Java, so the runtime does not think it needs to spend the time to GC it. These tiny non GC’d shadow objects link to large objects on the native side. As new documents are loaded or the DOM changes, the device runs out of memory on the native portion.
NOTE: THIS DOES NOT AFFECT THE BROWSER, JUST BROWSER FIELD USED BY APPLICATIONS
Parts of WebWorks that access the DOM were/are:
The different common symptoms that would be seen by this issue are:
Through our investigation there wasn’t anything that could be done to actually “stop” the leak from happening. This would be something that would require an OS upgrade which doesn’t help any developer out there providing software to the community who have existing devices. However, we did find that if we requested a Garbage Collection from the running WebWorks app (not a system level one) that it would actually trigger the clean-up of the Document DOM objects on the Native side of the IPC channel thus solving the problem of running out of memory.
What we do in the WebWorks application is listen for a low memory condition and when it is reached we “request” a Garbage Collection. The BlackBerry OS knows how to handle these requests and processes them if necessary. This is something that needs to be in place because Garbage Collections are expensive when it comes to performance.
We have tested various partner’s applications and the previous symptoms have now all been squashed.
What This Means Is:
When the device starts to run into a low memory condition a garbage collection will occur which will cause the hourglass to show up. On lower physical memory BB6 devices like the BlackBerry Style, or any 256MB BB6 device that was originally BB5 and has been upgraded to BB6, you will find that garbage collection happens frequently because low memory conditions are encountered more often.
What You Can Do In Your Application To Help Preserve Memory:
Using this best practice will also minimize the memory usage for any kind of garbage collection needs based on the solution we have put in place.
Memory Leak Fix #2
The symptoms were much like the Memory Leak Fix #1, but were not as impacting. They basically added to the issue of memory not being freed, but their impact footprint was much less
Memory Leak Fix Included in Previous v2.1.1
The symptoms here were much like those found in Memory Leak Fix #2
We went through all our APIs in v2.1.1 and changed any of these references to use “Weak References” to ensure that the reference count to these objects would not increment when we used them. By doing this the objects would then be freed on page change and application exit.