Re: [webkit-dev] Deployment of new EWS Non-Unified builder

I think Ross’ point about supported ports being bitten by missing includes is valid. I also agree that it can take more time (possibly a lot more time) for an engineer stepping on the issue later in time to fix the missing includes vs the original author fixing it if a non-unified EWS points

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

I forgot to add ... > On Jun 24, 2020, at 10:26 AM, Mark Lam wrote: > > Based on all the feedback given so far, it looks like we can move forward > with the following plan: > 1. JSC Debug test bots will build their own local jsc with O3 before running > the tests. 1.5 JSC

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

JSC test bot functional again. Thanks. Mark > On Jun 19, 2020, at 2:58 PM, Alexey Proskuryakov wrote: > > > >> 19 июня 2020 г., в 1:11 PM, Mark Lam > <mailto:mark@apple.com>> написал(а): >> >> >> >>> On Jun 19, 2020, at 10:

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

more about O3 >>>>> compiler bugs than O0, since we don’t ship O0, but ship a lot of O3. >>>>> >>>>> (And if we’re going to insist on “I want it to run what I build at my >>>>> desk”: I run debug with O3 at my desk, and I can run debug tests

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

t;>>> desk”: I run debug with O3 at my desk, and I can run debug tests in a >>>> reasonable amount of time now.) >>>> >>>> In evaluating what’s the better setup, I think it’s helpful to think about >>>> this from the other side. Let’s imagine

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

> On Jun 19, 2020, at 10:02 AM, Alexey Proskuryakov wrote: > > > >> 19 июня 2020 г., в 9:59 AM, Mark Lam > <mailto:mark@apple.com>> написал(а): >> >> >> >>> On Jun 19, 2020, at 9:53 AM, Alexey Proskuryakov >> <mailto:a.

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

t; - Saam >> >>> On Jun 17, 2020, at 9:48 PM, Simon Fraser >> <mailto:simon.fra...@apple.com>> wrote: >>> >>> I also object to losing good stack traces for crashes on Debug bots. >>> >>> Also, I don't think Debug bots sho

[webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

Hi folks, We're planning to switch the JSC EWS bot and build.webkit.org Debug build and test bots to building with the following set first: ./Tools/Scripts/set-webkit-configuration --force-opt=O3 This means the Debug builds will be built with optimization level

[webkit-dev] PSA: on make targets "testing" and "release+assert", ASSERT_ENABLED, and NDEBUG

Hi folks, Ever wanted to run tests with Debug ASSERTs enabled but the speed of the Debug build is so slow that it is a drag on your productivity? Well, now you can get a faster testing build in one of two ways: 1. Build WebKit with "make testing” (or “make t”) 2. Build WebKit with “make

Re: [webkit-dev] CI builds fail on all platforms with "ReferenceError: Can't find variable: WebAssembly"

I’m about to move it into JSTests/wasm/stress. See https://bugs.webkit.org/show_bug.cgi?id=201551 . > On Sep 6, 2019, at 11:31 AM, Saam Barati wrote: > > Those tests should be checking if WebAssembly is enabled at all before > running the

Re: [webkit-dev] Code Style: Opinion on returning void

I also prefer it, and I think some coding patterns may require it e.g. in templates where sometimes we want to specialize into a void function, and other times into a function that returns a value. However, this is rarely needed in practice. Without being able to return void, writing such a

Re: [webkit-dev] Exciting JS features (class fields) in need of review :)

Hi Xan, FYI, if you’re writing JSC stress tests, you can add test specific options by putting the following at the top of the test file: //@ requireOptions(“--myOption=true”, “--myOtherOption=1234”) For LayoutTests, you can add the following to the top line of the test html file: This way,

Re: [webkit-dev] WTFCrash()

> On Mar 6, 2018, at 9:09 PM, Michael Catanzaro wrote: > > Hi, > > After [1], WTFCrash() is used only in debug builds on Darwin. For Darwin > release builds, inline assembly is used to trigger a SIGTRAP. I experimented > with this today and found it works quite badly

[webkit-dev] Javier Fernandez is now a WebKit reviewer

Hi everyone, I would like to announce that Javier Fernandez (lajava on #webkit) is now a WebKit reviewer. Javier has worked on CSS Grid Layout and Box Alignment, as well as the selection and editing code. Please join me in congratulating Javier, and send him some patches to review. Javier,

[webkit-dev] Frédéric Wang is now a WebKit reviewer

Hi everyone, I would like to announce that Frédéric Wang (nick: fredw) is now a WebKit reviewer. Frédéric has worked on MathML, frame sandboxing, and scrolling. He is also a committer in Gecko and Chromium projects. Please congratulate him, and send him some patches to review. Thanks.

Re: [webkit-dev] How we enable template functions

One application of enable_if I’ve needed in the past is where I want specialization of a template function with the same argument signatures, but returning a different type. The only way I know to make that happen is to use enable_if in the return type, e.g.

Re: [webkit-dev] JIT probe mechanism soon required for DFG and FTL OSR Exit

org/show_bug.cgi?id=175446>). As a consequence, I’ll be disabling the DFG for the MIPS port in this patch. Mark > On Jul 19, 2017, at 9:52 AM, Mark Lam <mark@apple.com> wrote: > > > >> On Jul 19, 2017, at 9:49 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: >

Re: [webkit-dev] JIT probe mechanism soon required for DFG and FTL OSR Exit

> On Jul 19, 2017, at 9:49 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 19.07.2017, 02:49, "Mark Lam" <mark@apple.com>: >> FYI, I’m looking into making OSR exits work in a more memory efficient way >> using the JIT probe

[webkit-dev] JIT probe mechanism soon required for DFG and FTL OSR Exit

FYI, I’m looking into making OSR exits work in a more memory efficient way using the JIT probe mechanism. Once we make this transition, the DFG and FTL will not work for any CPU targets that don’t support the JIT probe mechanism. The API to the JIT probe will probably change as well as this

[webkit-dev] Jiewen Tan is now a WebKit reviewer

Hi everyone, I would like to announce that Jiewen Tan (jiewen on #webkit) is now a WebKit reviewer. Jiewen usually works on the WebCrypto API. Please join me in congratulating Jiewen, and send him some patches to review. Jiewen, congratulations. Mark

[webkit-dev] Konstantin Tokarev is now a WebKit reviewer

Hi everyone, I would like to announce that Konstantin Tokarev (annulen on #webkit) is now a WebKit reviewer. Konstantin has extensive knowledge of WebKit, and has resurrected the QtWebKit port, helped WebKit compete against Chromium in the Qt project, and ensured that the dozens of

Re: [webkit-dev] JF Bastien is now a WebKit reviewer

Oops, I have sticky fingers today. My apologies to JF. The title should have been "JF Bastien is now a WebKit reviewer”. > On Apr 4, 2017, at 3:57 PM, Mark Lam <mark@apple.com> wrote: > > Hi everyone, > > I would like to announce that JF Bastien (jfbastien on #

[webkit-dev] JS Bastien is now a WebKit reviewer

Hi everyone, I would like to announce that JF Bastien (jfbastien on #webkit) is now a WebKit reviewer. JF is on the C++ standards committee, and had previously worked on LLVM for 4 years. He currently works on JavaScriptCore and knows lots of things about WASM. Please join me in

[webkit-dev] Carlos Alberto Lopez Perez is now a WebKit Reviewer

Hi folks, I just want to announce that Carlos Alberto Lopez Perez (clopez on #webkit) is now a WebKit Reviewer. Carlos has been contributing on the WebKitGTK+ port and has expertise on tools and build/test infrastructure. Please join me in congratulating Carlos, and send him some patches to

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

not familiar with? Geoff, It just occurred to me that the developer does have one recourse: he/she can use break on exception thrown / on uncaught exception, and inspect the full stack via the debugger. Mark > On Mar 28, 2017, at 9:08 PM, Mark Lam <mark@apple.com> wrote: > > Cur

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

rs’ developer tools do? > > FireFox and Chrome show console entires with exception stack traces with 128 > and 200 frames (respectively). > >> >> Geoff >> >>> On Mar 28, 2017, at 4:09 PM, Mark Lam <mark@apple.com >>> <mailto:mark...

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

Error.stack which is captured at the time of instantiation of the Error object). exceptionStackTraceLimit is also limited to 100 by default. Mark > On Mar 17, 2017, at 1:04 PM, Mark Lam <mark@apple.com> wrote: > > @Geoff, my testing shows that we can do 200 frames

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

gt; wrote: > >> >> On Mar 17, 2017, at 11:09 AM, Mark Lam <mark@apple.com >> <mailto:mark@apple.com>> wrote: >> >> Thanks for the reminder to back observations up with data. I was previously >> running some tests that throws StackOverflo

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

mit the size of the JavaScript stack to avoid performance > problems like the ones you mention in many other contexts. Why is that limit > not sufficient? > > Did you consider implementing Chrome’s Error.stackTraceLimit behavior? > > Geoff > >> On Mar 16,

[webkit-dev] Proposal to limit the size of the captured exception stack

Hi folks, Currently, if we have an exception stack that is incredibly deep (especially for a StackOverflowError), JSC may end up thrashing memory just to capture the large stack trace in memory.This is bad for many reasons: 1. the captured stack will take a lot of memory. 2. capturing the

[webkit-dev] Devin Rousso is now a WebKit reviewer

Hi everyone, I would like to announce that Devin Rousso (dcrousso on #webkit) is now a WebKit reviewer. Devin has been contributing to Web Inspector for nearly two years. Please join me in congratulating Devin, and send him some patches to review. Devin, congratulations. Mark

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

ks (speedometer) are ok with it then we > should just do this. > > -Filip > >> On Feb 24, 2017, at 20:50, Mark Lam <mark@apple.com> wrote: >> >> The JSC VM has this method setExclusiveThread(). Some details: >> 1. setExclusiveThread() is only use

[webkit-dev] VM::setExclusiveThread()

The JSC VM has this method setExclusiveThread(). Some details: 1. setExclusiveThread() is only used to forego actually locking/unlocking the underlying lock inside JSLock. 2. setExclusiveThread() is only used by WebCore where we can guarantee that the VM will only ever be used exclusively on

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

On Wed, Feb 22, 2017 at 12:41 PM, Mark Lam <mark@apple.com> wrote: >> >> I would like to point out that we might be able to get the best of both >> worlds. Here’s how we can do it: >> >> define RELEASE_ASSERT(assertion) do { \ >>if (UN

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

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

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

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

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

by inline asm, the C++ compiler has less ability to determine that the crash sites have the same code (probably because it doesn’t bother comparing what’s in the inline asm blobs). Mark > On Feb 22, 2017, at 12:33 PM, Mark Lam <mark@apple.com> wrote: > >> >> On F

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

gt;> Oh yeah, I forgot about that. I think the register state is more >>>> important for crash analysis, especially if we can make sure that the >>>> compiler does not aggregate the int3s. I’ll explore alternatives. >>>> >>>>> On Feb 21,

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

> I thought the main point of moving to SIGTRAP was to preserve register state? > > That said, there are probably places where we care more about the message > than the registers. > > - Saam > >> On Feb 21, 2017, at 5:43 PM, Mark Lam <mark@apple.com> wrote

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

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 introduction of RELEASE_ASSERT in r140577 many years ago. Would anyone

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

...@apple.com>> wrote: >> >> 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 >> >&g

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

Over the holiday period, I looked into the possibility of giving EncodedJSValue a default constructor (because I didn’t like having to return encodedJSValue() instead of { } in lots of places), and learned why we had EncodedJSValue in the first place (i.e. for C linkage). This led me to

[webkit-dev] Said Abou-Hallawa is now a WebKit reviewer

Hi everyone, I would like to announce that Said Abou-Hallawa is now a WebKit reviewer. Said’s expertise is on SVG/graphics and image decoders. You may now ask Said to help review your code. Said, congratulations. Mark ___ webkit-dev mailing list

[webkit-dev] Wenson Hsieh is now a WebKit reviewer

Hi everyone, I would like to announce that Wenson Hsieh is now a WebKit reviewer. Wenson has worked on CSS Scroll Snapping, HTML forms, iOS gesture code, HTML editing, media, and more. You may now ask Wenson to help review your code. Wenson, congratulations. Mark

[webkit-dev] Manuel Rego Casasnovas is now a WebKit Reviewer

Hi everyone, I just want to announce that Manuel Rego Casasnovas (aka rego) is now a WebKit Reviewer. He has expertise in CSS, layout, selection, and the GTK port. You may now ping him for reviews. Congratulations, Rego. Cheers, Mark

[webkit-dev] Jon Lee is now a WebKit Reviewer

FYI, I just want to announce that Jon Lee is now a WebKit reviewer. You may now send him patches to review. Jon, congratulations. Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Keith Miller is now a WebKit reviewer

Hi everyone, Just want to announce that Keith Miller is now a reviewer. Keith primarily works on JavaScriptCore. Feel free to ask him for reviews. Congratulations, Keith. Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org

[webkit-dev] Joanmarie Diggs is now a WebKit reviewer

Hi everyone, Just want to announce that Joanmarie Diggs is now a reviewer. Joanmarie primarily works on GTK accessibility and is a current editor of the ARIA spec (https://www.w3.org/TR/wai-aria-1.1/ ). Congratulations, Joanmarie.

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

to:rn...@webkit.org>> wrote: >> Congratulations, Sukolsak! >> >> - R. Niwa >> >> On Tue, Mar 8, 2016 at 11:33 AM, Mark Lam <mark@apple.com >> <mailto:mark@apple.com>> wrote: >> Hi everyone, >> >> Just want t

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

Hi everyone, Just want to announce that Sukolsak Sakshuwong is now a reviewer. Congratulations, Sukolsak. Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] PSA: Distinguishing between failed release assertions and other crashes

As I shared in a previous email, I’ll be changing the implementation of WTFCrash() for non-debug OS(DARWIN) builds to use an inlined asm statement that issues a breakpoint instruction. See https://bugs.webkit.org/show_bug.cgi?id=153996 for details and discussion. I will be landing this patch

Re: [webkit-dev] PSA: Distinguishing between failed release assertions and other crashes

FYI, the change has landed in r196397: <http://trac.webkit.org/r196397>. > On Feb 10, 2016, at 3:01 PM, Mark Lam <mark@apple.com> wrote: > > As I shared in a previous email, I’ll be changing the implementation of > WTFCrash() for non-debug OS(DARWIN) builds to use

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

s preserved? > > -Filip > > >> On Feb 8, 2016, at 11:55 AM, Mark Lam <mark@apple.com> wrote: >> >> Hi WebKit folks, >> >> For non-debug OS(DARWIN) builds, I would like to change WTFCrash()’s >> implementation into an inlined function that has

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

Hi WebKit folks, For non-debug OS(DARWIN) builds, I would like to change WTFCrash()’s implementation into an inlined function that has a single inlined asm statement that issues a breakpoint trap. The intent is to crash directly in the caller’s frame and preserve the register values at the

[webkit-dev] Xabier Rodriguez-Calvar and Michael Catanzaro are now WebKit reviewers

Hi everyone, With pleasure, I would like to announce that Xabier Rodriguez-Calvar and Michael Catanzaro are now WebKit reviewers. Congratulations to Xabier and Michael. Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org

[webkit-dev] Youenn Fablet is now a WebKit reviewer

Hello everyone, I would like to announce that Youenn Fablet is now a WebKit reviewer. Please send him your congratulations, and some requests for patch reviews too. :-) Youenn, congratulations. Mark ___ webkit-dev mailing list

[webkit-dev] Lucas Forschler is now a WebKit reviewer

Hi everyone, Just want to announce that Lucas Forschler is now a reviewer. Congratulations, Lucas. Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Infinite JavaScript loop blocks the MiniBrowser

JSContextGroupSetExecutionTimeLimit() again. Hence, you’re probably not resetting the watchdog after a time out. Regards, Mark On Jul 29, 2015, at 9:54 AM, Mark Lam mark@apple.com wrote: Pascal, You can take a look at ExecutionTimeLimitTest.cpp for examples of the watchdog in action

Re: [webkit-dev] Infinite JavaScript loop blocks the MiniBrowser

Pascal, You can take a look at ExecutionTimeLimitTest.cpp for examples of the watchdog in action. The way the watchdog works is by throwing a non-catchable TerminatedExecutionException. Normally, the JSC APIs will clear the vm-exception() before returning to client code; the exception is

Re: [webkit-dev] Using OfflineAsm

Hi Chris, I’ll try to answer your questions below … On Sep 5, 2014, at 3:23 PM, Vienneau, Christopher cvienn...@ea.com wrote: Hello, I’m looking for some information about the Java script interpreter ASM backend, aka OfflineAsm. First a bit of background information; the code I

Re: [webkit-dev] Using OfflineAsm

On Sep 5, 2014, at 4:05 PM, Mark Lam mark@apple.com wrote: 4) Should I actually expect a performance increase compared to the “C LOOP”? Yes. The ASM LLINT should be faster than the C LOOP LLINT. To clarify, the C LOOP LLINT emulated a CPU’s behavior using emitted C instructions

Re: [webkit-dev] ftlopt merge - basically done

Ossy, Filip is on vacation. I’m keeping an eye on this issue, and will see what we can do about it. It may take some time. Just letting you know that we’re not ignoring it. Thanks. Mark On Aug 8, 2014, at 12:59 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Hi Filip, the latest

Re: [webkit-dev] Questions about JSC CLoop crashes on ppc64

cc’ing webkit dev because there may be other folks who might be interested in this information, and/or may also be able to help. On Apr 1, 2014, at 6:57 AM, Tomas Popela tpop...@redhat.com wrote: Hi Mark, if you don't mind I have some questions for you regarding to

Re: [webkit-dev] Seeking help/guidance with ParserError::StackOverflow porting JavaScriptCore to Android

One more time from the right email address: Eric, As a rule of thumb, you’ll want the following: errorModeRequiredStack requiredStack total Stack size. There are some minimum amount of stack space that some reasonable native (C/C++) code can use without needing to do a stack check. Let’s

[webkit-dev] C stack direction

Hi folks, I’m currently doing some work involving checks on the bounds of the native stack. According to WTF::StackBounds, it appears that WINCE is the only port that can potentially have a stack that grows up. Is anyone still building, testing, and using this configuration with an upward

Re: [webkit-dev] Moving LayoutTests/fast/js to LayoutTests/js

FYI, the move has been completed. On Sep 6, 2013, at 5:06 PM, Mark Lam mark@apple.com wrote: This is a courtesy notice: FYI, I’m in the process of moving LayoutTests/fast/js to LayoutTests/js for https://bugs.webkit.org/show_bug.cgi?id=120899. This change will touch many files

[webkit-dev] Moving LayoutTests/fast/js to LayoutTests/js

This is a courtesy notice: FYI, I’m in the process of moving LayoutTests/fast/js to LayoutTests/js for https://bugs.webkit.org/show_bug.cgi?id=120899. This change will touch many files in the test files and in Tools/Scripts to update the paths that expect fast/js to look for js instead. Mark

Re: [webkit-dev] Instrumenting JavaScriptCore

Erick, If your instrumentation is not performance critical, you might be interested in using the llint C++ backend. To use that: 1. in WTF/wtf/Platform.h (or equivalent), #define ENABLE_JIT 0, and #define ENABLE_LLINT 1. This will allow you to build for the C++ llint which generates C++

[webkit-dev] …Inlines.h vs …InlineMethods.h

FYI, some time in the near future (maybe this weekend), I plan to do some work to break inline methods in JavaScriptCore out of header files into their own inline header files. Naming-wise, the existing JSC code has a few inline headers named …Inlines.h and more named …InlinedMethods.h. On

[webkit-dev] Replacing the JSC classic C++ interpreter with a llint generated C++ interpreter

As part of an effort to simplify future development, the JSC team is deprecating the classic C++ interpreter (and will delete it shortly on Sept 24). In its place, we will use the LLINT (low level interpreter) with the C++ back-end (see https://bugs.webkit.org/show_bug.cgi?id=91052) to