beamjs / erlv8 Goto Github PK

Not sure how exactly it should be done, binary-to-string? Special kind of object?

I tried upgrading beamjs with new erlv8 (e6afbc0) and it got much slower and performance is degrading with each apachebench's run.

(such as this, holder, is it a constructor, etc.)

This applies to pids & refs

enif_is_proplist should have a flag to check the type of the key (or do it always?) so that we don't attempt convert non-convertable proplists into an object.

From Beam.JS REPL:

           beam.js> 2147483647
           2147483647
           beam.js> 2147483648
           size_object: bad tag for 0x0

           beam.js> -2147483648
           -2147483648
           beam.js> -2147483649
           size_object: bad tag for 0x0

Right now we'll silently ignore them and convert a tuple to an empty object

(so that we can create real objects/funs/... without assigning them or something)

Also it will be a good time refactor each "command" into a separate class

Major memory leak (other resources seems to work fine, like ctx resources)

For example

       beam.js> 21474836481232342342342342342234234234
       -9223372036854775808

While it is a perfectly legal number in Erlang:

       2> 21474836481232342342342342342234234234.
       21474836481232342342342342342234234234

This way mods and others can store references they need and such.

Here is an example (from beam.js REPL):

   beam.js> delete a.x
   size_object: bad tag for 0x0

   ./console: line 3: 25619 Abort trap

Right now passing a non-special atom (i.e. not true, false or undefined) will simply crash the VM.

Most likely this is happening with Erlang-to-Erlang calls.

So we can possibly load balance between VMs? Keep in mind that V8 is single-threaded anyway.

It looks like it will be a better place for it. This also means we'll need to drop erlv8_vm:register

Never seen this on my mac pro, but got this couple of times on my slow macbook air:

  Thread 6 (core thread 5):
  0  0x000000001001a3a9 in bf_get_free_block ()
  1  0x0000000010011c56 in mbc_alloc ()
  2  0x00000000100130dc in erts_alcu_alloc_thr_pref ()
  3  0x00000000100e51c4 in erl_drv_cond_create ()
  4  0x0000000013b002cc in VM::VM (this=0x107016f0) at c_src/erlv8.cc:28
  5  0x0000000013b00487 in new_vm (env=0xb0356df0, argc=0, argv=0x110f0500) at       c_src/erlv8.cc:124
  6  0x00000000100ff227 in process_main ()
  7  0x00000000100715a1 in sched_thread_func ()
  8  0x000000001018e431 in thr_wrapper ()
  9  0x000000001030e536 in _pthread_start ()
  10 0x000000001030e3e9 in thread_start ()

This is to be done once I'll figure out why most of these cleanup callbacks are never called.

It will most likely require term_to_external to pass a reference to the VM (which it doesn't receive in arguments yet)

At this moment only js_to_term supports Null/null

Relevant to #33

Examples are shown from beam.js REPL for convenience:

          beam.js> a = "x"
          "x"
          beam.js> this
          [{"a","a"}]

while it works for other kind of values, such as numbers:

          beam.js> a = 1
          1
          beam.js> this
          [{"a",1}]

The same behaviour for non-global object as well:

          beam.js>  a = {x: "y"}
          [{"x","y"}]
          beam.js> a
          [{"x","x"}]

and

          beam.js> a = {x:1}
          [{"x",1}]
          beam.js> a
          [{"x",1}]

It isn't going to be easy but there should be a way to treat passed objects as references