Javascript:SpiderMonkey:OdinMonkey: Difference between revisions

Javascript:SpiderMonkey:OdinMonkey (view source)

Revision as of 22:11, 16 July 2013

732 bytes removed , 16 July 2013

no edit summary

Lw

Confirmed users

367

edits

@@ Line 1: / Line 1: @@
 == Active ==
 * avoid parser memory spike : {{bug|880538}}
-* BinaryData (initial landing) : {{bug|578700}}
+* use float32 math (in general: {{bug|888109}}), propose/add Math.toFloat32 (TODO: bug), and then incorporate into asm.js
-* Improve heap access performance : {{bug|865516}}, {{bug|865523}}, {{bug|869606}}, {{bug|870743}}
+* add SIMD to the JS engine (in general: {{bug|894105}}) and then incorporate into asm.js
-* native vs. asm.js differential profiling : {{bug|861440}}, {{bug|863924}}
 == Larger future projects ==
+* Cache whole asm.js modules based in the browser (TODO: need bug)
+* Compile bytecode/asm.js in parallel for <script async> : (initial support: {{bug|875125}}, need new bug for <script async>)
 * asm.js parser : {{bug|854061}}
-* Fall back to baseline jit for very large functions : {{bug|875174}}
+* fall back to baseline jit for very large functions : {{bug|875174}}
-* Cache whole asm.js modules based in the browser (TODO: need bug)
-* Compile bytecode/asm.js in parallel for <script async> : {{bug|875125}}
+== Farther off ideas ==
-** Wrap up this functionality with a nice JS API, FunctionFuture : {{bug|854627}}
+* FunctionFuture : {{bug|854627}}
-* Add float32 and uint64 to the JS engine (estimated time: 3 month): this involves landing [http://wiki.ecmascript.org/doku.php?id=strawman:value_objects see value objects proposal] ({{bug|749786}}).  Then we can extend asm.js to allow these types.  We'll need to extend the IonMonkey backend to actually allow/optimize uint64/float32.
+* Support GC allocated Java-like objects to allow asm.js generation from JVM/CLR bytecode.  Use [http://wiki.ecmascript.org/doku.php?id=harmony:binary_data BinaryData] to describe class structure.
-* Add SIMD to the JS engine (estimated time: 3 months): first, we need to land [http://wiki.ecmascript.org/doku.php?id=harmony:binary_data BinaryData] objects ({{bug|578700}}) and then extend them to allow value semantics (like uint64/float32).  Then we can define real SIMD operations in asm.js.
-* Support GC allocated Java-like objects (estimated time: 3 months): to allow asm.js generation from JVM/CLR bytecode, support GC-heap allocation of [http://wiki.ecmascript.org/doku.php?id=harmony:binary_data BinaryData] objects.  For this to actually be useful, we'd have to work closely with an actual JS generator project (like http://jsil.org) to ensure we were actually providing a workable target.  For example, we'd probably need some form of a dynamically-checked downcast.
-== Smaller future projects ==
+== Smaller projects ==
-* Improve x86/ARM asm.js-to-asm.js ABI : {{bug|861785}}
+* native vs. asm.js differential profiling : {{bug|861440}}, {{bug|863924}}
+* improve heap access performance : {{bug|865516}}, {{bug|865523}}, {{bug|869606}}, {{bug|870743}}
+* improve x86/ARM asm.js-to-asm.js ABI : {{bug|861785}}
 * further improve FFI calls : {{bug|882399}}, {{bug|886411}}
 * Optimize calls into asm.js code (to avoid the general CallAsmJS C++ trampoline (estimated time: 1 week).