JavaScript in the smallSatish Chandra

!Manu Sridharan, Simon Jensen, Koushik Sen, Ming Jin

Wearables computers have arrived

Products from Samsung, Pebble, Google, Qualcomm, Nike and Fitbit

Wearable computers

• Form factor: capable of being worn for an extended period of time

• Smart: advanced processing and wireless connectivity

• Programmable: extend functionality by installing [third-party] apps

Outline

• Programming models for wearables

• Why JavaScript?

• Application memory considerations

• Evolving JavaScript

What’s different from smartphones?

• Less resources than on a smartphone

CPU, memory, battery capacity

• No independent WAN connectivity (current generation)

Make do with Bluetooth to a host

• Smaller (or no) display

• Sensors enabled by form factor

Application models• Standalone applications

• Applications dependent on a host (typically a smartphone)

Bluetooth connectivity to the host

Some future devices may have direct connectivity to the internet

Gear application model standalone

Wearable web app (HTML/CSS/JS)

Not

ifica

tion

Com

mun

icat

ion

Dev

ice

API

Gear application model companion

Wearable web app (HTML/CSS/JS)

Not

ifica

tion

Com

mun

icat

ion

Dev

ice

API

Host app

Not

ifica

tion

Com

mun

icat

ion

Template-based app model Wearable web app*

Not

ifica

tion

Com

mun

icat

ion

Dev

ice

API

Host app

Not

ifica

tion

Com

mun

icat

ion

Template manager

A template is equipped to display a JSON object in a fixed UI format. A template manager supports a set of templates. Does not need full web app support

Why JavaScript?• Popular. Atwood’s law.

• Runs in smartphones, desktops, servers, and even in embedded controllers

• Suitable for event-based programming

• Easy to build responsive UIs for various screen resolutions (with HTML/CSS)

WearScript

• JavaScript on Google Glass

• Motivation: rapid experimentation with apps

http://www.wearscript.com/en/latest/

JS in embedded controllers

48 KB RAM32 MB RAM

JavaScript, efficiently• Wearables are likely to have less computational

resources than smartphones

• Should wearables pay for a full-fledged JavaScript environment?

Less memory

Expectation of longer battery life too

• What if, realistic apps on wearables need only limited scripting support?

Memory size

2011 2012 2013 20142010

0.5G

1.0G

2.0G

?

JavaScript Memory Best Practices

Avoid Memory Leaks• Space leaks: objects kept reachable after last use

• If reachable, cannot be collected by GC

• With old browsers, also GC bugs with DOM objects

• Workarounds in frameworks (GWT, jQuery)

• Less of an issue with modern browsers

Leak Patterns• Closures: sometimes retain unexpected pointers

• Detached DOM nodes: Pointers from JavaScript heap prevent GC

• Event listeners: additional pointers must be cleared when DOM node dies

• Standard issues: caches, etc.

Diagnosing Leaks

Heap Snapshots in Chrome Dev Tools https://developers.google.com/chrome-developer-tools/docs/javascript-memory-profiling

“3 Snapshot” Technique1. Take a snapshot

2. Perform possibly-leaking action

3. Do steps 1 and 2 again

4. Take a third snapshot.

5. In third snapshot, view objects allocated between first and second snapshot (i.e., leaked objects)

Memory-Efficient Code• Avoid hash table object representation!

• For V8 objects, stable type structure!

• Don’t delete properties

• Don’t add properties unpredictably

• Same for arrays, and avoid mixing types

Staleness

• Staleness: long gap between last use and garbage collection !• A high number of stale objects indicates a potential problem !• To prevent staleness the programmer should ensure that object

becomes unreachable sooner so they can be garbage collected

!• Typical causes of staleness: Closures, caches and event listeners

Object allocated ! Object used ! Object is unreachable !

Staleness!

Detecting Staleness

• Difficult to accomplish with periodic heap snapshots because “use” is not recorded

• A continuous dynamic analysis that records all allocations, reads and writes is needed

Also keep track of links between objects

Object allocated ! Object used ! Object is unreachable !

Staleness!

Jalangi• Jalangi is a framework for doing record and replay

of JavaScript programs Developed at Samsung

!• Recorded executions can be replayed with

different analyses !

• Supports recording in both browser and node.js !

• Open source: https://github.com/SRA-SiliconValley/jalangi

Leaner JavaScript?

Rendering JS runtime / GC JS interpreter

JS libs / frameworks (jQuery)

Application

Memory usage analyses: leak / bloat detection,

object-equality profiling

Framework specialization, lazy

loading

Ahead-of-time compilation

Quasi-static memory

management

Restricted DOM API

Rendering JS runtime / GC JS interpreter

JS libs / frameworks (jQuery)

Application

Memory usage analyses: leak / bloat detection,

object-equality profiling

Framework specialization, lazy

loading

Ahead-of-timecompilation

Quasi-staticmemory

management

Restricted DOM API

Language restrictions

Language Restrictions• asm.js

Only typed array

Enabler for AOT compilation: no GC, no unboxing, no runtime checks, efficient loads and stores, etc

• LLJS

C-like, manual memory management. (asm.js with C-like syntactic sugar)

• Statically type-able subsets

• Other proposals (interest from ECMA?)

Espruino• Executes from source!

• Every datatype is allocated in a 20-byte chunk (strings and typed arrays are packed)

• Objects use two chunks per (key, value) pair

• Reference counting and occasional mark-and-sweep

Tessel

• AOT compiles JavaScript to Lua byte-code outside the device

• The device contains a Lua JIT runtime

Questions?