Hotspot loves PHP.reboot / stack capturing exception

[Thomas Wuerthinger]

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