RFR 9: 8165641 : Deprecate Object.finalize
stevenschlansker at gmail.com
Tue Mar 14 19:56:54 UTC 2017
> On Mar 14, 2017, at 12:25 PM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:
> 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 * 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
> 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;
> I did try that, and it does work, but it's an ugly waste of memory.
More information about the core-libs-dev