-
Bug
-
Resolution: Not an Issue
-
P3
-
None
-
22
The code in MemorySessionImpl has been consolidated, as part of JDK-8287909. Unfortunately, as a result of the consolidation, the public liveness check has changed from this:
```
@Override
public boolean isAlive() {
return (int) STATE.getVolatile(this) != CLOSED;
}
```
To this:
```
public boolean isAlive() {
return state >= OPEN;
}
```
That is, MemorySessionImpl::isAlive now only implements the check that was previously only allowed for _confined_ sessions.
This is wrong for two reasons.
First, given the lack of volatile semantics, it could be possible for threads to read stale state (e.g. observe the scope in alive state when the arena has already been closed). There is simply no happens-before between setting the state to CLOSED and reading it back in the `isAlive` method.
Secondly, since shared arenas have a third state (CLOSING) which is used while doing the thread-local handshake, clients can also observe the scope going from alive to !alive then back to alive.
These issues should be fixed, and the implementation of `isAlive` should just use the more robust logic that used to be available for SharedSession (even if the session is confined, after all it could be possible for a thread other than the owner thread to poll `isAlive`).
```
@Override
public boolean isAlive() {
return (int) STATE.getVolatile(this) != CLOSED;
}
```
To this:
```
public boolean isAlive() {
return state >= OPEN;
}
```
That is, MemorySessionImpl::isAlive now only implements the check that was previously only allowed for _confined_ sessions.
This is wrong for two reasons.
First, given the lack of volatile semantics, it could be possible for threads to read stale state (e.g. observe the scope in alive state when the arena has already been closed). There is simply no happens-before between setting the state to CLOSED and reading it back in the `isAlive` method.
Secondly, since shared arenas have a third state (CLOSING) which is used while doing the thread-local handshake, clients can also observe the scope going from alive to !alive then back to alive.
These issues should be fixed, and the implementation of `isAlive` should just use the more robust logic that used to be available for SharedSession (even if the session is confined, after all it could be possible for a thread other than the owner thread to poll `isAlive`).
- relates to
-
JDK-8310644 Make panama memory segment close use async handshakes
-
- Resolved
-