On Sep 14, 2011, at 3:05 PM, Thomas Wuerthinger wrote:
> But one could maybe disable the local variable liveness maps
> for the methods that use this functionality (i.e., the extended
> exception stack trace or the getLocalArray)?
Yes, of course. But this will increase spilling throughout thos
On 9/14/11 10:20 PM, Tom Rodriguez wrote:
> 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 intri
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?
>From Thomas
(e.g., they could
use the Java expression stack as their own expression stack
implementation).
I believe that this is both used and necessary to create reasonable
performance implementation
of Smalltalk on the jvm. I do this in Rtalk today mapping the Smalltalk
st
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
