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

compiler offers no flag to disable validation

    XMLWordPrintable

    Details

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

      Description

      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:

      ?pass(beam_validator_weak),
      

      should be inside

      {iff, 'no_validation', ...}

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

      code:unstick_mod(compile).
      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)] ++
            [{function,module_info,0,N*2+2,[{label,N*2+1},{func_info,{atom,put_tuple_elem},
              {atom,module_info},0},{label,N*2+2},{move,{atom,put_tuple_elem},{x,0}},
              {call_ext_only,1,{extfunc,erlang,get_module_info,1}}]},
            {function,module_info,1,N*2+4,[{label,N*2+3},{func_info,{atom,put_tuple_elem},
              {atom,module_info},1},{label,N*2+4},{move,{x,0},{x,1}},
              {move,{atom,put_tuple_elem},{x,0}},
              {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.

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            gregorymorse GregoryMorse
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: