Memory Leak Fixed, CyanogenMod 7 update to Android 2.3.5 r1

Recently Android 2.3.5 r1 was released, update 4G issue and NFC features for Nexus S. Some other updates does not be mentioned, one important thing is the fix to the Memory Leak issue.

As Milestone A853 has only 256MB memory, people who use this phone like me is suffering the low memory environment after updated to CyanogenMod 7 (Android 2.3 based rom), the system use more memory than the Froyo (Android 2.2), and that is unusual, do a research to the memory issue and some reports points to the display component, it is the Surfaceflinger has some bug, that make the memory leaking in some conditions.

To get more memory in Milestone A853 with CyanogenMod 7, developers have try some workaround, I rather to say it is much better than the first CM 7 rom, but the free memory still a little low. CyanogenMod 7 updated to Android 2.3.5 r1 yesterday, Hopefully the new fixs to the Surfaceflinger will bring us more free memory to use.

What is Surfaceflinger function?
1) Layers (Surfaces) content refresh the screen
2) maintain the Zorder Layer sequence, and Layer to make the final cut output calculation.
3) to respond to Client requirements, create the Surface Layer with the client to establish a connection
4) Client requirements to receive, modify Layer Properties (output size, Alpha and other settings)

Fixs to Surfaceflinger
changes:
Fix a race that could cause GL commands to be executed from the wrong thread.
RefBase subclasses can now decide how they want to be destroyed.
Fix a race in SurfaceFlinger that could cause layers to be leaked forever.
Fix a race-condtion in SurfaceFlinger that could lead to a crash.

Fix a race in SurfaceFlinger that could cause layers to be leaked forever. The transaction flags were atomically read-and-cleared to determine if a transaction was needed, in the later case, mStateLock was taken to keep the current state still during the transaction. This left a small window open, where a layer could be removed after the transaction flags were checked but before the transaction was started holding the lock. In that situation eTraversalNeeded would be set but only seen during the next transaction cycle; however, because we’re handling this transaction (because of another flag) it will be commited, “loosing” the information about the layer being removed — so when the next transaction cycle due to eTraversalNeeded starts, it won’t notice that layers have been removed and won’t populated the ditchedLayers array.