On Thu, May 26, 2011 at 12:55 AM, Ola Bini <[email protected]> wrote: > Actually, it was Remi who came up with this gem when we discussed adding > an isInvalid() method on SwitchPoint.
I don't say it's not clever. It's just not something anyone is typically going to figure out on their own. There will be constant questions "if I can invalidate a SwitchPoint, why can't I ask if it has been invalidated?" > The thing is, at least where I've used SwitchPoint, having a way of > asking is not as useful as being able to use the pattern to change work > later. So, for example, in Seph I allow "if" to be overridden. If that > doesn't happen I have a fastpath for ifstatements, guarded by a > switchpoint. When someone overrides "if" I want to stop checking for > "if", so I just add the method to check if "if" is overridden to the > switchpoint itself, with a fallback of not doing anything. > > I suspect that those kind of patterns are going to be much more common. That's certainly true, but in the case I'm considering I want to use it as both an inline guard and as a trigger to alter future compilation. Specifically, I want to use it to test whether Fixnum or Float have been modified, so I can stop emitting direct paths for their calls. The hope is that I can avoid bounding through a few field loads to check a JRuby-instance-local flag indicating whether they've been overridden, and simply have a switchpoint around the fast path math logic. I want SwitchPoint.isValid so that once it has been invalidated I only have a single place to check to know whether I should even bother trying to insert the fast path in the future. Yes, it could be another volatile boolean I set around the same time as invalidating the SwitchPoint, but I'm duplicating SwitchPoint's logic then. I can use the trick for now, but this seems like an obvious missing feature. SwitchPoint has state: is or is not valid. You can modify that state directly via invalidateAll. You should also be able to query it without doing a MH dance. - Charlie - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
