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

[Filip Pizło]

You guys are making a convincing case for Seconds/WallTime/MonotonicTime!

-Filip

> On May 22, 2016, at 11:19 PM, Ryosuke Niwa  wrote:
> 
> I'm with Brady here.  In WebCore, there are enough DOM and network
> APIs that mix wall time and monotonically increasing time (e.g. there
> has been proposals to use monodically increasing time in
> event.prototype.timeStamp even though various event related code
> relies on it being a wall clock time) that having a type system would
> be helpful.
> - R. Niwa
> 
> 
>> On Sun, May 22, 2016 at 10:47 PM, Brady Eidson  wrote:
>> 
>> 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 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 fixing std::chrono-based
>> code.  Finally I propose some options for how to use doubles for time.
>> 
>> Why we switched to std::chrono
>> 
>> A year ago we started using std::chrono for measuring time.  std::chrono has
>> a rich typesystem for expressing many different kinds of time.  For example,
>> you can distinguish between an absolute point in time and a relative time.
>> And you can distinguish between different units, like nanoseconds,
>> milliseconds, etc.
>> 
>> Before this, we used doubles for time.  std::chrono’s advantages over
>> doubles are:
>> 
>> Easy to remember what unit is used: We sometimes used doubles for
>> milliseconds and sometimes for seconds.  std::chrono prevents you from
>> getting the two confused.
>> 
>> Easy to remember what kind of clock is used: We sometimes use the monotonic
>> clock and sometimes the wall clock (aka the real time clock).  Bad things
>> would happen if we passed a time measured using the monotonic clock to
>> functions that expected time measured using the wall clock, and vice-versa.
>> I know that I’ve made this mistake in the past, and it can be painful to
>> debug.
>> 
>> In short, std::chrono uses compile-time type checking to catch some bugs.
>> 
>> Disadvantages of using std::chrono
>> 
>> We’ve seen some problems with std::chrono, and I think that the problems
>> outweigh the advantages.  std::chrono suffers from a heavily templatized API
>> that results in template creep in our own internal APIs.  std::chrono’s
>> default of integers without overflow protection means that math involving
>> std::chrono is inherently more dangerous than math involving double.  This
>> is particularly bad when we use time to speak about timeouts.
>> 
>> Too many templates: std::chrono uses templates heavily.  It’s overkill for
>> measuring time.  This leads to verbosity and template creep throughout
>> common algorithms that take time as an argument.  For example if we use
>> doubles, a method for sleeping for a second might look like
>> sleepForSeconds(double).  This works even if someone wants to sleep for a
>> nanoseconds, since 0.01 is easy to represent using a double.  Also,
>> multiplying or dividing a double by a small constant factor (1,000,000,000
>> is small by double standards) is virtually guaranteed to avoid any loss of
>> precision.  But as soon as such a utility gets std::chronified, it becomes a
>> template.  This is because you cannot have sleepFor(std::chrono::seconds),
>> since that wouldn’t allow you to represent fractions of seconds.  This
>> brings me to my next point.
>> 
>> Overflow danger: std::chrono is based on integers and its math methods do
>> not support overflow protection.  This has led to serious bugs like
>> https://bugs.webkit.org/show_bug.cgi?id=157924.  This cancels out the
>> “remember what unit is used” benefit cited above.  It’s true that I know
>> what type of time I have, but as soon as I duration_cast it to another unit,
>> I may overflow.  The type system does not help!  This is insane: std::chrono
>> requires you to do more work when writing multi-unit code, so that you
>> satisfy the type checker, but you still have to be just as paranoid around
>> multi-unit scenarios.  Forgetting that you have milliseconds and using it as
>> seconds is trivially fixable.  But if std::chrono flags such an error and
>> you fix it with a duration_cast (as any std::chrono tutorial will tell you
>> to do), you’ve just introduced an unchecked overflow and such unchecked
>> overflows are known to cause bugs that manifest as pages not working
>> correctly.
>> 
>> I think that doubles are better than std::chrono in multi-unit scenarios.
>> It may be possible to have std::chrono work with doubles, but this probably
>> implies us writing our own clocks.  std::chrono’s default clocks use
>> integers, not doubles.  It also may be possible to teach std::chrono to do
>> overflow protection, but that would make me so sad since using double means
>> not having to worry 

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

[Filip Pizło]

-Filip
> On May 23, 2016, at 12:12 AM, Michal Debski  wrote:
> 
> Please this example: http://ideone.com/c640Xd
> 
I'm not going to write "WTF::now()" every time I 
want the time. That's awful!

One of the problems with chrono is the use of awkward templates throughout the 
API. Your solution makes this worse. 
> From cppreference:
> 
> "(time_point) is implemented as if it stores a value of typeDuration 
> indicating the time interval from the start of the Clock's epoch."
> 
> "If Rep is floating point, then the duration can represent fractions of 
> ticks."
> 
> http://en.cppreference.com/w/cpp/chrono/time_point
> 
> http://en.cppreference.com/w/cpp/chrono/duration
> 
>  
> 
> time_point still remembers which clock it belongs to, see the specialization 
> now() returns.  
> 
> The only problem I see is that conversion from fractional duration with 
> Infinite value to integer duration is undefined. But I assume it would be 
> forbiden to use integer based chrono altogether.
> 
That seems like a tough thing to guarantee.
> As for the last point I don't understand what do you mean by non-canonical.
> 
According to Merriam-Webster, canonical means: conforming to a general rule or 
acceptable procedure. I don't think that your approach is the normal, generally 
accepted way to use std::chrono. 
> It uses the API as intended, why would c++ expose the templates if not for 
> specializing the behaviour? Also move operator is not canonical in WTF 
> strictly speaking.
> 
>  
> 
> I just remember about ugly bugs in MediaTime arithmetics.
> 
>  
> 
> Best regards,
> 
> Michal Debski
> 
>  
> 
> --- Original Message ---
> 
> Sender : Filip Pizlo
> 
> Date : May 23, 2016 07:32 (GMT+01:00)
> 
> Title : Re: [webkit-dev] RFC: stop using std::chrono, go back to using 
> doubles for time
> 
>  
> 
> 
> 
>> On May 22, 2016, at 10:46 PM, Michal Debski  wrote:
>> 
>> Hi,
>> 
>>  
>> 
>> sorry but this really bugs me. Isn't this enough?
>> 
>>  
>> 
>> namespace WTF {
>> 
>> using nanoseconds = std::chrono::duration;
>> using microseconds = std::chrono::duration;
>> using milliseconds = std::chrono::duration;
>> using seconds = std::chrono::duration;
>> using minutes = std::chrono::duration>;
>> using hours = std::chrono::duration>;
>> 
>> 
>> template 
>> std::chrono::time_point now()
>> {
>> return Clock::now();
>> }
>> 
> Can you clarify how this returns fractional seconds?
> 
> Note that your code snippets are not enough to cover WebKit's use of clocks. 
> For example we would need wall clock and monotonic clock classes with 
> time_point types. If we have to significantly customize std::chrono and 
> forbid some but not all of its API, then probably the total amount of code to 
> do this would be comparable to writing our own Seconds/WallTime/MonotonicTime 
> classes.
>> 
>> }
>> 
>>  
>> 
>> and forbid using std::chrono::clock::now()/durations with check-style. It 
>> seems like the best of both worlds.
>> 
> It's an interesting perspective. But I would find it confusing if we used a 
> non-canonical kind of std::chrono. And I'm not convinced that the changes 
> required to make this work are as simple as what you say. 
>> Oh and the infinity:
>> 
>>  
>> 
>> namespace std {
>> 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::infinity(); }
>> };
>> 
>> }
>> } 
>> 
>> Best regards,
>> Michal Debski
>> 
>>  
>> 
>> --- Original Message ---
>> 
>> Sender : Filip Pizlo
>> 
>> Date : May 23, 2016 02:41 (GMT+01:00)
>> 
>> Title : [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 fixing 
>> std::chrono-based code.  Finally I propose some options for how to use 
>> doubles for time.
>> 
>> Why we switched to std::chrono
>> 
>> A year ago we started using std::chrono for measuring time.  std::chrono has 
>> a rich typesystem for expressing many different kinds of time.  For example, 
>> you can distinguish between an absolute point in time and a relative time.  
>> And you can distinguish between different units, like nanoseconds, 
>> milliseconds, etc.
>> 
>> Before this, we used doubles for time.  std::chrono’s advantages over 
>> doubles are:
>> 
>> Easy to remember what unit is used: We sometimes used doubles for 
>> 

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

[Filip Pizło]

> On Apr 19, 2016, at 5:50 AM, Carlos Alberto Lopez Perez  
> wrote:
> 
>> On 18/04/16 21:50, Filip Pizlo wrote:
>> 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.
> 
> MIPS is still relevant on embedded devices (mainly set-top boxes).
> It is also a popular platform for IoT projects.

This doesn't seem like a big enough deal to have in trunk. 

Have you considered an out-of-tree port?

-Filip

> 
> I understand that you don't want to spend time supporting this
> architecture, and that is ok. Nobody is proposing here that JSC
> developers should spend time maintaining JSC on MIPS.
> 
> However, if someone is willing to do the work, I think we should let
> them do it and don't actively block it.
> 
> Having a buildbot testing JSC on MIPS certainly helps anyone interested
> in maintaining this architecture.
> 
> And anybody not interested in MIPS, can just ignore this bot.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS [WARNING - NOT VIRUS SCANNED]

[Filip Pizło]

I think that this is probably OK for the purposes of not creating obligations 
but I don't see it as a viable strategy for making WebKit work of MIPS. 

For example, you guys haven't even shown that JSC can pass all WebKit tests on 
MIPS. You haven't shown that the MIPS JIT produces a speed up over cloop on 
MIPS. My fear is that MIPS lags in correctness and that this will always be the 
case so long as the porting strategy is to track trunk. If that's the case then 
the MIPS changes will just cause noise for us and will not accomplish the goal 
of having a stable version of WebKit that works great on MIPS. 

Can you offer some insight into the current testing and perf status of MIPS?

-Filip

> On Apr 19, 2016, at 5:53 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 19.04.2016, 15:24, "Osztrogonác Csaba" :
>> Hi,
>> 
>> now the #error macro in Compiler.h is the only one blocker to
>> be able to build JSCOnly port with GCC 4.8 (without FTL JIT):
>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Compiler.h#L73
>> 
>> The existance of a buildbot doesn't mean any obligation for anybody.
>> We have many bots which are allowed to break. Everybody is allowed
>> to break the Apple Mac cmake build, WebKit2 owners can break EFL/GTK
>> builds, JSC developers can break ARM Linux builds.
> 
> 
> I also would like to note that existence of MIPS bot does not oblige JSC 
> developers who don't work on MIPS to keep it green, e.g. by implementing 
> missing MacroAssembler functions. However, having such bot might be useful in 
> case of refactorings which involve moving MIPS code around, which already 
> happened in the past.
> 
>> 
>> br,
>> Ossy
>> 
>> Filip Pizlo írta:
>>>  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 for MIPS port of JSC (with JSCOnly port on 
 Linux). On the first iteration it will just ensure that compilation is not 
 broken, afterwards I'm planning to add running tests on target.
 
  However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, 
 the latest one supplied by Broadcom), and unmodified tree won't build 
 because of GCC version check in Source/WTF/wtf/Compiler.h.
 
  Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
 (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
 errors myself.
 
  --
  Regards,
  Konstantin
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Filip Pizło]

> On Feb 10, 2016, at 9:14 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 10.02.2016, 20:10, "Filip Pizło" <fpi...@apple.com>:
>>>  On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>>> 
>>>  10.02.2016, 05:41, "Eric Wing" <ewmail...@gmail.com>:
>>>>>  On 2/7/16, Konstantin Tokarev <annu...@yandex.ru> wrote:
>>>>>   Please try updated version of my branch, it now does not use LLVM 
>>>>> unless you
>>>>>   enable USE_LLVM_DISASSEMBLER.
>>>> 
>>>>  I merged your branch. That seemed to build and work.
>>>>  So what would USE_LLVM_DISAAEMBLER get me if I could build it?
>>> 
>>>  It will allow you to disassemble JIT code on architectures that are 
>>> supported by LLVM but lack specialized disassembler inside JSC, e.g. it was 
>>> known to work on ARM traditional.
>> 
>> We should drop the llvm disassembler support since we don't need it for 
>> ARM64, ARMv7, or x86. If we care about disassembly on ARM traditional, we 
>> should write one. It's not that hard.
> 
> Out of curiosity, what is the reason not to reuse LLVM disassemblers? Just 
> because LLVM is "inconvenient" dependency?

It's extremely inconvenient since it doesn't have a stable API. Also in our 
experience that disassembler sometimes only supports those instructions that 
llvm would emit. If you look you'll see that on x86 we choose between the llvm 
disassembler and our own based on whether llvm generated the code or we did, 
since the llvm disassembler has historically had issues handling some of the 
instructions that out MacroAssembler know about. 

There's nothing worse than debugging a jit bug and being blocked on an upstream 
disassembler lacking a feature. It's much better if we have our own. That way 
we won't be blocked. 

> 
> -- 
> Regards,
> Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Filip Pizło]

> On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 10.02.2016, 05:41, "Eric Wing" :
>>> On 2/7/16, Konstantin Tokarev  wrote:
>>>  Please try updated version of my branch, it now does not use LLVM unless 
>>> you
>>>  enable USE_LLVM_DISASSEMBLER.
>> 
>> I merged your branch. That seemed to build and work.
>> So what would USE_LLVM_DISAAEMBLER get me if I could build it?
> 
> It will allow you to disassemble JIT code on architectures that are supported 
> by LLVM but lack specialized disassembler inside JSC, e.g. it was known to 
> work on ARM traditional.

We should drop the llvm disassembler support since we don't need it for ARM64, 
ARMv7, or x86. If we care about disassembly on ARM traditional, we should write 
one. It's not that hard. 

> 
>> Also, are there things I can do to shrink JavaScriptCore?

Disable various optimizing JITs if you're desperate enough. 

But I think you could also reduce size by experimenting with out-of-lining cold 
functions that are currently online. That would be a longer term project. 

> 
> 
> You can try to disable all code related to disassembler and inspector (if you 
> don't need these features).
> 
> Also you can try building without API/JSCTestRunnerUtils.cpp and 
> runtime/TestRunnerUtils.cpp.
> 
> 
>> It's now
>> over 20MB. I know ICU is a big part of that, but JSC itself seems to
>> keep getting bigger too.
>> 
>> To respond to a prior suggestion about ICU size, I am familiar with
>> the data archive option. However, there are several challenges with
>> that:
>> - I don't know what parts JSC actually needs to know what I can safely remove
> 
> 
> I second this request, it would be great if WebKit had a documentation which 
> kinds of ICU data are used by JSC and by WebCore.
> 
> 
>> - I don't know how ICU/JSC load the data archive. Android APK file
>> semantics are pretty terrible and you have to send around a Java
>> AsssetManager to access everything. Standard file library calls don't
>> 'just work'.
>> - I really need to build as a static library because since it is a
>> private implementation detail of JSC. There are problems if somebody
>> downstream of me wants to use ICU, with a potentially different
>> version. If I dynamically link and use data archives, I open up a lot
>> of conflict issues. Similarly, Android itself may use ICU internally
>> and I've been warned of conflict problems by others. Static linking
>> avoids these headaches. Also, I haven't figured out if data archive
>> and static libraries are compatible.
> 
> 
> IIRC, Android is shipped with ICU4J, and in recent ICU versions they are 
> using the same data format.
> 
> 
>> - I did notice Apple has a modified, stripped down version of ICU as
>> part of Darwin. I was unable to figure out how to get it built. It was
>> a pretty complicated Makefile.
>> 
>> Thanks,
>> Eric
>> 
>> P.S.
>> Here is an indentation fix for my previous ICU patch.
>> https://github.com/ewmailing/webkit/commit/e2c94e8b126143402b4e17cc514c4df412de5ace
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizło]

That's so awesome!  I can't wait to see it enabled on Linux!

The gcc-clang differences suggest that we will need to be extra careful now. 
I'd like to see more Linux testing of JSC. 

-Filip

> On Jan 30, 2016, at 1:00 PM, Yusuke SUZUKI <utatane@gmail.com> wrote:
> 
> Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and 
> https://bugs.webkit.org/show_bug.cgi?id=153711 are landed.
> 
> So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's time to 
> enable B3 in Linux x64 :D
> 
> Regards,
> Yusuke Suzuki
> 
>> On Sat, Jan 30, 2016 at 8:09 AM, Filip Pizlo <fpi...@apple.com> wrote:
>> Follow up on this:
>> 
>>> On Jan 29, 2016, at 11:38 AM, Filip Pizlo <fpi...@apple.com> wrote:
>>> 
>>> I started coverting the documentation to Markdown.  I don’t think this is a 
>>> good idea.
>>> 
>>> - Markdown has no definition lists.  The entire IR document is a definition 
>>> list.  I don’t want B3’s documentation to be blocked on this issue.
>> 
>> It turns out that it does have them, but they are very weak.  For example, 
>> you can’t have code blocks or paragraphs inside them.  We want to have code 
>> blocks inside opcode definitions, to show examples.
>> 
>>> - Markdown’s conversion step makes the workflow awkward.  I’m not going to 
>>> use some Markdown editing app - that will prevent me from being able to 
>>> properly format code examples.  I need a code editor for that.
>> 
>> This was hard to get around.  This isn’t a problem with Markdown, but 
>> rather, a problem with using Wordpress to render Markdown that is in svn.  
>> There is no way to preview the Markdown before committing it.  That would 
>> lead to unusual problems, where after a patch is landed, the patch author or 
>> someone else would have to do a bunch of blind follow-up commits to fix any 
>> style issues, like code blocks that don’t fit properly or whatever.
>> 
>> Considering that we will have to be hacking raw HTML inside those Markdown 
>> files (due to definition lists), the lack of preview basically means that 
>> you have no way of predicting what the your HTML will render like.
>> 
>>> 
>>> I think that this documentation should be HTML.  I don’t think we should 
>>> expend a lot of energy to formatting it nicely.  The point of this document 
>>> is for it to be read by engineers while they hack code.
>> 
>> I landed raw HTML documentation: http://trac.webkit.org/changeset/195841
>> 
>> I filed this bug about improving its style: 
>> https://bugs.webkit.org/show_bug.cgi?id=153674
>> 
>> -Filip
>> 
>> 
>>> 
>>> -Filip
>>> 
>>> 
>>>> On Jan 29, 2016, at 10:12 AM, Timothy Hatcher <timo...@apple.com> wrote:
>>>> 
>>>> I also added:
>>>> 
>>>> https://webkit.org/documentation/b3/air/ loads 
>>>> /docs/b3/assembly-intermediate-representation.md
>>>> 
>>>>> On Jan 29, 2016, at 10:05 AM, Filip Pizło <fpi...@apple.com> wrote:
>>>>> 
>>>>> Thank you!  I'll convert them today. 
>>>>> 
>>>>> -Filip
>>>>> 
>>>>>> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher <timo...@apple.com> wrote:
>>>>>> 
>>>>>> Markdown is pretty similar to the wiki formatting and very simple.
>>>>>> 
>>>>>> You can look at a cheatsheet if you login to the blog: 
>>>>>> https://webkit.org/wp/wp-admin/post.php?post=4300=edit
>>>>>> 
>>>>>> I have also used this HTML to Markdown converter before: 
>>>>>> http://domchristie.github.io/to-markdown/
>>>>>> 
>>>>>> The pages are created:
>>>>>> 
>>>>>> https://webkit.org/documentation/b3/ loads /docs/b3/bare-bones-backend.md
>>>>>> https://webkit.org/documentation/b3/intermediate-representation/ loads 
>>>>>> /docs/b3/intermediate-representation.md
>>>>>> 
>>>>>> Once those files are added to SVN, they will get picked up by the site. 
>>>>>> I can change those to point to other names if you want something 
>>>>>> different.
>>>>>> 
>>>>>> — Timothy Hatcher
>>>>>> 
>>>>>>> On Jan 29, 2016, at 9:34 AM, saam barati <saambara...@gmail.com> wrote:
>>>>>>> 
>>>>>>> I'm happy to co

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

[Filip Pizło]

> On Jan 30, 2016, at 3:16 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
>> On Sat, 2016-01-30 at 14:13 -0800, Filip Pizło wrote:
>> That's so awesome!  I can't wait to see it enabled on Linux!
>> 
>> The gcc-clang differences suggest that we will need to be extra
>> careful now. I'd like to see more Linux testing of JSC. 
>> 
>> -Filip
> 
> Hi,
> 
> We have two bots that run the JSC tests with GCC (our major
> distributors all use GCC). The JSC tests break regularly, but the
> failures are usually cross-platform and so get fixed fairly quickly. If
> there are any JSC failures, they show up here:
> 
> https://build.webkit.org/dashboard/
> 
> Currently all the JSC tests are passing (running FTL with LLVM).
> 
> It would be very nice if the EWS were to run GTK tests (without
> blocking commit-queue) so that developers can notice failures
> immediately. Otherwise, I don't see room for improvement here.

Do we have Linux bots that run Octane, Speedometer, JetStream and Kraken in 
browser?

We find that this catches a lot of bugs that none of the other tests catch. 

-Filip

> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizło]

Context: https://trac.webkit.org/wiki/b3Discussion2015

I plan to write more on this topic soon. 

-Filip

> On Jan 28, 2016, at 11:12 PM, Stéphane Letz  wrote:
> 
> Maybe a stupid question, but what is a the rationale for this new backend? (I 
> was thinking LLVM JIT was used instead to produce machine code….)
> 
> Thanks.
> 
> Stéphane Letz
> 
>> Le 29 janv. 2016 à 01:23, Filip Pizlo  a écrit :
>> 
>> Hi everyone,
>> 
>> We’ve been working on a new compiler backend for the FTL JIT, which we call 
>> B3.  It stands for “Bare Bones Backend”.  We recently enabled it on X86/Mac, 
>> and we’re working hard to enable it on other platforms.
>> 
>> If you’re interested in how it works, I’ve started writing documentation.  
>> I’ll be adding more to it soon!
>> https://trac.webkit.org/wiki/BareBonesBackend
>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>> 
>> -Filip
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizło]

I'm all for this but I don't know anything about markdown. 

What's the best way to proceed?

-Filip

> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher <timo...@apple.com> wrote:
> 
> They should be markdown files like we do for the code style and policy 
> documents.
> 
> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md
> 
> We can then make Wordpress pages on the site that load the markdown.
> 
> Maybe put them in a /docs/b3/ directory?
> 
> — Timothy Hatcher
> 
>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo <fpi...@apple.com> wrote:
>> 
>> I guess we could put it in Websites/webkit.org/b3.  Then patches could edit 
>> both B3 and the documentation in one go, and the documentation would go live 
>> when it’s committed.
>> 
>> Does anyone object to this?
>> 
>> -Filip
>> 
>> 
>>> On Jan 28, 2016, at 4:39 PM, Saam barati <sbar...@apple.com> wrote:
>>> 
>>> Yeah. That’d be the easiest way to keep it up IMO.
>>> 
>>> Saam
>>> 
>>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło <fpi...@apple.com> wrote:
>>>> 
>>>> +1
>>>> 
>>>> Do you think we should move the documentation to a file in svn so that it 
>>>> can be reviewed as part of patch review?
>>>> 
>>>> -Filip
>>>> 
>>>>> On Jan 28, 2016, at 4:32 PM, Saam barati <sbar...@apple.com> wrote:
>>>>> 
>>>>> This is great. Thanks Fil.
>>>>> 
>>>>> I propose that we do all that we can to keep this updated.
>>>>> I suggest that all patches that change to the IR should also include with 
>>>>> it 
>>>>> a change to the documentation, and that reviewers should require this.
>>>>> 
>>>>> It’d also be great if other significant changes that seem like the deserve
>>>>> a mention in the documentation also get added as part of patches.
>>>>> 
>>>>> Saam
>>>>> 
>>>>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo <fpi...@apple.com> wrote:
>>>>>> 
>>>>>> Hi everyone,
>>>>>> 
>>>>>> We’ve been working on a new compiler backend for the FTL JIT, which we 
>>>>>> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it on 
>>>>>> X86/Mac, and we’re working hard to enable it on other platforms.
>>>>>> 
>>>>>> If you’re interested in how it works, I’ve started writing 
>>>>>> documentation.  I’ll be adding more to it soon!
>>>>>> https://trac.webkit.org/wiki/BareBonesBackend
>>>>>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>>>>>> 
>>>>>> -Filip
>>>>>> 
>>>>>> ___
>>>>>> webkit-dev mailing list
>>>>>> webkit-dev@lists.webkit.org
>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizło]

Thank you!  I'll convert them today. 

-Filip

> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher <timo...@apple.com> wrote:
> 
> Markdown is pretty similar to the wiki formatting and very simple.
> 
> You can look at a cheatsheet if you login to the blog: 
> https://webkit.org/wp/wp-admin/post.php?post=4300=edit
> 
> I have also used this HTML to Markdown converter before: 
> http://domchristie.github.io/to-markdown/
> 
> The pages are created:
> 
> https://webkit.org/documentation/b3/ loads /docs/b3/bare-bones-backend.md
> https://webkit.org/documentation/b3/intermediate-representation/ loads 
> /docs/b3/intermediate-representation.md
> 
> Once those files are added to SVN, they will get picked up by the site. I can 
> change those to point to other names if you want something different.
> 
> — Timothy Hatcher
> 
>> On Jan 29, 2016, at 9:34 AM, saam barati <saambara...@gmail.com> wrote:
>> 
>> I'm happy to convert the document to markdown. Can you send me your latest 
>> revision or post it to the website?
>> 
>> I usually look at:
>> http://daringfireball.net/projects/markdown/syntax
>> For a refresher on the syntax.
>> 
>> Tim, could you create a page that loads the markdown file?
>> 
>> Thanks,
>> Saam
>> 
>>> On Jan 29, 2016, at 12:06 AM, Filip Pizło <fpi...@apple.com> wrote:
>>> 
>>> I'm all for this but I don't know anything about markdown. 
>>> 
>>> What's the best way to proceed?
>>> 
>>> -Filip
>>> 
>>>> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher <timo...@apple.com> wrote:
>>>> 
>>>> They should be markdown files like we do for the code style and policy 
>>>> documents.
>>>> 
>>>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md
>>>> 
>>>> We can then make Wordpress pages on the site that load the markdown.
>>>> 
>>>> Maybe put them in a /docs/b3/ directory?
>>>> 
>>>> — Timothy Hatcher
>>>> 
>>>>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo <fpi...@apple.com> wrote:
>>>>> 
>>>>> I guess we could put it in Websites/webkit.org/b3.  Then patches could 
>>>>> edit both B3 and the documentation in one go, and the documentation would 
>>>>> go live when it’s committed.
>>>>> 
>>>>> Does anyone object to this?
>>>>> 
>>>>> -Filip
>>>>> 
>>>>> 
>>>>>> On Jan 28, 2016, at 4:39 PM, Saam barati <sbar...@apple.com> wrote:
>>>>>> 
>>>>>> Yeah. That’d be the easiest way to keep it up IMO.
>>>>>> 
>>>>>> Saam
>>>>>> 
>>>>>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło <fpi...@apple.com> wrote:
>>>>>>> 
>>>>>>> +1
>>>>>>> 
>>>>>>> Do you think we should move the documentation to a file in svn so that 
>>>>>>> it can be reviewed as part of patch review?
>>>>>>> 
>>>>>>> -Filip
>>>>>>> 
>>>>>>>> On Jan 28, 2016, at 4:32 PM, Saam barati <sbar...@apple.com> wrote:
>>>>>>>> 
>>>>>>>> This is great. Thanks Fil.
>>>>>>>> 
>>>>>>>> I propose that we do all that we can to keep this updated.
>>>>>>>> I suggest that all patches that change to the IR should also include 
>>>>>>>> with it 
>>>>>>>> a change to the documentation, and that reviewers should require this.
>>>>>>>> 
>>>>>>>> It’d also be great if other significant changes that seem like the 
>>>>>>>> deserve
>>>>>>>> a mention in the documentation also get added as part of patches.
>>>>>>>> 
>>>>>>>> Saam
>>>>>>>> 
>>>>>>>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo <fpi...@apple.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi everyone,
>>>>>>>>> 
>>>>>>>>> We’ve been working on a new compiler backend for the FTL JIT, which 
>>>>>>>>> we call B3.  It stands for “Bare Bones Backend”.  We recently enabled 
>>>>>>>>> it on X86/Mac, and we’re working hard to enable it on other platforms.
>>>>>>>>> 
>>>>>>>>> If you’re interested in how it works, I’ve started writing 
>>>>>>>>> documentation.  I’ll be adding more to it soon!
>>>>>>>>> https://trac.webkit.org/wiki/BareBonesBackend
>>>>>>>>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>>>>>>>>> 
>>>>>>>>> -Filip
>>>>>>>>> 
>>>>>>>>> ___
>>>>>>>>> webkit-dev mailing list
>>>>>>>>> webkit-dev@lists.webkit.org
>>>>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>> 
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizło]

+1

Do you think we should move the documentation to a file in svn so that it can 
be reviewed as part of patch review?

-Filip

> On Jan 28, 2016, at 4:32 PM, Saam barati  wrote:
> 
> This is great. Thanks Fil.
> 
> I propose that we do all that we can to keep this updated.
> I suggest that all patches that change to the IR should also include with it 
> a change to the documentation, and that reviewers should require this.
> 
> It’d also be great if other significant changes that seem like the deserve
> a mention in the documentation also get added as part of patches.
> 
> Saam
> 
>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  wrote:
>> 
>> Hi everyone,
>> 
>> We’ve been working on a new compiler backend for the FTL JIT, which we call 
>> B3.  It stands for “Bare Bones Backend”.  We recently enabled it on X86/Mac, 
>> and we’re working hard to enable it on other platforms.
>> 
>> If you’re interested in how it works, I’ve started writing documentation.  
>> I’ll be adding more to it soon!
>> https://trac.webkit.org/wiki/BareBonesBackend
>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>> 
>> -Filip
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Stack Alignment error in LLINT

[Filip Pizło]

We generally assume that calls into JavaScriptCore are made on an aligned 
stack. So, to my knowledge, our code does not usually do dynamic stack 
realignment. You should check the vmEntryToJavascript thunk - which gets called 
when you make a call into JS from native code - to see if it does dynamic 
realignment. You could add dynamic realignment code there if it isn't there 
already. 

-Filip

 On Jul 27, 2015, at 8:50 AM, Rodney Dowdall rdowd...@cranksoftware.com 
 wrote:
 
 Thanks for the response Michael.  Where does the code that does the padding 
 live?  It may be that I need to add something in there.  I can try changing 
 what the stack alignment should be, but from what I understand the QNX OS 
 should align to 16.  Maybe it is the exceptions that are causing the problem. 
  I could try building a 32 bit Linux build with exceptions on to see if I get 
 the same problem.
 
 Regards,
 Rodney
 
 On 07/27/2015 11:24 AM, Michael Saboff wrote:
 Rodney,
 
 JavaScriptCore assumes that the stack is 16 byte aligned.  This may be more 
 restrictive than some OS / ABIs, but there is code to pad appropriately for 
 some platforms. You didn’t say what OS you are running on, but maybe there 
 needs to be a code added for your OS.  Turning on C++ exceptions could be 
 responsible, as that could be changing stack layout.  I don’t know of any 
 platform that turns on C++ exceptions, so you may be in uncharted waters.
 
 Your build is 2 months old, the current revision is 187434.  You could also 
 try a more recent build.
 
 - Michael
 
 On Jul 27, 2015, at 8:07 AM, Rodney Dowdall rdowd...@cranksoftware.com 
 wrote:
 
 Hello
 
 I am seeing a SIGTRAP generated in the LLINT code when I try and load up a 
 page.  It happens as soon as the page tries to execute JavaScript.  The 
 target is an 32 bit x86 machine.  The SIGTRAP appears to happen when it is 
 checking the stack alignment.  I have tried compiling the code with the gcc 
 option -mstackrealign and without it.  The SIGTRAP is generated in the same 
 spot with or without the option.  C++ exceptions are turned on (they have 
 to be with this particular compiler.  The compiler is gcc based).  The 
 version of Webkit that I am building from is 184845.
 
 
 Here is the assembly execution that causes the SIGTRAP:
 
  vmEntryToJavaScript:
 b9a80ef7:   push %ebp
 b9a80ef8:   mov %esp,%ebp
 b9a80efa:   push %esi
 b9a80efb:   push %edi
 b9a80efc:   push %ebx
 b9a80efd:   mov 0xc(%ebp),%ebx
 b9a80f00:   mov 0x8(%ebp),%edi
 b9a80f03:   mov %ebp,%esp
 b9a80f05:   sub $0x20,%esp
 b9a80f08:   mov %ebx,(%esp)
 b9a80f0b:   mov 0x1498(%ebx),%edx
 b9a80f11:   mov %edx,0x4(%esp)
 b9a80f15:   mov 0x1494(%ebx),%edx
 b9a80f1b:   mov %edx,0x8(%esp)
 b9a80f1f:   mov 0x10(%ebp),%esi
 b9a80f22:   mov 0x20(%esi),%edx
 b9a80f25:   add $0x4,%edx
 b9a80f28:   shl $0x3,%edx
 b9a80f2b:   mov %esp,%eax
 b9a80f2d:   sub %edx,%eax
 b9a80f2f:   cmp 0x2384(%ebx),%eax
 b9a80f35:   jae 0xb9a80f71 vmEntryToJavaScript+122
 
 b9a80f71:   mov %eax,%esp
 b9a80f73:   mov $0x4,%eax
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f9e:   sub $0x1,%ecx
 b9a80fa1:   movl $0xfffc,0x2c(%esp,%ecx,8)
 b9a80fa9:   movl $0x0,0x28(%esp,%ecx,8)
 b9a80fb1:   cmp %ecx,%edx
 b9a80fb3:   jne 0xb9a80f9e vmEntryToJavaScript+167
 b9a80fb5:   mov 0x28(%esi),%eax
 b9a80fb8:   test %edx,%edx
 b9a80fba:   je 0xb9a80fd0 vmEntryToJavaScript+217
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 b9a80f8e:   mov 0x10(%esi),%edx
 b9a80f91:   sub $0x1,%edx
 b9a80f94:   mov 0x20(%esi),%ecx
 b9a80f97:   sub $0x1,%ecx
 b9a80f9a:   cmp %ecx,%edx
 b9a80f9c:   je 0xb9a80fb5 vmEntryToJavaScript+190
 
 b9a80fd0:   mov %esp,0x1498(%ebx)
 b9a80fd6:   mov %ebp,0x1494(%ebx)
 b9a80fdc:   add $0x8,%esp
 b9a80fdf:   mov %esp,%ecx
 b9a80fe1:   and $0xf,%ecx
 b9a80fe4:   test %ecx,%ecx
 b9a80fe6:   je 0xb9a80fee vmEntryToJavaScript+247
 b9a80fe8:   mov $0xbad0dc02,%ecx
 b9a80fed:   int3
 
 So using the LLintAssembly.h I tracked this too:
 
\tjz