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?
Top Related