Stack allocation API

[Vladimir Ivanov]

> This seems to be using the underlying OS thread stack to allocate 
> things? Note that we can not do the same in Java. We want Java thread 
> stacks to be freely copyable for Loom, which means we can't have 
> pointers into the thread's native stack.

Strictly speaking, it is (and will be) allowed. Mixed thread stacks 
(single thread stack used for Java and native code) aren't going away 
any time soon. But native frames (and native resources/pointers) 
negatively affect Loom functionality and effectively pin virtual threads 
to OS threads (defeating the whole purpose of virtual threads).

As was already pointed out, the topic was discussed multiple times and I 
still consider stack allocation overrated [1]. And Loom will make it 
even less attractive.

FTR the referenced post [1] describes a way to implement stack 
allocation without any JVM assistance. It would be very helpful if 
somebody make such experiment and report their experience.

Best regards,
Vladimir Ivanov

[1] 
https://mail.openjdk.java.net/pipermail/panama-dev/2019-November/006752.html



> A solution to this problems would be for instance to have a dedicated 
> thread-local side stack for the native allocations, which is not moved 
> around. This is essentially what the LWJGL MemoryStack does. I believe 
> Loom's ScopeLocals could help to make the thread-local access part 
> faster in the future as well.
> 
> Jorn
> 
> On 17/02/2022 00:33, Radosław Smogura wrote:
>> Hi,
>>
>> My understanding is that scope local is like parameter you can pass to 
>> function (but it’s passed like a global reference), and enforces 
>> closure (Autoclosable can’t enforce value to be put in 
>> try-with-resources, so stack can be incorrect if exceptions are not 
>> properly handled).
>>
>> However I think that everyone (or at least me) think about something 
>> like this:
>>
>> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/stackalloc 
>>
>>
>> Kind regards,
>> Rado
>> On Feb 16, 2022, at 10:40 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> ----- Original Message -----
>> From: "Ioannis Tsakpinis" <iotsakp at gmail.com>
>> To: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>> Cc: "Felix Cravic" <themode at outlook.fr>, 
>> "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
>> Sent: Wednesday, February 16, 2022 9:56:43 PM
>> Subject: Re: Stack allocation API
>>
>>
>> ...
>>
>> An issue with LWJGL's approach is the thread-local access to grab the
>> current thread's MemoryStack. The thread-local lookup itself is not
>> terribly expensive (but not free either), however it does become a 
>> problem
>> in hot code. Hotspot cannot hoist it out of loops and this has 
>> unfortunate
>> consequences for the surrounding code.
>>
>> I wonder how the ScopeLocal of loom behave compared to ThreadLocal.
>> https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.concurrent/jdk/incubator/concurrent/ScopeLocal.html 
>>
>>
>>
>> - Ioannis
>>
>> Rémi