[RESTEASY-3135] Initial change for removing finalizers.

[jamezp]

https://issues.redhat.com/browse/RESTEASY-3135

This is not yet complete, but wanted to get some tests running.

[ronsigal]

@jamezp, can I just verify that I'm understanding "cleaning" correctly? It looks like

1. the CleanupAction has a strong reference to a Message
2. MultipartInputImpl has a strong reference to CleanupAction
3. java.lang.ref.Cleaner holds a phantom reference to the CleanupAction

So, when MultipartInputImpl goes away, the Message becomes phantom reachable.

[jamezp]

@jamezp, can I just verify that I'm understanding "cleaning" correctly? It looks like

1. the CleanupAction has a strong reference to a Message
2. MultipartInputImpl has a strong reference to CleanupAction
3. java.lang.ref.Cleaner holds a phantom reference to the CleanupAction

So, when MultipartInputImpl goes away, the Message becomes phantom reachable.

@ronsigal That is how I'm hoping it works at least. The idea is that we don't keep MultipartInputImpl from being GC'd. I'm not 100% sure I got it right which is why I like this second set of eyes on it :)

[ronsigal]

I'm not clear about this. cleanable.clean() will set the AtomicBoolean closed to true. Then, if the CleanupAction gets called, closed.compareAndSet(false, true) returns false and client.close() doesn't happen. What am I missing?

[jamezp]

When cleanable.clean() is invoked it's unregistered from the cleaner so it won't be cleaned again. https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/Cleaner.Cleanable.html#clean()

[ronsigal]

I was stuck on

() -> closed.set(true)

instead of

ResourceCleaner.register(engine, new CleanupAction(closed, (CloseableHttpClient) client))

for some reason.

It makes sense now.

Looks good to me. What else needs to be done?

[jamezp]

Since you approved it, it just needs to be merged :)