0

My android app need a lot of arrays. To prevent GC, I started to use Javolution.arrayFactory.
But if I alloc memory in one thread calling like following. 

byte []buffer = ArrayFactory.BYTES_FACTORY.array(size);

And free it in another thread like following. 

ArrayFactory.BYTES_FACTORY.recycle(buffer);

Then It couse memory leak. I need library or just class which realize array's pool.

Sumit Singh
  • 15,743
  • 6
  • 59
  • 89
KoVadim
  • 707
  • 1
  • 7
  • 22
  • Why does that cause a memory leak? – obataku Aug 07 '12 at 06:54
  • Eclipse Memory Analizator says than fastmap holds it after recycling. – KoVadim Aug 07 '12 at 06:58
  • That is what object pooling generally does, yes. Perhaps they forgot to use a `WeakReference`? – obataku Aug 07 '12 at 07:01
  • Does arrayFactory needs WeakReference? – KoVadim Aug 07 '12 at 07:05
  • If you don't want to prevent the references from being garbage collected, yes, but that's generally something you want when pooling objects. – obataku Aug 07 '12 at 07:09
  • I don't want to rewrite Javolution Library. – KoVadim Aug 07 '12 at 07:13
  • My point is merely that it's not a memory leak and that it's an intentional side-effect of pooling hard references to your data. – obataku Aug 07 '12 at 07:14
  • I don't holds any references to this array. And Memory Analizator says, that it is FastMap. – KoVadim Aug 07 '12 at 07:19
  • 1
    I never accused you of directly holding a hard reference... it is the Javolution array pool that does. – obataku Aug 07 '12 at 07:25
  • 1
    My english is not so good and maybe I undersood you wrong. Do you know an analog of array factory? – KoVadim Aug 07 '12 at 07:33
  • 1
    Do not worry, friend; I did not mean to offend you. The "leak" is because the allocator purposefully does not release the objects. Are you using `HeapContext` or `ImmortalContext`? – obataku Aug 07 '12 at 07:37
  • No, I just use only to lines of code. You could see it in my question. – KoVadim Aug 07 '12 at 07:41
  • Okay, it appears the default allocator is `HeapContext.HeapAllocator`. Now, is the leak from `FastMap` or from `FastTable`? – obataku Aug 07 '12 at 07:46
  • Memory Analizator says, that it is FastMap – KoVadim Aug 07 '12 at 07:48
  • 2
    I suspect the leak is in [HeapContext](http://kenai.com/projects/javolution/sources/source-code-repository/content/Javolution/src/main/java/_templates/javolution/context/HeapContext.java), involving the `FastMap` underlying `FACTORY_TO_ALLOCATOR`. Each `HeapAllocator` then maintains a `FastTable` of every object released through it, which includes the arrays released via `ArrayFactory.release`. – obataku Aug 07 '12 at 07:56
  • 2
    I just add `PoolContext.enter();` and `PoolContext.exit();` for my threads and now my app can work more than 10 minutes. 10tx. – KoVadim Aug 07 '12 at 08:33

1 Answers1

1

Instead of allocating lots of byte[] there are usually ways of reusing them rather than dynamically recycling them.

e.g. say you have a Socket handler object and it has a byte[]. You can create byte[] once and keep this for the life of the connection.

You can have a ByteBuffer which is split in multiple places to create multiple buffers using the same byte array.

Or you can store the data using structures you design such as off heap memory (I suspect this works better for the JVM than it does for Android)

I used to recycle a lot of byte[] but in time found ways on different projects to replace all of them with pre-allocated or long lived buffers and this had much lower CPU overhead.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130