Late cleanup of stack objects

[Arnaud Masson]

The bigBuffer is released as expected if the variable is set to null manually before calling the suspending sync IO method.

My concern is that we may lose the “smart” variable capture of lambda (from the async scenario) when moving to plain sync syntax.
That means that even if a waiting Loom vthread is cheap (no dedicated OS thread, no fixed size stack), it may still capture/retain too much “state” compared to an async lambda, on all call stack levels.

I will check if C2 helps, but afaik since it’s triggered when method is used often (not because the method consumes significant memory), it’s not ideal to count on it anyway. Moreover, I suspect it’s not documented public behavior while lambda capture is well defined.

Could the JVM guess that a method might block and be a bit more aggressive on stack variable cleanup? (Adding a minor null assignment overhead in that case)
I was thinking a good hint in real world could be that the called method throws well-known checked exceptions (IOException, InterruptedExeption…)
Worst case the hint is not detected and it’s current behavior.
Ok crazy idea maybe : )  (at least it would not be as annoying as true colored-functions)

Thanks
Arnaud

>Would making a wrapper around the allocated object make a difference? (And clear the reference in the wrapper after the right line)
>
>On Mon, 7 Nov 2022, 11:55 Alan Bateman, <Alan.Bateman at oracle.com> wrote:
>On 07/11/2022 07:29, Sam Pullara wrote:
>> I am kind of annoyed this doesn't solve the problem (scoping the
>> allocation):
>
>You may have reduced the scope of bigBuffer in the source code but the
>code generated by the javac compiler will be the same, meaning the
>method will have the same number of locals as before.
>
>For Arnaud's test, the local for bigBuffer will be live when it is
>running in the interpreter so freezing the stack during slowIO will keep
>it reachable.  It should be different once the code is warmed and
>compiled by C2 but it may be that the observations with VisualVM are
>done before it is compiled at run-time.
>
>-Alan


Unless otherwise stated above:

Compagnie IBM France
Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 664 069 390,60 €
SIRET : 552 118 465 03644 - Code NAF 6203Z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20221107/a356e698/attachment-0001.htm>