Project Proposal for CPSC-881: Stage 4

Josiah Hester Ravi Mandliya

jhester@clemson.edu

rmandli@g.clemson.edu

Yunhao Wan

yunhaow@clemson.edu
November 12, 2012

Introduction

One of the ways to make something work, is to eliminate the reasons why it would not work. Why Javascript would be not suitable for a sensor nodes platform is because of its non-deterministic, memory and resources consuming nature. If we eliminate the causes of these factors from Javascript, we may be left with javascript with less functionalities however suitable for our needs for a sensor network. We identied some major resource consuming features of javascript and measured their consumption on various platforms. This gives us an insight on which features we can accommodate in our Javascript model for sensor nodes. In the next part we worked on mapping of native code with the javascript libraries . We also investigated on current approach of garbage collection in Javascript and how that can be implemented in sensor nodes platform. We also tried to understand how these features and issues were handled in other language implementation in sensor networks.

Related Work

Darjeeling is an implementation of JVM on the mote. It implemented a large subset of JAVA with sacricing some features like oat data type, reection etc. It can be runned on 8-bit or 16-bit motes platforms. It also requires several hundreds KB of memories to run the JVM, which is still a great 1

burden for most of the existing sensor nodes. Meanwhile, the performance of Darjeeling is far from satisfaction, it can only be used in some specic situations. Mate is a communication-centric virtual machine designed for sensor nodes. It encapsulated instructions to simplify the programming and allow large network to be frequently reprogrammed in an energy-ecient way.

Design

- Best javascript features - Get rid of JavaScript features that are too CPU or memory intensive (use jsperf results), mixed arrays, multidimensional arrays. Nested closures. Currently Garbage collection in Javascript is more 'Performance' centric than 'Memory' centric. In sensor nodes, there is memory constraint and we need a bit dierent approach. A simple garbage collection model usually implemented in browsers is generational javascript model. In this model, the javascript garbage collector split the heap into several Generations.Shortlived objects tend to be collected more frequently than long-lived objects in the heap. Upon each garbage collection, any objects which aren't collected can be promoted to the long-lived generation. The idea is that by running garbage collection less frequently on longer-lived generations, garbage collection can feel more responsive. This model can be used in our sensor nodes model, however we need to keep track of our small heap memory. If heap memory is used above a threshold we need to increase the garbage collection frequency. If heap is being used above threshold for a specic time, we need to remove the oldest generations along with short lived objects which can be freed from the heap. This method might increase the pause time, however as it is mentioned in Darjeeling,high performance is not very critical in sensor application. Another question is can we implement something like Garbage Compaction Algorithm to reduce the holes in heap like it is done in Darjeeling.
3.1 Top Matter

Garbage Collection

This subsection's content...

Implementation

In order for JavaScript programs to access the node hardware, native libraries, and the virtual machine state, some mechanism for calling native methods is required. We will take advantage of the global scope of JavaScript as well as the RequireJS [http://requirejs.org] pattern, and make available certain global libraries that are implemented in native code, similar to the approach in the Darjeeling paper. JavaScript scoping is an interesting medley of C++, Scheme and LISP, scoping rules. Essentially JavaScript has functional scope, and global scope, for linking native libraries, we will ignore functional scope and treat any dependencies included in functional scope, as if they were in global scope. This will be a transparent detail to the programmer, for example, to access a library that will allow you to set the LEDs, you would do this:
// This tells the interpreter we need to link this library var ledLibrary = require(native/LED); // This calls one of many methods inside the library, note native type // function signature setLED(Uint16 id, Uint16 on) ledLibrary.setLED(Uint16(0), Uint16(1));

The native code implementation of this would be:

void native_led_setLED { // Pop arguments off the stack // in reverse order int16 t_on = dj_exec_stackPopShort(); int16 t_id = dj_exec_stackPopShort(); // Turn on an LED if (id==0) fos_leds_blue(on); if (id==1) fos_leds_green(on); if (id==2) fos_leds_red(on); }

Arguments would be popped o the stack in reverse order, then used in the main body of the native method call. This would function similarly to how SWIG[http://www.swig.org] bindings work, or even KrollContext in the TitaniumSDK. 3