Inflater/Deflater improvements

[Xueming Shen]

Clemens,

If I read the code correctly, what your patch is trying to address is to 
save the redundant
memory allocate/free operations at native level, if the input byte 
buffer is bigger than the
"stride" size? In other words, it does not really reduce any memory copy 
but reduce the
trip numbers of java<->native. Am I reading the code correctly? I will 
take a second
round of read later...

Couple months ago I also tried some experimental code on the zip 
package, then I got
detoured to something else:-( maybe it's the time to revisit it, 
together with your code.

What I was trying to do is to pull as much as the native stuff to the 
java level...and to
use the ByteBuffer instead of byte[], in which we might get the chance 
to really reduce
the copy of data, if the input ByteBuffer is a direct bytebuffer...there 
was a nasty bug
somewhere in the code I did not have time to figure out back then tough. 
The snapshot
of part of the code is at

http://cr.openjdk.java.net/~sherman/deflater2/webrev/

Just tried to share some idea for discussion.

Sherman


Clemens Eisserer wrote:
> Hi Martin,
>
>   
>> I think many people will be interested in performance improvements
>> in Inflater/Deflater.  I may have time to help review.
>>
>> Caution: This is an area where it can be very tricky to make
>> improvements.  Past efforts have optimized one usage pattern
>> at the cost of pessimizing another.
>>     
>
> I can't imagine a use-case where this version would perform a lot
> worse, however a clear downside is for sure the larger amount of
> C-heap consumed.
> However the current implementation is so bad, it should be worth it ;)
> I am more afraid of behaviour change in corner cases ...
>
> Thanks, Clemens
>