SWTT 140407 session04
-
Upload
seo-young-hwang -
Category
Technology
-
view
105 -
download
1
description
Transcript of SWTT 140407 session04
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?