RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

[Martin Buchholz]

Peter,

You keep impressing me with your development speed!
Looking at ObjectPool ... looking pretty good

keepalivetime should be > 0.  (also very small keepalive times are a
bad idea, but what's "very small"?)
I'm thinking one second for ZipFile keep alive time.  Thread pools
have 60 seconds.

Maybe we need a Consumer<T> resetter in addition to a releaser.

I'm opposed to creating a new STPE.  jdk 9 CompletableFuture comes
with a hidden thread scheduler, so the idea is to use delayedExecutor
to share that one thread for all common scheduling.

I think you want to call pop poll instead, since it can return null?

We want a purger task to be created at most once per keep alive
period, and never after the pool is quiescent.  Not sure if we're
there yet.

On Fri, May 20, 2016 at 7:31 AM, Peter Levart <peter.levart at gmail.com> wrote:
> Hi Martin,
>
>
>
> On 05/20/2016 02:51 AM, Martin Buchholz wrote:
>>
>> On Thu, May 19, 2016 at 7:29 AM, Peter Levart <peter.levart at gmail.com>
>> wrote:
>>>
>>> So Martin, what do you think?
>>
>> I studied your code and we are fundamentally in agreement!
>> ... Except for need for periodic cleanup of the cache...
>> Maybe we should do
>> CompletableFuture.runAsync(purgeCache,
>> CompletableFuture.delayedExecutor(1, SECONDS))
>> as a periodic task while cache is non-empty instead of my strategy of
>> relying on a weak reference.
>>
>> Purging a cache on quiescence in the optimal way seems to be a hard
>> problem.
>> Time to write ObjectPool<T> (as many others have done before us)?
>>
>> ObjectPool(Supplier<T> factory,  Consumer<T> releaser, maxCacheSize,
>> keepAliveTime)
>>
>> Except this time we'll do it right!  With jdk9 machinery!
>
>
> Something like the following?
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile_Inflater.cleanup/webrev.02/
>
> I still must debug the cause of OutOfMemoryError in
> java/util/zip/ZipFile/TestZipFile.java.
>
> Regards, Peter
>