Changes between Initial Version and Version 1 of April 2012 JavaScriptCore Roundup


Ignore:
Timestamp:
Apr 20, 2012, 11:34:20 AM (13 years ago)
Author:
wingo@igalia.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • April 2012 JavaScriptCore Roundup

    v1 v1  
     1= JavaScriptCore Roundup, April 2012 Edition =
     2
     3Filip Pizlo moderates.
     4
     5== Status ==
     6
     7Two interpreters, two jits!  The low-level interpreter, the "classic"
     8interpreter, the baseline JIT, and the optimizing JIT (the DFG). 
     9
     10GC: Parallel GC, enabled in Mac and Qt
     11
     12ES6 work: Andy Wingo working on this
     13
     14Test262: ES5 Conformance Suite, preparing for ES6.
     15
     16Oliver Hunt introduces self, as TC39 member.
     17
     18Erik Arvidsson introduces self as Google's representative.
     19
     20Pizlo asks about TC39 status.
     21
     22Erik answers: there is ES6 and there is Harmony.  Harmony are
     23things planned for future versions that include but are not limited to
     24ES6.  The spec is out.  There are contentious things that are in there,
     25and there.  Modules seem tricky but necessary, V8 does it, JSC should do
     26it at some point.  The current spec is fairly stable, loading is still
     27in flux.  Latency and RTTs are a concen.
     28
     29Modules are lexically scoped and there is no global object at the top of
     30the scope chain.  Let strict mode only?  The question of sharing also:
     31loading a module multiple times loads code multiple times, currently,
     32would be good to fix to allow shared code.  E.g. generated code
     33references objects from a heap.
     34
     35Pizlo asks about loading the same module twice from two different
     36places, what happens.  Oliver says that there isn't an answer yet.
     37
     38Code sharing is an impl question; do users get to share data, though?
     39
     40Mark notes that module loaders can prevent sharing.
     41
     42Oliver notes that the syntax (and semantics?) for importing a module
     43statically is currently implementation-dependent wrt interpreting the
     44"from STRING" part.  In JS we will probably expose a module loading
     45hander.
     46
     47Pizlo asks about interaction between load handlers and async loading.
     48Oliver notes that anywhere outside of module loading, you have to use an
     49async module loader.  You get a callback when that module is able to use
     50the static imports syntax.
     51
     52Ggaren asks, module loading implies that there will be a loader for all
     53JS, even outside the browser.  Oliver says yes, you need to allow
     54embedders to provide a module loader.  Ggaren says you need a run loop,
     55event processing, ...  TC39 members say something muddy.
     56
     57Oliver says the spec provides for a URI mapping, so that getting a
     58module for a given URI is idempotent.  GGaren says that a run loop makes
     59GC better too.
     60
     61Pizlo asks how this affects workers.  Erik says he doesn't see how it affects workers at all.  Erik says that there are two modes: one that allows loading and one that does not.  `<script async="">`.  Oliver doubts script async will make it.  Some confusion.
     62
     63Wingo asks about feedback and developer tools.  Pizlo says that there is some simple plumbing that can be done there.  IR dumping and bytecode dumping is always built, and guarded by globals.  One option is to plumb through API to to turn these off and on.  Joe mentions the JavaScript CPU profiler, giving time in functions.  Rniwa nots that there are apple inspector features that are only enabled in V8, and implementing those bits would be good.  E.g. heap profiler, stack tracing.  More.  Oliver notes that you can always get stack traces.   Someone notes that there are bugs that open;  Gavin notes that things have improved a lot in the last couple weeks.  Oliver also says that the inspector shouldn't model the stack, and just ask JSC for the stack.  Rniwa said that in a hackathon to find gmail's leak, and that the heap snapshor and diff feature was really useful to them.  Oliver says that JSC has no heap profiling currently.  Gavin asks for clarification.  Some nodding of heads (in agreement).
     64
     65Ggaren asks if the snapshot automatically gives you a diff: yes, apparently.
     66
     67Oliver asks if we can make a list of tools that help JS writers and JSC embedders.  (The intention would be to figure out what's useful for the inspector)
     68
     69  * Real stack traces
     70  * Dump value profiles
     71  * Heap profiler
     72  * Heap snapshot
     73  * Source maps
     74  * Dumping assembly, bytecode, dfg node graph
     75  * Line-level profiling (bytecode-level profiling, asm-level profiling, allocation by line)
     76  * Fix+continue
     77  * Real profiler
     78 
     79Rniwa notes that while the inspector gives you lots of information, it's unclear what to do to make things faster.  Oliver says it's tough, but that Shark used to do this, and we should try to have that in the inspector: to beat Instruments.
     80
     81GGaren asks about counts vs sampling.  Pizlo says that precise counts are what he's used to doing GC work.  Useful for identifying the source of a heap object leak.  Wingo asks about statistical profiling based on GC.  Pizlo says that the statistics don't add up, you only GC some 10 times a second.  Mark notes that GC can expose more statistics.
     82
     83Pizlo proposes that the engine expose a statistical profile, and a counter-based profile for each basic block.  Oliver says that he wanted to do that for a while.  Someone proposes sampling every N allocations.  There is some discussion but general agreement that it might be a good idea.
     84
     85Pizlo asks what information you want from a GC profiler.  Crickets.  Ggaren says, "why am I running slow, and why am I using too much memory".  Also, "if I make a change, did it help, and how much".
     86
     87Tomz asks about opportunities for taking advantage of multiple cores.  Oliver mentions River Trail.  Pizlo gives reality check: We have workers.  We have a parallel GC.  It is possible to make some parts of the VM run on a separate thread.  E.g., JIT compilation (gavin mentions this).  Pizlo says that however, if you fork off an activity that is already fast to a separate thread, there is an overhead.  DFG compilation is from 100s to 1000s of us.  Automatic parallelization of JS in particular is horrific: even with FP langs, no demonstrable speedup over years of work.  However, there are probably more things in WebKit that can be parallelized.
     88
     89Pizlo notes that VM implementors are using terrible benchmarks in which compiling on the main thread will always be a win.  But if we actually focus on real sites with oodles of code, this could become an advantage.  Oliver notes that modules might offer a means for parallelized compilation.  However JSC has many refcounted objects that may be shared.
     90
     91Question about compiling different large pieces of code in parallel.  Pizlo notes that parsing hard to do both lazily and concurrently.
     92
     93Ggaren notes that a big question about JITing is the processor model.  If you are using one core, are you consuming the same amount of battery as if you are consuming 16 cores?  Because if so we need to use those extra cores.  But if not, if those cores can go to sleep, then perhaps concurrency not a win... Tomz expands on power / time tradeoff.
     94
     95Pizlo notes overlap between parallelism and how you build a VM.  JVMs completely drank concurrent kool-aid, and so it really affected them.
     96
     97Gavin returns to the idea of providing primitives that users can use to enable multicore -- not convinced that it's a great idea, Intel keeps pushing new sets of these primitives and not really succeeding yet.  However perhaps there are higher-level approaches (somewhat unclear).
     98
     99Oliver notes JIT as attack vector for security vulns.  Recently added constant blinding.  Used to do DEP support, but that is currently broken with the DFG and the allocator doesn't support multiple threads in that case.  Notes some Windows feature that avoids overwriting Vtables because vtable overwrite is a vuln.  Question about other potential issues.
     100
     101Zoltan says re: workers, that they are a good opportunity for multicore, but they are not as useful as they could be because they can't get the DOM.  Is there a way to get the DOM to those threads?  Async read and write of DOM properties? Oliver says that the worker model is designed to reduce latency on UI thread, not necessarily to make things faster.  So there is no support for concurrently working on the same data structure.  DOM postMessage can send typed arrays now, perhaps that helps reduce the copy cost.  In summary: reduce latency > share work.
     102
     103One more topic: Inlining getters and setters.  Erik says V8 trying to do it, WebIDL needs it (practically).  Apparently IE team too.  To be clear, ES5 getters and setters.  Oliver says that currently we use _custom_ getters directly on the object, but WebIDL specifies that now they must be standard ES5 getters/setters on the prototype.  Oliver notes that JSC can do getters well, but not setters.  Pizlo says that he should probably fix that.  Oliver notes that we still need to work to not re-enter VM for getters&setters.
     104
     105Pizlo is thankful for having so many things to work on.
     106
     107Some gnashing of teeth regarding proxies.