Hi, 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. Andrew.
