1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-29 16:30:56 -05:00
Commit graph

7 commits

Author SHA1 Message Date
Ryan Dahl
523ab6a929
Upgrade V8 to 7.7.37 (#2492) 2019-06-10 18:49:30 -04:00
Ryan Dahl
e043697521
Expose dynamic import in core (#2472) 2019-06-10 15:27:34 -04:00
Michał Sabiniarz
9bea576f3e Deno.core.evalContext & Deno.core.print fix (#2465) 2019-06-06 21:51:04 -04:00
Ryan Dahl
cbcb78f188
libdeno: expose dynamic import (#2461) 2019-06-06 19:07:47 -04:00
Bert Belder
ae0544b7ce core: remove support for moving deno_buf ownership from C++ to JavaScript
The functionality hasn't been in use for a long time. Without this feature,
the `alloc_ptr` and `alloc_len` fields are no longer necessary.
2019-05-02 06:25:44 +02:00
Bert Belder
41c7e96f1a
Refactor zero-copy buffers for performance and to prevent memory leaks
* In order to prevent ArrayBuffers from getting garbage collected by V8,
  we used to store a v8::Persistent<ArrayBuffer> in a map. This patch
  introduces a custom ArrayBuffer allocator which doesn't use Persistent
  handles, but instead stores a pointer to the actual ArrayBuffer data
  alongside with a reference count. Since creating Persistent handles
  has quite a bit of overhead, this change significantly increases
  performance. Various HTTP server benchmarks report about 5-10% more
  requests per second than before.

* Previously the Persistent handle that prevented garbage collection had
  to be released manually, and this wasn't always done, which was
  causing memory leaks. This has been resolved by introducing a new
  `PinnedBuf` type in both Rust and C++ that automatically re-enables
  garbage collection when it goes out of scope.

* Zero-copy buffers are now correctly wrapped in an Option if there is a
  possibility that they're not present. This clears up a correctness
  issue where we were creating zero-length slices from a null pointer,
  which is against the rules.
2019-05-01 21:11:09 +02:00
Ryan Dahl
c9614d86c1
Move //libdeno to //core/libdeno (#2015)
Fixes some sed errors introduced in c43cfe.

Unfortunately moving libdeno required splitting build.rs into two parts,
one for cli and one for core.

I've also removed the arm64 build - it's complicating things at this
re-org and we're not even testing it. I need to swing back to it and get
tools/test.py running for it.
2019-03-30 14:45:36 -04:00
Renamed from libdeno/binding.cc (Browse further)