[erlang-bugs] Hipe/native and reloading modules

[Philip Smolen]

I noticed something strange when I use the "native" option to compile my
code.  Code reloading doesn't work the same way as when I don't specify
"native".  Here's some sample code.

 

-module(reload).

-export([show/0, loop/0, version/0]).

 

show() -> spawn(fun loop/0).

 

loop() ->

  io:format("This process: ~p, Most current version: ~p ~n",

            [version(), reload:version()]),

  receive

    reload -> reload:loop();

    exit -> void

  after 5000 ->

    loop()

  end.

 

%% Change this each time:

version() -> 22.

 

When I don't use the native mode, it works as documented.  When I change the
version number and say "c(reload)" the first version number stays the same
and the second version number is incremented.

 

If I say "c(reload, native)" then it acts strange.  In that case both
version numbers change to the latest one.  More precisely:

*	The recursive call to loop() always calls the original version of
the code, as it should.  (Change the io:format statement if you want to
verify that.)
*	The recursive call to reload:loop() always calls the most recent
version of the code, as it should.
*	The call to reload:version() always calls the most recent version of
the code, as it should.
*	The call to version() works differently in different cases.  If you
compiled without the native switch, it calls the original version of the
code, as it should.  If you compiled with the native switch, it incorrectly
calls the latest version.

 

I noticed something else that was strange, although I'm not sure if it's a
bug or a feature.  When I don't use the "native" switch, I can see that
there are only two versions of the code.  Erlang kills my process if it's
using code that's too old, exactly as documented.  However, if I compile
with the "native" switch then Erlang never kills my old code.

 

I'm running otp_src_R11B-5.tar.gz on Fedora.

 

PS The native option makes things work much faster!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20070916/c215b13f/attachment.htm>