SWTT 140407 session04

556 views

Published on

SWTT(7th Apr 2014) Session 04
- Title: "JavaScript in the Small"
- Speaker: Satish Chandra, Samsung

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
556
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

SWTT 140407 session04

  1. 1. JavaScript in the small Satish Chandra ! Manu Sridharan, Simon Jensen, Koushik Sen, Ming Jin
  2. 2. Wearables computers have arrived Products from Samsung, Pebble, Google, Qualcomm, Nike and Fitbit
  3. 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
  4. 4. Outline • Programming models for wearables • Why JavaScript? • Application memory considerations • Evolving JavaScript
  5. 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. 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
  7. 7. Gear application model standalone Wearable web app (HTML/CSS/JS) Notification Communication DeviceAPI
  8. 8. Gear application model companion Wearable web app (HTML/CSS/JS) Notification Communication DeviceAPI Host app Notification Communication
  9. 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. 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. 11. WearScript • JavaScript on Google Glass • Motivation: rapid experimentation with apps http://www.wearscript.com/en/latest/
  12. 12. JS in embedded controllers 48 KB RAM32 MB RAM
  13. 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?
  14. 14. Memory size 2011 2012 2013 20142010 0.5G 1.0G 2.0G ?
  15. 15. JavaScript Memory Best Practices
  16. 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. 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. 18. Diagnosing Leaks Heap Snapshots in Chrome Dev Tools https://developers.google.com/chrome-developer-tools/docs/javascript-memory-profiling
  19. 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. 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. 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. 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. 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
  24. 24. Leaner JavaScript?
  25. 25. 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
  26. 26. 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 Language restrictions
  27. 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. 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
  29. 29. Tessel • AOT compiles JavaScript to Lua byte-code outside the device • The device contains a Lua JIT runtime
  30. 30. Questions?

×