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 Instructions:

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

Background:

This is the most impacting memory leak fix.The system architecture starting on BB6 devices is such that there’s a Native WebKit process running providing content rendering services and a JavaScript engine via a BrowserField java class used by WebWorks.Starting in BB6 an IPC mechanism was created to allow communications back and forth between the Native WebKit process and the Java runtime for BrowserField.In this IPC mechanism a method was designed to allow access to Native WebKit DOM elements from Java.This involved a lot of complicated logic and object shadowing on both sides of the IPC channel that I won’t get into.

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:

Focus Based Navigation mode (it traversed the DOM from Java looking for focusable items).Even if you don’t have any focusable items, it still checks via the DOM.

Any JavaScript API that provided a callback function.Since a “function” resides on the DOM, having a handle to that function in Java in order to make a callback is accessing the DOM

Symptoms:

The different common symptoms that would be seen by this issue are:

Open and close your application multiple times and eventually you would run out of memory

To get memory back you needed to do a battery pull

Browse to multiple URL’s in your WebWorks application and then eventually you would run out of memory

The less physical memory the device has (depending on your model number) the more often the problem would be encountered

Solution Used:

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:

In general you can make your application more memory efficient by using an AJAX style of development much like hotmail or gmail by having a single page and loading in content dynamically via AJAX. This makes it so that the most memory intensive parts of web pages are avoided.Namely tearing down and recreating the DOM and JavaScript engine on page loads when the URL of the page changes.

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

Background:

The BlackBerry browser has some native blackberry.* objects that are used in JavaScript.These are blackberry.location, blackberry.network and blackberry.launch.Some of these are older artifacts for backwards compatibility before the introduction of Google Gears or HTML5 support.As you know, our WebWorks APIs all also start with blackberry.* in order to keep consistency with the other JavaScript objects that came before us.But this is where an underlying issue was found.

Any WebWorks API that followed the pattern blackberry.x was fine.But any API that followed the pattern blackberry.x.y was not being released by the Browser’s JavaScript engine.The reason for this is that the Browser creates its own blackberry object.What was happening was that when we added an API that used the pattern blackberry.x.y it was actually appending the object to the existing Browser’s blackberry object.Thus it was confusing the number of reference counts and never getting released in memory.

Symptoms:

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

Solution Used:

We now run JavaScript before any page loads to actually delete the “blackberry” object from the Browser and hold it in a temporary variable.We then load our WebWorks “blackberry” object and append the browser’s “blackberry” object members to our WebWorks instance.This ensures that our WebWorks APIs are not appended to the object handle held by the Browser and thus memory gets all cleaned up on every page change and exit of the application.

Memory Leak Fix Included in Previous v2.1.1

Background:

Similar to Memory Leak Fix #1, there was an issue with JavaScript extensions that had a handle to objects that were part of the main WebWorks application. Some examples of these were handles to BrowserField, the Screen object among others.What was happening was that when these APIs were being used with the JavaScript engine, the reference count to the objects were never being released because of their handle to these Java objects.

Symptoms:

The symptoms here were much like those found in Memory Leak Fix #2

Solution Used:

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.

We have also made further changes in v2.2 where we are moving our APIs over one-by-one to an architecture where we no longer need to use “Scriptable” Java objects.Instead we are using the same approach found in WebWorks for Tablet OS and the Ripple Emulator by layering our procedural JavaScript API over top of an AJAX style RESTful service.