1. 04 Feb, 2018 1 commit
  2. 01 Feb, 2018 3 commits
  3. 24 Jan, 2018 2 commits
    • Philip Chimento's avatar
      profiler: Reduce API surface · c3a4f694
      Philip Chimento authored
      We actually don't want callers to have control over the lifetime of the
      profiler object. It should be tied entirely to the GjsContext. This makes
      most of the profiler API private.
      
      Now, to control the profiler, you have two construct-only properties of
      GjsContext: profiler-enabled and profiler-sigusr2. profiler-sigusr2
      implies profiler-enabled, and does the work that
      gjs_profiler_setup_signals() would previously have accomplished. The
      GJS_PROFILER_ENABLED environment variable, if set, overrides the value of
      profiler-signal.
      
      By default when you call gjs_context_eval(), the profiler will be started
      and stopped automatically around the evaluation of the JS code. If you
      need to call gjs_context_eval() more than once, you probably only want to
      do that within one profiling session. For that case we provide the
      gjs_profiler_start() and gjs_profiler_stop() API, which will prevent the
      auto-starting and stopping.
      c3a4f694
    • Philip Chimento's avatar
      profiler: Always activate profiler if GJS_ENABLE_PROFILER=1 · f8528da4
      Philip Chimento authored
      This checks in gjs_context_eval() to see if the GJS_ENABLE_PROFILER
      environment variable is set but no profiler has been created. In that
      case, we run a profiler for the duration of the JS code evaluation.
      
      This is to accommodate applications such as Polari that are written in JS
      but ship their own loader that links to libgjs and calls
      gjs_context_eval(). This way, they can be profiled without writing any
      extra code in their loaders (though they will still need it if, for
      example, they want to add a command line argument.)
      f8528da4
  4. 04 Oct, 2017 1 commit
    • Philip Chimento's avatar
      jsapi-util: Remove jsapi-private · e23b19ef
      Philip Chimento authored
      Ever since removing the gjs-module API, there has not really been a
      distinction between "public" and "private" jsapi-util functions. Just
      remove the private files and incorporate everything declared or defined
      there into the other jsapi-util files.
      e23b19ef
  5. 22 Sep, 2017 1 commit
  6. 01 Sep, 2017 1 commit
  7. 23 Aug, 2017 1 commit
  8. 13 Aug, 2017 1 commit
  9. 19 Jul, 2017 3 commits
  10. 09 Jul, 2017 6 commits
    • Philip Chimento's avatar
      js: Remove JSRuntime · ec0d7140
      Philip Chimento authored
      JSRuntime is merged into JSContext in SpiderMonkey 52.
      
      We reorganize things a bit to reflect the new situation. The files
      runtime.cpp and runtime.h are renamed to engine.cpp and engine.h, and
      will contain everything having to do with the SpiderMonkey engine:
      initializing the JSContext, and any callbacks that the engine requires
      embedders to set.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=784196
      ec0d7140
    • Philip Chimento's avatar
      js: Replace JSRuntime APIs that now take JSContext · b98b9f9c
      Philip Chimento authored
      Many APIs that adapted to the removal of JSRuntime can be trivially
      replaced with JSContext without any other code changes.
      
      JS_AbortIfWrongThread() also takes JSContext instead of JSRuntime, but
      we only called it to check that we were creating a JSContext on the
      correct thread. Before creating the JSContext, there is no point in
      calling it, so remove it.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=784196
      b98b9f9c
    • Philip Chimento's avatar
      js: Adapt to options changes · 3199806e
      Philip Chimento authored
      JS::RuntimeOptions and JS::ContextOptions have merged into one
      JS::ContextOptions class. JS::CompartmentOptions, on the other hand, has
      split into "creation options" (can be set only at construct time) and
      "behaviors" (can be changed at run time.)
      
      The DontReportUncaught option is removed and is now activated
      unconditionally.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=784196
      3199806e
    • Philip Chimento's avatar
      js: Adapt to new JS::TraceEdge<T> API · a3d22db2
      Philip Chimento authored
      Replacing the old JS_CallFooTracer() API is a new C++ JS::TraceEdge<T>()
      function. It works the same, but is templated. The old API will be going
      away in SpiderMonkey 52.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=784196
      a3d22db2
    • Philip Chimento's avatar
      js: Switch from JS::NullPtr() to nullptr · ef18c5a4
      Philip Chimento authored
      JS::NullPtr() is gone, and instead now functions that took JS::NullPtr()
      as a null handle value take nullptr_t, so we should use C++ nullptr.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=784196
      ef18c5a4
    • Philip Chimento's avatar
      js: Refactor global object creation · 2a38e4ae
      Philip Chimento authored
      In order to more easily create global objects, we refactor code that
      deals with them into gjs/global.cpp and gjs/global.h. Previously global
      objects were set up partly in gjs_context_constructed() and partly in
      gjs_init_context_standard(); we disentangle that code and move everything
      dealing with setting up the GjsContext into gjs_context_constructed(),
      while global object setup moves to gjs_create_global_object().
      
      Since global objects all share the same root importer, we must split the
      setup into two. Creating the root importer is the responsibility of
      gjs_context_constructed(), and it requires that the first global has been
      created. After creating the root importer, the global object is finished
      with gjs_define_global_properties().
      
      In the case of global objects beyond the first, such as the global object
      for the coverage compartment, gjs_define_global_properties() will also
      wrap the root importer in a cross-compartment wrapper so that the new
      global can access it.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=781429
      2a38e4ae
  11. 24 May, 2017 1 commit
  12. 06 May, 2017 1 commit
  13. 18 Apr, 2017 1 commit
  14. 16 Apr, 2017 1 commit
    • Philip Chimento's avatar
      maint: Use correct mode lines in all files · 9e4169eb
      Philip Chimento authored
      I finally figured out why my highlighting was always messed up; the mode
      lines in all these files said "C" whereas they were C++ or JS files. This
      was in such a blind spot that I even copied it to new files that I had
      created in the meantime...
      
      Unreviewed.
      9e4169eb
  15. 01 Apr, 2017 1 commit
  16. 08 Mar, 2017 2 commits
    • Philip Chimento's avatar
      function: Perform dirty exit at FFI boundary · c7bdcaab
      Philip Chimento authored and Philip Chimento's avatar Philip Chimento committed
      If an "uncatchable" (SpiderMonkey term) exception is thrown (that is,
      return false from a JSAPI call without an exception pending on the
      JSContext), then we have to deal with the condition when returning back
      to C code. We use the uncatchable exception mechanism to implement
      System.exit(), and so gjs_context_eval() checks for this and exits if
      appropriate.
      
      However, when calling System.exit() inside a callback marshalled by FFI,
      the uncatchable exception propagates up to gjs_callback_closure() and
      stopes there. There is nothing that can propagate the exception after
      that point. There may be one or more main loops running, and until they
      exit, we don't even get back to our JSAPI code that will propagate the
      exception up to gjs_context_eval().
      
      Therefore, we do a "dirty exit" (our term) if an FFI callback throws an
      uncatchable exception. This will, unfortunately, trip an assertion if
      SpiderMonkey is compiled in debug mode, because we haven't cleaned up the
      JSContext by the time the JSRuntime is destroyed when the thread exits.
      We can't clean up the JSContext, either, because the caller of
      gjs_context_eval() is still holding a request on the JSContext so if we
      did that we would trip a different assertion.
      
      This SpiderMonkey limitation is reflected in the added test, whereby the
      test will still pass if the script exits with any nonzero code, which
      covers the debug-mode case where we fail the assertion.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=779692
      c7bdcaab
    • Philip Chimento's avatar
      context: Private method to get owner thread · c0fdda01
      Philip Chimento authored
      Each JSRuntime has an associated thread, an "owner thread" in
      SpiderMonkey terminology. Most entry points into the JS engine will check
      if the calling thread is the owner thread. Since we need to check if we
      are on the owner thread in order to decide whether to handle toggle refs
      on objects immediately or to defer them to an idle function, we record
      the owner thread when constructing the GjsContext and provide an internal
      method to retrieve it.
      
      This makes it unnecessary to maintain a static pointer to the owner
      thread in object.cpp, which was causing problems because it would not get
      initialized if no custom classes were created.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=779693
      c0fdda01
  17. 27 Feb, 2017 1 commit
  18. 15 Feb, 2017 1 commit
  19. 13 Feb, 2017 1 commit
    • Philip Chimento's avatar
      object: Refactor to use GjsMaybeOwned instead of keep-alive · ea43a1c4
      Philip Chimento authored
      In object.cpp, we previously kept a GObject's JS wrapper object alive by
      adding it to the keep-alive object. We can now use GjsMaybeOwned for this
      purpose if we add an accessor function to check whether the GjsMaybeOwned
      is in rooted mode.
      
      This is in preparation for an even deeper refactor where we replace the
      JS::Heap wrapper stored in the object's qdata with GjsMaybeOwned as well.
      
      This requires a small change to GjsContext's dispose handler so that we
      handle all pending toggle notifications before doing the first garbage
      collection.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=776966
      ea43a1c4
  20. 08 Feb, 2017 1 commit
    • Philip Chimento's avatar
      js: Refactor dual use of JS::Heap wrapper · cc71606f
      Philip Chimento authored
      The previous situation was that a JS::Heap wrapper was used to root a GC
      thing under some conditions using JS::AddFooRoot() or the keep-alive
      object, and trace or maintain a weak pointer otherwise.
      
      This will not be possible anymore in SpiderMonkey 38. JS::AddFooRoot()
      and JS::RemoveFooRoot() are going away, in favour of
      JS::PersistentRootedFoo. The keep-alive object has its own problems,
      because the SpiderMonkey 38 garbage collector will move GC things around,
      so anything referring to a GC thing on the keep-alive object will have to
      know when to update its JS::Heap wrapper when the GC thing moves.
      
      This previous situation existed in two places.
      
        (1) The JS::Value holding a trampoline's function. If the function was
        owned by the trampoline (the normal case), then it was rooted. If the
        function was a vfunc, in which case it was owned by the GObject class
        prototype and the trampoline was essentially leaked, then it remained a
        weak pointer.
      
        (2) The JSObject associated with a closure. In the normal case the
        object and the closure had the same lifetime and the object was rooted.
        Similar to above, if the closure was a signal it was owned by the
        GObject class, and traced.
      
      For both of these places we now use GjsMaybeOwned, a wrapper that sticks
      its GC thing in either a JS::PersistentRootedFoo, if the thing is
      intended to be rooted, or a JS::Heap<Foo>, if it is not. If rooted, the
      GjsMaybeOwned holds a weak reference to the GjsContext, and therefore
      can send out a notification when the context's dispose function is run,
      similar to existing functionality of the keep-alive object.
      
      This will still need to change further after the switch to SpiderMonkey
      38, since weak pointers must be updated when they are moved by the GC.
      (This is technically already the case in SpiderMonkey 31, but the API
      makes it difficult to do correctly, and in practice it isn't necessary.)
      
      https://bugzilla.gnome.org/show_bug.cgi?id=776966
      cc71606f
  21. 28 Jan, 2017 1 commit
  22. 27 Jan, 2017 1 commit
  23. 26 Jan, 2017 4 commits
    • Philip Chimento's avatar
      context: Root interned strings · bc988e50
      Philip Chimento authored
      We put the collection of interned strings into an array of
      JS::PersistentRootedId to make sure they are not garbage-collected;
      otherwise there was nothing keeping them from being freed.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=776966
      bc988e50
    • Philip Chimento's avatar
      js: Refactor gjs_object_*_property() · f9380569
      Philip Chimento authored
      This code was due for some refactoring, and changing GjsConstString to be
      rooted in the following commit was the opportunity for it. We now have
      gjs_object_get_property(), gjs_object_has_property(),
      gjs_object_set_property(), and gjs_object_define_property() as wrappers
      for JS_GetPropertyById(), etc., that take a GjsConstString constant
      instead of a jsid.
      
      In addition, we rename gjs_object_require_property_value() to be an
      overload of gjs_object_require_property(); the old name was confusing
      because the name _without_ "value" was the one that dealt with a
      JS::Value!
      
      Same rename for gjs_object_require_converted_property_value().
      
      This whole thing allows us to get rid of some code, moving a bunch of
      roots into these new functions. These roots are strictly speaking still
      necessary, but in the next commit we're going to root all the interned
      strings permanently, which should have been done all along.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=776966
      f9380569
    • Philip Chimento's avatar
      context: Empty heap wrapper after removing tracer · d857b26a
      Philip Chimento authored
      This did not break before, but in SpiderMonkey 38 not doing this is more
      likely to cause crashes because the pointer stored in the JS::Heap
      wrapper is more likely to become invalid once it is no longer traced.
      This would crash under SpiderMonkey 38 when executing JS::Heap's
      destructor, so we should instead empty out the wrapper after removing the
      tracer.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=776966
      d857b26a
    • Philip Chimento's avatar
      js: Implement barriers correctly in structs · bb16545b
      Philip Chimento authored
      Fundamental was the only class that didn't have the IMPLEMENTS_BARRIERS
      flag set. In SpiderMonkey 38 it's required on all classes that have a
      trace hook.
      
      In addition, in order to implement barriers correctly we need to make sure
      that JS::Heap's constructor and destructor are called. In most cases we do
      this by making the containing struct a C++ struct, and calling its
      constructor and destructor. In the case of GjsContext (a GObject struct)
      and GjsCoveragePrivate (a GObject private struct) we can't do that, so
      instead we use placement new on the JS::Heap member.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=776966
      bb16545b
  24. 25 Jan, 2017 1 commit
    • Chun-wei Fan's avatar
      Windows: Define a DllMain() · 5ef8799a
      Chun-wei Fan authored and Philip Chimento's avatar Philip Chimento committed
      Use the DllMain() to call JS_Init()/JS_ShutDown() so that we can reduce
      the use of constructors on Windows, and ensure that JS_Init() is called
      when libgjs is being loaded.  As we automatically get a HINSTANCE/HMODULE
      with the DllMain(), make use of it so that we can construct paths to load
      introspection items and scripts at runtime so that we do not need to
      hardcode paths at build time.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=775868
      5ef8799a
  25. 18 Jan, 2017 1 commit
  26. 06 Jan, 2017 1 commit