RFR 9: 8165641 : Deprecate Object.finalize

[David M. Lloyd]

In regards to the optimized-out "this" stuff - remember that a while ago 
Paul Sandoz introduced java.lang.ref.Reference#reachabilityFence()...

On 03/12/2017 06:55 PM, Hans Boehm wrote:
> I agree that's indeed a solvable problem, perhaps not terribly elegantly,
> but without too much user-visible complication. Cf. Android's
> (internal-use-only) NativeAllocationRegistry. Basically the GC triggering
> heuristic needs to consider other resources as well as Java memory. And
> "other resources" seems to mean "native heap" in 90+% of cases.
>
> The premature cleanup issues (due to e.g. optimized out "this" pointers)
> scare me much more, since they require either significant changes to
> compiler guarantees and the language spec, or a really difficult user
> education effort. It seems to take on the order of an hour one-on-one
> conversation to convince the typical developer that their finalizer or
> java.lang.ref use is broken, which it seems to be about 80% of the time.
>
> But I think we agree that it doesn't matter for this discussion; neither of
> these problems are addressed by deprecating finalizers. PhantomReferences
> have exactly the same issues. And in my experience it's unfortunately
> unrealistic to say we're going to use neither. There will be Java wrappers
> for native objects. And they will be embedded in Java data structures.
> Requiring explicit management for those amounts to mostly throwing out Java
> garbage collection.
>
> On Sun, Mar 12, 2017 at 12:02 PM, Uwe Schindler <uschindler at apache.org>
> wrote:
>
>> Hi,
>>
>>>>> I guess "difficulty in properly triggering GC for non-memory resource
>>>>> exhaustion" is closest to what I just described.
>>>>
>>>> This has long been an issue in the Java client area where native
>> desktop
>>>> resources or the like need to be managed carefully, but it is not just
>>>> native window handles but any resource not managed by GC.
>>>>
>>>> So more precisely "non-Java Heap" resource exhaustion as you could
>>>> allocate 2GB of native heap and the GC would not care at all if
>>>> it were tied solely to a 32 byte finalizable Java object.
>>>
>>> Indeed.  For what it's worth, I have a plan to design and implement a
>>> mechanism to allow native memory to be safely deallocated without
>>> using finalization, but it's proving rather difficult to find a nice
>>> way to design the API and make it fit the JMM.  I hope to get it done
>>> by JDK 10.  :-)
>>
>> Yeah, make it work! If you have some time, don't mind to share updated
>> ideas with Robert Muir and me!
>>
>> Thanks, Uwe
>> (for Apache Lucene MMapDirectory where a few bytes of heap space bind up
>> to terabytes of mmap fulltext index data ��)
>>
>>
>>

-- 
- DML