[External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads
Ron Pressler
ron.pressler at oracle.com
Sat Aug 3 23:06:52 UTC 2024
> On 2 Aug 2024, at 15:58, robert engels <robaho at icloud.com> wrote:
>
> Sorry to keep this thread going but in reviewing my test results I think this capability is now dangerous, as I related to the Thread.stop(). It is going to be the same issue.
>
> A lot of native resource backed objects have Java shadows with finalizers / reference queues. If the referenced are released without traveling up the stack the program/system can be in an inconsistent state.
>
> Take for instance a file system lock file that is removed on finalization. This would be removed allowing other processing to continue even though the locking process never completed nor rolled back.
>
> Maybe you could argue it is a bad design to do this but I think the pattern with Cleaners, etc is fairly pervasive.
>
> By releasing the objects program order guarantees are broken - I don’t think it is valid to do this - especially concerning try/finally.
>
> As I also said you could maybe be very tricky and just release the memory but that isn’t what is happening here. It is collecting the objects which allows side effects through finalization and reference queues.
You are absolutely right that finalizers (and reference queues/cleaners in general) are a dangerous feature that should be avoided, but that’s the case regardless of thread collection, and even in the case of thread stacks, remember that references on the stack may be collected even if the thread is reachable, which is why ReachabilityFence exists. It is simply *not* the case, neither in theory nor in practice, that only references that have been popped off the stack are collected. That is *not* a guarantee, and if it's your assumption, then you’re in for some surprises and shouldn’t use finalizers/cleaners. In fact, the general advice is not to use these mechanisms at all. They don’t work as most people might assume they do.
Having said all that, collecting a thread whose references are already allowed to be collected is valid.
More information about the loom-dev
mailing list