performance-boost and fix of memory-issues: Get rid of `Object.finalize()`

Here (https://github.com/facebook/react-native/issues/8711) you can find a lengthy explanation why Object.finalize() is bad, but the two main reasons, why Fresco should stop using it are:

1. The FinalizerQueue can fill-up and stop being processed, this can happen for many reasons, and it’s possible that Object.finalize() is never called until the JVM exits. This also means that, every object that’s referenced from an object whose finalizer isn’t called, isn’t garbage-colllected. So even finalizers that log only can lead to memory issues.

2. Finalizers slow everything down by a giant amount. Quote from effective java:

   Oh, and one more thing: there is a severe performance penalty for using finalizers. On my machine, the time to create and destroy a simple object is about 5.6 ns. Adding a finalizer increases the time to 2,400 ns. In other words, it is about 430 times slower to create and destroy objects with finalizers.

I know it’s tedious to release everything manually, but doing it will give Fresco and depending projects an extreme performance-boost and lower memory-footprint. This will help everyone.

Finalizers were just a bad idea which should have never happened.

[brianhama]

This seems to be a huge issue with Fresco. We just switched to Fresco from Picasso and now our memory heap looks like this:

We weren’t seeing anything like this before in terms of the number of finalizers. Our analytics are showing a lot of OOMs. I won’t pretend to understand the issue anywhere near as well as fab1an, but I can verify that the issue does seem to be having a very negative impact.

[fab1an]

@balazsbalazs I know why you are using finalizers, I have read the code, that’s why I already posted in https://github.com/facebook/react-native/issues/8711:

“Finalization might seem to be a good mechanism for making sure that resources do not go undisposed, […] an alternate fallback mechanism, a “second chance” safeguard which will automagically save the day by disposing of the resources that they forgot. This is dead wrong.”

1. What you achieve is a mechanism that is sometimes able to check if a user forgot to close a resource. If your app has enough HeapSize, but you are out of native memory then your finalizers won’t run to free native resources or warn users and there’s nothing you can do about that. So exactly the case you want to warn about, is the case where finalizers won’t be able to help you.
2. What you achieve 100% of the time is a slowdown of the entire VM your code runs in.

As a last comment, I’m quoting Wikipedia (https://en.wikipedia.org/wiki/Finalizer#Problems)

"Finalizers can cause a significant number of problems, and are thus strongly discouraged by a number of authorities.

• Finalizers may not be called in a timely manner, or at all, so they cannot be relied upon to persist state, release scarce resources, or do anything else of importance.
• Finalizers are run based on garbage collection, which is generally based on managed memory pressure – they are not run in case of other resource scarcity, and thus are not suited for managing other scarce resources.
• Slow finalizers may delay other finalizers.
• Finalizers may cause synchronization issue, even in otherwise sequential (single-threaded) programs, as finalization may be done concurrently (concretely, in one or more separate threads).
• …

I won’t spend more time on profiling what essentially are vendor-dependent race-conditions.

I consider it a waste of development time to reproduce mistakes that thousands of other have done and written about before.

I’ll probably just switch to Picasso from square for now, since I mostly have static images anyway.