[concurrency-interest] Should I avoid compareAndSet with value-based classes?
gil at azul.com
Fri Jul 7 13:32:29 EDT 2017
On Jul 7, 2017, at 10:04 AM, Kirk Pepperdine <kirk at kodewerk.com<mailto:kirk at kodewerk.com>> wrote:
3. The exception-throwing thing is IMO the healthy way to go IMO. I.e. throw some runtime exception when encountering an indentity-based operation on an instance of a value-based class. Hard to argue that "an exception should not be thrown here" given the clear warnings in the spec. My worry is mostly about coverage. Throwing exceptions in all cases where identity based operations are attempted would clearly be right, and healthy. But doing so only in some cases (and leaving some undefined behavior executing paths that don't throw exceptions) doesn't solve the problem [and may make things worse by encouraging false confidence]. Since no one *requires* us to throw an exception right now, JVM implementors will probably keep taking the lazy approach and not work hard on trying to achieve complete coverage. And since don't do it at all" is probably better/easier to verify than "do it in some places but not in others", we'll probably avoid it altogether for now. This *may* change when value-based optimizations materialize.
I think I’d have to (violently) disagree with this. There is a reason no one requires you to throw an exception when expressing equality and that is because this is a guaranteed property in the runtime. Without it you lose a fundamental property of the runtime.
Synchronous exceptions can be thrown for example because (https://docs.oracle.com/javase/specs/jls/se7/html/jls-11.html#jls-11.1.2):
* evaluation of an expression violates the normal semantics of the Java programming language (§15.6<https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.6>), such as an integer divide by zero.
* an error occurs while loading, linking, or initializing part of the program (§12.2<https://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.2>, §12.3<https://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.3>, §12.4<https://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4>); in this case, an instance of a subclass of LinkageError is thrown.
* an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language; in this case, an instance of a subclass of VirtualMethodError is thrown. [GT: this is mis-spelled in the spec. Should be VirtualMachineError].
I'd hope to have it qualify under the first bullet, but it is not listed in the specific list of runtime exception causes in 15.6. However, evaluating an == expression where one of the operands is an instance of a value-based class (and has no identity) can probably qualify under "an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language" (third bullet). Especially when the Java SE spec explicitly says "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects".
Separately, asynchronous exceptions can be thrown anywhere in the code. E.g. An OOME can hit a == point in the code too.
I'd rather not make such exceptions a subclass of VirtualMachineError would be better tho...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest