geometric memory growth

Ulf Wiger ulf@REDACTED
Sat Nov 26 22:38:48 CET 2005

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:

   -record(rec, {a,b}).

   new() -> #rec{}.

   f(R) ->

compiled as:

   new() ->

   f(R) ->

   module_info() ->

   module_info(X) ->

and consequently:

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

(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:


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.

Ulf Wiger

More information about the erlang-questions mailing list