geometric memory growth

[Ulf Wiger]

Den 2005-11-26 19:44:48 skrev Matthias Lang <matthias@REDACTED>:

> I failed to notice that your suggestion only applied to things
> carried in via the environment. So it seemed stranger than it was,
> because it seemed to make funs behave differently to normal functions.
>
> Now I see it's 'merely' that you want record field selectors to be
> more than just syntactic sugar for an element/2 call.

Well, it is.  (:

Or, at least, if Kostis gets his way, it will be.


In OTP R10B, the following code:

   -module(foo).
   -export([new/0,f/1]).
   -record(rec, {a,b}).

   new() -> #rec{}.

   f(R) ->
      R#rec.a.

compiled as:

   new() ->
       {rec,undefined,undefined}.

   f(R) ->
       erlang:element(2,R).

   module_info() ->
       erlang:get_module_info(foo).

   module_info(X) ->
       erlang:get_module_info(foo,X).



and consequently:

2> c(foo).
{ok,foo}
3> foo:f({a,b,c}).
b

(which almost makes Thomas's argument against me moot,
because as things work today, you may or may not get
an exception if State is not a record. If it's a tuple
of sufficient arity, you will get _something_, but quite
possibly not at all what you expected.)

But if we check debug_info for the same module:

           {function,
               7,
               f,
               1,
               [{clause,
                 7,
                 [{var,7,'R'}],
                 [],
                 [{record_field,
                   8,
                   {var,8,'R'},
                   rec,
                   {atom,8,a}}]}]},


It's when the compiler goes beyond this point and
transforms record_field(R, a) that it over-simplifies
and currently produces code that (a) is not always
safe, and (b) sometimes causes memory explosions.

I think these are two very good reasons to make
record field selectors into something more than
just syntactic sugar for element/2.

/Uffe
-- 
Ulf Wiger