This page is no longer maintained — Please continue to the home page at

Re: I learned something about scala and gc

No replies
Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.

On Thu, Aug 18, 2011 at 5:11 PM, Matthew Pocock
> HI,
> On 18 August 2011 15:29, Adriaan Moors wrote:
>> On Thu, Aug 18, 2011 at 4:11 PM, Matthew Pocock
>> wrote:
>>> Or should scalac ideally be inlining all use-once vals? Possibly with
>>> @inline hints on the val declaration? Not sure how this would play with
>>> debuggers - the inlined vals would not be there from the point of view of
>>> the bytecode.
>> I think the problem with that is that it potentially changes program
>> behaviour -- not a desirable property of an optimiser
>> i.e., if `val x = new Foo` is not inlined, Foo's constructor is called
>> where the val is declared -- if it's inlined, the constructor call does not
>> happen until the val is used
> Good catch. For non-pure expressions, inlining the initialization of the val
> could change how the program runs. I was thinking more of maintaining the
> order but avoiding keeping a reference in the local variable table if it can
> be avoided. I think it comes down to the bytecode that's generated for the
> val. It gets stored in a local with astore. When it's passed to the
> function, there's an aload that places a reference onto the stack. In our
> example case, that aload is the last time the local is accessed, but the
> reference persists in the local variable table, locking it into memory.
> Clearing the local (aconst_null; astore ), or eliminating the
> astore/aload entirely where redundant, would have fixed this.
> I've decompiled some code produced by both scalac and javac, and neither of
> them explicitly release local variables. With luck, either the method runs
> off the end, or another local in a different block uses the same local slot,
> freeing up the reference that way. This makes the presence or absence of a
> reference to the object a bit of a lottery - you have a guaranteed minimum
> scope of the current block, and a guaranteed maximum scope of the method,
> but that's about it. It depends on what code is down-stream in the method.

I believe that Clojure does release local variables to avoid this very
problem. I'm sure there was a discussion about it on the mailing lists
a couple years back, but I can't conjure it up.


Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland