Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Killing Me Softly

Killing Me Softly

SoftReference is very common for memory caching.

But Android Developers (http://developer.android.com/reference/java/lang/ref/SoftReference.html) says it is not efficient for such use case.

Then, how SoftReference works on Android? This talk will show how it works and when to use it.

Reference:
- SoftReference | Android Developers
http://developer.android.com/reference/java/lang/ref/SoftReference.html
- WeakReference | Android Developers
http://developer.android.com/reference/java/lang/ref/WeakReference.html
- MarkSweap.cpp
https://android.googlesource.com/platform/dalvik.git/+/android-4.4.4_r2.0.1/vm/alloc/MarkSweep.cpp

Hiroshi Kurokawa

June 16, 2015
Tweet

More Decks by Hiroshi Kurokawa

Other Decks in Technology

Transcript

  1. SoftReference Story Garbage Collection (GC) With GC, a programmer is

    neither in charge of manually allocating physical memory nor freeing this memory up by himself. An object to which there exists at least one path from the root set is called strongly-reachable. A reference that is cleared when its referent is not strongly reachable and there is memory pressure. A reference that may be cleared as soon as is known to be weakly-reachable (not strongly/softly reachable). Soft Reference Weak Reference
  2. Why SoftReference is important? SoftReference has been used for memory

    caching S e t < S o f t R e f e r e n c e < B i t m a p > > m R e u s a b l e B i t m a p s ; p r i v a t e L r u C a c h e < S t r i n g , B i t m a p D r a w a b l e > m M e m o r y C a c h e ; / / I f y o u ' r e r u n n i n g o n H o n e y c o m b o r n e w e r , c r e a t e a / / s y n c h r o n i z e d H a s h S e t o f r e f e r e n c e s t o r e u s a b l e b i t m a p s . i f ( U t i l s . h a s H o n e y c o m b ( ) ) { m R e u s a b l e B i t m a p s = C o l l e c t i o n s . s y n c h r o n i z e d S e t ( n e w H a s h S e t < S o f t R e f e r e n c e < B i t m a p > > ( ) ) ; } from Managing Bitmap Memory | Android Developers However...
  3. Is SoftReference ineffcient? Avoid Soft References for Caching In practice,

    soft references are inefficient for caching. ... Most applications should use an android.util.LruCache instead of soft references. from SoftReference | Android Developers
  4. When is a soft-reachable object killed? @wasabeef_jp @hotchemi うーん。それがよく分からないんですよ ね。Android

    Developers には、2.3 以降でアグレッシブになったとい う記述がありますし、感覚的にはソフト参照でも、GC が走るとすぐ に解放される気がするのですが、どうなんでしょう。 2015年5月30日 16:10 5月30日 wasabeef_jp ​ @wasabeef_jp @hydrakecat @hotchemi 4.4以降で、即時開放されるってのは、弱 の話ですよね Hiroshi Kurokawa ​ @hydrakecat フォローする SoftReference: A reference that is cleared when its referent is not strongly reachable and there is memory pressure.
  5. The actual (Oracle Java) On Oracle Java 7, the behaviour

    is as expected. The soft-reachable objects are garbage-collected only when there is not enough actual available memory. How about Android? / / A l l o c a t e 1 0 0 M B , I n c r e a s e t h e h e a p s i z e H e a p S i z e : 5 5 9 . 0 M B , M a x H e a p S i z e : 8 3 4 . 0 M B , F r e e : 5 8 . 4 M B / / A l l o c a t e 1 0 0 M B , I n c r e a s e t h e h e a p s i z e H e a p S i z e : 6 4 2 . 5 M B , M a x H e a p S i z e : 8 3 4 . 0 M B , F r e e : 4 1 . 9 M B / / A l l o c a t e 1 0 0 M B , T r y t o i n c r e a s e t h e h e a p s i z e b u t r e a c h t h e l i m i t / / T h e n , s o f t r e f e r e n c e s a r e r e l e a s e d H e a p S i z e : 1 6 9 . 0 M B , M a x H e a p S i z e : 8 3 4 . 0 M B , F r e e : 6 8 . 1 M B
  6. Observations Note: It is not fully tested on various versions

    and devices. It is just for your reference. API Level < 9 The half of the soft-reachable objects seems to be freed when normal GC (GC_FOR_ALLOC or GC_EXPLICIT) runs. Even when normal GC runs multiple times, the other half seems remain until GC_BEFOR_OOM runs. 9 ≤ API Level < 21 Every time normal GC runs, the half of the soft-reachable objects are freed. When GC_BEFOR_OOM runs, all of them are freed. GC_FOR_ALLOC sometimes runs even if there is enough heap memory (maybe due to fragmentation). Thus, the number of soft-reachable objects is rapidly decreased to 1. 21 ≤ API Level When heap memory size is increased, sometimes all of the soft-reachable objects are freed. It is often but not usual.
  7. Why half? https://android.googlesource.com/platform/dalvik.git/+/android- 4.4.4_r2.0.1/vm/alloc/MarkSweep.cpp 6 6 8 s t a

    t i c v o i d p r e s e r v e S o m e S o f t R e f e r e n c e s ( O b j e c t * * l i s t ) . . . 6 8 2 b o o l m a r k e d = i s M a r k e d ( r e f e r e n t , c t x ) ; 6 8 3 i f ( ! m a r k e d & & ( ( + + c o u n t e r ) & 1 ) ) { 6 8 4 / * R e f e r e n t i s w h i t e a n d b i a s e d t o w a r d s a v i n g , m a r k i t . * / 6 8 5 m a r k O b j e c t ( r e f e r e n t , c t x ) ; 6 8 6 m a r k e d = t r u e ; 6 8 7 }
  8. Conclusion Should not use SoftReference for casual memory caching. Use

    LruCache instead. If you want to free an object as soon as it is not strong- reachable, use WeakReference. GC on Lollipop (ART) is rather efficient ὠ