[infinispan-dev] Adaptive marshaller buffer sizes - ISPN-1102

[Sanne Grinovero]

2011/6/10 Manik Surtani <manik at jboss.org>:
>
> On 10 Jun 2011, at 04:48, Tristan Tarrant wrote:
>
>> I don't know if I'm actually contributing something here or just creating noise.
>>
>> Are these buffers reused over time ? If not, from a GC point of view
>> it would be better then not to reduce the size of the buffer just to
>> save a few bytes: it would mean throwing to GC a perfectly valid bit
>> of memory. Increasing the size is another matter.
>> If Infinispan is not reusing buffers, why isn't it ?
>
> Actually this is a good point.  We're looking at holding on to the buffer size in a thread-local, but actually creating a new buffer each time.
>
> Somewhere in this thread there was discussion of creating a buffer per thread (thread-local again) but was determined to be too much of a mem leak (and I agree with this).
>
> Maybe it makes sense to create a pool of buffers, to be shared?  It would certainly save on gc overhead.  But what about the cost of synchronizing access to this buffer pool?  Maybe allocating one large buffer and different threads making use of different ranges here?  Again, the sync could be pretty complex.  But concievably lots of benefits though.
>
> Thoughts and opinions?

If we go for the thread owned buffer, maybe when they're small enough,
I'd be inclined to like it, but nothing can be said without a very
good test.

As Bela already mentioned, I doubt any kind of pool shared across
threads would be
helpful: if we keep the buffers for a very short time they won't leave
the new zone, and there's hardly any gc overhead there, actually gc is
going to copy over again and again the memory regions we hold on to perform
memory compaction, so it's quite likely that allocating a new one each
time is quicker as we reuse the efficient Eden space.

So I'd work in a direction to prevent having to resize the buffer
multiple times: while it's always good to consider GC cost it doesn't
look like the primary concern here.
If we have to resize the buffer again and again during the same
serialization, we might end up consuming the eden space quicker, so it
would be nice to have a good approximation to reduce the frequency of
resizing operations.

Cheers,
Sanne

>
> Cheers
> Manik
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>