Opened 5 years ago

Last modified 5 years ago

#3266 new change

[meta] Libadblockplus based on JavaScriptCore (for iOS)

Reported by: sergz Assignee:
Priority: Unknown Milestone:
Module: Libadblockplus Keywords: meta 2015q4
Cc: mario, fhd Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by sergz)


We would like to reuse our JavaScript core on iOS and in Safari, however there are restrictions from Apple on using of v8, but we may use JavaScriptCore (JSC).


The plan is to refactor the current code, so we can add another implementation of JsValue and JsEngine and then add the implementation of them based on JavaScriptCore.

Regarding other files using v8

In addition there are such files like ConsoleJsObject.cpp, FileSystemJsObject.cpp, WebRequestJsObject.cpp, etc which are heavily using v8, therefore we need to re-implement such functionality for JavaScriptCore as well.

Implementation of platform specific interfaces

It also seems better to have platform specific implementation based on Foundation Framework for iOS and others because it allows to perform some operations in a safer or more efficient way.

Threading model

Although JavaScriptCore supports multi-threading with certain restrictions (BTW, there is no such locking functionality like v8::Locker and v8::Isolate::Scope) it seems safer, natural and more popular (read as less number of new unresolved multithreaded issues with JSC) to use JavaScriptCore only from one thread.
As well as it's not a good idea to create a new thread for setTimeout for example and a new thread for each short background operation, it's better to use some pool of threads for such tasks.

As a result, the library has the following restriction: the client should use it only from one thread with the message loop. It's possible to have several instances of JsEngine and others in the same thread as well as to have several instances in different threads with message loops, but each instance should be accessed only from its thread.


It's a static library which can be linked either with OSX-application or iOS-application. It's not possible to create a Universal Framework (IIRC Universal Framework requires to expose only Objective-C headers), however it's possible to have some kind of universal static library.

Objective-C vs C++

It seems so far there is no need to wrap our C++ code by Objective-C, the client can easily use it via Objective-C++.


The library can throw C++ exception, however so far it does not convert JavaScriptCore errors into C++-exceptions. Pay attention to it during the high level code review and then make it consistent.


  • JavaScriptCore does not work with 64-bit integers it rather works with double for them, however there are methods to deal with 32-bit integers.
  • There is a couple of not implemented things, basically they are not used and there is no API in JavaScriptCore, if we really need them, we might can find some workaround later, as it's already done for some constructors names (that's really a hack). So far, it seems there is no way to implement GetOwnPropertyNames and to get stack trace in the console.log.

What to change

Here will be the list of particular issues.

Change History (5)

comment:1 Changed 5 years ago by sergz

  • Keywords meta added

comment:2 Changed 5 years ago by sergz

  • Description modified (diff)

comment:3 Changed 5 years ago by sergz

Currently the code is available at my github account It has a lot of limitations.

The plan is to perform the high level code review, define the order of merging the changes and what should be done in addition. And then merge it using our usual procedures and tools (create particular issues in this tracker, add them as blocking for the current issue and discuss each change in the codereview tool).

comment:4 Changed 5 years ago by sergz

  • Cc mario fhd added

comment:5 Changed 5 years ago by mario

  • Keywords 2015q4 added
Note: See TracTickets for help on using tickets.