ReservedStackAccess in ThreadLocal

[David Holmes]

On 29/09/2023 6:33 am, Егор Зиборов wrote:
> Hello, Alan
> 
> I’ve experienced SO in ThreadLocal#set on my production instance
> (more than that it‘s happened in Spring’s ExposeInvocationInterceptor
> that uses TL as context storage)As a result of SO in ThreadLocal
> we’ve experienced unexpected errors with Spring AOP, but I’m sure
> that it could affects lots of frameworks
SOE will nearly always lead to unexpected errors, so that in itself is 
not sufficient justification for trying to apply ReservedStackAccess. We 
added RSA to address an insidious situation where SOE would leave 
ReentrantLocks in a broken state - and we wanted ReentrantLock to be as 
reliable as built-in monitor locks (or as near as feasible). So you need 
a very strong case to apply RSA elsewhere. You also need to be sure that 
the stack needed from the annotated method is small enough for the RSA 
mechanism to protect. Also note that RSA doesn't prevent SOE it simply 
defers it out of the critical code protected by SOE, so the problem is 
simply pushed to the caller.

Just my 2c.

David

>>
>> 28 сент. 2023 г., в 19:55, Alan Bateman <Alan.Bateman at oracle.com> написал(а):
>>
>> On 28/09/2023 17:21, Егор Зиборов wrote:
>>> Hello, everyone
>>>
>>> I'm new there and writing this letter during advice of Dalibor Topic
>>>
>>> I faced an issue with SOE in ThreadLocal and want to add this java9 annotation on ThreadLocal#set. Does anyone have any concerns about it?
>>>
>> This annotation is for very core/critical areas that are particularly sensitive to SO. Did the SO that you observe just happen to be in ThreadLocal.set or is there more to this story? Asking because there are dozens places in java.base where the argument could be made but we have to be very careful to not sprinkle it about.
>>
>> -Alab
>>