review request (URGENT): 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated

[Charles Oliver Nutter]

On Fri, Jun 3, 2011 at 2:48 AM, John Rose <john.r.rose at oracle.com> wrote:
> http://cr.openjdk.java.net/~jrose/7051206
> This is a changed method name (and inverted sense), replacing
> SwitchPoint.isValid.  Here's the updated javadoc:
>
> hasBeenInvalidated
>
> public boolean hasBeenInvalidated()

A side effect of this is that it's no longer a valid JavaBean name and
won't be recognized by bean-aware setups. It's an entirely unimportant
point, though.

> Determines if this switch point has been invalidated yet.
>
> Discussion: Because of the one-way nature of invalidation, once a switch
> point begins to return true for hasBeenInvalidated, it will always do so in
> the future. On the other hand, a valid switch point visible to other threads
> may invalidated at any moment, due to a request by another thread.
>
> Since invalidation is a global and immediate operation, the execution of
> this query, on a valid switchpoint, must be internally sequenced with any
> other threads that could cause invalidation. This query may therefore be
> expensive. The recommended way to build a boolean-valued method handle which
> queries the invalidation state of a switch point s is to
> call s.guardWithTest on constant true and false method handles.

If this is the recommended way and it's not expensive, why doesn't
hasBeenInvalidated simply do this under the covers and avoid the
drama? I'm confused why one way is expensive and the other is not,
when they produce the same result with the same threading effects and
the same instability/stability of true/false results.

- Charlie