Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
  b=zrKE9sjcmky25znA+QoW9DwW41bEyZFyWhN0TP7cb6rHGjG5FVNiM9il63kowxMZ9Ky+aXNK6us05xjtTMcrZYpe/5CMrh1KaHQ0TR/nisOopF40ZSI5AuVl6dxRStZjlDXgmquUhCBf84ENoxJ8EFfurVulFKhtQaBkLKDpkrQ=;
Message-ID: <414465.95634.qm@web57008.mail.re3.yahoo.com>
Date: Sun, 12 Dec 2010 19:27:21 -0800 (PST)
From: "Balazs Attila-Mihaly \(Cd-MaN\)" <x_at_y_or_z@yahoo.com>
Reply-To: "Balazs Attila-Mihaly \(Cd-MaN\)" <x_at_y_or_z@yahoo.com>
Subject: [collections]
To: "dev@commons.apache.org" <dev@commons.apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1514470296-1292210841=:95634"

--0-1514470296-1292210841=:95634
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello everybody.=0A=0AI would like to know if there would be any interest o=
f including a "disk-backed map" into the commons-collections? The problem s=
tatement for it would be:=0A=0A- while we are moving to 64bit, it will stil=
l take a couple of years until all hardware is 64 bit and more importantly,=
 all software (or at least the OS + JVM running on it) are 64 bit. In the m=
eantime you can easily run out of memory space, even though you physically =
would have enough memory and you would accept some swapping (rather than th=
e process dying with OOM). I had such an issue with running PMD CPD on a la=
rger codebase (2+ million LOC).=0A=0AThe solution:=0A=0A- a Map which keeps=
 its keys in memory but writes the values to disk (to a temporary file, mar=
ked deleteOnExit). It also keeps WeakRefs to the values. When a request com=
es in for a value, it tries to satisfy it using the weakref, and if it fail=
s, it reads it back from the temporary file. This would be efficient for a =
mostly read-intensive application (it does not try to efficiently handle th=
e situations when there are many removes/updates to the file).=0A=0AWould y=
ou be interested in including this solution in the framework?=0A=0ABest reg=
ards (and happy holidays),=0AAttila=0A=0A=0A=0A      
--0-1514470296-1292210841=:95634--