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

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] 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] 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] 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] 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] 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] 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] [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] [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

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] 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] 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

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

> 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

> 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] 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] 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] 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] 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 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?

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

> 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 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] Meltdown and Spectre attacks

Here is what else is in trunk: - index masking - pointer poisoning I’m going to write up what our thoughts are shortly. :-) For now feel free to browse the code with those two hints. -Filip > On Jan 5, 2018, at 8:31 AM, Konstantin Tokarev wrote: > > > >> Hi, >> >> Here's a collection of

Re: [webkit-dev] Build issues due to anonymous namespace

That also means not using static, for the same reason. FWIW, I think it’s a good idea. -Filip > On Dec 3, 2017, at 12:10 PM, Darin Adler wrote: > > I think it’s also worthwhile to remove the anonymous namespace wrapping each > of these DestroyFunc structures when renaming them. Generally spe

Re: [webkit-dev] Build issues due to anonymous namespace

Maybe just give that DestroyFunc a more unique name like JSSegmentedVariableObjectDestroyFunc. Cc me on such a patch and I’ll happily review it. -Filip > On Dec 3, 2017, at 8:44 AM, Caio Lima wrote: > > Hi guys. I'm working in a Patch that is adding some files to JSC and I faced > following

Re: [webkit-dev] BigInt implementation

Seems like V8’s is an ok place to start. Maybe all you’d have to do is remove the accurate GC artifacts (Handle and such). -Filip > On Oct 19, 2017, at 2:31 AM, Daniel Ehrenberg wrote: > > On 2017-10-19 03:18, Filip Pizlo wrote: >>> On Oct 18, 2017, at 5:50 PM, Caio Lima

Re: [webkit-dev] BigInt implementation

> On Oct 18, 2017, at 5:50 PM, Caio Lima wrote: > > Hi WebKittens. > > I’m planning to start implement JS BigInt proposal on JSC, however I > would like to sync with you the way you are planning to implement such > feature. > > Right now, I’m thinking in implement BigInt operations into C++ >

Re: [webkit-dev] Bring back ARMv6 support to JSC

ntaining the 32_64 value representation is no value for us. -Filip > > -Original Message- > From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of > Filip Pizlo > Sent: Tuesday, September 5, 2017 8:37 AM > To: Adrian Perez de Castro > Cc: webk

Re: [webkit-dev] Bring back ARMv6 support to JSC

There isn’t anyone maintaining the 32-not JIT ports to the level of quality we have in our 64-not ports. Making 32-bit use the 64-bit cloop would be a quality progression for actual users of 32-bit. -Filip > On Sep 5, 2017, at 8:02 AM, Adrian Perez de Castro wrote: > >> On Tue, 5 Sep 2017 16

Re: [webkit-dev] Bring back ARMv6 support to JSC

for ARMv6 looks a good >>>> improvement step and the amount of code we are touching in current >>>> trunk code to make it possible is small. >>>> >>>> The results are attached and I also uploaded them in >>>> https://bugs.webkit.org/show

Re: [webkit-dev] Get rid of RefPtr, replace with std::optional?

> On Sep 1, 2017, at 10:07 AM, Brady Eidson wrote: > > > >> On Sep 1, 2017, at 9:46 AM, Maciej Stachowiak wrote: >>> >>> Does RefPtr do anything for us today that std::optional doesn’t? >> >> The obvious things would be: uses less storage space > > Grumble. If that’s true (which, thinking

Re: [webkit-dev] Get rid of RefPtr, replace with std::optional?

> On Sep 1, 2017, at 10:09 AM, Chris Dumez wrote: > > I think std::optional> looks ugly. Also, unlike RefPtr<>, I do not > think it is copyable. It is pretty neat to be able to capture a RefPtr<> by > value in a lambda. > Also, how do you convert it to a raw pointer? myOptionalRef.value_or(nu

Re: [webkit-dev] Get rid of RefPtr, replace with std::optional?

> On Sep 1, 2017, at 9:30 AM, Brady Eidson wrote: > > I recently worked on a patch where - because of the organic refactoring of > the patch over its development - I ended up with a std::optional instead > of a RefPtr. > > A followup review after it had already landed pointed this out, and i

Re: [webkit-dev] Bring back ARMv6 support to JSC

https://bugs.webkit.org/show_bug.cgi?id=172765. > > PS.: Some test cases (bigswitch-indirect-symbol-or-undefined, > bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm > already investigating the source of problem to fix them. > > Regards, > Caio. >

Re: [webkit-dev] Bring back ARMv6 support to JSC

than bringing it back. -Filip > On Jul 5, 2017, at 6:14 PM, Caio Lima wrote: > > 2017-07-05 18:25 GMT-03:00 Filip Pizlo : >> You need to establish that the JIT is a performance progression over the >> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there

Re: [webkit-dev] Bring back ARMv6 support to JSC

You need to establish that the JIT is a performance progression over the LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is some evidence provided that you’re actually getting speed-ups. -Filip > On Jun 13, 2017, at 6:48 PM, Caio Lima wrote: > > Hi All. > > Some of you

Re: [webkit-dev] Data Memory Barrier ARMv6 question

We should not use those helpers, especially in the JIT. It does not make sense for the JIT to emit calls to system functions when the user is expecting it to emit an instruction. If we cannot perfectly select the right barrier on a particular CPU, we should disable concurrency on that CPU. -Fi

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

> On Jun 13, 2017, at 1:00 PM, Chris Dumez wrote: > > >> On Jun 13, 2017, at 12:51 PM, Filip Pizlo > <mailto:fpi...@apple.com>> wrote: >> >>> >>> On Jun 13, 2017, at 12:37 PM, Alex Christensen >> <mailto:achristen...@apple.com>&g

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

> On Jun 13, 2017, at 12:37 PM, Alex Christensen wrote: > > Ok, maybe we can get rid of std::function, then! I hadn’t used BlockPtr as > much as Chris. I’d be opposed to adding a copy constructor to WTF::Function > because the non-copyability of WTF::Function is why we made it, and it has >

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

And ObjC blocks share instead of copying, which is more like SharedTask. I think that’s another reason why adding copy constructors to WTF::Function that do block-like sharing under the hood is rather attractive. -Filip > On Jun 13, 2017, at 12:29 PM, Alex Christensen wrote: > > std::functi

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

> On Jun 13, 2017, at 11:56 AM, Brady Eidson wrote: > >> >> On Jun 13, 2017, at 9:55 AM, Filip Pizlo > <mailto:fpi...@apple.com>> wrote: >> >> Would SharedTask’s sharing be semantically incorrect for users of >> WTF::Function? In other wo

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

p to each other >> than Function, SharedTask and ScopedLambda. > > Maybe rename Function to UniqueFunction? > >> >> (I'm not sure if the direct assignment from a lambda is an incidental >> difference or one that's required by the different own

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

placement for most uses in WebCore > since we actually very rarely need copying (either it just builds or the code > can be refactored very slightly to avoid the copying). > > -- >  Chris Dumez > > > > >> On Jun 13, 2017, at 9:34 AM, Filip Pizlo > <

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

We should have a better story here. Right now the story is too complicated. We have: - ScopedLambda or ScopedLambdaRef if you have a stack-allocated function that outlives its user - SharedTask if you have a heap-allocated function that you want to share and ref-count - WTF::Function if you h

Re: [webkit-dev] !!Tests for equality comparison

I think that this aspect of the style - its implications for ints - was deliberate. The code uses the !int style in so many places that this style change would be a lot of churn for little benefit. I eventually got used to this style, and now it feels pretty natural. -Filip > On Apr 27, 20

Re: [webkit-dev] VM::setExclusiveThread()

marks running in the browser (e.g. JetStream)? > > - Maciej > >> On Feb 28, 2017, at 10:48 AM, Filip Pizlo wrote: >> >> Sounds good! >> >> I agree that a 20% regression on a microbenchmark of the exclusive JSLock is >> not a problem, since that'

Re: [webkit-dev] VM::setExclusiveThread()

cks removed (simply due to > that code doing less work). > > I’ll put up a patch to remove the use of exclusive thread status. This will > simplify the code and make it easier to move forward with new features. > > Mark > > >> On Feb 24, 2017, at 9:01 PM, Filip Pizlo

Re: [webkit-dev] VM::setExclusiveThread()

Seems like if the relevant benchmarks (speedometer) are ok with it then we should just do this. -Filip > On Feb 24, 2017, at 20:50, Mark Lam wrote: > > The JSC VM has this method setExclusiveThread(). Some details: > 1. setExclusiveThread() is only used to forego actually locking/unlocking t

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

Geoff, If you find a case of code that looks like this: if (!things) { dataLog(...); RELEASE_ASSERT_NOT_REACHED(); } and this code blames to fpi...@apple.com, then I can tell you why I wrote it that way. It was because I had crashed on some assert in that function, and I needed to figur

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:41 PM, Mark Lam wrote: > >> >> On Feb 22, 2017, at 12:35 PM, Filip Pizlo > <mailto:fpi...@apple.com>> wrote: >> >>> >>> On Feb 22, 2017, at 12:33 PM, Mark Lam >> <mailto:mark@apple.com>

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

; >> On Feb 22, 2017, at 12:33 PM, Mark Lam > <mailto:mark@apple.com>> wrote: >> >>> >>> On Feb 22, 2017, at 12:16 PM, Filip Pizlo >> <mailto:fpi...@apple.com>> wrote: >>> >>> >>>> On Feb 22, 2017, at 11:58 AM,

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:33 PM, Mark Lam wrote: > > >> On Feb 22, 2017, at 12:16 PM, Filip Pizlo > <mailto:fpi...@apple.com>> wrote: >> >> >>> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen >> <mailto:gga...@apple.com>> wrote: &

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

> On Feb 22, 2017, at 12:23 PM, Saam barati wrote: > >> >> On Feb 22, 2017, at 12:16 PM, Filip Pizlo > <mailto:fpi...@apple.com>> wrote: >> >> >>> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen >> <mailto:gga...@apple.com&

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

So, I use the explicit: if (!thing) { dataLog(“…”); RELEASE_ASSERT_NOT_REACHED(); } -Filip > > Geoff > >> On Feb 22, 2017, at 11:09 AM, Filip Pizlo wrote: >> >> I disagree actually. I've lost countless hours to converting this: >> >&g

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

I disagree actually. I've lost countless hours to converting this: RELEASE_ASSERT(blah) into this: if (!blah) { dataLog("Reason why I crashed"); RELEASE_ASSERT_NOT_REACHED(); } Look in the code - you'll find lots of stuff like this. I don't think analyzing register state at crashes is m

Re: [webkit-dev] Webkit port to ppc64le.

You have to port the llint either way since even the JIT relies on some llint code. -Filip > On Feb 22, 2017, at 07:22, Atul Sowani wrote: > > Sure, thanks @Konstantin. So I will first attempt having working JIT on > ppc64le. Your comments definitely helped in deciding the direction for > p

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

+1 -Filip > On Feb 21, 2017, at 17:43, Mark Lam wrote: > > Is there a reason why RELEASE_ASSERT (and friends) does not call > WTFReportAssertionFailure() to report where the assertion occur? Is this > purely to save memory? svn blame tells me that it has been this way since > the introduct

Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 12, 2017, at 08:54, Brady Eidson wrote: > > My take-away from this discussion so far is that there is actually very > little consensus on usage of auto, which means there’s probably very little > room for actual style guideline rules. > > I think there are two very limited rules tha

Re: [webkit-dev] [webkit-reviewers] usage of auto

I'm only arguing for why using auto would be bad in the code snippet that we were talking about. My views regarding auto in other code are not strong. I only object to using auto when it is dropping useful information. -Filip > On Jan 11, 2017, at 9:15 AM, Darin Adler wrote: > > OK, you d

Re: [webkit-dev] [webkit-reviewers] usage of auto

On Jan 10, 2017, at 23:49, Darin Adler wrote: >> On Jan 10, 2017, at 10:17 PM, Filip Pizlo wrote: >> >>while (Arg src = worklist.pop()) { >>HashMap>::iterator iter = >> mapping.find(src); >>

Re: [webkit-dev] [webkit-reviewers] usage of auto

Brady asked: > Have you identified any situation where explicitly calling out the type in a > range-based for loop has been better than using the proper form of auto? > Have you identified a situation where explicitly calling out a nasty > templated type, like in my example, added to readabilit

Re: [webkit-dev] Thread naming policy in WebKit

👍 -Filip > On Jan 5, 2017, at 10:51 AM, Geoffrey Garen wrote: > > Alternatively, we could just change thread name from a char* to a struct { > char*, char* } that contains a long name and a short name. > > Geoff > >> On Jan 5, 2017, at 9:37 AM, Brady Eidson > > wro

Re: [webkit-dev] Thread naming policy in WebKit

This sounds great to me! -Filip > On Jan 4, 2017, at 20:28, Yusuke SUZUKI wrote: > > Hi WebKittens! > > Recently, I started naming threads in Linux. And I also started naming > threads created by WTF::AutomaticThread. > Previously, all the thread is not named in Linux. It makes difficult to f

Re: [webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

I think that this is great! I agree with the policy that we should use JSValue everywhere that it would give us the same codegen/ABI (args in registers, return in registers, etc). -Filip > On Jan 3, 2017, at 14:33, Mark Lam wrote: > > Over the holiday period, I looked into the possibility of

Re: [webkit-dev] Standalone B3 JIT compiler for WebAssembly ?

> On Dec 20, 2016, at 05:29, Stéphane Letz wrote: > > Hi, > > This is a LLVM standalone JIT compiler for WebAssembly here : > https://github.com/WebAssembly/wasm-jit-prototype > > How complex would it be to follow the same approach with the B3 JIT compiler? Probably not very hard. You could

[webkit-dev] PSA: SharedArrayBuffer is now enabled by default in JSC on all ports

As of http://trac.webkit.org/changeset/209568 -Filip ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

EWS doesn't hate it anymore! Reviews welcome. I've been slowly integrating feedback as I've received it. -Filip > On Nov 4, 2016, at 11:52 AM, Filip Pizlo wrote: > > Haha, I'm fixing it! > > I could use a review of the time API even while I fix some b

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

Haha, I'm fixing it! I could use a review of the time API even while I fix some broken corners in WebCore and WK2. -Filip > On Nov 4, 2016, at 11:31 AM, Brent Fulgham wrote: > > EWS Hates your patch! :-) > >> On Nov 4, 2016, at 10:01 AM, Filip Pizlo > <ma

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

that transitively touches ParkingLot - and converts it to use the new time classes. Reviews welcome! -Filip > On May 22, 2016, at 6:41 PM, Filip Pizlo wrote: > > Hi everyone! > > I’d like us to stop using std::chrono and go back to using doubles for time. > First I list

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

> On Sep 6, 2016, at 11:07 AM, Geoffrey Garen wrote: > > “take” grinds my gears too — though I’ve gotten used to it, more or less. > > I read “object.verb()” as a command, “verb”, directed at “object” (or > sometimes as a question, “verb?”, directed at “object”). I think most APIs > are phras

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

> On Sep 5, 2016, at 2:35 PM, Ryosuke Niwa wrote: > > On Mon, Sep 5, 2016 at 10:13 AM, Darin Adler > wrote: >> Hi folks. >> >> WebKit has some critical functions that involve asking an object to give up >> ownership of something so the caller can take ownership. >> >>

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

> On Sep 5, 2016, at 10:13 AM, Darin Adler wrote: > > Hi folks. > > WebKit has some critical functions that involve asking an object to give up > ownership of something so the caller can take ownership. > > In the C++ standard library itself, this is called move, as in std::move. > > In WebK

Re: [webkit-dev] Proposal: Adopt Web Inspector coding style for all WebKit JS/CSS source code

I like the idea of adopting inspector style for JS builtins! It might also be good to adopt it for JS tests that we write ourselves, with an escape hatch if you need to violate style to test some feature. For example, it should be a goal to follow inspector style for the JetStream harness code,

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

On May 23, 2016, at 11:16 AM, Geoffrey Garen wrote: >> 3 - There exists a solution - non-templated custom classes - that removes >> both classes of subtle bugs, without the template creep. > > Hard to argue with this. > > Can we go with “WallClock” and “MonotonicClock” instead of “WallTime”

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

> namespace chrono { > > template<> > struct duration_values { > static constexpr double min() { return > -std::numeric_limits::infinity(); } > static constexpr double zero() { return .0; } > static constexpr double max() { return > std::numeric_limits::in

[webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

Hi everyone! I’d like us to stop using std::chrono and go back to using doubles for time. First I list the things that I think we wanted to get from std::chrono - the reasons why we started switching to it in the first place. Then I list some disadvantages of std::chrono that we've seen from

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

> On Apr 19, 2016, at 12:55 PM, Konstantin Tokarev wrote: > > > > 19.04.2016, 18:23, "Filip Pizło" mailto:fpi...@apple.com>>: >>> On Apr 19, 2016, at 5:50 AM, Carlos Alberto Lopez Perez >> <mailto:clo...@igalia.com>> wrote: >>>

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

> On Apr 19, 2016, at 11:33 AM, Konstantin Tokarev wrote: > > > > 19.04.2016, 21:15, "Filip Pizlo" mailto:fpi...@apple.com>>: >> I did a quick look over the trac query of GCC 4.8 changes that you provided. >> None of the ones I looked at were scary

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

at 17:27 -0700, Filip Pizlo wrote: >> I am sympathetic to the principle that we should support the >> compilers that ship on the most popular versions of Linux. > > Great. :) > >> I’d like to understand if that argument is sufficient to support GCC >> 4.8.

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

> On Apr 19, 2016, at 10:11 AM, Michael Catanzaro wrote: > > On Mon, 2016-04-18 at 17:26 -0700, Filip Pizlo wrote: >> Yeah. If we allow GCC 4.8 then I think we should make all of our >> code compile with it. If that proves too difficult (like if we had >> to get

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

> On Apr 18, 2016, at 4:43 PM, Michael Catanzaro wrote: > > On Mon, 2016-04-18 at 15:01 -0700, Geoffrey Garen wrote: >> GCC 4.8 is three years old. > > Yeah, unfortunately no Linux distros are ever willing to do major > compiler upgrades, even Fedora is only willing to take minor compiler > upg

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

n’t think we should require different versions of GCC for different > projects. > > - Anders > >> On Apr 18, 2016, at 12:50 PM, Filip Pizlo wrote: >> >> I don't want a buildbot for MIPS. It's not a relevant architecture anymore. >> I don't th

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

I don't want a buildbot for MIPS. It's not a relevant architecture anymore. I don't think that JSC developers should have to expend effort towards keeping this architecture working. -Filip > On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev wrote: > > Hello, > > I'd like to run build slave fo

Re: [webkit-dev] Sukolsak Sakshuwong is now a WebKit Reviewer

Congrats! -Filip > On Mar 8, 2016, at 11:33 AM, Mark Lam wrote: > > Hi everyone, > > Just want to announce that Sukolsak Sakshuwong is now a reviewer. > Congratulations, Sukolsak. > > Mark > > ___ > webkit-dev mailing list > webkit-dev@lists.web

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

Phil, I think you need to do better than this. -Filip > On Mar 6, 2016, at 7:28 PM, Phil Bouchard wrote: > > On 03/06/2016 10:17 PM, Filip Pizlo wrote: >> >>> On Mar 6, 2016, at 6:36 PM, Phil Bouchard wrote: >>> >>> That should speed up my benc

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

> On Mar 6, 2016, at 6:36 PM, Phil Bouchard wrote: > > On 03/06/2016 12:59 AM, Phil Bouchard wrote: >> >> Anyway I am not sure if I can create a patch within a short period of >> time but if I happen to have an interesting Javascript benchmark then I >> will repost it to this mailing list. > >

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

o be about a 2x-5x slow-down. I would expect a 2x slow-down if you did non-thread-safe reference counting, and 5x if you made it thread-safe. -Filip > On Mar 5, 2016, at 8:05 PM, Phil Bouchard wrote: > > On 03/05/2016 01:02 AM, Phil Bouchard wrote: >> On 03/05/2016 12:49 AM, Fili

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

> On Mar 4, 2016, at 9:33 PM, Phil Bouchard wrote: > >> On 03/05/2016 12:07 AM, Ryosuke Niwa wrote: >> Hi Phil, >> >> You made a similar post in December 2014: >> https://lists.webkit.org/pipermail/webkit-dev/2014-December/027113.html >> >> Are you suggesting you have done or ready to do the

Re: [webkit-dev] Change WTFCrash to not trash the crash site register state.

. We can still identify the crash as an > assertion by looking fro the EXC_BREAKPOINT instead of the 0xbbadbeef address. > > Mark > > >> On Feb 8, 2016, at 12:14 PM, Filip Pizlo wrote: >> >> I like this idea. I’ve wanted this for a while. >> >>

Re: [webkit-dev] Change WTFCrash to not trash the crash site register state.

I like this idea. I’ve wanted this for a while. Can you explain why your approach doesn’t inline a store to 0xbbadbeef, so that this aspect of the current behavior is preserved? -Filip > On Feb 8, 2016, at 11:55 AM, Mark Lam wrote: > > Hi WebKit folks, > > For non-debug OS(DARWIN) builds,

Re: [webkit-dev] Some text about the B3 compiler

> On Feb 2, 2016, at 4:56 PM, Carlos Alberto Lopez Perez > wrote: > > On 02/02/16 19:58, Ryosuke Niwa wrote: >> On Tue, Feb 2, 2016 at 10:42 AM, Carlos Alberto Lopez Perez >>> But this script seems focused on comparing the performance between >>> different browsers (safari vs chrome vs firefox)

  1   2   3   4   >