On 13.09.2011 00:59, John Rose wrote: > This exposes the question of liveness: JVMs routinely nullify > non-live variables, but what if the only remaining use is the > getLocalArray intrinsic? Shouldn't it count as a weak reference? Or > will we allow it to "reanimate" all local values? That would impose a > systemic cost on the register allocator, for the whole method. I cannot think of a use case where nullifying non-live variables would be a problem.
> Now I want to back up to Thomas' specific suggestion. Instead of > putting in a catch, suppose we use the "throws" clause of the method > to control local capture. This is a clever way to have existing > metadata encode an intention to collect locals "automagically", > without explicit bytecodes or handlers. It requires an overloading of > the idea of "throws", so it might be better to use a new attribute or > annotation. > > In any case, it seems to me that magic frame metadata which causes > fillInStackTrace (of selected Throwable types) to collect local values > is almost completely equivalent (modulo some simulation overhead) to > collecting the locals in each affected frame's handler. > > I say "almost" because the magic metadata can provide the local > information in unpopped frames, while the less magic method (which can > be done today) requires each dying frame to be popped, except perhaps > for the oldest, in order for the local values (and other state) to be > collected into the flying exception. Yes. The "simulation overhead" in terms of additional bytecodes and local variable liveness is however possibly significant. Also, the try-catch solution does not work for capturing expression stack values. The special-exception solution would enable language implementors to generate more compact (and simpler) bytecode methods (e.g., they could use the Java expression stack as their own expression stack implementation). - thomas _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
