Tag: JavaScript

What’s New in Chakra JavaScript Engine

A few weeks ago I decided to install Windows 10 Mobile Insider Preview on my Nokia Lumia 630 and played a little bit with it. Since then, I have completely forgotten about it until yesterday when I saw a notification for pending software update (10.0.12562.84). So I grabbed the opportunity to see what changed in Chakra JavaScript engine and JsRT API.

Overview

I am going highlight only some of the architectural changes in Chakra, for more information you can read MSDN documentation. Firstly, Microsoft decided to create new chakra.dll library and keep the old jscript9.dll library for compatibility reasons. This is a good decision because it allows shorter release cycles and provides some space for experimentation as well. Secondly, it seems that Microsoft is all into performance optimizations right now. Some of the most important optimizations are:

  • concurrent JIT compiler
  • new simple JIT compiler (when bailout happens)
  • improved polymorphic inline cache
  • equivalent object type specialization
  • bounds checking elimination (array optimization)
  • minified code optimization (sounds interesting and very promising)
  • concurrent mark-and-sweep GC (mark phase)

Lastly, with the upcoming ECMAScript 6 Microsoft decided to provide better support for it which is a big win for everybody.

JsRT

This is where it becomes interesting. As I work on NativeScript project, I would like to access WinRT APIs from JavaScript. In fact, Microsoft already supports this scenario in WinJS but I am interested in accessing all WinRT APIs and being able to build XAML based UI from JavaScript. Last September I blogged how to embed Chakra in Windows Phone 8.1 but back then this scenario was practically not supported by Microsoft. There wasn’t even jscript9.lib import library for ARM.

I am happy to say that those days are gone. Now, JsRT provides better support for WinRT projections. This is done through the following APIs:

  • JsProjectWinRTNamespace
  • JsInspectableToObject
  • JsObjectToInspectable

Let’s see how this works (I assume you have already installed Windows 10 Technical Preview and Visual Studio 2015 RC). Create new WinRT library project (Visual C++ -> Windows -> Windows Universal -> Windows Runtime Component). In my case I named it WindowsRuntimeComponent1 and created a simple Greeter class as follows.

namespace WindowsRuntimeComponent1
{
    public ref class Greeter sealed
    {
    public:
        Platform::String^ SayHello()
        {
            return ref new Platform::String(L"Hello");
        }
    };
}

Create an empty app (Visual C++ -> Windows -> Windows Universal -> Blank App) and add reference to the WindowsRuntimeComponent1 project. You have to define the macro USE_EDGEMODE_JSRT  in order to use the new JsRT API and link against chakrart.lib as well. Projecting WinRT classes is as easy as follows.

JsErrorCode err = JsProjectWinRTNamespace(L"WindowsRuntimeComponent1");
assert(JsNoError == err);

Now we are ready to consume the projected WinRT classes from JavaScript.

var g = new WindowsRuntimeComponent1.Greeter();
var s = g.sayHello();

I have to say that the debugging experience is almost perfect. I say “almost” only because I don’t see script debugging for ARM devices. I guess since this is Visual Studio 2015 RC it is a kind of expected. Also, you can always use script debugger on Windows Phone emulator since it is running x86 code.

You can find the sample project at GitHub.

Conclusion

Using the new JsRT together with Windows 10 Universal Application Platform (UAP) makes it easy to write apps that use JavaScript scripting. The good thing is that UAP guarantees that your apps will work across all kind of devices. There are some important limitations though:

  • cannot use XAML types (I guess it is still related to WebHostHidden attribute)
  • cannot extend types from JavaScript (again related to XAML)
  • cannot access Chakra in WinJS apps from WinRT components

I guess if you don’t want to build JavaScript/native bridges then the new JsRT is good enough. Resolving the above-mentioned issues will allow writing much more sophisticated apps though. Right now, you can use JsRT for simple scripting and nothing else. Making Chakra engine an open-source project will solve these and other issues. It will allow people to contribute to and customize the engine. Will it ever happen? Only time will tell.

The Quiet Horror of instanceof Operator

During the last months I was busy with NativeScript more than ever. While my work keeps me busy with embedding V8 JavaScript engine I rarely have the chance to write JavaScript. Recently I had to deal with mapping Java OOP inheritance into JavaScript and more specifically I had to fix a failing JavaScript unit test which uses instanceof operator. So I grabbed the opportunity to dig more into instanceof internals.

It is virtually impossible to talk about instanceof operator without mentioning typeof operator first. According MDN documentation

The typeof operator returns a string indicating the type of the unevaluated operand.

As described typeof operator does not seem useful. Probably the most interesting thing the use of unevaluated word. This allows us to test whether particular symbol is defined. For example

if (typeof x !== 'undefined')

will execute without ReferenceError even when x is not present.

Let’s see instanceof documentation

The instanceof operator tests whether an object has in its prototype chain the prototype property of a constructor.

After digging into instanceof operator I was even more puzzled. While typeof operator was introduced since the first edition of ECMAScript it seems that language designer(s) didn’t have clear idea about instanceof operator. It is mentioned as a reserved keyword in the second edition of ECMAScript and it is finally introduced into the third edition of ECMAScript. The operator definition is clear but I have troubles finding meaningful uses. Let’s see the following common example.

if (x instanceof Foo) {
   x.bar();
}

I feel uneasy with the assumption that if x has Foo‘s prototype somewhere in its prototype chain then it is safe to assume that bar exists. Mixing properties of nominal type system with JavaScript just doesn’t seem intuitive to me. I guess there are some practical scenarios where typeof and instanceof operators are useful but my guess is that their number is limited.

Embedding Chakra JavaScript Engine on Windows Phone

Today I am going to show you how to embed Chakra JavaScript engine in Windows Phone 8.1 app. Please note that at the time of writing this app won’t pass Microsoft Windows Store certification requirements. I won’t be surprised though if Microsoft reconsider their requirements in future.

Last year Microsoft released JsRT which exposes C-style API for embedding Chakra JavaScript engine. To use the API you only need to include jsrt.h and add a reference to jsrt.lib. On my machine the header file is located at

C:\Program Files (x86)\Windows Kits\8.1\Include\um\jsrt.h

and the lib files (for x86 and x64 accordingly) are located at

C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\jsrt.lib
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\jsrt.lib

Curiously, there is no jsrt.lib for ARM architecture. It is even more interesting that JsRT is not exposed in Windows Phone SDK. E.g. you won’t find jsrt.h file in

C:\Program Files (x86)\Windows Phone Kits\8.1\Include

neither you will find jsrt.lib in

C:\Program Files (x86)\Windows Phone Kits\8.1\lib\ARM
C:\Program Files (x86)\Windows Phone Kits\8.1\lib\x86

However this shouldn’t discourage us. The first thing we should check is that JsRT API is exposed on Windows Phone 8.1. I know it is there because IE11 shares same source code for desktop and mobile and because Windows Phone 8.1 supports WinRT programming model. Anyway, let’s check it.

Find flash.vhd file. On my machine it is located at

C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.1\Emulation\Images

Use Disk Management and attach flash.vhd file via Action->Attach VHD menu. Navigate to \Windows\System32 folder on MainOS partition and copy JSCRIPT9.DLL somewhere. Open Visual Studio command prompt and run the following command

dumpbin /exports JSCRIPT9.DLL >jscript9.def

Open jscript9.def file in your favorite editor and make sure you see the full JsRT API listed here. Edit the file so it becomes like this one https://gist.github.com/anonymous/88e44e8931cc8d118da9. Run the following command from the Visual Studio command prompt

lib /def:jscript9.def /out:jsrt.lib /machine:ARM

This will generate import library so you can use all exports defined in JSCRIPT9.DLL library. We are almost ready.

We generated jsrt.lib import library for ARM architecture, what’s next? In order to use jsrt.h header in our Windows Phone 8.1 project we must edit it a little bit. First copy it and its dependencies to your project. Here is the list of all the files you should copy

  • activdbg.h
  • activprof.h
  • ActivScp.h
  • DbgProp.h
  • jsrt.h

In case you don’t want JavaScript debugging support you can copy jsrt.h file only and replace all pointers to the interfaces from ActiveScript API with void*. Once you copy the the header files you must edit them to switch to Windows Phone API. To do so, you have to replace WINAPI_PARTITION_DESKTOP with WINAPI_PARTITION_PHONE_APP. It may sound like a lot of work but it is just a few lines change. You can see the change here.

That’s it. Now you can use the new header and lib files in your project. You can find the full source code at https://github.com/mslavchev/chakra-wp81.

In closing I would like to remind you that at present this app won’t pass Windows Store certification requirements. Here is the list of the requirement violations

Supported API test (FAILED)
    This API is not supported for this application type - Api=CoGetClassObject. Module=api-ms-win-core-com-l1-1-1.dll. File=ChakraDemoApp.exe.
    This API is not supported for this application type - Api=JsCreateContext. Module=jscript9.dll. File=ChakraDemoApp.exe.
    This API is not supported for this application type - Api=JsCreateRuntime. Module=jscript9.dll. File=ChakraDemoApp.exe.
    This API is not supported for this application type - Api=JsDisposeRuntime. Module=jscript9.dll. File=ChakraDemoApp.exe.
    This API is not supported for this application type - Api=JsRunScript. Module=jscript9.dll. File=ChakraDemoApp.exe.
    This API is not supported for this application type - Api=JsSetCurrentContext. Module=jscript9.dll. File=ChakraDemoApp.exe.
    This API is not supported for this application type - Api=JsStartDebugging. Module=jscript9.dll. File=ChakraDemoApp.exe.
    This API is not supported for this application type - Api=JsStringToPointer. Module=jscript9.dll. File=ChakraDemoApp.exe.

Hopefully Microsoft will revisit their requirements.

Running JavaScriptCore on Windows Phone 8.1

After the first release of NativeScript I decided to spend some time playing with JavaScriptCore engine. We use it in NativeScript bridge for iOS and so far I heard good words about it from my colleagues. So I decided to play with JavaScriptCore and compare it to V8 engine.

At present NativeScript supports Android and iOS platforms only. We have plans to add support for Windows Phone as well and I thought it would be nice to have some experience with JavaScriptCore on Windows Phone before we make a choice between Chakra and JavaScriptCore.

The first difference I noticed between JavaScriptCore and V8 is that it has an API much closer to C style while the V8 API is entirely written in C++. This is not an issue and sometimes I consider it as an advantage.

The second difference, in my opinion, is that JavaScriptCore API is more simpler and expose almost no extension points. From this point of view I consider the V8 API the better one. Compared to JavaScriptCore, V8 provides much richer API for controlling internals of the engine like JIT compilation, object heap management and garbage collection.

Nevertheless it was fun to play with JavaScriptCore engine. You can find a sample project at GitHub.

Synchronizing GC in Java and V8

In the last post I wrote that I work on a project that involves a lot of interoperability between Java and V8 JavaScript engine. Here is an interesting problem I was investigating the last couple of days.

Both V8 and JVM use garbage collector for memory management. While using GC provides a lot of benefits sometimes having two garbage collectors in a single process can be tricky though. Suppose we have a super-charged version of LiveConnect where we have access to the full Java API.

var file = new java.io.File("readme.txt");

console.log("length=" + file.length());

These two lines of JavaScript may seem quite simple at first glance. We create an instance of java.io.File and call one of its methods. The tricky part is that we are doing this from JavaScript and we must take care that the actual Java instance would not be GC’ed before we call length method. In other words, we should provide some form of memory management. Suppose we decide to use JNI global references and we call NewGlobalRef every time when we create a new Java object from JavaScript. Accordingly we call DeleteGlobalRef when V8 makes Java object unreachable from JavaScript.

Let’s see a more complicated scenario.

var outStream = new java.io.FileOutputStream("log.txt");

var eventCallback = new com.example.EventCallback({
    onDataReceived: function(data) {
       outStream.write(data);
    }
});

var listener = new com.example.EventListener(eventCallback);

In this case we create an instance of com.example.EventCallback and provide its implementation in JavaScript. Now suppose that all these three JavaScript objects become unreachable and V8 is ready to GC them. Just because all of these objects are unreachable in JavaScript it does not mean that their actual counterparts in Java are unreachable. It’s possible that listener and eventCallback objects are still reachable through a stack of a listener Java thread.

gcchain

Now comes the interesting detail. While in JavaScript eventCallback has a reference to outStream through the function onDataReceived there is no such reference in Java and it is legitimate for Java GC to collect outStream object. The next time when the callback object calls write method there won’t be a corresponding Java object and the application will fail.

There are several solutions to this problem. One of them is to maintain the reachability in Java GC heap graph in sync with the one in JavaScript. After all, if there is an edge connecting eventCallback and outStream Java GC won’t try to collect the latter.

There are two options:

  • sync Java heap graph automatically
  • sync Java heap graph manually

As usual there is a trade-off. While the first option is very desirable there is a price to pay. We should analyze every closure in V8 that is GC’ed and traverse all objects reachable from there. This could slow down the GC by orders of magnitude.

The second option also has drawbacks. In general, JavaScript developers are not used to manual memory management. Introducing new memory management API could cause a lot of discomfort to the less experienced JavaScript developers.

scope(eventCallback, outStream);

Event if we make the API nice and simple, there is a burden of the mental model that JavaScript developers have to maintain. I tend to prefer this option though because many C/C++ developers proved it is possible to build high quality software using manual memory management.

In closing I would say that there are other solutions to this problem. I’ll discuss them in another blog post.

Java and V8 Interoperability

The project I currently work on involves a lot of Java/JavaScript (V8 JavaScript engine) interoperability. Fortunately, Java provides JNI and V8 has a nice C++ API which make the integration process very smooth. Most of the Java-JNI-V8 type marshaling is quite straightforward but there is one exception.

The JNI uses modified UTF-8 strings to represent various string types. Modified UTF-8 strings are the same as those used by the Java VM. Modified UTF-8 strings are encoded so that character sequences that contain only non-null ASCII characters can be represented using only one byte per character, but all Unicode characters can be represented.

I was well aware of this fact since the beginning of the project but somehow I neglected it. Until recently, when one of my colleagues showed me a peculiar bug that turned out to be related to the process of marshaling a non-trivial Unicode string.

At first, I tried a few quick and dirty workarounds just to prove that the root of problem is more complex it seemed. Then I realized that jstring type is not the best type when it comes to string interoperability with V8 engine. I decided to use jbyteArray type instead of jstring though I had some concerns about the performance overhead.

private static native void doSomething(byte[] strData);

String s = "some string";
byte[] strData = s.getBytes("UTF-8");
doSomething(strData);

The code doesn’t look ugly though the string version looks better. I did microbenchmarks and it turned out the performance is good enough for my purposes. Nevertheless, I decided to compare the performance with Nashorn JavaScript engine. As expected, Nashorn implementation was faster because it uses the same internal string format as the JVM.

ECMAScript 262 And Browser Compatibility

I was curious to check how well the current browsers implement ECMAScript 262 specification. At the time of writing I have the following browsers installed on my machine:

  • Google Chrome (34.0.1847.116 m)
  • Microsoft IE (11.0.9600.17031 / 11.0.7)
  • Mozilla Firefox (28.0)

I guess Chrome, IE and Firefox present at least 90% of all desktop browsers. I tested them against the test suite provided by ECMA (http://test262.ecmascript.org) and it turned out none of them passed all the tests. Here is the list of failing tests for each browser.

I know that some of the smartest guys in IT work on these projects for many years. So, the next time I hear that JavaScript is a simple scripting language I won’t consider it seriously.