Uploaded image for project: 'Erlang/OTP'
  1. Erlang/OTP
  2. ERL-1351

compiler offers no flag to disable validation



    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Won't Do
    • Affects Version/s: 23
    • Fix Version/s: None
    • Component/s: compiler
    • Labels:


      Another issue where the compiler is good at being strict, but there is plenty of .S asm code that will not crash the virtual machine but will fail the validation check.

      In compile the line containing:


      should be inside

      {iff, 'no_validation', ...}

      Otherwise you have to copy the compiler erlang source code, comment that line out and do something like:

      ErlSourcePath = os:getenv("USERPROFILE") ++ "/Desktop/Apps/otp-OTP-23.0".
      c("src/compile.erl", [debug_info,{outdir, "ebin"},{i,ErlSourcePath ++ "/lib/compiler/src"},{i, ErlSourcePath ++ "/lib/stdlib/include"}]).

      For example. I wanted to see what happened if tuples were operated on like random access arrays for sake of performance comparison.  Unfortunately the set_tuple_element (and get_tuple_element) opcodes force a constant integer and do not accept variable indexes.  The check for a preceding erlang:setelement might be fakable to fool the validator.

      Anyway, obviously you can generate lots of functions for each index (until you crash erlang with more than some constant around 500000 functions allowed in a module).

      gen_put_asm(N) ->
        Names = list_to_tuple([list_to_atom("do" ++ integer_to_list(X)) || X <- lists:seq(1, N)]),
        {ok, put_tuple_elem, CplBin} = compile:forms(
          {put_tuple_elem,[{element(X, Names), 2} || X <- lists:seq(1, N)] ++ [{module_info,0},{module_info,1}],[],
            [{function,element(X, Names),2,X*2,[{label,X*2-1},{func_info,{atom,put_tuple_elem},
              {atom,element(X, Names)},2},{label,X*2},{set_tuple_element,{x,1},{x,0},X-1},return]} || X <- lists:seq(1, N)] ++
              {call_ext_only,2,{extfunc,erlang,get_module_info,2}}]}],7}, [binary, from_asm]),
        code:load_binary(put_tuple_elem, [], CplBin), Names.

      This works great.  Yes it breaks immutability but as long as you deliberately know what you are doing it is fine.  And from BEAM assembly perspective, everything effectively becomes mutable.  I tried a merge sort implementation which could not hit the performance of the clever lists:sort code but it worked absolutely fine.

      I also tried just random read/write accesses - maps, array and tuples have very fast reads unsurprisingly.  For writing, maps has always been the clear winner which is interesting but this strange tuple idea actually can be faster than the array module.  lists are of course very slow an inappropriate in this case.

      Anyway, I was wondering if a no_validation could be added.  For the beam_asm case at least.  Since it makes no sense to force validation of custom BEAM code where the erlang language semantic restrictions should not necessarily be enforced.




            gregorymorse GregoryMorse
            0 Vote for this issue
            2 Start watching this issue