= JavaScriptCore Roundup, April 2012 Edition =

Filip Pizlo moderates.

== Status ==

Two interpreters, two jits!  The low-level interpreter, the "classic"
interpreter, the baseline JIT, and the optimizing JIT (the DFG).  

GC: Parallel GC, enabled in Mac and Qt

ES6 work: Andy Wingo working on this

Test262: ES5 Conformance Suite, preparing for ES6.

Oliver Hunt introduces self, as TC39 member.

Erik Arvidsson introduces self as Google's representative.

Pizlo asks about TC39 status.

Erik answers: there is ES6 and there is Harmony.  Harmony are
things planned for future versions that include but are not limited to
ES6.  The spec is out.  There are contentious things that are in there,
and there.  Modules seem tricky but necessary, V8 does it, JSC should do
it at some point.  The current spec is fairly stable, loading is still
in flux.  Latency and RTTs are a concen.

Modules are lexically scoped and there is no global object at the top of
the scope chain.  Let strict mode only?  The question of sharing also:
loading a module multiple times loads code multiple times, currently,
would be good to fix to allow shared code.  E.g. generated code
references objects from a heap.

Pizlo asks about loading the same module twice from two different
places, what happens.  Oliver says that there isn't an answer yet.

Code sharing is an impl question; do users get to share data, though?

Mark notes that module loaders can prevent sharing.

Oliver notes that the syntax (and semantics?) for importing a module
statically is currently implementation-dependent wrt interpreting the
"from STRING" part.  In JS we will probably expose a module loading
hander.

Pizlo asks about interaction between load handlers and async loading.
Oliver notes that anywhere outside of module loading, you have to use an
async module loader.  You get a callback when that module is able to use
the static imports syntax.

Ggaren asks, module loading implies that there will be a loader for all
JS, even outside the browser.  Oliver says yes, you need to allow
embedders to provide a module loader.  Ggaren says you need a run loop,
event processing, ...  TC39 members say something muddy.

Oliver says the spec provides for a URI mapping, so that getting a
module for a given URI is idempotent.  GGaren says that a run loop makes
GC better too.

Pizlo 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.

Wingo 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).

Ggaren asks if the snapshot automatically gives you a diff: yes, apparently.

Oliver 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)

  * Real stack traces
  * Dump value profiles
  * Heap profiler
  * Heap snapshot
  * Source maps
  * Dumping assembly, bytecode, dfg node graph
  * Line-level profiling (bytecode-level profiling, asm-level profiling, allocation by line)
  * Fix+continue
  * Real profiler
 
Rniwa 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.

GGaren 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.

Pizlo 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.

Pizlo 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".

Tomz 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.

Pizlo 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.

Question about compiling different large pieces of code in parallel.  Pizlo notes that parsing hard to do both lazily and concurrently.

Ggaren 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.

Pizlo notes overlap between parallelism and how you build a VM.  JVMs completely drank concurrent kool-aid, and so it really affected them.

Gavin 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).

Oliver 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.

Zoltan 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.

One 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.

Pizlo is thankful for having so many things to work on.

Some gnashing of teeth regarding proxies.