BEAM implementation questions

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

James Hague-5
Just a couple of questions about the current Erlang implementation:

1. BEAM builds structured constants at runtime, whereas HIPE doesn't.
For example, consider nouns() -> ["house", "cat", "tree"].  Each time
nouns() is called, four new lists are created with BEAM, whereas HIPE
simply returns a pointer to pre-built data.  Any chance of this ever
being brought over to BEAM?

2. Let's say I have the following code:

receive ready -> do_something() end

Now suppose I send 100 messages to that process and the last one is
the atom "ready".  Is there some kind of high-level checking when a
message is sent to that process, to see that the process is
specifically waiting for a message of a certain format?  Or does the
process simply get executed periodically, scans the mailbox for
"ready," finds that there is none and exits?  (I'm hoping that makes
sense!)

James


Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Mikael Pettersson
James Hague writes:
 > 1. BEAM builds structured constants at runtime, whereas HIPE doesn't.
 > For example, consider nouns() -> ["house", "cat", "tree"].  Each time
 > nouns() is called, four new lists are created with BEAM, whereas HIPE
 > simply returns a pointer to pre-built data.  Any chance of this ever
 > being brought over to BEAM?

This is difficult to do, because of some fundamental and not easily
changed aspects of the Erlang/OTP memory management system. Even the
HiPE implementation suffers, in that it cannot handle arbitrarily large
amounts of constant terms.

There are plans to rectify the underlying problem, at which time also
BEAM could support constant terms. But don't hold your breath because
it's a non-trivial change and developer time is scarce..

/Mikael
(one of the HiPE developers)


Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Raimo Niskanen-3
In reply to this post by James Hague-5
Well, it is only the receiver that knows what it wants, and it executes
.beam code to match the received messages, so - yes, the receiver
gets scheduled, tries to match from the inqueue, fails and schedules
out. The good thing is that it is remembered which message is the
next to match (since the receive clauses will not change during
the recive no old messages will ever match) so it is only new
messages that are tried next time.


james.hague (James Hague) writes:

> 2. Let's say I have the following code:
>
> receive ready -> do_something() end
>
> Now suppose I send 100 messages to that process and the last one is
> the atom "ready".  Is there some kind of high-level checking when a
> message is sent to that process, to see that the process is
> specifically waiting for a message of a certain format?  Or does the
> process simply get executed periodically, scans the mailbox for
> "ready," finds that there is none and exits?  (I'm hoping that makes
> sense!)
>
> James

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Thomas Lindgren-5
In reply to this post by James Hague-5

--- James Hague <james.hague> wrote:

> Just a couple of questions about the current Erlang
> implementation:
>
> 1. BEAM builds structured constants at runtime,
> whereas HIPE doesn't.
> For example, consider nouns() -> ["house", "cat",
> "tree"].

I'd like support for this, perhaps even moreso if
there was some language support for declaring
"constant data".

> [messaging implementation]

As far as I recall, when a message arrives to a
waiting process, the process is set to be ready to
run. If the message doesn't match the current receive,
the process resuspends. (If several messages have
arrived, they are scanned in arrival order.)

A suspended process thus has already scanned through
the existing messages in the mailbox, if any. The
whole mailbox will be rescanned at the next receive.

However, while this implementation seems reasonable
enough, the actual semantics of Erlang (such as they
are) permit other implementations than this.

Best,
Thomas




       
               
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail


Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Richard Carlsson-4

> However, while this implementation seems reasonable
> enough, the actual semantics of Erlang (such as they
> are) permit other implementations than this.

There is surprisingly little slack in the semantics of
receive (sometimes this can be a bit of a problem for
implementors). Possibly the most compact and complete
description can be found in the Core Erlang specification:

  http://www.it.uu.se/research/group/hipe/cerl/

(There is no real difference between the receive construct
in Core Erlang and in Erlang.)

        /Richard


Richard Carlsson (richardc)   (This space intentionally left blank.)
E-mail: Richard.Carlsson WWW: http://user.it.uu.se/~richardc/
 "Having users is like optimization: the wise course is to delay it."
   -- Paul Graham


Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Thomas Lindgren-5

--- Richard Carlsson <richardc> wrote:

> There is surprisingly little slack in the semantics
> of receive (sometimes this can be a bit of a problem
> for implementors).

Yet even if we use the Core Erlang definition, it's
still lax enough to permit other implementations with
the same functional behaviour, I'm sure you'll agree.

Taking a broader view, the semantics you mention in
the Core Erlang specification is very operational, but
one could also go for more denotational (or at least
higher-level) versions.

The message passing guarantees I seem to recall seeing
in the Erlang documentation are fairly freewheeling
about order of delivery of messages sent, for example.
(Though I can't seem to find the passage I was
thinking about, so I'll have to mumble a bit here ...
:-)

An Erlang implementation (a perverse one?) could
conceivably exploit that, for instance.

(Well, this could probably be expressed better, but
I'll have to leave it at that.)

Best,
Thomas



               
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo 


Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Dominic Williams
In reply to this post by Thomas Lindgren-5
Thomas Lindgren wrote:

> I'd like support for this, perhaps even moreso if
> there was some language support for declaring
> "constant data".

I'm curious about why you'd want any specific support.
What's wrong with a constant function, e.g.:

pi() -> 3.1415.
max_users() -> 50.

Regards,

Dominic Williams
http://www.dominicwilliams.net

----



Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Thomas Lindgren-5

--- Dominic Williams <erlang-list>
wrote:

> Thomas Lindgren wrote:
>
> > I'd like support for this, perhaps even moreso if
> > there was some language support for declaring
> > "constant data".
>
> I'm curious about why you'd want any specific
> support.
> What's wrong with a constant function, e.g.:
>
> pi() -> 3.1415.
> max_users() -> 50.

There's nothing _really_ wrong with functions
returning constant data, I just find it (a bit)
clearer to have a separate notation to say "this is a
data access, not a computation" and to indicate that I
want this data to be cached and shared somewhere. (In
some cases you instead want to hide that distinction,
of course.)

Here's one case where it turns up: when I build a
lexer (lex.erl in jungerl), I dynamically generate the
lexing table and index into it when driving the lexer.
But it would be nicer to instead have a data structure
I could emit once and for all, and then index into it
with something like:

lextable[StateName, Char]   (forgive the syntax :-)

with lextable/2 thus being a constant 2D array, not a
function. Saving the generated table as a loadable
module would also be quite useful.

The same issue turns up for yecc, incidentally, which
generates a huge swathe of code in order to implement
what amounts to a table. Cf. erl_parse.erl.

Best,
Thomas



               
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail 


Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Vladimir Sekissov
Good day,

thomasl_erlang> > > I'd like support for this, perhaps even moreso if
thomasl_erlang> > > there was some language support for declaring
thomasl_erlang> > > "constant data".

But you can use parameterized modules to emulate this.

-module(t, [Data]).

-export([gv/1]).

gv(Idx) ->
  proplists:get_value(Idx, Data).

1> T=t:new([{a, b}, {c, d}]).
{t,[{a,b},{c,d}]}

2> T:gv(a).
b

3> file:write_file("T.dump", term_to_binary(T)).
ok
....

1> l(t).
{module,t}

2> {ok, B} = file:read_file("T.dump").
{ok,<<131,104...

3> T=binary_to_term(B).
{t,[{a,b},{c,d}]}

4> T:gv(a).
b

Best Regards,
Vladimir Sekissov


Reply | Threaded
Open this post in threaded view
|

BEAM implementation questions

Thomas Lindgren-5

--- Vladimir Sekissov <svg> wrote:

> Good day,
>
> thomasl_erlang> > > I'd like support for this,
> perhaps even moreso if
> thomasl_erlang> > > there was some language support
> for declaring
> thomasl_erlang> > > "constant data".
>
> But you can use parameterized modules to emulate
> this.

Well, that solves part of it, at the very least. I'll
have a look at using them. Thanks for the tip!

Best,
Thomas



               
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo