Hotspot loves PHP.reboot / stack capturing exception

[Tom Rodriguez]

On Sep 14, 2011, at 10:10 AM, Thomas Wuerthinger wrote:

> 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.

But I don't think the compiler knows which locals are live in this case since the state is going to passed to some unknown piece of code.  Any JVMState used by getLocalArray would have to treat all locals as live.

tom

> 
>> 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev