Re: [webkit-dev] squirrefish extreme on Arm.

2011-11-26 Thread Filip Pizlo
but can I Cross-compile webkit on my x_64 machine so I can use it on my armv7 machine?? Which port are you working on? Mac or other? And I can't find any documentation about squirrelfish back-end, optimizations passes and so on. Currently I'm diong optimizations on Gcc compiler, and now I

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

2011-12-05 Thread Filip Pizlo
It's not quite true that multiple languages are exposed to the web. One Turing-complete language is exposed, and any Turing-complete language can be compiled to any other Turing-complete language. The fact that some developers compile their favorite languages to JS doesn't mean that we should

Re: [webkit-dev] Using Go in WebKit

2011-12-07 Thread Filip Pizlo
Can you comment why you think that Go would be the right tool for the job here, as opposed to Python, Perl, Ruby, or something else? I'm just curious, since I have not used Go. :-) -Filip On Dec 7, 2011, at 3:39 PM, Ojan Vafai wrote: Anyone have objections to me using Go for the test

Re: [webkit-dev] JSCore GDB Integration

2011-12-24 Thread Filip Pizlo
Hi all! I've been trying to add GDB support to JavaScriptCore; basically giving GDB the ability to understand code emitted by the JIT. This is easier now, due to a GDB extension I worked on some time back [1]. I have some of it working, and using a jit-reader plugin (again, see [1]), it

Re: [webkit-dev] [PATCH] JSCore with GDB

2011-12-28 Thread Filip Pizlo
Can you combine this into a single patch and put it up for review on bugs.webkit.org? Also please do add changelogs... It is our custom to have in the patches we put up for review. Which platforms is this tested on, btw? Thanks for your work on this! -Filip On Dec 28, 2011, at 3:38 AM,

Re: [webkit-dev] JavaScriptCore Garbage Collector Invocation

2012-02-06 Thread Filip Pizlo
Hi, I have been trying to optimize or somehow control the invocation of the Java Script Core's Garbage Collector by changing certain values like the highWaterMark and minBytesPerCycle of Heap.cpp. By default the value of minBytesPerCycle is 512 KB, but when i change it to 2 MB i found

Re: [webkit-dev] Difference between jit/JITArithmetic32_64 and jit/JITArithmetic

2012-02-17 Thread Filip Pizlo
The JIT class is quite large, and so its implementation is broken up into multiple files. The manner in which it is broken up is somewhat arbitrary, with the main goal being to not have any outrageously large .cpp files. Here's the intuition I use for finding what I want: JIT.cpp: the

Re: [webkit-dev] IDEA: Is it possible WebKit use LLVM as our JIT system of Javascript engine?

2012-02-17 Thread Filip Pizlo
It might be possible. But you'd have to solve the following problems: - OSR exits at the rate of roughly one per opcode. I'm not sure if LLVM supports them at all and if it does, I'm not sure that it can efficiently support as many of them as our backend. We can provide meta-data for how to

Re: [webkit-dev] Fwd: Native code generation for put_global_var instruction on X86_64 platform

2012-02-23 Thread Filip Pizlo
1. What is mean of currentInstruction[2]? As I Understand it's holds information about Int32: 6(@k1). Am I right?? It's a register index. Usually, it means that that index times 8 plus whatever is in the call frame register, you'll find the data for the register. But if it's larger than

Re: [webkit-dev] How to enable or disable jit when building QtWebKit

2012-03-12 Thread Filip Pizlo
I believe that QtWebKit has the JSC JIT enabled by default. The way I disable the JIT if I need to is: 1) Open Source/JavaScriptCore/wtf/Platform.h 2) Insert the line #define ENABLE_JIT 0 right after the #include wtf/Compiler.h -F On Mar 11, 2012, at 11:57 PM, Yongbing Huang wrote: Hi all,

Re: [webkit-dev] DFG optimizations

2012-03-25 Thread Filip Pizlo
Currently we do not have either LICM, or loop peeling, or GCSE. We do have a patch that implements LICM, but we are letting it simmer for now because under the current DFG IR, it is somewhat of a complicated beast. My main concern is just bug tail, due to the various stunts that the current

Re: [webkit-dev] Dfg phase.

2012-04-13 Thread Filip Pizlo
Can you clarify your question? It's OK to be more verbose. Thanks, -Filip On Apr 12, 2012, at 5:19 PM, asher brikaski wrote: Hi. I have some questions about methods: Can you tell me how take constants, variables in different vectors for each functions ? Thanks a lot

Re: [webkit-dev] SFX instructions emission slow cases

2012-04-18 Thread Filip Pizlo
JavaScript is a dynamically typed language. Therefore, we cannot know for sure what types of values may flow into an instruction at the time we compile it. a + b may be an integer addition that produces an integer result, an integer addition that overflows and produces a double, an addition of

Re: [webkit-dev] Eliminate potential null pointer dereference?

2012-04-20 Thread Filip Pizlo
On Apr 20, 2012, at 11:40 AM, Benjamin Poulain benja...@webkit.org wrote: On Fri, Apr 20, 2012 at 10:53 AM, Luke Macpherson macpher...@chromium.org wrote: What do we hope to achieve by adding a test when fixing a bug? To prevent a bug from being reintroduced into the codebase at a later

Re: [webkit-dev] spamming the developer console

2012-05-11 Thread Filip Pizlo
I broadly concur, and option (1) feels sensible. Here's my variant of option (1) and (4): display all these warnings by default but allow the user to click on one and select something like suppress all, which will suppress all warnings of that kind in the current session. Also have a reset

Re: [webkit-dev] can we stop using Skipped files?

2012-06-08 Thread Filip Pizlo
On Jun 8, 2012, at 4:38 AM, Balazs Kelemen kbal...@webkit.org wrote: On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote: Hi, Dirk Pranke írta: I believe most if not all of the ports have started using either TestExpectations files or a combination of TestExpectations files (except for the

Re: [webkit-dev] can we stop using Skipped files?

2012-06-08 Thread Filip Pizlo
On Jun 8, 2012, at 9:16 AM, Balazs Kelemen wrote: On 06/08/2012 05:21 PM, Filip Pizlo wrote: On Jun 8, 2012, at 4:38 AM, Balazs Kelemenkbal...@webkit.org wrote: On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote: Hi, Dirk Pranke írta: I believe most if not all of the ports have started

Re: [webkit-dev] can we stop using Skipped files?

2012-06-08 Thread Filip Pizlo
On Jun 8, 2012, at 9:52 AM, Ojan Vafai wrote: On Fri, Jun 8, 2012 at 9:25 AM, Filip Pizlo fpi...@apple.com wrote: On Jun 8, 2012, at 9:16 AM, Balazs Kelemen wrote: On 06/08/2012 05:21 PM, Filip Pizlo wrote: On Jun 8, 2012, at 4:38 AM, Balazs Kelemenkbal...@webkit.org wrote: On 06

Re: [webkit-dev] can we stop using Skipped files?

2012-06-08 Thread Filip Pizlo
On Jun 8, 2012, at 12:19 PM, Dirk Pranke wrote: On Fri, Jun 8, 2012 at 8:21 AM, Filip Pizlo fpi...@apple.com wrote: On Jun 8, 2012, at 4:38 AM, Balazs Kelemen kbal...@webkit.org wrote: On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote: Hi, Dirk Pranke írta: I believe most if not all

Re: [webkit-dev] can we stop using Skipped files?

2012-06-08 Thread Filip Pizlo
On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote: On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo fpi...@apple.com wrote: It's a lot harder to dive into, a lot more cumbersome to improve, and not any easier to maintain. I definitely agree that NRWT is more complicated than it seems like

Re: [webkit-dev] can we stop using Skipped files?

2012-06-08 Thread Filip Pizlo
On Jun 8, 2012, at 1:04 PM, Ryosuke Niwa wrote: On Fri, Jun 8, 2012 at 12:50 PM, Filip Pizlo fpi...@apple.com wrote: On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote: On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo fpi...@apple.com wrote: It's a lot harder to dive into, a lot more cumbersome

Re: [webkit-dev] DOM tree traversal on detached nodes

2012-06-11 Thread Filip Pizlo
I think that a lot of the performance penalty can be alleviated by: 1) Moving rarely executed paths into non-inlineable methods. 2) Marking the various refing methods ALWAYS_INLINE, after you've moved as much as possible out of line. 3) Using LIKELY and UNLIKELY where appropriate. The

Re: [webkit-dev] DOM tree traversal on detached nodes

2012-06-12 Thread Filip Pizlo
On Jun 11, 2012, at 11:35 PM, Ojan Vafai o...@chromium.org wrote: On Mon, Jun 11, 2012 at 9:32 PM, Filip Pizlo fpi...@apple.com wrote: I think that a lot of the performance penalty can be alleviated by: 1) Moving rarely executed paths into non-inlineable methods. 2) Marking the various

Re: [webkit-dev] are fuzzer tests appropriate layout tests?

2012-06-13 Thread Filip Pizlo
Are we sure that we want to make this a general rule? We have two profitable fuzzers in fast/js that I believe deserve to be in LayoutTests and should be run every time you make any JSC change: LayoutTests/fast/js/dfg-double-vote-fuzz.html LayoutTests/fast/js/dfg-poison-fuzz.html Both are

Re: [webkit-dev] DFG, inline functions compileing

2012-06-16 Thread Filip Pizlo
It's a bug. It's not a show stopper but if you've got a fix, I'd encourage you to submit a patch. -Filip On Jun 16, 2012, at 1:01 PM, Nare Karapetyan n...@rock.com wrote: Why in DFG inline functions are optimized(compiled) more than once - one time itself and then in caller function's

Re: [webkit-dev] DFG, inline functions compileing

2012-06-17 Thread Filip Pizlo
I'm not talking about the C++ compiler compiling the DFG. I'm instead referring to the DFG compiling JS code. -Filip On Jun 17, 2012, at 1:06 AM, Zoltan Herczeg zherc...@webkit.org wrote: Where are they compiled twice? If in the object file, than it is ok, since the compiler must provide a

Re: [webkit-dev] build-webkit failure

2012-06-17 Thread Filip Pizlo
Hi Mark! First, can you file a bug on bugs.webkit.org and assign it to me? Second, can you attach the contents of your LLIntDesiredOffsets.h file (the one at /WebKit-r120550/WebKitBuild/Release/LLIntOffsets/LLIntDesiredOffsets.h) along with preferably the entire build log? -F On Jun 17,

Re: [webkit-dev] DFG, inline functions compileing

2012-06-19 Thread Filip Pizlo
On Jun 19, 2012, at 5:04 AM, Nare Karapetyan wrote: If the object file is meant by a cfg IR dump, then yes. Assume that all of repeated compilations are okay, but then again going through all the passes of the optimizations in caller function probably does not make sense. Or I'm not right?

Re: [webkit-dev] JavaScriptCore memory issue

2012-06-20 Thread Filip Pizlo
Filing a bug is a good place to start! https://bugs.webkit.org/show_bug.cgi?id=89622 -F On Jun 20, 2012, at 5:28 PM, Horky Chen wrote: Hi, I found one memory management issue about JSC while testing below website on Mac OS Lion: http://bigsword.sinaapp.com/game.html Chrome only

[webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

2012-06-21 Thread Filip Pizlo
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

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

2012-06-22 Thread Filip Pizlo
On Jun 22, 2012, at 12:43 PM, Zoltan Herczeg zherc...@webkit.org 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

Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

2012-06-22 Thread Filip Pizlo
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 zherc...@webkit.org wrote: I

Re: [webkit-dev] Pointers and self-documenting code

2012-07-06 Thread Filip Pizlo
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 returning

Re: [webkit-dev] Class-level comments in the source code

2012-07-06 Thread Filip Pizlo
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

Re: [webkit-dev] Class-level comments in the source code

2012-07-06 Thread Filip Pizlo
. - 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 Pizlo fpi...@apple.com

Re: [webkit-dev] JavaScriptCore AST generator bug?

2012-07-08 Thread Filip Pizlo
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 laur...@gameclosure.com wrote: While experimenting with the new llint in JSCore, I noticed that the Not class (located in offlineasm/ast.rb) may have

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

2012-07-19 Thread Filip Pizlo
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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

2012-07-19 Thread Filip Pizlo
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 beid...@apple.com wrote: On Jul 19, 2012, at 10:53 AM, Andreas Kling

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

2012-07-19 Thread Filip Pizlo
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 alexis.men...@openbossa.org wrote: On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo fpi...@apple.com wrote: One reason for preferring printf

Re: [webkit-dev] Mystery of resolve_global bytecode instruction

2012-07-19 Thread Filip Pizlo
On Jul 19, 2012, at 2:28 AM, wingoog moon wingoo...@gmail.com 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*

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

2012-07-19 Thread Filip Pizlo
On Jul 19, 2012, at 2:58 PM, Balazs Kelemen kbal...@webkit.org wrote: On 07/19/2012 11:27 PM, Maciej Stachowiak wrote: On Jul 10, 2012, at 8:52 AM, Brady Eidsonbeid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menardalexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at

Re: [webkit-dev] Non JS Function call.

2012-07-24 Thread Filip Pizlo
On Jul 24, 2012, at 5:51 AM, vahe vardanyan vahag...@gmail.com 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

Re: [webkit-dev] Question about Floating-point operations base SH4 JIT

2012-08-02 Thread Filip Pizlo
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.

Re: [webkit-dev] Question about Floating-point operations base SH4 JIT

2012-08-02 Thread Filip Pizlo
On Aug 2, 2012, at 12:00 AM, 石梦军 talking1...@126.com wrote: My platform use the little-endian. -- BGs/Felix Shi At 2012-08-02 14:51:48,Filip Pizlo fpi...@apple.com wrote: What is the endianness of your platform? I think that the big endian code in JavaScriptCore may have rotted

Re: [webkit-dev] DFG Idom relation

2012-08-06 Thread Filip Pizlo
Sure, go ahead and submit a patch. -Filip On Aug 6, 2012, at 2:11 AM, Nare Karapetyan n...@rock.com 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

Re: [webkit-dev] Optimize Property Access failed

2012-08-08 Thread Filip Pizlo
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 the

Re: [webkit-dev] A proposal for handling failing layout tests and TestExpectations

2012-08-15 Thread Filip Pizlo
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

Re: [webkit-dev] A proposal for handling failing layout tests and TestExpectations

2012-08-15 Thread Filip Pizlo
On Aug 15, 2012, at 2:16 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 15, 2012, at 12:27 PM, Filip Pizlo fpi...@apple.com wrote: 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

Re: [webkit-dev] A proposal for handling failing layout tests and TestExpectations

2012-08-15 Thread Filip Pizlo
...@chromium.org wrote: On Wed, Aug 15, 2012 at 12:27 PM, Filip Pizlo fpi...@apple.com 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 are checking

Re: [webkit-dev] A proposal for handling failing layout tests and TestExpectations

2012-08-15 Thread Filip Pizlo
On Aug 15, 2012, at 4:02 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Aug 15, 2012 at 3:06 PM, Filip Pizlo fpi...@apple.com 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

Re: [webkit-dev] A proposal for handling failing layout tests and TestExpectations

2012-08-15 Thread Filip Pizlo
...@chromium.org wrote: On Wed, Aug 15, 2012 at 5:00 PM, Filip Pizlo fpi...@apple.com 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

Re: [webkit-dev] A proposal for handling failing layout tests and TestExpectations

2012-08-15 Thread Filip Pizlo
On Aug 15, 2012, at 5:51 PM, Peter Kasting pkast...@chromium.org wrote: On Wed, Aug 15, 2012 at 5:45 PM, Filip Pizlo fpi...@apple.com 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

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling failing layout tests and TestExpectations

2012-08-17 Thread Filip Pizlo
+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 rn...@webkit.org wrote: On Fri,

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling failing layout tests and TestExpectations

2012-08-17 Thread Filip Pizlo
Pranke dpra...@chromium.org 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 fpi...@apple.com wrote: +1

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling failing layout tests and TestExpectations

2012-08-17 Thread Filip Pizlo
, 2012 at 5:35 PM, Filip Pizlo fpi...@apple.com wrote: +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

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling failing layout tests and TestExpectations

2012-08-18 Thread Filip Pizlo
) but notify you of an unexpected pass if actual == expected. -F On Aug 18, 2012, at 1:02 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 17, 2012, at 8:02 PM, Filip Pizlo fpi...@apple.com wrote: So this is down to expected/failing and expected/previous? The difference is not just one

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling failing layout tests and TestExpectations

2012-08-18 Thread Filip Pizlo
smaller set of differences than status-quo versus any variant of this proposal. -Filip On Aug 18, 2012, at 2:01 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 18, 2012, at 1:08 AM, Filip Pizlo fpi...@apple.com wrote: I like your idea of having both the result-we-currently-expect

Re: [webkit-dev] A simpler proposal for handling failing tests WAS: A proposal for handling failing layout tests and TestExpectations

2012-08-18 Thread Filip Pizlo
On Aug 18, 2012, at 5:55 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 18, 2012, at 5:11 PM, Filip Pizlo fpi...@apple.com 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

Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt

2012-09-17 Thread Filip Pizlo
Annotations to spoonfeed a static analysis would make me profoundly unhappy. -Filip On Sep 17, 2012, at 8:13 PM, Hajime Morrita morr...@chromium.org wrote: On Tue, Sep 18, 2012 at 8:46 AM, Eric Seidel e...@webkit.org wrote: On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain

Re: [webkit-dev] Time to remove LIKELY and UNLIKELY macros?

2012-10-02 Thread Filip Pizlo
On Oct 2, 2012, at 12:48 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 2, 2012 at 12:17 AM, Mike Lawther mikelawt...@google.com wrote: On 2 October 2012 16:29, Maciej Stachowiak m...@apple.com wrote: Note, despite the stackoverflow thread cited, I would be highly surprised if

Re: [webkit-dev] recompilation in dfg

2012-10-12 Thread Filip Pizlo
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

Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Filip Pizlo
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 pkast...@chromium.org wrote: On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak m...@apple.com wrote: I am not sure a blanket rule is correct.

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

2012-11-03 Thread Filip Pizlo
On Nov 2, 2012, at 5:48 PM, Mark Lam mark@apple.com 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

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

2012-11-03 Thread Filip Pizlo
On Nov 3, 2012, at 10:09 AM, Mark Lam mark@apple.com wrote: On Nov 3, 2012, at 2:11 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 3, 2012, at 1:48 AM, Mark Lam mark@apple.com wrote: 1. If the inline method is a 1 liner, then leave it in the original header file. 2. If it

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

2012-11-05 Thread Filip Pizlo
On Nov 5, 2012, at 4:15 PM, Brendan Eich bren...@mozilla.org 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

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

2012-11-05 Thread Filip Pizlo
On Nov 5, 2012, at 9:27 PM, Geoffrey Garen gga...@apple.com 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

[webkit-dev] PSA: fixing indentation in JSC

2012-11-06 Thread Filip Pizlo
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.

Re: [webkit-dev] Instrumenting JavaScriptCore

2012-11-12 Thread Filip Pizlo
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

Re: [webkit-dev] Fwd: Understending LLInt

2012-11-14 Thread Filip Pizlo
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 wingoo...@gmail.com wrote: -- Forwarded message -- From: wingoog moon wingoo...@gmail.com Date: Wed, Nov 14,

Re: [webkit-dev] LLINT Value Profiling

2012-11-29 Thread Filip Pizlo
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

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

2013-01-09 Thread Filip Pizlo
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

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

2013-01-09 Thread Filip Pizlo
On Jan 9, 2013, at 10:04 PM, Ian Hickson i...@hixie.ch 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

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

2013-01-10 Thread Filip Pizlo
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 aba...@webkit.org napisał(a): Thanks everyone for your feedback. Detailed responses inline. On Wed, Jan 9, 2013 at 9:41 PM, Filip Pizlo fpi...@apple.com wrote: I

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

2013-01-11 Thread Filip Pizlo
understand why you would say you don't plan to build a test when above you cited a test and your plans to run it before and after. Am I missing some nuance? I didn't quite follow this last paragraph. On Thu, Jan 10, 2013 at 11:00 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for your detailed

Re: [webkit-dev] SVG external referencing not working as of latest chrome canary

2013-01-14 Thread Filip Pizlo
Sent from my PDP-11 On Jan 14, 2013, at 12:51 AM, Steve Williams stephen.j.h.willi...@googlemail.com 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

Re: [webkit-dev] WebKit Wishes

2013-01-30 Thread Filip Pizlo
Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org 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

Re: [webkit-dev] Deprecating JS interface

2013-02-17 Thread Filip Pizlo
On Feb 17, 2013, at 1:04 AM, Dirk Schulze dschu...@adobe.com wrote: On Feb 17, 2013, at 12:08 AM, Adam Barth aba...@webkit.org wrote: On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16,

Re: [webkit-dev] LLINT implementation for ARM traditional

2013-02-20 Thread Filip Pizlo
Yes, I think this is a great way to do it. Happy hacking, -Filip On Feb 20, 2013, at 6:56 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu wrote: Hello! I have started to implement LLINT for ARMv5 traditional and ARMv7 traditional but most of the instructions are identical with the ARMv7

Re: [webkit-dev] LLInt without JIT

2013-03-08 Thread Filip Pizlo
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

Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

2013-03-26 Thread Filip Pizlo
On Mar 26, 2013, at 1:40 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain benja...@webkit.org wrote: On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org wrote If we have consensus that we should just switch to paths relative to Source

Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

2013-03-27 Thread Filip Pizlo
On Mar 26, 2013, at 5:51 PM, Benjamin Poulain benja...@webkit.org wrote: On Tue, Mar 26, 2013 at 4:35 PM, Daniel Bratell brat...@opera.com wrote: Den 2013-03-26 21:29:32 skrev Benjamin Poulain benja...@webkit.org: On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org wrote If

Re: [webkit-dev] Fwd: Compiling WebKit up to 25% faster in Windows?

2013-03-27 Thread Filip Pizlo
On Mar 26, 2013, at 9:56 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi, On Mar 26, 2013, at 1:50 PM, Ryosuke Niwa rn...@webkit.org wrote: Interesting. I have the exact opposite experience, having to paw around to figure out where Font.h actually lives rather than just seeing

Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

2013-03-27 Thread Filip Pizlo
On Mar 27, 2013, at 12:40 PM, Pau Garcia i Quiles pgqui...@elpauer.org 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

Re: [webkit-dev] Feature announcement: Web VHS API

2013-04-01 Thread Filip Pizlo
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 barraclo...@apple.com wrote: On Apr 1, 2013, at 12:36 PM,

Re: [webkit-dev] Cleaning House

2013-04-04 Thread Filip Pizlo
On Apr 4, 2013, at 10:03 AM, Brent Fulgham bfulg...@gmail.com 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

Re: [webkit-dev] Cleaning House

2013-04-04 Thread Filip Pizlo
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

Re: [webkit-dev] Cleaning House

2013-04-04 Thread Filip Pizlo
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,

Re: [webkit-dev] Ruby in WebKit

2013-04-08 Thread Filip Pizlo
Wow, this is really cool! Congrats on the hard work! On Apr 8, 2013, at 11:41 AM, Tim Mahoney tim.maho...@me.com 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

Re: [webkit-dev] Sunsetting committership and reviewership

2013-04-10 Thread Filip Pizlo
Interesting. What privileges, if any, would you propose 'emeritus reviewers' to have? -Filip On Apr 9, 2013, at 2:54 PM, Dmitry Titov dim...@chromium.org wrote: How about creating an 'emeritus reviewer' status (no r+ power) and let people *voluntarily* move themselves to this status? I

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

2013-04-10 Thread Filip Pizlo
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 mikhail.pozdnya...@intel.com wrote: Hi, As far as I'm concerned WebCL would have serious security issues as it lets web app to

Re: [webkit-dev] Sunsetting committership and reviewership

2013-04-10 Thread Filip Pizlo
use of the word emeritus, so I should let him speak! On Tue, Apr 9, 2013 at 11:39 PM, Filip Pizlo fpi...@apple.com wrote: Interesting. What privileges, if any, would you propose 'emeritus reviewers' to have? -Filip On Apr 9, 2013, at 2:54 PM, Dmitry Titov dim...@chromium.org wrote

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

2013-04-10 Thread Filip Pizlo
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, April 10, 2013 10:37 AM To: Pozdnyakov, Mikhail Cc: Jer Noble

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

2013-04-10 Thread Filip Pizlo
On Apr 10, 2013, at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo fpi...@apple.com wrote: On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com wrote: Why not infer ParallelArrays automatically

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

2013-04-10 Thread Filip Pizlo
On Apr 10, 2013, at 1:15 PM, Filip Pizlo fpi...@apple.com wrote: On Apr 10, 2013, at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo fpi...@apple.com wrote: On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail mikhail.pozdnya

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

2013-04-10 Thread Filip Pizlo
On Apr 10, 2013, at 1:03 PM, Dirk Pranke dpra...@chromium.org 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

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

2013-04-11 Thread Filip Pizlo
On Apr 11, 2013, at 2:30 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Apr 10, 2013 at 1:17 PM, Filip Pizlo fpi...@apple.com wrote: I.e. if you believe that (A) is not a solvable problem, then this constitutes an argument against ParallelArrays, and not against inferring

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

2013-04-12 Thread Filip Pizlo
On Apr 12, 2013, at 8:36 AM, Hudson, Rick rick.hud...@intel.com 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

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

2013-04-12 Thread Filip Pizlo
On Apr 12, 2013, at 1:39 PM, Jarred Nicholls jarred.nicho...@gmail.com wrote: On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo fpi...@apple.com wrote: On Apr 12, 2013, at 8:36 AM, Hudson, Rick rick.hud...@intel.com wrote: I'm assuming that we agree that JavaScript must evolve to leverage

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

2013-04-12 Thread Filip Pizlo
On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: On Apr 12, 2013, at 1:39 PM, Jarred Nicholls jarred.nicho...@gmail.com wrote: On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo fpi...@apple.com wrote

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

2013-04-12 Thread Filip Pizlo
On Apr 12, 2013, at 6:35 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 12, 2013, at 2:13 PM, Filip Pizlo fpi...@apple.com wrote: On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: On Apr 12

  1   2   3   4   >