ReservedStackAccess in ThreadLocal

[Егор Зиборов]

Unexpected behaviour is too common phrase - got it

As i sad i’ve experienced it in https://github.com/spring-projects/spring-framework/blob/main/spring-aop/src/main/java/org/springframework/aop/interceptor/ExposeInvocationInterceptor.java

Error on ThreadLocal#set in finally section there lead to leaving wrong state of TL (in my case it was non-null value into TL, that Spring’s AOP treats like “part of recursion calls” and AOP will return null insteadof expected value (for all execution in such “poisoned” thread)

I believe that the same situation is possible with ThreadLocal#remove too


> 29 сент. 2023 г., в 05:37, David Holmes <david.holmes at oracle.com> написал(а):
> 
> 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
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230929/c06d8fbd/attachment.htm>