The variables themselves have concurrency isolation, but not the objects referenced from the variables. The thread local storage implementation in some JVMs uses the shared global heap.
There's no sharing at the application level or the implementation level in Erlang.
If you don't explicitly pass the objects referenced in TLS to outside or to other threads, I don't see it breaks the concurrency isolation.
For some JVM implementation that use a shared global heap, that may just impact the performance due to lock. The concurrency isolation contract is not broken. The app still has full confidence that its TLS values are not changed in other threads. OT: if performance comes into picture, one can claim excessive copying of immutable objects cause performance problem as well.
If you don't explicitly pass the objects referenced in TLS to outside or to other threads, I don't see it breaks the concurrency isolation.
Sure. That's the same as if you never share any resource in any shared global heap between threads.
The point is that Erlang's concurrency model allows the programmer to never make that mistake, because you're storing immutable resources not references to mutable data. See my longer post on the subject, further down the page. :)
OT: if performance comes into picture, one can claim excessive copying of immutable objects cause performance problem as well.
When you have a share-nothing immutable-data concurrency model like Erlang's, heap type is an implementation detail (and you'd probably choose it based on your performance requirements, as you've alluded to.) To wit, as TFA says, you can run the Erlang VM with either a shared heap or a separate heap model. Language semantics stay the same.
There's no sharing at the application level or the implementation level in Erlang.