RFR 9: 8165641 : Deprecate Object.finalize

Timo Kinnunen timo.kinnunen at gmail.com
Tue Mar 14 19:25:43 UTC 2017


Maybe rather than “an ugly waste of memory” which sounds somewhat negative, we could instead call it “an honestly assessed true resource cost”?

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.


More information about the core-libs-dev mailing list