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.bate...@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
