Hotspot loves PHP.reboot / stack capturing exception
thomas.wuerthinger at oracle.com
Wed Sep 14 10:10:21 PDT 2011
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
> 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).
More information about the mlvm-dev