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. -Filip > On Sep 20, 2018, at 9:07 AM, Michael Catanzaro <[email protected]> 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 [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
