Most JSC development focuses on JSVALUE64.  JSVALUE32_64 is currently years 
behind JSVALUE64 - it has no concurrent JIT, no concurrent GC, no FTL.  We 
regularly do tuning that ends up affecting both JSVALUE32_64 and JSVALUE64 
without even testing its impact on JSVALUE32_64.  JSVALUE32_64 is a 
second-class citizen in JSC.

I propose this:

- Enable cloop/JSVALUE64 to work on 32-bit.  I don’t think it does right now, 
but that’s probably trivial to fix.
- Switch Darwin ports to that configuration for 32-bit.
- When changes land to support new features, make it mandatory to support 
JSVALUE64 and optional to support JSVALUE32_64.  Such changes should include 
whoever volunteers to maintain JSVALUE32_64 in CC.

If you guys consider JSVALUE32_64 to be critical, then you can go ahead and 
maintain it.  We’ll let JSVALUE32_64 stay in the tree so long as someone is 
maintaining it.


> On Sep 20, 2018, at 9:07 AM, Michael Catanzaro <> wrote:
> I believe Guillaume has previously established that results in a substantial 
> performance regression for WPE. It is currently running in production on tens 
> of millions of consumer set top boxes. I think that's substantial testing. :)
> Michael

webkit-dev mailing list

Reply via email to