3. 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
5. 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
6. 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
9. Template-based app model
Wearable web app*
Notification
Communication
DeviceAPI
Host app
Notification
Communication
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
10. 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)
11. WearScript
• JavaScript on Google Glass
• Motivation: rapid experimentation with apps
http://www.wearscript.com/en/latest/
13. 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?
16. 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
17. 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.
18. Diagnosing Leaks
Heap Snapshots in Chrome Dev Tools
https://developers.google.com/chrome-developer-tools/docs/javascript-memory-profiling
19. “3 Snapshot” Technique
1. 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)
20. 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
21. 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!
22. 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!
23. 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
27. 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?)
28. 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