RFR 9: 8165641 : Deprecate Object.finalize

[Hans Boehm]

It's not hard to add an API to tell the garbage collector to pretend that
you're holding onto those 18GB of additional memory when it decides whether
to collect, without actually actually holding onto all of that memory. I
personally think this is still worth doing, since PhantomReferences will
continue to have this issue.

But discussing this in terms of file descriptors is questionable, since
they should and usually can be managed explicitly. (In my experience, this
isn't true 100% of the time, but close. Counterexample: Some "rope"
(heavyweight string) implementations allow such a string to own a file
containing the actual representation. You don't really want the user to
explicitly manage memory for ropes/strings just in case it might contain a
file.)

To me, wrappers for C++ objects are a more interesting case.

On Tue, Mar 14, 2017 at 12:56 PM, Steven Schlansker <
stevenschlansker at gmail.com> wrote:

>
> > On Mar 14, 2017, at 12:25 PM, Timo Kinnunen <timo.kinnunen at gmail.com>
> wrote:
> >
> > Hi,
> >
> > Maybe rather than “an ugly waste of memory” which sounds somewhat
> negative, we could instead call it “an honestly assessed true resource
> cost”?
> >
>
> Yuck!  I'm imagining opening 32k file descriptors that represent sockets
> in e.g. a
> high performance asynchronous Jetty web server and finding that it consumes
> new long[65536] = 65536 * 8 bytes * 32768 ~= 18GB
>
> just in "fake garbage" to pressure out file descriptors.  Sure sounds
> negative to me!
>
>
> > Besides, this amount wouldn’t have to be set in stone. It could be
> easily increased or decreased in response to resource pressures. Lots of
> ergonomics options here. In fact you’d never need more memory for this than
> what the maximum amount is that’s available for new allocations. And it
> turns out you’ll always have that much memory available by definition, so
> really no memory would have to be wasted at all.
> >
> >
> >
> > Sent from Mail for Windows 10
> >
> > From: Andrew Haley
> > Sent: Tuesday, March 14, 2017 19:03
> > To: Timo Kinnunen; Hans Boehm; Uwe Schindler
> > Cc: core-libs-dev
> > Subject: Re: RFR 9: 8165641 : Deprecate Object.finalize
> >
> > On 14/03/17 14:01, Timo Kinnunen wrote:
> >
> >> File handles aren’t that scarce of a resource, really, at least on
> >> Windows.
> >
> > I've seen processes running out of file handles.  It is possible to
> > change the per-process limit.  And, of course, there is a lot of
> > hidden context in the kernel and device drivers.
> >
> >> On Windows threads are a lot scarcer resource than file handles, and
> >> I don’t recall anyone suggesting Java’s GC wasn’t suitable for
> >> managing that limited but crucially important resource.
> >
> > Java's GC isn't used for managing threads.
> >
> >> The question should then be, what makes threads so much easier to
> >> manage than file handles and how can we make file handles be more
> >> like threads?
> >
> > They're not.
> >
> >> Food for thought: threads need a big stack which means a lot of
> >> memory, but a file handle might be just 8 bytes which is hard to
> >> keep track of. So, change the storage of file handles to use slot-0
> >> of new long[65536];
> >
> > I did try that, and it does work, but it's an ugly waste of memory.
> >
> > Andrew.
> >
>
>