And it's landed. Things seem more-or-less OK.
I'll be around for the rest of the day to help with breakage.
At this point, it just seems like there are some tests to rebase and some
Windows stuff to fix.
-Filip
On Aug 15, 2013, at 12:21 AM, Filip Pizlo wrote:
> Here
Hopefully I'll get some help on Qt, also; but I think I covered my
bases there.
I plan to land this patch before 5PM PST tomorrow.
Thanks for all of the help I've received so far!
-Filip
On Aug 13, 2013, at 11:19 AM, Filip Pizlo wrote:
> Hi everyone!
>
> For the past we
its
> subtype relationship, or lack thereof, with Uint8Array.
>
> I prefer the Firefox semantics. Any objections?
>
> -Filip
>
>
> On Aug 13, 2013, at 11:19 AM, Filip Pizlo wrote:
>
>> Hi everyone!
>>
>> For the past week or so I've
mplementation.
>
> -jochen
>
>
> On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo wrote:
> What WebKit previously did: Uint8ClampedArray is a subtype of Uint8Array,
> i.e. Uint8ClampedArray.prototype.__proto__ === Uint8Array.prototype.
>
> I believe that Chrome still does
On Aug 13, 2013, at 11:19 AM, Filip Pizlo wrote:
> Hi everyone!
>
> For the past week or so I've been working on making typed arrays faster, use
> less memory, and GC better. It involves moving typed arrays entirely into
> JSC, and rewriting them so that they benefit f
Hi everyone!
For the past week or so I've been working on making typed arrays faster, use
less memory, and GC better. It involves moving typed arrays entirely into JSC,
and rewriting them so that they benefit from JSC object model optimizations.
Link: https://bugs.webkit.org/show_bug.cgi?id=11
JSValue must be 64 bits, no more, no less. This is a hard requirement for all
of our execution engines.
-Filip
> On Aug 5, 2013, at 6:57 AM, Abhishek Bichhawat
> wrote:
>
> Hi,
>
> I tried changing the JSValue.h and JSCell.h classes by adding new fields. It
> runs fine in some of the cases
It is possible to edit the LLInt and make it behave differently.
-Filip
> On Jul 10, 2013, at 2:22 AM, Abhishek Bichhawat
> wrote:
>
> Hi,
>
> With the classical interpreter being put off, is it possible to instrument
> the llint interpreter to make the opcodes work in a different way or be
Sent from my PDP-11
On Jun 19, 2013, at 9:41 AM, Dan Bernstein wrote:
>
>
> On Jun 19, 2013, at 7:37 PM, Timothy Hatcher wrote:
>
>> What about?
>>
>> StyleResolver* existingStyleResolver()
>> StyleResolver& styleResolver()
>
> I like it.
>
>>
>> — Timothy Hatcher
>>
>>
>> On Jun 19,
On Jun 26, 2013, at 7:36 AM, Gabor Rapcsanyi wrote:
> Hello!
>
> As I saw the DFG optimization and compilation are running on the main thread
> in JSC. I'm wondering if there is any known technical issue which block the
> parallelization of this?
This is damn hard. In ToT, the DFG JIT queri
I think the best way to make such points is to create a bug and post a patch.
-Filip
On Jun 11, 2013, at 1:32 PM, wkcensorshipbypass00...@mailinator.com wrote:
> Niwa, hi,
>
> CodeGenerator has already been rewritten in python, combining the following:
>
> * Mozilla's xpcom xpidl.py generator
Sent from my PDP-11
On Jun 7, 2013, at 6:18 AM, Simon Fraser wrote:
> Based on the fact that AtomicString is really a singleton string, I’d like to
> suggest a new name for this class:
>
> Stringleton
+1
>
> Simon
>
> On Jun 3, 2013, at 3:37 PM, Brendan Long wrote:
>
>> On 06/01/2013 1
Three suggestions:
1) If you find a bug in some part of WebKit (JSC or elsewhere), you should file
it on bugs.webkit.org. webkit-dev isn't really the right venue for bug reports.
2) You should be more specific - in the bug report that you will file and not
in this thread - about what port you'
On Apr 19, 2013, at 10:17 PM, Zoltan Herczeg wrote:
> Hi,
>
>> First, we think of WebCL more like a specialized toolbox for
>> JavaScriptlibrary providers, specifically those targeting compute
>> intensive use
>> cases. Areas such as image/photo editing, video and audio processing,
>> physical
On Apr 13, 2013, at 12:35 PM, Dirk Pranke wrote:
>
> On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
>> Perhaps we can come up with some JS API for shared memory & lock and propose
>> it in TC39 or W
On Apr 13, 2013, at 10:01 AM, Ian Hickson wrote:
> On Sat, 13 Apr 2013, Filip Pizlo wrote:
>>>
>>> It doesn't imply you can't have locks, it implies you can't have
>>> unprotected shared state.
>>
>> Same difference. I think this is
On Apr 13, 2013, at 8:37 AM, Ian Hickson wrote:
> On Sat, 13 Apr 2013, Filip Pizlo wrote:
>>>
>>> Actually, you can't. We very specifically designed workers (and even
>>> more importantly the API on the main thread) so that you cannot block
>>> o
On Apr 12, 2013, at 11:56 PM, Ian Hickson wrote:
> On Fri, 12 Apr 2013, Filip Pizlo wrote:
>>
>> There is a possibility of deadlock. You can have one task waiting for a
>> message from another, and that other waiting for a message from the
>> first.
>
On Apr 12, 2013, at 11:07 PM, Ryosuke Niwa wrote:
> On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
>
>> On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo wrote:
>>
>> On Apr 12, 2013, at 1:59 PM, Ryosu
On Apr 12, 2013, at 7:03 PM, Dirk Pranke wrote:
> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
> I'm curious: would you want to use ParallelArray, if you had the flexibility
> of building a different abstraction?
>
> I find ParallelArray to be an awkward abstracti
On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
> On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
>
>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>>
>> On Apr 12, 2013, at 1:39 PM, Jarred N
On Apr 12, 2013, at 9:46 PM, Rik Cabanier wrote:
>
>
> On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg wrote:
> > A message passing model a la Web Workers has some advantages compared to
> > threads with shared mutable state and locks:
> > - No possibility of deadlock
> > - No possibility of
On Apr 12, 2013, at 6:35 PM, Maciej Stachowiak wrote:
>
> On Apr 12, 2013, at 2:13 PM, Filip Pizlo wrote:
>
>>
>> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
>>
>>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>>>
>>> On
On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls
> wrote:
>
>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote:
>>
>> For as little worth as i
On Apr 12, 2013, at 1:39 PM, Jarred Nicholls wrote:
> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 8:36 AM, "Hudson, Rick" wrote:
>
> > I'm assuming that we agree that JavaScript must evolve to leverage the
> > hardwar
On Apr 12, 2013, at 8:36 AM, "Hudson, Rick" wrote:
> I'm assuming that we agree that JavaScript must evolve to leverage the
> hardware's power stingy parallelism.
True, but there is also the question of how high of a priority we should give
to this relative to other project goals, and also wh
On Apr 11, 2013, at 2:30 PM, Dirk Pranke wrote:
> On Wed, Apr 10, 2013 at 1:17 PM, Filip Pizlo wrote:
>> I.e. if you believe that (A) is not a solvable problem, then this
>> constitutes an argument against ParallelArrays, and not against inferring
>> that a normal array
On Apr 10, 2013, at 1:03 PM, Dirk Pranke wrote:
> Right, you need some way to ensure that the functions applied to the array
> are "pure", the array doesn't mutate, etc. I thought perhaps your
> ParallelArray() type would be ensuring this (e.g., by enforcing type checking
> and freezing the a
On Apr 10, 2013, at 1:15 PM, Filip Pizlo wrote:
>
> On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote:
>
>>
>>
>>
>> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote:
>>
>>
>> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov
On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote:
>
>
>
> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote:
>
>
> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail"
> wrote:
>
> >
> >
> >> Why not infer ParallelArrays
e developers
> to introduce OpenCL snippets to their web apps.
It's even more natural to not add yet another array type to ECMAScript.
-F
>
> BR,
> Mikhail
>
>
> From: Filip Pizlo [fpi...@apple.com]
> Sent: Wednesday,
have in our CC list, but not give any privileges to.
>
> Again, my thoughts on this may bear no reflection to what Dmitry had
> in mind with his use of the word "emeritus", so I should let him
> speak!
>
> On Tue, Apr 9, 2013 at 11:39 PM, Filip Pizlo wrote:
>&g
Why not infer ParallelArrays automatically? What is the specific reason for
requiring a new type?
-Filip
On Apr 10, 2013, at 12:16 AM, "Pozdnyakov, Mikhail"
wrote:
> Hi,
>
> As far as I'm concerned WebCL would have serious security issues as it lets
> web app to provide OpenCL target code
Interesting. What privileges, if any, would you propose 'emeritus reviewers'
to have?
-Filip
On Apr 9, 2013, at 2:54 PM, Dmitry Titov wrote:
> How about creating an 'emeritus reviewer' status (no r+ power) and let people
> *voluntarily* move themselves to this status? I bet a lot of 'inacti
Wow, this is really cool! Congrats on the hard work!
On Apr 8, 2013, at 11:41 AM, Tim Mahoney wrote:
> I modified WebKit to support Ruby. It needs more work, and I'd like some
> comments.
>
> You can check it out here:
> http://trydecaf.org
> http://github.com/timahoney/decaf
>
> I wrote a
Supporting multiple JS engines is a major burden, and prevents us from doing
optimizations that more seamlessly bridge the gap between DOM and JSC. I
suspect we won't want to continue supporting multiple JS engines like we did
when the Chrome folks used WebKit with V8.
-Filip
On Apr 4, 2013,
I think everyone is agreeing that we should have a suitable replacement for
EWS.
But I also want to see us move forward with clean ups. I think such clean ups
will bring clarity to what we would want our EWS testing to look like since
we'll have fewer configurations to test.
I like the appro
On Apr 4, 2013, at 10:03 AM, Brent Fulgham wrote:
> I would strongly suggest purging V8, for the many performance and code
> complexity reasons Google is removing JSC from blink. (See
> www.chromium.org/blink/developer-faq)
+1
>
> I'd also suggest purging the chromium layout tests ASAP so
We could do a custom JIT using Intel's crypto acceleration.
Could be even more epic than writing regexp JITs, I'm telling you it'll make
other engines look like fisher-price toys!
-Filip
On Apr 1, 2013, at 1:26 PM, Gavin Barraclough wrote:
> On Apr 1, 2013, at 12:36 PM, Glenn Adams wrote:
>
On Mar 27, 2013, at 12:40 PM, Pau Garcia i Quiles wrote:
> Hello,
>
> This thread already contains about 30 speculative messages. What about
> providing a patch for the whole WebKit and some benchmarks on the main
> platforms and compilers?
Good idea, want to write such a patch and put it up
On Mar 26, 2013, at 9:56 PM, Brent Fulgham wrote:
> Hi,
>
> On Mar 26, 2013, at 1:50 PM, Ryosuke Niwa wrote:
>
>> Interesting. I have the exact opposite experience, having to paw around to
>> figure out where "Font.h" actually lives rather than just seeing
>> "WebCore/platform/graphics/Font
On Mar 26, 2013, at 5:51 PM, Benjamin Poulain wrote:
> On Tue, Mar 26, 2013 at 4:35 PM, Daniel Bratell wrote:
> Den 2013-03-26 21:29:32 skrev Benjamin Poulain :
> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
>
> If we have consensus that we should just switch to paths relative to
> Sour
On Mar 26, 2013, at 1:40 PM, Dirk Pranke wrote:
> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain wrote:
> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
> If we have consensus that we should just switch to paths relative to Source
> (or maybe a couple different options), that would be
Yes. You can use the assembly LLInt backend without using the JIT. That's how
I was running it when I first wrote it.
I think that the code in Platform.h is being conservative, in the sense that it
assumes that if ENABLE(JIT) is not set then you're compiling for a target that
the LLInt wouldn
Yes, I think this is a great way to do it.
Happy hacking,
-Filip
On Feb 20, 2013, at 6:56 AM, Gabor Rapcsanyi wrote:
> Hello!
>
> I have started to implement LLINT for ARMv5 traditional and ARMv7 traditional
> but most of the instructions are identical with the ARMv7 ones, so I would
> lik
On Feb 17, 2013, at 1:04 AM, Dirk Schulze wrote:
>
> On Feb 17, 2013, at 12:08 AM, Adam Barth wrote:
>
>> On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze wrote:
>>> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak wrote:
On Feb 16, 2013, at 10:16 PM, Dirk Schulze wrote:
> On Feb 16,
Thanks for sharing this.
On Jan 30, 2013, at 1:28 PM, Eric Seidel wrote:
> I wish we only had one build system (it were easy to add/remove/move files).
>
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy sign for the project. Adam is not the only person who ha
Sent from my PDP-11
On Jan 14, 2013, at 12:51 AM, Steve Williams
wrote:
> Hi Maciej,
>
> 1. It's been on your bug database for ages hence filing another entry won't
> move anything forwards.
> 2. svg 1.1 spec seems a little over the top in places so not personally
> interested in full sup
make a significant complexity-imposing
>> architectural change for performance reasons, without any way to test
>> whether it delivers the claimed performance benefits, or how it compares to
>> less complex approaches, then why should any rational person agree with that
>
n then probably
everyone will be happy. But if it doesn't then it would be great to have a
"plan of retreat".
-Filip
Dnia 10 sty 2013 o godz. 12:07 Adam Barth napisał(a):
> Thanks everyone for your feedback. Detailed responses inline.
>
> On Wed, Jan 9, 2013 a
Hi Zoltan,
I would be curious how you did the synchronization. I've had some luck
reducing synchronization costs before.
Was the patch ever uploaded anywhere?
-F
On Jan 10, 2013, at 12:11 AM, Zoltan Herczeg wrote:
> Parsing, especially JS parsing still takes a large amount of time on page
On Jan 9, 2013, at 10:04 PM, Ian Hickson wrote:
> On Wed, 9 Jan 2013, Eric Seidel wrote:
>>
>> The core goal is to reduce latency -- to free up the main thread for
>> JavaScript and UI interaction -- which as you correctly note, cannot be
>> moved off of the main thread due to the "single thr
I think your biggest challenge will be ensuring that the latency of shoving
things to another core and then shoving them back will be smaller than the
latency of processing those same things on the main thread.
For small documents, I expect concurrent tokenization to be a pure regression
becaus
What you describe is super hard to do. Not just in WebKit but in any system.
The classical approach involves some combination of checkpointing (what you
seem to call "deep copy" - though the words "deep" and "copy" don't accurately
describe the technical challenge - there's no way for WebKit t
No. The type predictions come in via Node::getHeapPrediction() for those nodes
that were generated from bytecodes that had value profiles. The bytecode
parser sets the heap prediction (see OpInfo() arguments to addToGraph()) and
the prediction propagator propagates those heap predictions to th
The LLInt doesn't compile anything to native code, since its an interpreter. It
interprets the code instead.
-Filip
On Nov 14, 2012, at 3:19 AM, wingoog moon wrote:
>
>
> -- Forwarded message --
> From: wingoog moon
> Date: Wed, Nov 14, 2012 at 1:51 AM
> Subject: Understend
On Nov 12, 2012, at 7:55 PM, Erick Lavoie wrote:
> Hi,
>
> A research team instrumented JavaScriptCore in 2010 to gather empirical data
> about the dynamic behavior of JavaScript [1]. I am currently wondering how
> easy it would be to replicate their setup using the latest WebKit release.
>
>
I like this patch.
But I don't quite see why this couldn't live in WTF. It would certainly be
useful from places in JSC and WTF, so it would be unfortunate if this was
WebCore-only. And I don't see the circular dependency. And if you wanted to
have a wtfPrint() for IntRect, then couldn't you
All,
Over the next week or so I plan to fix indentation in JavaScriptCore.
Currently there is a tendency to indent four spaces inside namespaces, which is
contrary to our style guide as I understand it. I will do this one file at a
time. So far JSObject.h, JSArray.h, and JSCell.h are done.
On Nov 5, 2012, at 9:27 PM, Geoffrey Garen wrote:
>>> (5) Adopt the convention that any function that is not as trivial as "int
>>> x() { return m_x; }" moves out of the class declaration.
>>
>> How about we simplify this slightly to:
>>
>> (5) Adopt the convention that any function that is n
On Nov 5, 2012, at 4:15 PM, Brendan Eich wrote:
> Geoffrey Garen wrote:
>>> The proposed design requires adding a FooInlines.h include to source files
>>> that use that function, when any function moves into FooInlines.h. This can
>>> happen any time a function is made inline or when a short i
On Nov 3, 2012, at 10:09 AM, Mark Lam wrote:
>
> On Nov 3, 2012, at 2:11 AM, Maciej Stachowiak wrote:
>> On Nov 3, 2012, at 1:48 AM, Mark Lam wrote:
>>> 1. If the inline method is a 1 liner, then leave it in the original header
>>> file.
>>> 2. If it takes more than 1 line, then move it into
On Nov 2, 2012, at 5:48 PM, Mark Lam wrote:
> 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 nam
Peter Kasting napisał(a):
> On Sun, Oct 28, 2012 at 2:29 PM, Filip Pizlo wrote:
>> It is useful to say that "getting a pointer to T from an object of type S
>> does not change S's state".
>
> That's pretty much
It is useful to say that "getting a pointer to T from an object of type S does
not change S's state".
-F
On Oct 28, 2012, at 2:09 PM, Peter Kasting wrote:
> On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak wrote:
> I am not sure a blanket rule is correct. If the Foo* is logically related
Two bad things could have happened:
1) OSR entry failed. That's rare. You could try to put some logging in
prepareOSREntry.
2) The GC decided that it didn't want to keep your code around anymore. We
have heuristics for doing this even if your code doesn't OSR exit, and even
when the owning
On Oct 2, 2012, at 12:48 AM, Ryosuke Niwa wrote:
> On Tue, Oct 2, 2012 at 12:17 AM, Mike Lawther wrote:
>
> On 2 October 2012 16:29, Maciej Stachowiak wrote:
>
> Note, despite the stackoverflow thread cited, I would be highly surprised if
> static branch predicition had no effect ever, even
Annotations to spoonfeed a static analysis would make me profoundly unhappy.
-Filip
On Sep 17, 2012, at 8:13 PM, Hajime Morrita wrote:
> On Tue, Sep 18, 2012 at 8:46 AM, Eric Seidel wrote:
>> On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain
>> wrote:
>> > On Mon, Sep 17, 2012 at 4:11 PM, J
I approve.
Regardless of opinions of how good Coverity is at catching real bugs (I have
doubts), we already have changesets based on its advice. That ship has already
sailed. So, it would be great if the tool was more broadly available if only so
that others could see how it works.
-Filip
O
On Aug 18, 2012, at 5:55 PM, Maciej Stachowiak wrote:
>
> On Aug 18, 2012, at 5:11 PM, Filip Pizlo wrote:
>
>> Maybe at this point we can agree to let Dirk land some variant of this with
>> whatever half-way sensible name (any of the options on the table are decent)
&g
smaller set of differences than
status-quo versus any variant of this proposal.
-Filip
On Aug 18, 2012, at 2:01 PM, Maciej Stachowiak wrote:
>
> On Aug 18, 2012, at 1:08 AM, Filip Pizlo wrote:
>
>> I like your idea of having both the result-we-currently-expect and the
>> r
= failing (if a failing file exists) but
notify you of an "unexpected pass" if actual == expected.
-F
On Aug 18, 2012, at 1:02 AM, Maciej Stachowiak wrote:
>
> On Aug 17, 2012, at 8:02 PM, Filip Pizlo wrote:
>
>> So this is down to expected/failing and expected/prev
gt;> abstract sense. It is an expectation, not a reference.
>>> - It still leaves a clear indication of tests that somebody needs to look
>>> at further, to determine if a regression occurred.
>>> - It leaves both old and new result in place for easy comparison by an
>
Pranke wrote:
> All non-flaky failures, yes.
>
> Flaky tests would still require entries in the TestExpectations files
> at this time; discussion of how to treat them is a separate topic.
>
> -- Dirk
>
> On Fri, Aug 17, 2012 at 5:35 PM, Filip Pizlo wrote:
>> +1,
+1, contingent upon the following: are we agreeing that all current uses of
TEXT, IMAGE, and so forth in TestExpectations should be in the *very near term*
following Dirk's change be turned into -failing files?
-Filip
On Aug 17, 2012, at 5:01 PM, Ryosuke Niwa wrote:
> On Fri, Aug 17, 2012 at
On Aug 16, 2012, at 2:13 PM, Dirk Pranke wrote:
> On Wed, Aug 15, 2012 at 6:02 PM, Filip Pizlo wrote:
>>
>> 2) Possibility of the sheriff getting it wrong.
>>
>> (2) concerns me most. We're talking about using filenames to serve as a
>> kind of un
On Aug 15, 2012, at 6:18 PM, Peter Kasting wrote:
> On Wed, Aug 15, 2012 at 6:02 PM, Filip Pizlo wrote:
> 2) Possibility of the sheriff getting it wrong.
>
> (2) concerns me most. We're talking about using filenames to serve as a kind
> of unchecked comment. We alread
On Aug 15, 2012, at 5:51 PM, Peter Kasting wrote:
> On Wed, Aug 15, 2012 at 5:45 PM, Filip Pizlo wrote:
> The typical approach used in situations that you describe is to rebase, not
> skip.
>
> Which is precisely what Dirk is proposing. Literally the only difference
>
> On Wed, Aug 15, 2012 at 5:00 PM, Filip Pizlo wrote:
> I believe that the cognitive load is greater than any benefit from catching
> bugs incidentally by continuing to run a (1-fail) or (3) test, and continuing
> to evaluate whether or not the expectation matches some notions
On Aug 15, 2012, at 4:02 PM, Dirk Pranke wrote:
> On Wed, Aug 15, 2012 at 3:06 PM, Filip Pizlo wrote:
>> Apparently I was somewhat unclear. Let me restate. We have the following
>> mechanisms available when a test fails:
>>
>> 1) Check in a new -expected.* file
2:40 PM, Dirk Pranke wrote:
> On Wed, Aug 15, 2012 at 12:27 PM, Filip Pizlo wrote:
>> This sounds like it's adding even more complication to an already
>> complicated system.
>
> In some ways, yes. In other ways, perhaps it will allow us to simplify
> things; e.g., if we
On Aug 15, 2012, at 2:16 PM, Maciej Stachowiak wrote:
>
> On Aug 15, 2012, at 12:27 PM, Filip Pizlo wrote:
>
>> This sounds like it's adding even more complication to an already
>> complicated system.
>>
>> Given how many tests we currently have, I als
This sounds like it's adding even more complication to an already complicated
system.
Given how many tests we currently have, I also don't buy that continuing to run
a test that is already known to fail provides much benefit. If the test covers
two things and one fails while the other succeeds
The existence of the enable flag you mention implies that you have an ancient
version of WebKit. Please consider updating.
-Filip
On Aug 7, 2012, at 11:39 PM, talking1...@gmail.com wrote:
> Hi
> I enable ENABLE_JIT_OPTIMIZE_PROPERTY_ACCESS feature and find that it will
> crash when go back th
Sure, go ahead and submit a patch.
-Filip
On Aug 6, 2012, at 2:11 AM, Nare Karapetyan wrote:
> Hi.
> What are you thinking about building idom structure in DFGDominators? I
> suggest add idom relation(i.e. dominators tree), since that's much used in
> global optimizations. Isn't it ?
> I
re to look.
-F
On Aug 2, 2012, at 12:00 AM, 石梦军 wrote:
> My platform use the little-endian.
>
> --
> BGs/Felix Shi
>
> At 2012-08-02 14:51:48,"Filip Pizlo" wrote:
> What is the endianness of your platform? I think that the big endian code in
> JavaScrip
What is the endianness of your platform? I think that the big endian code in
JavaScriptCore may have rotted.
This smells to me like the tag and payload getting flipped around, which might
happen if there are parts of the code that are assuming little endian and your
hardware is big endian.
-F
On Jul 24, 2012, at 5:51 AM, vahe vardanyan wrote:
> Hi all.
>
> As I understand in SFX all non JS functions calls go trough
> JITStubs:op_call_NotJSFunction function.
>
> But in which point, where, the op_call_NotJSFunction function is called?
It's called from code generated by the JIT. I w
On Jul 19, 2012, at 2:58 PM, Balazs Kelemen wrote:
> On 07/19/2012 11:27 PM, Maciej Stachowiak wrote:
>> On Jul 10, 2012, at 8:52 AM, Brady Eidson wrote:
>>
>>> On Jul 10, 2012, at 5:25 AM, Alexis Menard
>>> wrote:
>>>
On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson wrote:
> On Jul 9
On Jul 19, 2012, at 2:28 AM, wingoog moon wrote:
> Hi all.
>
> I'm trying to understand how resolve_global instruction works for several
> days. Let's look at the code
>
> void JIT::emit_op_resolve_global(Instruction* currentInstruction, bool)
> {
>
> // Fast case
> void* globalObject =
But I do want a debugging utility to does land, is always compiled in, and that
everyone enjoys using.
-Filip
On Jul 19, 2012, at 11:37 AM, Alexis Menard wrote:
> On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo wrote:
>> One reason for preferring printf syntax is that it r
I should note that WTF already has an API for this. See DataLog.h. In JSC we've
been using it quite extensively to add pretty printers for a bunch of classes.
-Filip
On Jul 19, 2012, at 11:03 AM, Brady Eidson wrote:
>
> On Jul 19, 2012, at 10:53 AM, Andreas Kling wrote:
>
>> On Tue, Jul 10
One reason for preferring printf syntax is that it results in dramatically more
compact code. In JSC we take advantage of this to have debug printf support
built even in release builds. So or example if you want CodeBlock to print
itself in a release build, you don't first have to #define a bunc
Yes that's a bug.
In future, if in doubt, file a bug. No need to email the list first.
-Filip
On Jul 8, 2012, at 10:59 AM, Laurent Desegur wrote:
> While experimenting with the new llint in JSCore, I noticed that the
> Not class (located in offlineasm/ast.rb) may have an incorrect method:
>
.
- If you tried to show change log entries for that class, you would be
overwhelmed.
I think if you want to understand many of the hairy parts of the code, you just
need to read it.
-F
On Jul 6, 2012, at 4:11 PM, Ryosuke Niwa wrote:
>
> On Jul 6, 2012 3:04 PM, "Filip Pi
It is indeed a problem of incentives.
Nobody has the incentive to maintain a class comment when making changes, since
comments are not checked by the compiler.
Therefore, it's much better to not write comments, and instead find other ways
of making the code legible.
-F
On Jul 6, 2012, at 3:
On Jul 6, 2012, at 1:35 PM, Joe Mason wrote:
> As has been noted in a recent thread, WebKit strives to make the code clear
> and understandable rather than have embedded comments that can become
> obsolete. One common practice that I find quite opaque is for classes to
> have functions return
Ah, sorry, I misunderstood!
What about having a convention that assembly port maintainers are CC'd on bugs
that require new assembler support?
This will give you probably 10 hours heads up before the patch lands.
-F
On Jun 22, 2012, at 9:29 PM, Zoltan Herczeg wrote:
>> I don't want adding i
On Jun 22, 2012, at 12:43 PM, Zoltan Herczeg wrote:
> True, most of the changes are trivial. The problem is that the changes are
> usually appear without prior notice. A patch which depends on new macro
> assembler instructions, will obviously break the build, and we are not
> necessary there to
Hi all,
We are actively trying to improve the WebKit JavaScript engine
(JavaScriptCore), with new debugging, profiling, memory efficiency, and
performance features. Because JavaScriptCore is a JIT-based engine, this
inevitably means doing JIT work, which in turn includes adding new instruction
201 - 300 of 331 matches
Mail list logo
