From dev-return-60012-archive-asf-public=cust-asf.ponee.io@pdfbox.apache.org Wed Dec 5 18:41:09 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 4D06818062B for ; Wed, 5 Dec 2018 18:41:09 +0100 (CET) Received: (qmail 33642 invoked by uid 500); 5 Dec 2018 17:41:03 -0000 Mailing-List: contact dev-help@pdfbox.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@pdfbox.apache.org Delivered-To: mailing list dev@pdfbox.apache.org Received: (qmail 33548 invoked by uid 99); 5 Dec 2018 17:41:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Dec 2018 17:41:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 11A51C20C0 for ; Wed, 5 Dec 2018 17:41:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -110.301 X-Spam-Level: X-Spam-Status: No, score=-110.301 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id pnPZxpaN18L9 for ; Wed, 5 Dec 2018 17:41:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 44DE65F588 for ; Wed, 5 Dec 2018 17:41:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 7352EE00E1 for ; Wed, 5 Dec 2018 17:41:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 2EECB2776F for ; Wed, 5 Dec 2018 17:41:00 +0000 (UTC) Date: Wed, 5 Dec 2018 17:41:00 +0000 (UTC) From: "Ben Manes (JIRA)" To: dev@pdfbox.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PDFBOX-4396) Memory leak due to soft reference caching MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/PDFBOX-4396?page=3Dcom.atlassia= n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D167= 10391#comment-16710391 ]=20 Ben Manes commented on PDFBOX-4396: ----------------------------------- Yes, I agree caching makes sense in general. My case is extreme due to N th= ousand page documents from scanned paperwork, taking 3-13 seconds per page = for PdfBox to render into an image.=C2=A0While I'd appreciate better perfor= mance, that's only if it retains stability. I agree weak references are not a fit here and did not intend to imply othe= rwise. My point is that the cache=C2=A0held=C2=A0430k HashMap.Entry objects= where many might have null values. This can be pruned by using a Reference= Queue, something like the below code. Soft references are problematic and typically chosen because a developer do= esn't know a good size. Instead of a strict limit, the decision is left to = the JVM. The references are in a global cache, so an inexpensive cache=C2= =A0might=C2=A0cause a critical one to be flushed. The collection behavior i= s GC specific and the penalty is placed in the critical section of the paus= e time.=C2=A0Many=C2=A0collectors=C2=A0are not aggressive, which increases = hit rates but the memory pressure causes full GCs in short intervals. A col= lector that is aggressive makes the cache ineffective. If there is a way to estimate the size, then a bounded cache is preferrable= . This avoids the above problems with the potential of higher hit rates, as= LRU can easily to polluted. See for example [Caffeine's hit rates|https://= github.com/ben-manes/caffeine/wiki/Efficiency]=C2=A0by taking frequency int= o account, or our new=C2=A0[research paper|https://drive.google.com/file/d/= 1CT2ASkfuG9qVya9Sn8ZUCZjrFSSyjRA_/view?usp=3Dsharing]=C2=A0for an adapting = policy. If the number of entries or weight of an entry can be estimated the= n a strong reference cache is typically=C2=A0the preferred approach. If tha= t is problematic, usually one has=C2=A0to investigate off-heap caching. So far resetting the=C2=A0ResourceCache has been effective. I could try amo= rtizing that, e.g.=C2=A0reseting it every N pages, to gain a little better = reuse as you=C2=A0indicated. If I had a better sense of the=C2=A0objects be= ing cached, I would switch to a Caffeine-backed version for an explicit bou= nd. Can the=C2=A0ResourceCache=C2=A0be shared across documents or are=C2=A0= the entries=C2=A0document specific? {code:java} final ReferenceQueue queue; final Map> cache; public void put(K key, V value) { prune(); cache.put(key, new SoftValueReference<>(key, value, queue)); } public V get(K key) { prune(); var ref =3D cache.get(key); return (ref =3D=3D null) ? null : ref.get(); } private void prune() { Reference ref; while ((ref =3D queue.poll()) !=3D null) { var reference =3D (SoftValueReference) ref; cache.remove(ref.getKey()); } } static final class SoftValueReference extends SoftReference { private final K key; public SoftValueReference(K key, V value, ReferenceQueue queue) { super(value, queue); this.key =3D key; } public Object getKey() { return key; } } {code} > Memory leak due to soft reference caching > ----------------------------------------- > > Key: PDFBOX-4396 > URL: https://issues.apache.org/jira/browse/PDFBOX-4396 > Project: PDFBox > Issue Type: Bug > Affects Versions: 2.0.12 > Environment: JDK10; G1 > Reporter: Ben Manes > Priority: Major > Attachments: memory leak 2.png, memory leak.png > > > In a heap dump, it appears that=C2=A0DefaultResourceCache is retaining 5.= 3 GB of memory due to buffered images (via=C2=A0PDImageXObject).=C2=A0I=C2= =A0suspect=C2=A0that G1 is not collecting soft references across all region= s before it out-of-memory errors. > In PDFBOX-4389, I discovered very slow PDDocument#load times due to a JDK= 10 I/O bug. Previously I was loading the document to render each page, but = this took 1.5 minutes. To work around that=C2=A0bug I reused the document i= nstance across pages. This seems to have fail because the pages were cached= and not=C2=A0cleared by the GC. > The=C2=A0DefaultResourceCache does not prune its cache entries when the s= oft references are collected.=C2=A0Like WeakHashMap, it should use=C2=A0a R= eferenceQueue, poll it on every access, and prune accordingly. > Thankfully=C2=A0PDDocument#setResourceCache exists. For now I am going to= reset the cache to a new instance after a page has been rendered.=C2=A0The= entries should no longer be reachable and be GC'd more aggressively. If th= at doesn't work, I'll either replace the cache (e.g. with Caffeine) or disa= ble it by setting the instance to null. > I think the desired fix is to prune the=C2=A0DefaultResourceCache and, id= eally, reconsider usage of soft references (as they tend to be poor in prac= tice).=C2=A0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org For additional commands, e-mail: dev-help@pdfbox.apache.org