Re: [webkit-dev] Disabling the 32-bit JITs by default.

> On Feb 19, 2018, at 10:53 AM, Guillaume Emont wrote: > > Hi Keith, > > We at Igalia have been trying to provide a better story for 32-bit > platforms, in particular for Armv7 and MIPS. These platforms are very > important to us, and disabling JIT renders many use cases impossible. What use c

Re: [webkit-dev] Disabling the 32-bit JITs by default.

> On Feb 19, 2018, at 11:43 AM, Guillaume Emont wrote: > > Quoting Filip Pizlo (2018-02-19 13:05:27) >> >>> On Feb 19, 2018, at 10:53 AM, Guillaume Emont wrote: >>> >>> Hi Keith, >>> >>> We at Igalia have been trying to provid

Re: [webkit-dev] Disabling the 32-bit JITs by default.

> On Feb 19, 2018, at 1:03 PM, Adrian Perez de Castro wrote: > > Hello everybody, > > On Mon, 19 Feb 2018 13:43:38 -0600, Guillaume Emont > wrote: >> Quoting Filip Pizlo (2018-02-19 13:05:27) >>> >>>> On Feb 19, 2018, at 10:53 AM, Guillaume Emo

Re: [webkit-dev] Disabling the 32-bit JITs by default.

, we won’t keep them building or working. How does that sound? -Filip > On Feb 19, 2018, at 5:12 PM, Guillaume Emont wrote: > > Quoting Filip Pizlo (2018-02-19 14:17:44) >> >>On Feb 19, 2018, at 11:43 AM, Guillaume Emont >> wrote: >> >>Q

Re: [webkit-dev] Style guidelines for braced initialization

> On Apr 26, 2018, at 10:35 AM, ross.kirsl...@sony.com wrote: > > Hi everybody, > > A simple question regarding https://webkit.org/code-style-guidelines/ > : > > I've currently got a clang-format patch up (https://reviews.llvm.org/D46024) >

Re: [webkit-dev] bmalloc design question about relation with std malloc

Ideally we would use the mmap allocator. But I wouldn’t do that if it causes a space usage regression, for example if we allocate a lot of small vectors. -Filip > On Apr 30, 2018, at 3:35 AM, Yusuke SUZUKI wrote: > > Hi, WebKittens, > > IIRC, bmalloc uses mmap based page allocator for intern

Re: [webkit-dev] Question about ARMv7 JIT maintenance by Apple

We aren’t maintaining armv7. -Filip > On May 4, 2018, at 7:01 PM, Yusuke SUZUKI wrote: > > Hi WebKittens, > > JSC has X86, X86_64, ARM64, ARM, ARMv7, and MIPS JIT architectures. > While X86, X86_64, and ARM64 is maintained by build bots configured by Apple, > the other architectures are maint

Re: [webkit-dev] JavaScriptCore on Fuchsia

Hi Adam, This looks super interesting! I have some questions: - Does your JSC port enable all of JSC’s optimization features, like the FTL JIT and concurrent GC? - Is it a goal to enable basically everything we enable, long term? - Is this 32-bit, 64-bit, or both? - Is this mainly for

Re: [webkit-dev] JavaScriptCore on Fuchsia

> On Jun 26, 2018, at 2:28 PM, Adam Barth wrote: > > On Tue, Jun 26, 2018 at 2:08 PM Filip Pizlo wrote: >> This looks super interesting! > > Thanks. :) > >> I have some questions: >> >> - Does your JSC port enable all of JSC’s optimization featur

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

I don’t like this proposal. If we are running low on memory, we should switch to bounds checked memory. -Filip > On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki > wrote: > > Posted this mail to webkit-dev mailing list too :) > > On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki > wrote: > > Thanks! > > On Wed, Aug 29, 2018 at 3:22 Filip Pizlo <mailto:fpi...@apple.com>> wrote: > I don’t like this proposal. > > If we are running low on memory, we should switch to bounds checked memory.

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

> On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki > wrote: > > > > On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki <mailto:yusukesuz...@slowstart.org>> wrote: > > > On Wed, Aug 29, 2018 at 3:27 Filip Pizlo <mailto:fpi...@apple.com>> wrote: >

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

> On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki > wrote: > > > > On Wed, Aug 29, 2018 at 3:58 Filip Pizlo <mailto:fpi...@apple.com>> wrote: > >> On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki > <mailto:yusukesuz...@slowstart.org>> wrote: >>

Re: [webkit-dev] node-jsc: A node.js port to the JavaScriptCore engine and iOS

Wow! That’s pretty cool! I think that it would be great for this to be upstreamed. Can you create a bug on bugs.webkit.org and post your patches for review? -Filip On Sep 13, 2018, at 4:02 PM, Koby Boyango mailto:koby.b@mce.systems>> wrote: > Hi, > > I'm Koby Boyang

Re: [webkit-dev] node-jsc: A node.js port to the JavaScriptCore engine and iOS

;> 1. We can run tests designed for node.js, it makes our JSC implementation >> more solid. >> 2. We can run benchmarks designed for node.js including JS libraries. JS >> libraries distributed in npm are more and more used in both node.js and >> browser world. >&g

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

> On Sep 16, 2018, at 4:03 PM, Darin Adler wrote: > > I noticed that the “Offline Assembler” build step was taking between 5 and 30 > seconds every time I build. Really stands out in incremental builds. I > realized that this step does not do any dependency analysis. Every time, it > builds

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

> On Sep 16, 2018, at 8:48 PM, Darin Adler wrote: > >> On Sep 16, 2018, at 5:59 PM, Filip Pizlo wrote: >> >> Which offline assembler build step are you referring to? > > The one that is the “Offline Assembler” target in Xcode, which runs this > command: &g

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

possible to run it in parallel to other steps. -Filip > On Sep 17, 2018, at 10:01 AM, Darin Adler wrote: > > I don’t know. > > Sent from my iPhone > >> On Sep 17, 2018, at 7:49 AM, Filip Pizlo wrote: >> >> >> >>> On Sep 16, 2018, at 8:48 PM

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

the > assembly generation half, if there is also a new object offsets binary (from > LLIntOffsetsExtractor.cpp). We’re talking about the compiling of the offset extractor binary and the assembly generation half. -Filip > > Cheers, > Keith > >> On Sep 17, 2018,

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

> On Sep 17, 2018, at 1:41 PM, Darin Adler wrote: > > Sent from my iPhone > >> On Sep 17, 2018, at 10:21 AM, Filip Pizlo wrote: >> >> Sorry, I should have asked: does it even rebuild when you change nothing? > > I don’t know what it’s doing, only how

Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

I think that we should move to removing JSVALUE32_64, since it doesn’t get significant testing or maintenance anymore. I’d love it if 32-bit targets used the cloop with JSVALUE64, so that we can rip out the 32-bit jit and offlineasm backends, and remove the 32-bit representation code from the ru

Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

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 s

Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

elopment should be encouraged to land changes only for 64-bit since that’s our focus as a project. -Filip > > Guillaume > >> >> On Fri, Sep 21, 2018 at 2:33 AM Michael Catanzaro >> wrote: >> >>>On Thu, Sep 20, 2018 at 12:02 PM, Filip Pizlo wrote: &g

Re: [webkit-dev] Intent to land PlayStation port

> On Oct 29, 2018, at 2:19 PM, don.olmst...@sony.com wrote: > > Hello WebKittens, > > We've been working hard on our WinCairo port of WebKit and would like to > begin landing our PlayStation port to trunk. We have opened a meta bug at > https://bugs.webkit.org/show_bug.cgi?id=191038 >

Re: [webkit-dev] Intent to land PlayStation port

> On Oct 29, 2018, at 2:32 PM, don.olmst...@sony.com wrote: > > The PlayStation is x64. No JIT in the initial implementation. Music to my ears! -Filip > > From: fpi...@apple.com > Sent: Monday, October 29, 2018 2:29 PM > To: Olmstead, Don > Cc: WebKit Development > Subject: Re: [webkit-

Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

I like to draw this distinction: is the initializer a constant? It’s not a constant if it relies on arguments to the constructor. “This” is an argument to the constructor. It’s also not a constant if it involves reading the heap. So, like you, I would want to see this code done in the constru

Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

s in WebKit it would add lots of >> duplication with little benefit. If it were a class with a default >> constructor we would have a high risk of forgetting a constructor somewhere. >> >>> On Mar 20, 2019, at 9:22 AM, Simon Fraser wrote: >>> >>>> On

Re: [webkit-dev] Concurrent JS and 32bit platforms

> On Apr 11, 2019, at 7:03 AM, Xan wrote: > > Hi all, > > as part of our work on improving 32bit support in JSC we at Igalia are > planning to have a look at enabling concurrent js We don’t support concurrent JavaScript. We do have concurrent JITs and concurrent GC. > for these platforms

Re: [webkit-dev] Tadeu and Robin are now WebKit reviewers

Congrats! -Filip > On Jun 10, 2019, at 6:10 PM, Yusuke Suzuki wrote: > > Congrats! :D > >> On Jun 10, 2019, at 3:49 PM, Saam Barati wrote: >> >> Hi folks, >> >> Tadeu and Robin are both now WebKit reviewers. Join me in congratulating >> them. Please ask them to review your code! They both

Re: [webkit-dev] Accidental binary bloating via C/C++ class/struct + Objective-C

Wow, that sounds like an awesome find! -Filip > On Jan 13, 2020, at 5:53 PM, Yusuke Suzuki wrote: > > Hello WebKittens, > > I recently striped 830KB binary size in WebKit just by using a work-around. > This email describes what happened so far, to prevent from happening again. > > ## Problem

Re: [webkit-dev] Request for position on Atomics.waitAsync

I think it’s a good idea. It seems to be a decent fit for how WK handles this already internally. -Filip > On Aug 28, 2020, at 3:52 AM, Marja Hölttä wrote: > >  > Hi Webkit-Dev, > > I would like to get an official position from Webkit on the Atomics.waitAsync > JavaScript feature (TC39 Sta

<    1   2   3   4