Re: [webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
Hi, Since EFL supports cairo, we compared EFL-TyGL and EFL-Cairo * Canvas-performance: 1.7 times faster with TyGL (21 tests run correctly from 23 tests) Site: http://flashcanvas.net/examples/dl.dropbox.com/u/1865210/mindcat/canvas_perf.html * Asteroids-benchmark: 3.4 times faster with TyGL (4 tests run correctly from 6 tests) Site: http://www.kevs3d.co.uk/dev/asteroidsbench/ Regards, Zoltan How does TyGL perform compared to the other rasterizers? What benchmarks do you use to guide the performance work? On 11/12/14, 11:12 PM, Zoltan Herczeg wrote: Hi All, We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher. The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations. 2D graphics is traditionally software-based however, and 2D APIs are interfaces to these CPU-based algorithms. WebKit GraphicsContext API is no different, so the key challenge of our project was and is producing the expected output in a GPU friendly way. Key features: Batching pipeline: GPU provides the highest performance when a large number of triangles are drawn with a single draw command without any OpenGL state changes. The GraphicsContext API in WebKit provides draw operations for single shapes however, which can result frequent state changes if implemented naively. TyGL was designed to group these commands to reduce the number of draw calls. Automatic shader generator: TyGL can generate complex shaders from multiple shader fragments, which allows efficient batching but it also takes care to make them fit into the shader cache of the GPU. Trapezoid based path rendering: TyGL uses trapezoid-based tesselation of shapes and the GPU renders them with high anti-aliasing quality. We are continuously improving this part of the engine and look forward to make use of new GPU capabilities (like Pixel Local Storage) to squeeze more performance out of it. No software fallback: The whole engine is optimized for GPU without legacy software fallback. Hence we don't need to sacrifice optimizations for compatibility. There are enough software based 2D libraries which can be used when GPU is not available. TyGL is already capable of rendering many web-sites correctly, but some features have not been implemented yet. We continue this work and we are open to contributions from the community. Contact to us if you want more information about the project. Regards, U-Szeged's web browser team. ___ 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] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
Hi, we encountered some unexpected issues with Cairo-EFL on our board. When it works again, we will do some measurement. Regards, Zoltan How does TyGL perform compared to the other rasterizers? What benchmarks do you use to guide the performance work? On 11/12/14, 11:12 PM, Zoltan Herczeg wrote: Hi All, We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher. The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations. 2D graphics is traditionally software-based however, and 2D APIs are interfaces to these CPU-based algorithms. WebKit GraphicsContext API is no different, so the key challenge of our project was and is producing the expected output in a GPU friendly way. Key features: Batching pipeline: GPU provides the highest performance when a large number of triangles are drawn with a single draw command without any OpenGL state changes. The GraphicsContext API in WebKit provides draw operations for single shapes however, which can result frequent state changes if implemented naively. TyGL was designed to group these commands to reduce the number of draw calls. Automatic shader generator: TyGL can generate complex shaders from multiple shader fragments, which allows efficient batching but it also takes care to make them fit into the shader cache of the GPU. Trapezoid based path rendering: TyGL uses trapezoid-based tesselation of shapes and the GPU renders them with high anti-aliasing quality. We are continuously improving this part of the engine and look forward to make use of new GPU capabilities (like Pixel Local Storage) to squeeze more performance out of it. No software fallback: The whole engine is optimized for GPU without legacy software fallback. Hence we don't need to sacrifice optimizations for compatibility. There are enough software based 2D libraries which can be used when GPU is not available. TyGL is already capable of rendering many web-sites correctly, but some features have not been implemented yet. We continue this work and we are open to contributions from the community. Contact to us if you want more information about the project. Regards, U-Szeged's web browser team. ___ 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] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
Hi, What makes the 2D drawing code WebKit-specific? Is it possible to package up the rendering code into a self-contained standalone library? It is possible to make it a standalone library in the future. But we are working on WebKit, we want to accelerate WebKit graphics, and WebKit has a nice low-level infrastructure we don't want to duplicate. At least for now. Regarding text, do you have a strategy for instancing geometry or using a glyph atlas? Did you implement the Loop Blinn path algorithm? For fonts, we use glyph atlas at the moment. We don't use Loop-Blinn, since it has some issues with self-intersecting paths. Instead we use fast trapezoid partitioning. To achieve high anti-aliasing quality, we need to draw the path onto an internal texture first, which is slow because of texture fbo binding. However, if multiple paths are drawn (which is a frequent case), we draw multiple paths onto a single texture, so no fbo rebinding is needed. We hope Pixel Local Storage extension will eliminate the need of temporary images at all. It provides the freedom we need for a 2D engine allowing since all temporary data can be kept on GPU. Did you experiment with attempting to re-order independent drawing commands to achieve high GPU occupancy? We know overdraw is costly, and we want to use opacity information to reorder / drop unnecessary draws in the future. But this wasn't the biggest issue we had so far. My personal experience is that GPUs are very fast, after the fbo rebinding cost is paid. I did not see much difference of drawing a hundred or a thousand triangles (at least not a linear increment), except if the shader is very costly. Copy data between CPU and GPU is also very costly (and glReadPixels runtime is not predictable), so it is very important to keep data on textures. For example, we use inter-process texture sharing to transmit Cooridnated Graphics updates between the UI and Web process. Are you measuring power use in addition to time-based performance? Not yet. It sounds like OpenGL is doing the drawing itself; I would imagine there are many many draw calls per webpage. Does the OpenGL driver introduce significant overhead? Yes, that is why we use batching. And we still want to improve that, since we see significant improvement with clever batching. Are you thinking of publishing your findings? I would be very interested to read about design decisions you encountered along the way. Well, it is true we found many surprising issues and had to redesign core algorithms several times. Tile based embedded GPUs has unique strengths and weaknesses. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
Hi All, We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher. The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations. 2D graphics is traditionally software-based however, and 2D APIs are interfaces to these CPU-based algorithms. WebKit GraphicsContext API is no different, so the key challenge of our project was and is producing the expected output in a GPU friendly way. Key features: Batching pipeline: GPU provides the highest performance when a large number of triangles are drawn with a single draw command without any OpenGL state changes. The GraphicsContext API in WebKit provides draw operations for single shapes however, which can result frequent state changes if implemented naively. TyGL was designed to group these commands to reduce the number of draw calls. Automatic shader generator: TyGL can generate complex shaders from multiple shader fragments, which allows efficient batching but it also takes care to make them fit into the shader cache of the GPU. Trapezoid based path rendering: TyGL uses trapezoid-based tesselation of shapes and the GPU renders them with high anti-aliasing quality. We are continuously improving this part of the engine and look forward to make use of new GPU capabilities (like Pixel Local Storage) to squeeze more performance out of it. No software fallback: The whole engine is optimized for GPU without legacy software fallback. Hence we don't need to sacrifice optimizations for compatibility. There are enough software based 2D libraries which can be used when GPU is not available. TyGL is already capable of rendering many web-sites correctly, but some features have not been implemented yet. We continue this work and we are open to contributions from the community. Contact to us if you want more information about the project. Regards, U-Szeged's web browser team. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcement: web replay support
Wow, this looks great! Regards, Zoltan Hello all, I’m excited to announce that I’ve begun work on upstreaming web replay support into WebKit. Web replay functionality allows developers to debug their web applications by exactly recording interactions with a web program, and then replaying the resulting execution at will. A prototype implementation has integration with the Web Inspector, and supports many important web features. Most replay-related code will be behind the ENABLE(WEB_REPLAY) flag. It will be off by default until folks feel that the feature is ready for feedback through nightly builds. A high-level technical description of the prototype is available in the following paper: http://homes.cs.washington.edu/~mernst/pubs/record-replay-uist2013.pdf There’s also short demo video from last year: http://www.youtube.com/watch?v=ugHAzyQ6H00 Some accumulated details are on the prototype's wiki: https://github.com/burg/timelapse/wiki -Brian___ 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] Announcing new port: Nix
However, I am quite happy that people have been working on improving the libcURL support :-) Thank you Brent. Although many people left, we are still here, and continually improving WebKit. We are serious about it. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
Perhaps we can come up with some JS API for shared memory lock and propose it in TC39 or WebApps WG? I think that would be wonderful. Anyone else interested? We proposed a shared memory concept a long time ago: https://bugs.webkit.org/show_bug.cgi?id=53485 Although it helps to reduce the message passing (decoding/encoding) costs of large buffers, it still involves JS on the other side. We are definitely interested to improve JS with multicore support. Now even phones have 2-4 cores, and would be great to use them for computing. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
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 corrupting data structures due to races - No performance penalty from correctly supporting fine-grained concurrent access to arbitrary mutable objects The first is particularly important as you really do not want the web page's UI thread to lock up, even if the page itself is not making progress. I believe message passing as a concurrent programming model is much less prone to severe errors than shared mutable state + locking. I think you have to be super smart to even have a chance of using shared mutable state correctly. That being said, I am not sure Web Workers as they exist today are the best possible form of message passing. We tried to use WebWorkers for parallel computation, but in their current form, they are useless. We also searched for other Worker demos on the net, and all of them were slower with workers. I suspect ParallelArray will not help either. The problem is not producing messages, but receiving and processing them on the other side. Why? Because that involves JS. Noone will use JS to search prime numbers, they want to control the UI (animations, image generation, physics, etc.). Imho Workers need an API, which can be used to set (and perhaps get) properties without calling JS. Especially timed set (the change should be happen in a given time in the future). Very important for smooth animations. These properties must be constants: numbers, strings, RGBA arrays, etc. When we set dozens of properties, the extra cost on the UI side should be minimal. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Thank You
I may miss some mails, but I didn't see a proper reply for this mail. Personally, I think WebKit and its community should also be grateful to you guys. You did a lot for WebKit as well. Although the cooperation was not always smooth, let's just keep the good memories. I wish you luck for your Blink project. Regards, Zoltan I’m writing to say thank you, personally, and on behalf of the Chromium project. Chromium could not have happened without WebKit and the help of its contributors. As you likely have seen, Adam just posted http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html announcing Blink, which is a departure from our previous WebKit workflow. I hope that others will see Blink as I do: as a chance to take the WebKit codebase to exciting new places. I hope someday that many of the ideas we pursue in Blink will find their way into many platforms, including WebKit. For those interested in the technical details, we’ll be posting more of our thoughts and plans to blink-...@chromium.org. WebKit and Chromium have a long, shared history, and we hope to continue our relationship. We will be available on #webkit and webkit-dev and hope to continue our connections with this great community for years to come. Thank you again. Eric p.s. Adam and I are happy to work with other reviewers to remove PLATFORM(CHROMIUM) code and other messes we may have caused over the years from webkit.org. Adam and I are still running queues.webkit.org and associated EWS/CQ/sherriff-bot and plan to do so for the next few weeks as we work to transition them to new owners. ___ 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] Is the wxWidgets port maintained?
My point is that I think that lots of ports are part of what makes WebKit the goodness it is. Maybe I'm alone here, or at best part of a minority, but I wanted us to not lose sight of this idea. I totally agree. But I also agree with those, who thinks the different ports should not overburden the project. I would not mind to set up conditions for being part of the trunk. That could be useful for both adding and removing ports. There was also an unanswered question: is there anyone here who had difficulties because of the wxWidgets port? Or the only reason is that it has only one active maintainer, who has not committed anything for 6 months? Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
Where in WebKit do you experience problems with color conversion? As for me WebKit2 transmits BGRA images, which needs to be converted to RGBA before it is uploaded to a texture on GLES 2.0. These conversions seems computation heavy for certain animations, and I was wondered whether do we really need to use BGRA here. It would be nice to invent something to avoid that. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] RGBA8 and BGRA8 formats in WebKit
Hi, In WebKit both RGBA and BGRA formats are used for different purposes and different platforms in WebKit. Do we have a policy which one we prefer? It would be nice to reduce conversions between them in the future as it seems costly on embedded systems. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
Parsing, especially JS parsing still takes a large amount of time on page loading. We tried to improve the preload scanner by moving it into anouther thread, but there was no gain (except some special cases). Synchronization between threads is surprisingly (ridiculously) costly, usually worth for those tasks, which needs quite a few million instructions to be executed (and tokenization takes far less in most cases). For smaller tasks, SIMD instruction sets can help, which is basically a parallel execution on a single thread. Anyway it is worth trying, but it is really challenging to make it work in practice. Good luck! Regards, Zoltan 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 thread of execution model of the web. Parsing and (maybe to a lesser extent) compiling JS can be moved off the main thread, though, right? That's probably worth examining too, if it hasn't already been done. 100% agree. However, the same problem I brought up about tokenization applies here: a lot of JS functions are super cheap to parse and compile already, and the latency of doing so on the main thread is likely to be lower than the latency of chatting with another core. I suspect this could be alleviated by (1) aggressively pipelining the work, where during page load or during heavy JS use the compilation thread always has a non-empty queue of work to do; this will mean that the latency of communication is paid only when the first compilation occurs, and (2) allowing the main thread to steal work from the compilation queue. I'm not sure how to make (2) work well. For parsing it's actually harder since we rely heavily on the lazy parsing optimization: code is only parsed once we need it *right now* to run a function. For compilation, it's somewhat easier: the most expensive compilation step is the third-tier optimizing JIT; we can delay this as long as we want, though the longer we dela y it, the longer we spend running slower code. Hence, to make parsing concurrent, the main problem is figuring out how to do predictive parsing: have a concurrent thread start parsing something just before we need it. Without predictive parsing, making it concurrent would be a guaranteed loss since the main thread would just be stuck waiting for the thread to finish. To make optimized compiles concurrent without a regression, the main problem is ensuring that in those cases where we believe that the time taken to compile the function will be smaller than the time taken to awake the concurrent thread, we will instead just compile it on the main thread right away. Though, if we could predict that a function was going to get hot in the future, we could speculatively tell a concurrent thread to compile it fully knowing that it won't wake up and do so until exactly when we would have otherwise invoked the compiler on the main thread (that is, it'll wake up and start compiling it once the main thread has executed the function enough times to get good profiling data). Anyway, you're absolutely right that this is an area that should be explored. -F -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
https://bugs.webkit.org/show_bug.cgi?id=63531 The work was done by Zoltan Horvath and Balazs Kelemen. Regards, Zoltan 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 zherc...@webkit.org wrote: Parsing, especially JS parsing still takes a large amount of time on page loading. We tried to improve the preload scanner by moving it into anouther thread, but there was no gain (except some special cases). Synchronization between threads is surprisingly (ridiculously) costly, usually worth for those tasks, which needs quite a few million instructions to be executed (and tokenization takes far less in most cases). For smaller tasks, SIMD instruction sets can help, which is basically a parallel execution on a single thread. Anyway it is worth trying, but it is really challenging to make it work in practice. Good luck! Regards, Zoltan 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 thread of execution model of the web. Parsing and (maybe to a lesser extent) compiling JS can be moved off the main thread, though, right? That's probably worth examining too, if it hasn't already been done. 100% agree. However, the same problem I brought up about tokenization applies here: a lot of JS functions are super cheap to parse and compile already, and the latency of doing so on the main thread is likely to be lower than the latency of chatting with another core. I suspect this could be alleviated by (1) aggressively pipelining the work, where during page load or during heavy JS use the compilation thread always has a non-empty queue of work to do; this will mean that the latency of communication is paid only when the first compilation occurs, and (2) allowing the main thread to steal work from the compilation queue. I'm not sure how to make (2) work well. For parsing it's actually harder since we rely heavily on the lazy parsing optimization: code is only parsed once we need it *right now* to run a function. For compilation, it's somewhat easier: the most expensive compilation step is the third-tier optimizing JIT; we can delay this as long as we want, though the longer we dela y it, the longer we spend running slower code. Hence, to make parsing concurrent, the main problem is figuring out how to do predictive parsing: have a concurrent thread start parsing something just before we need it. Without predictive parsing, making it concurrent would be a guaranteed loss since the main thread would just be stuck waiting for the thread to finish. To make optimized compiles concurrent without a regression, the main problem is ensuring that in those cases where we believe that the time taken to compile the function will be smaller than the time taken to awake the concurrent thread, we will instead just compile it on the main thread right away. Though, if we could predict that a function was going to get hot in the future, we could speculatively tell a concurrent thread to compile it fully knowing that it won't wake up and do so until exactly when we would have otherwise invoked the compiler on the main thread (that is, it'll wake up and start compiling it once the main thread has executed the function enough times to get good profiling data). Anyway, you're absolutely right that this is an area that should be explored. -F -- Ian Hickson U+1047E)\._.,--,'``. fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit + OpenCL
Hi, I was thinking for some time whether I should reply, as there was no question in the mail, only an opinion. I still cannot say anything else that I respect this opinion. I am sure the intent is to make WebKit better, the same thing most of us want here. Dirk explained the technical part (btw we also have optimizations for Skia). This is the purpose of the /platform directory. Regards, Zoltan On Nov 23, 2012, at 2:43 PM, Andreas Kling akl...@apple.com wrote: Hi folks, Do we really think it's a good idea to add yet another implementation of filters? We already have generic, NEON-optimized and WTF::ParallelJobs (which includes generic, OpenMP and libdispatch backends) implementations of this code, and now we're adding OpenCL too. On the WebKit Project Goals page http://www.webkit.org/projects/goals.html, it states that: WebKit is an engineering project not a science project. For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven. Correct me if I'm wrong, but we don't see much use of these features on the web. I understand that there's a bit of a chicken/egg problem where a feature won't be interesting to content creators until it performs well enough, but it seems like we could at least decide on a single path forward instead of repeatedly forking the code. I designed the current SVG Filters implementation in a way that hopefully make it possible to implement HW accelerated filters on top of it. Skia and NEON already go this path. I am not defending the OpenCL implementation for SVG Filters per se, but different platform dependent solutions were expected and wanted. Software filters were designed to be a fallback if an implementation does not provide HW acceleration (yet). I hope that we see a Core Image version of filters in the near future as well. The code for that is in the history of the repository already. Greetings, Dirk -Kling On Nov 21, 2012, at 7:30 PM, Zoltan Herczeg zherc...@webkit.org wrote: Hi, we start upstreaming some OpenCL optimizations into WebKit. This is the master bug: https://bugs.webkit.org/show_bug.cgi?id=70099 Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebKit + OpenCL
Hi, we start upstreaming some OpenCL optimizations into WebKit. This is the master bug: https://bugs.webkit.org/show_bug.cgi?id=70099 Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] x32 support of JavaScriptCore
Just out of curiosity, how much code modifications are required? I read the ABI documentation the link you attached, and x32 is a regular 64 bit mode, except it seems to me that the global descriptor table is tweaked to store the same descriptors for all 4G address spaces, so the upper 32 bit is basically ignored when you access a memory address. It is called Small Code Model or something. I suspect the changes in the JIT code are minimal. Regards, Zoltan Thanks for the suggestions, Kenneth. I'm refining the code and trying to enable the last major component - the low level interpreter for x32. Yes it's ideal if we can upstream the code, and as you mentioned, keep maintaining it. The buildbot is a good idea while we are still way far from it - it requires a mature x32 system which at least supports all of the things that a WebKit port depends on. I know there're efforts porting Gentoo and Fedora to x32 - we may depend on each other. Currently I'm testing the JSC shell only. Though I use the EFL port, I eliminated most of the unnecessary dependencies on EFL libraries to run the JSC shell, so that I don't need to put efforts on compiling and enabling those dependencies for x32 at current stage. Thanks, -Yuqiang -Original Message- From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] Sent: 2012年10月11日 5:51 To: Xian, Yuqiang Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] x32 support of JavaScriptCore Hi, I don't think another branch on webkit.org will help you much; then you can as well have a branch anywhere. If you want this code to be well tested and maintained, you need to get it upstream (through all the review process) and promise that you have resources to keep maintaining it. It will also be an advantage if we can get a buildbot running this exact configuration, so that others can make sure they don't break your code. I think that whether the community will accept it upstream depends much about your commitment and the quality of the code, as well as how well you interact with the community during the reviews. Which port of WebKit is you currently using for testing? Cheers Kenneth On Wed, Oct 10, 2012 at 5:02 PM, Xian, Yuqiang yuqiang.x...@intel.com wrote: Hi, As you may already know there’s a new x32 ABI – a 32-bit psABI for x86-64 with 32-bit pointer size. It tries to leverage the advantage of more registers and IP relative addressing from x64 and the advantage of smaller memory footprint from IA32. You can find more details of the x32 ABI here: https://sites.google.com/site/x32abi/. The Linux kernel supports x32 since 3.4, and the commonly used development tools and libraries are getting in the x32 support. Also more details about current status is available in the above link. Now back to WebKit. In theory most part of the WebKit code should be fine (or require less efforts) to support x32, if they’re pure C++ code and can be compiled with the x32 toolchain. The major challenge is the JIT compiler in the JavaScript engine (and the low level interpreter) and some hand-written assembly code. So I’m currently working on enabling the x32 support of JavaScriptCore, the WebKit JavaScript engine, to try to remove the major obstacle. My current status is that I have enabled the baseline JIT, the DFG JIT and the Yarr JIT on x32 – it passes all the JavaScriptCore tests and the 3 major benchmarks. I’m posting this message in order to seek for some advices on how we should have our work shared to more people. I understand that it’s not very appropriate to try to get it into current WebKit trunk considering current x32 support status in major systems and the lack of maintenance in upstream, but we want to keep it synchronized with the newest changes of the WebKit code. So is it possible for us to maintain the code in a separate branch hosted at the WebKit server? Any suggestions are appreciated. Thanks, -Yuqiang ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4093 0598 / E-mail kenneth at webkit.org ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
Hi, parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: Unfortunately this part is removed by the mail server, and from webkit-dev archives, but as far as I remember (we measured the memory consumption of webkit several times before), the main memory consumers were JavaScriptCore (to reduce GC calls) and Resource caches, not rendering. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. This looks complicated and will likely break. The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. Guys here have a lot of experience with static source code analysis, I can give their contacts if you interested. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
The ARM support for DFG-JIT is finished, and the patch is ready to review at bug 90198. Regards, Zoltan On the topic of JIT support, the baseline JIT's role is increasingly only to serve only to gather profiling data for the DFG JIT, and if you want high performance JavaScript on your platform you need to have the DFG JIT enabled. As the purpose of the two JITs becomes increasingly coupled it may grow difficult to support the baseline JIT alone without the DFG JIT (we already have a maze of ifdefs for the two JITs, two interpreters, assembler support, value profiling support, etc), so any platforms that want to continue to keep a JIT enabled should probably look into supporting the DFG JIT sooner rather than later. cheers, G. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Good for me. Thanks for helping us. This will help to the buildbot maintainers as well, since if a patch cause a break where all of our names are CC'ed, they can just disable the JIT until the fix is landed. I think the several ports of JSC is something we should be proud of and I hope we can keep them in the future. Regards, Zoltan 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 don't want adding instructions to SH4, MIPS, and legacy ARM to be a blocker for JSC work. I didn't say you have to wait. I just said you should notify us that something is coming which will break the build. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi Filip, we (Gabor Loki and me) are the maintainers of the traditional ARM port, and we are willing to fix all issues. Just let us know what we need to do. You can assign the necessary bug reports to us and we are available in the #squirrelfish (or #webkit) channel as well. Regards, Zoltan 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 instructions to the JIT assemblers and changing the API between the assemblers and the JIT. Currently, the maintenance situation in the assembler layer is not great. We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then we have three assemblers that appear to be on life support: legacy (non-THUMB2, pre-v7) ARM, SH4, and MIPS. It is increasingly painful to maintain these three barely-supported assemblers. None of these assemblers has been updated to support the new JIT or interpreter infrastructure, and there appears to be no ongoing effort to do so. That means that for progress to be made on X86 and ARMv7, we need to increasingly scatter #if ENABLE(...) noise throughout the system to keep those other assemblers building. Neither the active JavaScriptCore contributors, nor those running the bots for those hardware platforms, appear to have much interest in maintaining those assemblers, other than the occasional build fix. This is not a good situation to be in. So, I am curious: is anyone shipping with the legacy ARM assembler, the MIPS assembler, or the SH4 assembler? As a secondary question, if you are shipping the legacy ARM assembler, are you doing so because you have legacy ARM hardware or because you have not had the chance to switch to the new ARM assembler in your codebase? -Filip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
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 fix it immediately. I think most improvements require time to finish, so these new instructions are known several days before the patch is submitted to the bugzilla. If we would know about these new instructions before the patch appears, we could prepare the macro assembler to handle them. Would it be possible to share us these new requirements before such patches appear? Regards, Zoltan That would be the ifdef hell we currently deal with. One option (that would keep everything building till appropriate people have fixed whatever needs to be fixed) would simply be to disable the JIT for effected platforms everytime something changes that is too difficult for us to blindly fix. Then people with appropriate hardware and toolchains could make the (probably trivial) changes required to bring them up again. --Oliver On Jun 22, 2012, at 11:20 AM, Maciej Stachowiak wrote: Is there a way to reduce these costs other than deleting the slower-maintained JITs? For example, could we temporarily freeze the JIT (perhaps the whole JSC engine somehow) at old versions somehow for architectures that may take time to catch up? Regards, Maciej On Jun 22, 2012, at 10:52 AM, Oliver Hunt oli...@apple.com wrote: The problem is that as we make changes we end up breaking the SH4, MIPS, ARMvOld builds, which we are ostensibly not allowed to do, and so have to spend significant amounts of time trying to ensure that the builds don't break/start failing horribly, and then having committed the patch[es] we have to spend multiple build bot cycles discovering all the cases that we missed. This consumes a lot of time that would be better spent working on the higher level portions of the JIT, that benefit all platforms. --Oliver On Jun 21, 2012, at 11:44 PM, Zoltan Herczeg wrote: Hi Filip, we (Gabor Loki and me) are the maintainers of the traditional ARM port, and we are willing to fix all issues. Just let us know what we need to do. You can assign the necessary bug reports to us and we are available in the #squirrelfish (or #webkit) channel as well. Regards, Zoltan 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 instructions to the JIT assemblers and changing the API between the assemblers and the JIT. Currently, the maintenance situation in the assembler layer is not great. We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then we have three assemblers that appear to be on life support: legacy (non-THUMB2, pre-v7) ARM, SH4, and MIPS. It is increasingly painful to maintain these three barely-supported assemblers. None of these assemblers has been updated to support the new JIT or interpreter infrastructure, and there appears to be no ongoing effort to do so. That means that for progress to be made on X86 and ARMv7, we need to increasingly scatter #if ENABLE(...) noise throughout the system to keep those other assemblers building. Neither the active JavaScriptCore contributors, nor those running the bots for those hardware platforms, appear to have much interest in maintaining those assemblers, other than the occasional build fix. This is not a good situation to be in. So, I am curious: is anyone shipping with the legacy ARM assembler, the MIPS assembler, or the SH4 assembler? As a secondary question, if you are shipping the legacy ARM assembler, are you doing so because you have legacy ARM hardware or because you have not had the chance to switch to the new ARM assembler in your codebase? -Filip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
I don't want adding instructions to SH4, MIPS, and legacy ARM to be a blocker for JSC work. I didn't say you have to wait. I just said you should notify us that something is coming which will break the build. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
Where are they compiled twice? If in the object file, than it is ok, since the compiler must provide a standalone function for even inline ones. It is needed if the function is passed as pointer. These extra functions should be thrown out by the linker in the final binary. Regards, Zoltan 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 body? -- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] can we stop using Skipped files?
Hi, I don't see why it would make sense to keep two parallel tools for this once all the workflow bugs people have are addressed. The reason is easy. In the past when people tried to add new features to NRWT, they were not allowed to because the feature is not useful for NRWT devs. Eventually people got tired of NRWT and use ORWT instead since its development is not as restricted. Is this changed? Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] can we stop using Skipped files?
Hi Dirk, At any rate, I believe we are definitely open to adding new features; feel free to suggest them or work on them! I am happy to hear that. https://bugs.webkit.org/show_bug.cgi?id=88680 This is definitely a right step! And it looks like still a lot of things to do before NRWT reach ORWT level. We decided to have a meeting in the beginning of the next week where we discuss the needs of our bots and devices (like parallel layout testing on multiple ARM devices). We can send you a summary, and decide the best way to add them to NRWT. We always think RWT as a swiss knife not an end user software. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Transformations precision: double - float
Hi, is there any reason why the transformations in WebKit use doubles? We could optimize some functions further with ARM SIMD if they would be floats. Is there any objection to make them float if the change would have no other side effects except some rounding because of the lower precision? Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Anyone using NEON code on ARM builds?
Hi,
btw if anyone interested about the details of this optimization you can
read more about it here:
http://blogs.arm.com/software-enablement/699-using-arm-neon-to-accelerate-scalable-vector-graphics-in-webkit-by-up-to-4X/
Regards,
Zoltan
Hi Jonathan,
On 21/03/2012, at 12:56 AM, Jonathan Kliegman wrote:
On Wed, Mar 14, 2012 at 2:14 PM, Dean Jackson d...@apple.com wrote:
Hi,
There are three files with embedded NEON code to speed up filters:
./Source/WebCore/platform/graphics/filters/arm/FECompositeArithmeticNEON.{h,cpp}
./Source/WebCore/platform/graphics/filters/arm/FEGaussianBlurNEON.{h,cpp}
./Source/WebCore/platform/graphics/filters/arm/FELightingNEON.{h,cpp}
Are any ARM ports using this? (would require SVG and FILTERS both
enabled) If so, could you contact me? Off list is fine.
I see the code came from Felician Marton via Zoltan reviewed by Dirk
(eg. https://bugs.webkit.org/show_bug.cgi?id=65522) and it's been very
slightly touched for some chromium build issues.
Chrome OS has ports that use NEON and has SVG and FILTERS both enabled
so this would still be used.
Excellent!
Zoltan and I have been chatting offline a bit. I was testing compilation
on Darwin/iOS ARM and running into a few issues. The first was about
alignment errors from the compiler. The second was some linking issues,
for example:
https://bugs.webkit.org/show_bug.cgi?id=81568
Is there someone (you?) on the Chrome team I should CC on any bugs raises?
Dean
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Grafikus teamnek
Sziasztok! Jatszottam penteken OpenGL-el egy kicsit (MAC-en gluttal szepen ment), es arra gondoltam hogy elindulas keppen csinalhatnank valami brainstormingot az egesz temarol. Nem tudom ki mennyire ismeri az OpenGL es OpenVG mukodeset (en sem tulsagosan). Eszerint: http://www.gsmarena.com/nokia_n9-3398.php az N9 GPU-ja egy Imagination Technologies PowerVR SGX530 Eszerint: http://www.imgtec.com/corporate/newsdetail.asp?NewsID=441 tud OpenVG-t. Eszerint http://www.imgtec.com/powervr/sgx_series5.asp pedig OpenGL 2.0-at. Ezeket elvben tudja a MALI is a Samsung Origen-en. Na most az OpenGL-nel az extensionok lekeresen sok mulik. glGetString(GL_EXTENSIONS)-al lehet oket lekerni, es meg kene neznunk mi az ami mindket celplatformon elerheto. Foggalmam sincs az OpenVG-nel vannak-e ilyenek. Ott is fel kene allitani valami demoalkalmazast ami mondjuk kirajzol egy-ket vonalat meg kiirja az extension-oket. Udv HZ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Grafikus teamnek
Oops sorry. Ignore this mail. Regards, Zoltan Sziasztok! Jatszottam penteken OpenGL-el egy kicsit (MAC-en gluttal szepen ment), es arra gondoltam hogy elindulas keppen csinalhatnank valami brainstormingot az egesz temarol. Nem tudom ki mennyire ismeri az OpenGL es OpenVG mukodeset (en sem tulsagosan). Eszerint: http://www.gsmarena.com/nokia_n9-3398.php az N9 GPU-ja egy Imagination Technologies PowerVR SGX530 Eszerint: http://www.imgtec.com/corporate/newsdetail.asp?NewsID=441 tud OpenVG-t. Eszerint http://www.imgtec.com/powervr/sgx_series5.asp pedig OpenGL 2.0-at. Ezeket elvben tudja a MALI is a Samsung Origen-en. Na most az OpenGL-nel az extensionok lekeresen sok mulik. glGetString(GL_EXTENSIONS)-al lehet oket lekerni, es meg kene neznunk mi az ami mindket celplatformon elerheto. Foggalmam sincs az OpenVG-nel vannak-e ilyenek. Ott is fel kene allitani valami demoalkalmazast ami mondjuk kirajzol egy-ket vonalat meg kiirja az extension-oket. Udv HZ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top 100 sites browsing tests proprosal
But are you planning to run test builds against live websites? That's not very polite on people's servers (i certainly wouldn't like anyone stress-testing my own servers for their benefit). And like some other people said, tests that rely on network randomness are not very reliable indicators of anything. I think he is planning to have a local copy of those websites, and its public interface will only be run tests like the EWS system. As far as I know that is possible way to avoid copyright issues. Thanks for the explanation Sergio, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top 100 sites browsing tests proprosal
Just be careful with copyright issues. Regards, Zoltan Go for it. Adam On Sat, Jan 21, 2012 at 2:12 AM, Sergio Villar Senin svil...@igalia.com wrote: Hi, I've been thinking about this for some time now, but only a recent bug I'm constantly hitting these days (https://bugs.webkit.org/show_bug.cgi?id=76574) triggered this email [1]. What I would like to propose here is to have a battery of tests that would check that the most visited sites (let's say the top 100 for example) are correctly loaded by WebKit. By correctly loaded, I don't mean layout or ref tests, they'll just check that the page poad ends without any assertion. I know that trunk is for raw development but having 25k layout tests passing is nothing if a so popular site as Wikipedia triggers an assertion while being loaded. The obvious answer is ok so we need more tests, we all agree on that, but having like real-word permanent tests would not harm I guess (and probably help defining more layout tests). I haven't took a detailed look at them, but maybe these main sites browsing tests could be part of the perf tests rniwa and others recently setup. What do you think? BR [1] note that I am not blaming anyone in particular, we all add bugs, just that this one finally flipped the switch :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Arm conditional instructions support
Hi! Condition cc=ALL is the default function parameter in C++ (http://www.learncpp.com/cpp-tutorial/77-default-parameters/). There is no conditional instruction support in MacroAssembler level in SFX, but some lower-level optimizations use conditional execution. Regards, Zoltan Hi! I found that in http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/assembler/ARMAssembler.h all functions were called with Condition cc=ALL parametr Does it mean that SFX currently cannot support conditional execution? -- View this message in context: http://old.nabble.com/Arm-conditional-instructions-support-tp32958547p32958547.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Custom written css lexer
Hi, I am working on rewriting the css lexer, and someone suggested that it should be mentioned to a broader community, since we can drop the flex tool dependency from WebKit which affects all build systems. This mail is just a note, since the patch is not yet ready. https://bugs.webkit.org/show_bug.cgi?id=70107 Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
Hi Anton, I am sorry if it didn't sound clear enough in our original message, but we're not proposing a new language support, but we're proposing a patch which allows others runtimes to run along with JS in the browser. and they mostly replied to that (including some solution ideas like converting your language to JS. You might even see some speedup :) ). Of course, we're doing this because of our work on Dart, but our intent was to solicit a feedback from the WebKit community if there is any interest in supporting runtimes additional to JS (and not JS + Dart) in the first place. The question they raised was what we need to sacrifice for this support. JS is heavily tied with WK internals, lots of JS specific things everywhere (yeah, you can change the JS engine in WK, but only to another JS engine). Change that to something general affects maintenance (new abstraction layers / API) and performance (probably memory as well), and its drawbacks are unknown yet (and its advantages are questionable), especially in a mixed environment. I think you should start this work in a private branch (code.google.com?) and tell us your experiences later. It is difficult to judge this feature at the moment. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
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 support all of them natively. Such a complicated way to say no :) Actually I agree with those who think this would be too much burden on the project. Both in terms of maintainability and performance. However, setting up your own branch somewhere you have access should not be a trouble. We do that all the time when we need custom features. If your project will be successful, we could add A+ to the supported languages ;) Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] squirrefish extreme on Arm.
Hi, WebKit supports ARM and Thumb2 instructions sets (called ARMv7). You can find them here (or in your own source code): http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/assembler SquirrelFish Extreme is just a codename for the JavaScript JIT compiler (and Nitro is another). The JIT compiler is enabled by default on most OS-es, just compile WebKit and you have it. Regards, Zoltan Hi all. I didn't find any documentation about porting squirrefish extreme on Arm. I tried to google it, and found some posts where said that there is squirrefish extreme on Arm, but I can't find source cod,or any documentation about it( Can anybody help me. Any information about squirrefish extreme is important for me:) p.s I download latest code of webkit from offical site by svn and built it under x86_64. In source code I didn't find any squirrefish extreme I think that squirrefish extreme source code is in javaScriptCoe folder. Am I right??? and if no how I can compile webkit with squirrefish extreme -- View this message in context: http://old.nabble.com/squirrefish-extreme-on-Arm.-tp32876913p32876913.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing ENABLE_SINGLE_THREADED and ENABLE_JSC_MULTIPLE_THREADS
Hi, I like this idea. Multicore cpus are getting widespread even in the low-end devices nowadays. Regards, Zoltan Hi folks. To help move WebKit and JavaScriptCore forward, I'd like to remove old platform cruft that creates particular pain points for development. To that end, I'd like to remove ENABLE_SINGLE_THREADED and !ENABLE_JSC_MULTIPLE_THREADS. I believe these code paths are untested by core WebKit developers. Also, in the modern world of multicore CPUs, it seems prudent to allow programmers to assume that all OS's running WebKit at least know what a thread is how to create one. Thoughts? Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScripCore on Android
Hi, ThreadSpecific contains the platform dependent TLS (Thread Local Storage) implementation for WebKit. In Platform.h: #if PLATFORM(ANDROID) #define WTF_USE_PTHREADS 1 ... Thus, Android should use pthread.h (Please check this line in your Source/JavaScriptCore/wtf/Platform.h) You could try to add a #include wtf/Platform.h to the beginning of ThreadSpecific.h header file, but it would be strange if it would not be included. Regards, Zoltan Hi, I hope I make myself clear, but i am sorry for my poor English. I am trying to build the JavaScriptCore (a piece of webkit) as a shared object to use in my Android Application. I got a lot of errors and i corrected them by configuring my Android.mk file. But, now i am getting the following error: In file included from /home/ecioffi/Spring/JavaScriptCore/runtime/JSGlobalData.h:48, from /home/ecioffi/Spring/JavaScriptCore/interpreter/CallFrame.h:26, from /home/ecioffi/Spring/JavaScriptCore/runtime/JSCell.h:27, from /home/ecioffi/Spring/JavaScriptCore/runtime/JSAPIValueWrapper.h:26, from /home/ecioffi/Spring/JavaScriptCore/API/APICast.h:29, from /home/ecioffi/Spring/JavaScriptCore/API/JSValueRef.cpp:29: /home/ecioffi/Spring/JavaScriptCore/wtf/ThreadSpecific.h:208:2: error: #error ThreadSpecific is not implemented for this platform. /home/ecioffi/Spring/JavaScriptCore/wtf/ThreadSpecific.h:232:2: error: #error ThreadSpecific is not implemented for this platform. I believe the problem is in the beginning of the build because i am not able to regenerate the correct config.h file (specific to Android platform). Can you help me? How can I configure the build correctly? When I execute the ./configure script passing the Android NDK information i got some File not found errors. I appreciate any help... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Rounding issues on different platforms
Hi, If you maintain some bots, and you saw rounding issues which makes 1px difference on let's say 32 and 64 bit environments for several layout tests, you may interested in this bug: https://bugs.webkit.org/show_bug.cgi?id=62204 I try to explain what exactly happens there, and it could be used as a master bug for tracking these issues. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More thoughts on cleaning up the root directory
Like it. I only have a few questions: * Where would the build (WebKitBuild) directory would go? Perhaps a Build/ would fit in the root directory. * Some manual-tests belong to the regression tests, and some are belong to the performance test. Would be good to separate them. * I think the build related files could go to Sources/ (no need an extra level) Regards, Zoltan Here's a snapshot of my current thinking on where the files and folders currently in the top-level directory might go. There are a bunch of build-system related files that are currently in the root. I'm not sure whether we should leave them in there or move them into Sources somewhere. I'm tempted to put them into Sources so that Sources is self-contained package of all the stuff you need to build WebKit. That said, having a top-level Makefile that kicks off the whole process also seems reasonable. Examples/ PerformanceTests/ PageLoad/ (was PageLoadTests) SunSpider/ HTMLParser/ (was WebCore/benchmarks/parser) RegressionTests/ (was LayoutTests) manual/ (was WebCore/manual-tests) Sources/ automake/ cmake/ JavaScriptCore/ JavaScriptGlue/ Platform/ (was WebCore/platform) WebCore/ WebKit/ WebKit2/ WTF/ (was JavaScriptCore/wtf) ThirdParty/ ANGLE/ + Contents WebKitLibraries Tools/ Websites/ .gitattributes .gitignore ChangeLog Makefile Makefile.shared == UNSURE == autogen.sh Android.mk common.pri cmakeconfig.h.cmake CMakeLists.txt configure.ac GNUmakefile.am wscript DerivedSources.pro WebKit.pri WebKit.pro In this layout, I haven't merged PerformanceTests and RegressionTests for two reasons. First, the natural name, Tests, conflicts with tab-completing Tools. Second, folks so commonly access the current LayoutTests directory that it seems a bit inefficient to place it another level lower in the directory hierarchy. Comments welcome, of course. :) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
LayoutTests = Tests That would kill the new Ttab is enough to enter the Tools directory feature :P I like the Ltab for generic tests. Cheers, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
Hm, thinking a bit about it I realized these renamings could help the usability of the source code. I actually use a lot the WebKitBuild directory, and would be happy if it would be renamed to Build (= Btab), and Scripts could go to the root directory. In that case, LayoutTests = Tests would be be OK for me, if Tools would be renamed to anything which does not start with T. It would be good if the renamings would be based on directory entering statistics. Regards, Zoltan LayoutTests = Tests That would kill the new Ttab is enough to enter the Tools directory feature :P I like the Ltab for generic tests. Cheers, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
On 6 December 2010 22:31, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Crash in WTF::fastMalloc? Such things only happen if something overwrites memory areas belongs to the memory manager (i.e overwrites some bytes before or after a block returned by malloc). Try some valgrind equivalent on mac to detect those writings into red zones. How can you use valgrind to help on that? We had some symptoms similar to this and also came to the conclusion that probably something is overwriting the structures used by fast malloc, but couldn't find anything with valgrind. Overwriting in an area that has bee reserved is not an error vangrind finds, at least not with any options that I know. I haven't received your reply before. To capture this bug, you have to disable fastmalloc, and use the internal (trackable) memory allocator replacement of valgrind. Run build-webkit --system-malloc This will redirect all allocations to the system malloc. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
It is possible to add macros to the code to help valgrind know which areas are being used by a custom allocator. (See VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK, for example.) I'm not sure if they're useful in this situation, but they're worth taking a look at. I see. That would discover errors such as something overwriting structures allocated by the allocator but that were not handled to the application, right? Is there any reason why that's not included in the webkit allocator? I mean apart from lack of time/interest, of course. I don't think that would be useful. Real allocators do several optimizations, which could hide many errors. An example: p = malloc(100); free(p); p = malloc(100); I clever allocator would probably return with the same pointer. However, valgrind wants to detect unintended access to freed blocks, so its allocator would never reuse the same address if possible. Moreover, it skips X bytes before and after the block to detect overwrite / underwrite situations (red zones). Thus, we should use the system malloc if possible (captured and redirected by valgrind). And leave that macro to those cases, where the software is designed to not use system malloc (garbage collected memory areas for example). Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit/Cairo build errors
Hi, try webkit-help, which is the right place for such qestions. Regards, Zoltan Hi, I'm having problems building WebKit Cairo port (from 23/11 nightly). First it gives an error on RenderMediaControls.cpp which includes CoreGraphics/CoreGraphics.h and it shouldn't (right? this is part of the Apple CoreGraphics). So I replaced this include by cairo.h. Is this the right way to fix this error? Now it gives other errors namely on WebKitSystemInterface.h about 'CGFloat' being undeclared. Can anyone help me? Regards, João Neves ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] ANGLE
Hi, ANGLE looks like a graphics helper library. Why it is placed in the root WebKit directory? Perhaps WebCore/platform/graphics or some kind of /3rparty directory would be better, wouldn't it? Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review queue crazy idea
Patches sit in the queue for numerous reasons. Some of us used to scan the queue every day. But I've stopped doing that. Now I scan it more like once a week or two. There is no good way to find which patches might I have a chance of reviewing, so you end up spending 30 minutes just to find a patch you could actually review. You mean basically the problem is how a reviewer find a patch which he/she can review? WebKit as a project does not encourage matching a patch to a reviewer, but those, who are here for a long time know who can review their patches, and just CC them to the bug. This is difficult for a new contributor. I suggest a keyword - reviewer matching bot: a contributor is encouraged to select some keywords related to his/her patch from a list, and a bot could automatically CC some reviewers based on these keywords and other attributes (like component) of the bug report. Most patches get rejected for easily-bot-detectable reasons. Like bad or missing ChangeLogs, poor comment style, tabs, breaking EWS bots. Now that the style bot and EWS bots work better we should at least cq- patches which fail those bots (or fail to apply). The bots set the boxes to red near the patch, and post a small message to the bug report. This is more than enough for me, but a new contributor might have no idea how to fix them. A link to a wiki page should be added to these posts, which explains the steps to fix such problems. Or just mention some names, whose are an expert of different build systems, and can help to fix build issues. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
We can't really download them from stixfonts.org. Alex, wouldn't be possible to contact them and ask some help? Maybe they could offer us an acceptable solution. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to integrate the SFX JIT for SH4 in the webkit svn tree.
Hi, nice job, Haithem. This page explains how to contribute code to WebKit: http://webkit.org/coding/contributing.html You may find helpful the bugzilla entries for other JSC-JIT ports: ARM: https://bugs.webkit.org/show_bug.cgi?id=24986 MIPS: https://bugs.webkit.org/show_bug.cgi?id=30144 Both of them are quite long, so expect some iterations before landing. (You should not foget to CC the JSC reviewers to your bug report. You can ask JSC related questions on #squirrelfish channel on freenode as well.) Cheers, Zoltan Hi, We in STMicroelectronics have ported the SFX javascript engine to SH4 processor. Currently is it integrated/tested using the WebkitGtk 1.1.90 development release. We would like to integrate our port in the main webkit svn tree. can anybody give me the steps to follow for that. Kind regards. Haithem -- Be to GOD as he wants , HE'll be for you more than what you want. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel controls in JavaScriptCore engine
Hi,
why don't you simply use a workaround?
script
function success()
{
alert(Success);
continueTask(true);
}
function failure()
{
alert(Failure);
continueTask(false);
}
function continueTask(success)
{
x= 10+1;
}
/script
Zoltan
Hello,
As part of my project, we need to implement custom JS objects using
JavaScriptCore API.
I am seeking help in implementing in implementing one of the requirement
and
its possibility of accomplishing it in Webkit/JavaScriptcore.
So, the requirement is, We need to add custom JS object , lets say
MyObject and this object has one method wait() which should block the
control until its previously requested operation completes.
in Detail,
*
script
function success()
{
alert(Success);
}
function failure()
{
alert(Failure);
}
MyObject.postMessage(success,failure,hello, How r u?);
MyObject.wait();
x= 10+1;
/script*
Here, MyObject.wait() should resume only after either of its success or
failure callback is executed. The statement x=10+1 would be executed
only
after either success or failure callback invoked.
So my question here is, is this really possible to stop execution at one
place and execute some thing else and resume back to previous execution
point with JavaScript engine of Webkit.
I have tried this using two threads by blocking the wait using mutex and
calling success/failure callback using another thread but it app crashing.
Can you please suggest me what are the possible ways to achieve the above
requirement.
Thanks
Srinu
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Function Property Names
Hi, https://bugs.webkit.org/show_bug.cgi?id=32561 Zoltan Is there any way to map specific bytecode instruction instances to the position in the source code of the JavaScript code they correspond to? -- View this message in context: http://old.nabble.com/Function---Property-Names-tp28394250p28429934.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Hi! Your wiki says: DrawingArea - an abstraction for a cross-process drawing area. Multiple drawing strategies are possible, the simplest is just a shared memory bitmap. Could you tell me more about it? I am working on a parallel painting feature (GraphicsContext commands can be forwarded to different threads), and would be interested how this feature affect my work. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Coming Soon: new-run-webkit-tests
We should make the new tool record the order so order-specific failures can be explored. A custom random generator would be enough. The seed can be given by a user or a just starts with a random value which is reported when the test finish. Much easier to share seed-revision pairs than anything else, and also easy to replay. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
Hi, Thank all of you for your feedbacks! Let's continue this discussion in the bug report, I will provide more details there. Zoltan On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. EFL port would be interested in this. Could you provide more details on the implementation? Is the painting thread a single thread, or is it being split to N cores? Did you consider the alternative that is isolate webkit layout in another thread as well? From our environment tests (embedded systems), re-layout process can take few seconds without any paint... that being done in the main thread hurts the whole experience as the event processing of menus, animations and others are blocked. In an ideal world WebKit would never block, it would just proxy input and output events to its thread (hard, error-prone... :-/), there it would layout, render and when ready release the main thread to use the painted contents (maybe tiles as the Qt port now enables). BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
Of course, I did a lot of profiling before (using oprofile), and painting was slow on my platform. Zoltan Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time painting, rather time is more often spent in layout, style resolution, or javascript execution/bindings. -eric On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] parallel painting
Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Questions regarding memory debugging
But in cases like the SharedBuffer one, there is no mystery about who allocated the memory. The mystery is typically who is holding on to a reference to it. I have a technique to capture ref/deref problems with gdb. When the object is created (inside the object constructor), I just put a write break point to the address of m_refCount: watch this-m_refCount in gdb. The backtrace can be inspected every time when this watch point is hit. Ref / derefs must be in pairs, usually easy to find which ref has no deref pair. Gdb also supports executing scripts when a breakpoint is hit, this could be useful to perform some tasks (see the COMMAND command). Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why I'm reviewing patches outside my area (and why you should too)
Hi, It's also a big help when peers (which aren't necessarily WebKit reviewers) look over it and give review-style feedback as well. Especially when said peers know more about that code than any of the official reviewers. Is that really help? Sometimes when a patch looks good to me, it still rots in the bugzilla for weeks. On the other hand, sometimes I have concerns about the patch, and somebody just pop in and give an r+ without any comments. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel rendering in WebKit
Hi, thanks for all of your for your help. I would be worried about correctness - if painting is not complete by the time the paint method returns, then you could get flashes of intermediate states showing up onscreen. We plan to do the painting on a background image. When all the painting finished, the image appears on the screen. We don't need to duplicate the dom tree, only the painting commands should be sent to the thread. We could keep the changes below RenderContext level in this way. I suspect resources like fonts or images *will* need to be duplicated, either that or use thread-safe refcounting and copy-on-write. The internal state of images can be mutated by progress in loading the image, or by ongoing animation. No need thread safe refcounting, since when a request object is processed by the thread, the thread sends back the request object to the main thread, which can release the resources. It is necessary, since memory alloc / free pairs on a memory chunk must be executed by the same thread. We can post a series of commands to the thread message queues (including the main thread), which will processed later (no wait is necessary). I'm also curious how this will help overall rendering time. Embedded platforms would normally only be displaying one document at a time, so how will one thread per document help? Not anymore. The UI design of mobile or handheld devices use more and more html-based content. It is easier for both UI designers (enough to know how to create html pages) and developers (a browser is needed anyway, and not need to maintain a separate UI rendering engine). Of course we need reliable and fast brower engines to achive these features. I can't promise any major gain at this momment, but it seems there is not any design issue in WebKit, which makes this approach impossible. Wish us luck :) Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ARM JIT for WinCE
Hi,
the dateProtoFuncGetTimezoneOffset does not use the argList argument,
while functionPrint does. Perhaps passing this argument is still not yet
WinCE compatible. ArgList contains a pointer to the arguments (JSValue
pointers), and the length of the arguments. This structure is 8 bytes on
32 bit machines (1 pointer, 1 int), and allocated on the stack, because
the function got a reference (pointer) to it.
Could you try the following JS code: print(a, 1, true)
The length should be 3.
Zoltan
Hi,
I did some further investigation today.
I did a quick hack in the privateCompileCTIMachineTrampolines to get the
same
maybe correct register values like without OPTIMIZE_NATIVE_CALL.
move(callFrameRegister, regT0);
+move(ARMRegisters::r2, ARMRegisters::r3);
+move(ARMRegisters::r1, ARMRegisters::r2);
+move(ARMRegisters::r0, ARMRegisters::r1);
-move(stackPointerRegister, ARMRegisters::r3);
+move(stackPointerRegister, ARMRegisters::r0);
-call(Address(regT1, OBJECT_OFFSETOF(JSFunction, m_data)));
+call(Address(regT2, OBJECT_OFFSETOF(JSFunction, m_data)));
addPtr(Imm32(sizeof(ArgList)), stackPointerRegister);
Now it produces the following code:
003E01B0 mulsr0, r3, r0
003E01B4 subsr1, r1, r0
003E01B8 str r1, [sp]
003E01BC ldr r2, [r1, #-4]
003E01C0 ldr r1, [r4, #-8]
003E01C4 mov r0, r4
003E01C8 mov r3, r2
003E01CC mov r2, r1
003E01D0 mov r1, r0
003E01D4 mov r0, sp
003E01D8 mov lr, pc
003E01DC ldr pc, [r2, #0x1C]
003E01E0 addssp, sp, #8
003E01E4 ldr r3, [pc, #0x80]
003E01E8 ldr r2, [r3]
003E01EC bicsr3, r2, #0
003E01F0 bne 003E0204
The arguments seam to be sane now in the call to
dateProtoFuncGetTimezoneOffset, but it crashes afterwards.
When i step through it with the debugger i get the following register
after
the function finished and it jumps to 0x000139d8 instead of 0x003e01e0:
(lr = 0x003e01e0 when i enter the function!)
R0 = 0x182af984 R1 = 0x003f8054 R2 = 0x00601500 R3 = 0x0060
R4 = 0x003f8054 R5 = 0x0200 R6 = 0x182af984 R7 = 0x003f8054
R8 = 0x R9 = 0x182afbfc R10 = 0x R11 = 0x002b0370
R12 = 0x182af8f0 Sp = 0x182af95c Lr = 0x003e01e0
Pc = 0x000139d8 Psr = 0x201f
I then tried to return jsNaN(exec) always. So R4 won't be used and
prolog/epilog changed:
00071600 mov r12, sp
00071604 stmdb sp!, {r0 - r3}
00071608 stmdb sp!, {r4, r12, lr}
0007160C sub sp, sp, #0x1C
00071700 ldr r0, [sp, #8]
00071704 add sp, sp, #0x1C
00071708 ldmia sp, {r4, sp, pc}
changed to
000734EC mov r12, sp
000734F0 stmdb sp!, {r0 - r3}
000734F4 stmdb sp!, {r12, lr}
000734F8 sub sp, sp, #0x1C
000735A4 ldr r0, [sp, #8]
000735A8 add sp, sp, #0x1C
000735AC ldmia sp, {sp, pc}
I now get following registers and it jumps to the correct address
(0x003e01e0), but it crashes then in functionPrint.
R0 = 0x182af984 R1 = 0x182af8f8 R2 = 0x R3 = 0x182af984
R4 = 0x003f8080 R5 = 0x0200 R6 = 0x0060 R7 = 0x003e07c8
R8 = 0x R9 = 0x182afbfc R10 = 0x R11 = 0x002b0370
R12 = 0x03fc2c50 Sp = 0x182af984 Lr = 0x0001bc18
Pc = 0x003e01e0 Psr = 0x601f
I tried jsc.exe with the following javascript file:
print(getTimeZoneDiff());
function getTimeZoneDiff() {
return (new Date(2000, 1, 1)).getTimezoneOffset();
}
This doesn't make many sense to me in the moment.
- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ARM JIT for WinCE
Hi Patrick,
hm, I feel I found something. Please have a look at
JavaScriptCore/jit/JITOpcodes.cpp : privateCompileCTIMachineTrampolines.
The second one, when JSVALUE32_64 is disabled. If JIT_OPTIMIZE_NATIVE_CALL
is enabled, a specialized code is generated to call native builtin
functions (like Date.toString). This code for arm is around line 1733.
Perhaps WinCE ABI wants the arguments in a different way than GCC. The
faulting address according to your call stack is 0x003e01d4, which is the
call(Address(regT1, OBJECT_OFFSETOF(JSFunction, m_data))); macro
assembler instruction in line 1768. (Thank you for sending the instruction
dump). Please try to fix this code according to WinCE ABI, since I am not
sure JIT_OPTIMIZE_NATIVE_CALL can be disabled.
Regards
Zoltan
Hi Gabor,
Thanks for your prompt reply.
Make sure your assembler does not break ctiVMThrowTrampoline
and ctiOpThrowNotCaught functions. This approach requires that the
ctiVMThrowTrampoline fall-backs to ctiOpThrowNotCaught
after 'bl cti_vm_throw' call. Or you can simply copy the body of
ctiOpThrowNotCaught into ctiVMThrowTrampoline after the
call.
I've copied it, but I think it's unnecessary (see disassembly)
Did you do anything with DEFINE_STUB_FUNCTION macro?
I've done it like for the RVCT compiler. (e.g. see cti_op_end in
disassembly)
When I run jsc.exe tests\mozilla\ecma_2\shell.js it crashes with the
following callstack:
0x
jsc.EXE!JSC::JSCell::inherits(JSC::ClassInfo* info = 0x00189818) Line:
335,
Byte Offsets: 0x2c
jsc.EXE!JSC::JSValue::inherits(JSC::ClassInfo* classInfo = 0x00189818)
Line:
345, Byte Offsets: 0x40
jsc.EXE!JSC::dateProtoFuncGetTimezoneOffset(JSC::ExecState* exec =
0x00601b60,
JSC::JSObject* __formal = 0x00601b40, JSC::JSValue thisValue = {...},
JSC::ArgList __formal = {...}) Line: 764, Byte Offsets: 0x1c
0x003e01d4
Is there a better javascript file to start with? When I enter a simple
1+2+3
into the interactive jsc.exe it prints the correct result.
Here are some parts of the disassembly:
// Execute the code!
inline JSValue execute(RegisterFile* registerFile, CallFrame*
callFrame, JSGlobalData* globalData, JSValue* exception)
{
000A7868 mov r12, sp
000A786C stmdb sp!, {r0 - r3}
000A7870 stmdb sp!, {r12, lr}
000A7874 sub sp, sp, #0x20
return
JSValue::decode(ctiTrampoline(m_ref.m_code.executableAddress(),
registerFile,
callFrame, exception, Profiler::enabledProfilerReference(), globalData));
000A7878 bl |JSC::Profiler::enabledProfilerReference ( 1b2e0h )|
000A787C str r0, [sp, #0x14]
000A7880 ldr r0, this
000A7884 bl |WTF::RefPtrJSC::Profile::operator- ( d2e3ch )|
000A7888 str r0, [sp, #0x18]
000A788C ldr r3, globalData
000A7890 str r3, [sp, #4]
000A7894 ldr r3, [sp, #0x14]
000A7898 str r3, [sp]
000A789C ldr r3, exception
000A78A0 ldr r2, callFrame
000A78A4 ldr r1, registerFile
000A78A8 ldr r0, [sp, #0x18]
000A78AC bl 0014A000
000A78B0 str r0, [sp, #0x1C]
000A78B4 ldr r1, [sp, #0x1C]
000A78B8 ldr r0, [sp, #0x2C]
000A78BC bl |JSC::JSValue::decode ( 1b94ch )|
000A78C0 ldr r3, [sp, #0x2C]
000A78C4 str r3, [sp, #0x10]
}
000A78C8 ldr r0, [sp, #0x10]
000A78CC add sp, sp, #0x20
000A78D0 ldmia sp, {sp, pc}
ctiTrampoline:
0014A000 stmdb sp!, {r1 - r3}
0014A004 stmdb sp!, {r4 - r8, lr}
0014A008 sub sp, sp, #0x24
0014A00C mov r4, r2
0014A010 mov r5, #2, 24
0014A014 mov lr, pc
0014A018 bx r0// r0 = 0x003e0270
0014A01C add sp, sp, #0x24
0014A020 ldmia sp!, {r4 - r8, lr}
0014A024 add sp, sp, #0xC
0014A028 bx lr
ctiVMThrowTrampoline:
0014A02C mov r0, sp
0014A030 bl 0014A6D4
0014A034 add sp, sp, #0x24
0014A038 ldmia sp!, {r4 - r8, lr}
0014A03C add sp, sp, #0xC
0014A040 bx lr
ctiOpThrowNotCaught:
0014A044 add sp, sp, #0x24
0014A048 ldmia sp!, {r4 - r8, lr}
0014A04C add sp, sp, #0xC
0014A050 bx lr
cti_op_convert_this:
0014A054 str lr, [sp, #0x20]
0014A058 bl |JITStubThunked_op_convert_this ( ae718h )|
0014A05C ldr lr, [sp, #0x20]
0014A060 bx lr
cti_op_end:
0014A064 str lr, [sp, #0x20]
0014A068 bl |JITStubThunked_op_end ( ae878h )|
0014A06C ldr lr, [sp, #0x20]
0014A070 bx lr
003E017C mov pc, r0
003E0180 mov r0, lr
003E0184 str r0, [r4, #-0x14]
003E0188 ldr r1, [r4,
[webkit-dev] TARGET_OS_EMBEDDED
Hi, it would be a great to have a macro in WebKit, which would be enabled on embedded systems. We could replace macros like PLATFORM(SYMBIAN) in TextCodecQt.cpp to this new macro. However, TARGET_OS_EMBEDDED macro enables WTF_PLATFORM_IPHONE. Well, not only symbian and iPhone exist in embedded domain. What is your suggestion? Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] improving String::append()
Hi, according to my measurements, a large chunk of WebKit memory consumption comes from WebCore::TextResourceDecoder::decode (loader/TextResourceDecoder.cpp:818) which calls String::append (String.cpp:82). The comment there says: // FIXME: This is extremely inefficient. I would volunteer to rewrite the code (especially reducing the memory consumption), but first, I would like to hear your opinion how can we make the string handling of WebKit better. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] jit for arm
Hi, seems the original mail was sent to both webkit-dev and webkit-help. My reply was on webkit-help, and the discussion continued there. https://lists.webkit.org/pipermail/webkit-help/2009-November/000380.html Perhaps we should clarify better the purpose of these mailing lists, since if people can't decide which list is better for them, they do double posts. Zoltan On Nov 4, 2009, at 8:37 AM, ll Jefferry wrote: Hi, when i reading the jit for arm source code, i am not very clear the functionality of the flowing functions: ctiTrampoline This code is used when entering from the C runtime into JIT generated code. JIT generated code does not necessarily respect C calling conventions, so this routine sets up the stack frame, preserves registers, etc, as necessary to allow the JIT code to be run. ctiVMThrowTrampoline To perform certain operations the JIT will call back into C code. Usually the C callback can just return in a perfectly normal fashion and continue execution once it has completed, however in the case that an exception is thrown special handling is required to change the control flow. The return address of the C callback is instead changed to point to this, and this piece of code handles looking up the exception handler at which execution will be resumed. ctiOpThrowNotCaught This is used to from within cti_op_throw, which implements the 'throw' keyword in JavaScript. The cti_op_throw method will attempt to look up a handler routine that catches the exception. However if the exception is not caught it is necessary to force an early termination of JIT execution. The cti_op_throw C callback always modifies its return address, either to point to the code for the appropriate exception handler to catch the exception, or to ctiOpThrowNotCaught if no handler is found. could you explain to me? and another question is that: in cacheFlush function, why the system call number is 0xf0002? if it is defined by the toolchain? Zoltan, Gabor? thanks! BR, Jeff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JIT for arm is dependant on gcc
Hi, these entry/leave functions are implemented in assembly for all ports. It is faster this way. (Previously, the jit generated these functions, but the reviewers convinced us to do this way). External .asm files would be a nightmare, since we have to create (and maintain) the build rules for all ports. Is is difficult to implement these functions for your assembler? They are simple code fragments. Zoltan I've noticed that there are three functions that use inline gcc assembler for compiling JIT for ARM_TRADITIONAL. Is it possible for these to be reworked using the macro assembler so that JIT can be compiled without the gcc toolchain dependency for arm? (sp. I am using armasm from Microsoft?). Alternatively, perhaps this could be moved to an external .asm or .s file. This looks like it has been done for PaintHooks.asm; so maybe something similar to that. These are the functions that I am missing trying to build JIT: CacheFlush, ctiTrampoline, ctiVMThrowTrampoline ctiOpThrowNotCaught If there is a way to compile JIT without these dependencies please let me know. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JIT for arm is dependant on gcc
Hi,
sorry, I don't know anything about ms arm tools (ok, not just their arm
tools).
push/pop {regs} is an alias for stmdb/ldmia sp!, { regs }
I presume you use ms os, which means you have to implement the
cacheflush() for your own os as well. (The current implementation is
designed for Linux) Unfortunately the neccessary mcr instruction can only
be executed on supervisor level, so there is no platform independent way
to implement this important function.
Zoltan
The Microsoft ARM toolchain does not support inline assembler so I'm
unable to compile any inline assembler. I'm trying to understand how to
make these functions external but it doesn't appear to be straightforward
(e.g. The first problem I hit was that the asm push instruction is
unknown, also svc must be renamed swi and probably others. Also, I'm not
able to easily create the pre/post stack frame for cacheflush as I haven't
used 3 parameter assembler language before although I'm sure I could do
this with a couple of hours research.
Can you maybe show me how to get the jit to generate this for this
toolchain?
Jason.
-Original Message-
From: Zoltan Herczeg [mailto:zherc...@inf.u-szeged.hu]
Sent: Wednesday, October 21, 2009 9:45 AM
To: Jason Rukman
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] JIT for arm is dependant on gcc
Hi,
these entry/leave functions are implemented in assembly for all ports. It
is faster this way. (Previously, the jit generated these functions, but
the reviewers convinced us to do this way).
External .asm files would be a nightmare, since we have to create (and
maintain) the build rules for all ports.
Is is difficult to implement these functions for your assembler? They are
simple code fragments.
Zoltan
I've noticed that there are three functions that use inline gcc
assembler for compiling JIT for ARM_TRADITIONAL. Is it possible for
these to be reworked using the macro assembler so that JIT can be
compiled without the gcc toolchain dependency for arm? (sp. I am using
armasm from Microsoft?).
Alternatively, perhaps this could be moved to an external .asm or .s
file. This looks like it has been done for PaintHooks.asm; so maybe
something similar to that.
These are the functions that I am missing trying to build JIT:
CacheFlush, ctiTrampoline, ctiVMThrowTrampoline ctiOpThrowNotCaught
If there is a way to compile JIT without these dependencies please let
me know.
Thanks,
Jason.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] jit, unordered compare
Hi fortunately, no, I don't need double branch here. cmpvs reg0, reg0 is a conditional instruction, which only executes if the v flag is set. My proposal would be to add a new DoubleCondition called DoubleEqualOrNAN, or something similar to clarify what we expect from the conditional branch. Since I feel (and by IEEE as you mentioned) a comparison to NaN should be false, not true as x86 actually does. Zoltan unfortunately cmf was used by the old fpa (floating point accelerator), which is replaced by vfp (vector floating point) for some time. Perhaps I can try a cmpvs reg0, reg0 instruction, which sets zero flag if one argument is NaN (since reg0 is always equal to reg0). Otherwise it does nothing (=nop). That should work, but it would require two branches instead of one (compare to 0, compare to self). I'm sure there must be a way to do an IEEE double comparison on ARM with only one branch. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] jit, unordered compare
Hi, My stougle with USE_JSVALUE32_64 still continues on ARM. In emit_op_jfalse, there is a comparison here (fpRegT0 contains 0.0): addJump(branchDouble(DoubleEqual, fpRegT0, fpRegT1), target + 2); In x86, if either operand is NaN, the zero flag is set by definition (ucomisd instruction). I have no idea why (NaN == anything is true?). Unfortunately, ARM does not set the zero flag. What would be a portable way to improve this instruction? (and emit_op_jtrue) Perhaps this affects the possible thumb2 implementation with USE_JSVALUE32_64 as well. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] jit, unordered compare
Hi,
unfortunately cmf was used by the old fpa (floating point accelerator),
which is replaced by vfp (vector floating point) for some time. Perhaps I
can try a cmpvs reg0, reg0 instruction, which sets zero flag if one
argument is NaN (since reg0 is always equal to reg0). Otherwise it does
nothing (=nop).
Zoltan
Hi Zoltan.
I believe you're talking about this code for op_jfalse:
zeroDouble(fpRegT0);
emitLoadDouble(cond, fpRegT1);
addJump(branchDouble(DoubleEqual, fpRegT0, fpRegT1), target);
and this code for op_jtrue:
zeroDouble(fpRegT0);
emitLoadDouble(cond, fpRegT1);
addJump(branchDouble(DoubleNotEqual, fpRegT0, fpRegT1),
target);
The goal of this code is to perform a comparison that distinguishes
{ 0, NaN } from all other doubles. op_jfalse should branch in the case
of 0 or NaN, and, inversely, op_jtrue should branch in all other cases.
It sounds like the equal / zero condition does not indicate NaN on all
platforms. Bummer.
I'm not an expert in ARM (or other floating point processors, for that
matter), so I'm not sure what the best abstraction is for this notion
of compares to zero as equal or unordered. Since IEEE double
requires all comparisons to NaN to be implicitly false, I do expect
that there is some efficient single branch that can do this on ARM.
From http://www.heyrick.co.uk/assembler/fpops.html#cmf, it looks like
the CMF instruction should be used to test for equality (ie when a
BEQ or BNE is used afterwards) or to test for unorderedness (in the V
flag).
Gavin, do you have any ideas here?
Geoff
On Oct 12, 2009, at 4:05 AM, Zoltan Herczeg wrote:
Hi,
My stougle with USE_JSVALUE32_64 still continues on ARM. In
emit_op_jfalse, there is a comparison here (fpRegT0 contains 0.0):
addJump(branchDouble(DoubleEqual, fpRegT0, fpRegT1), target + 2);
In x86, if either operand is NaN, the zero flag is set by definition
(ucomisd instruction). I have no idea why (NaN == anything is true?).
Unfortunately, ARM does not set the zero flag. What would be a
portable
way to improve this instruction? (and emit_op_jtrue) Perhaps this
affects
the possible thumb2 implementation with USE_JSVALUE32_64 as well.
Zoltan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] compileOpCallSetupArgs
Hi, I am not sure this is a bug, so I am curios about your opinion. Currently, I am trying to enable JSVALUE32_64 on ARM. First step, as usual, with all optimizations disabled. Unfortunately, I got a crash. If JIT_OPTIMIZE_CALL is disabled, callee is loaded to regT1 and regT2, while if enabled, to regT0 and regT1. However, there is only one type of compileOpCallSetupArgs, which presumes that callee is in regT0 and regT1. If this is indeed a bug, which way should I choose: change compileOpCall or put ifdef-s to compileOpXXXSetupArgs functions? Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Leak reports during shutdown
Hi Kevin, WebKit approach is NOT to free memory before quit to make the quit process as fast as possible. The memory manager should free the unfreed objects. However, this approach makes really hard to find the real leaks (which are unreferenced objects). In my experince the unfreed (non-leak) objects come from several sources: - JavaScriptCore garbage collector is not called before quit - Caches are not cleared before quit The previous two are performed by QtLauncher in debug mode. See WebKit/qt/QtLauncher/main.cpp launcherMain() - In case of workers, the gc() does not called for each worker threads when the application quits. The JavaScript threads are simply aborted. - Global objects are not freed at all. There was an attempt to free them (see https://bugs.webkit.org/show_bug.cgi?id=27980 ) but seems not worth to continue that work, although it helped to find leaks such as this: https://bugs.webkit.org/show_bug.cgi?id=29295 The remaining unfreed objects are possible leaks. Many of them are probably port specific (not all port maintainers have resources to keep leak hunters). Zoltan Hi all, For a while, ports like wx and Win/Cairo have been seeing various leaks reported on shutdown, but at least on Mac I've been unable to see these leaks using memory leak checkers like the one in Instruments, so I decided to poke into the code a bit more and try to understand what's going on a bit better. What I found was that the reported object leaks were pretty much all related to objects that JSC has references to. Changing ~ScriptController to do a garbageCollectNow() instead of garbageCollectSoon(), for example, drastically reduced the number of reported leaks, cleaning up all the CachedResource leaks and almost all the WebCoreNode leaks. The remaining leaks were almost all JSC::Structure objects. I've been digging through the code to try and find the place where these JSC objects are finally deleted, but I haven't found anyplace obvious in the code, neither in common code nor in the ports' code. My question is, is there somewhere these objects are being deleted on final shutdown that apparently happens after the leaks are reported, or does WebKit have assumptions such as that all still running timers must fire before final shutdown that ports such as ours are not honoring? (e.g. in my tests garbageCollectSoon() does not end up firing the callback because the app shuts down too fast.) Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-help] webkit cross compilation error
Hi, -m64 means: generate code for 64 bit machines. ARM is not a 64 bit architecture. Does your Ubuntu use a x86-64 kernel? Which WebKit platform do you use? Perhaps a mechanism detected your architecture and pass this flag to WebKit to make optimized code for your machine. Zoltan hi, i'm cross compiling webkit for ARM on my ubuntu8.10 installed X86 machine. i'm using scratchbox2 for cross compilation. when i gave this command to build webkit for ARM $sb2 ./build-webkit --qt it giving an error: cc1plus: error: unrecognized command line option -m64 make[1]: *** [obj/release/pcre_compile.o] Error 1 make[1]: Leaving directory `/home/ravijks/webkit/WebKitBuild/Release/WebCore' make: *** [sub-WebCore-make_default-ordered] Error 2 am i doing right here? i've installed all the dependencies eg gperf, flex, bison, sqlite etc. -- Ravi Swami EnMedia Software Technologies Ph +91-953-836-1085 ___ webkit-help mailing list webkit-h...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-help ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New marking model for GC collected objects
Darin has already submitted a big patch to the bug report, which hopefully
solve all of these issues.
Zoltan
In WTF_USE_JSVALUE32 DateInstance needs to override createStrucutre to
remove the HasDefaultMark bit
--Oliver
On Sep 2, 2009, at 6:54 AM, Zoltan Herczeg wrote:
Hi Geoff,
That function is not called.
I have opened a bug report for this issue (a simple failed example
included)
https://bugs.webkit.org/show_bug.cgi?id=28909
Zoltan
Hi Zoltan.
JSWrapperObject::markChildren is responsible for marking the
internalValue of a DateInstance. Is that function not being called?
Geoff
On Sep 1, 2009, at 6:16 AM, Zoltan Herczeg wrote:
Hi Oliver,
it seems on ARM using WTF_USE_JSVALUE32, the internal value of a
date
object is sometimes freed by the garbage collector.
More specifically:
The double (millisecond) representation of a date object (returned
by a
new Date expression) is stored in JSWrapperObject:
m_internalValue. This
m_internalValue points to a JSNumberCell, which stores the double
value.
Although this JSNumberCell is referenced by m_internalValue, the GC
still
collects its memory space.
How can I fix this bug with the new mark() model?
Zoltan
Last night I landed a patch that replaces the old recursive marking
functions with a new iterative model that uses an explicit mark
stack. This means that any custom mark methods that you need to
write
now need to be slightly different from what they were previously,
i'll
attempt to summarise here.
The most obvious change is that an object is no longer responsible
for
marking itself instead the recursive mark methods have been
replaced
by a new virtual markChildren(MarkStack) which is responsible for
appending an objects children to the stack.
The MarkStack is a very simple class, and the only method you
really
need to know about is MarkStack::append which adds a new object to
the
stack.
The changes to how your custom marking functions are implemented
are
trivial, but here's a simple example
void MyAwesomeObject::mark()
{
Base::mark();
if (!m_child.marked())
m_child.mark();
}
Becomes
void MyAwesomeObject::markChildren(MarkStack markStack)
{
Base::markChildren(markStack);
markStack.append(m_child);
}
And that's it, you're done.
It's important to note that you will never be in a position where
you
call markChildren yourself, if you are that is an error.
--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New marking model for GC collected objects
Hi Oliver,
it seems on ARM using WTF_USE_JSVALUE32, the internal value of a date
object is sometimes freed by the garbage collector.
More specifically:
The double (millisecond) representation of a date object (returned by a
new Date expression) is stored in JSWrapperObject: m_internalValue. This
m_internalValue points to a JSNumberCell, which stores the double value.
Although this JSNumberCell is referenced by m_internalValue, the GC still
collects its memory space.
How can I fix this bug with the new mark() model?
Zoltan
Last night I landed a patch that replaces the old recursive marking
functions with a new iterative model that uses an explicit mark
stack. This means that any custom mark methods that you need to write
now need to be slightly different from what they were previously, i'll
attempt to summarise here.
The most obvious change is that an object is no longer responsible for
marking itself instead the recursive mark methods have been replaced
by a new virtual markChildren(MarkStack) which is responsible for
appending an objects children to the stack.
The MarkStack is a very simple class, and the only method you really
need to know about is MarkStack::append which adds a new object to the
stack.
The changes to how your custom marking functions are implemented are
trivial, but here's a simple example
void MyAwesomeObject::mark()
{
Base::mark();
if (!m_child.marked())
m_child.mark();
}
Becomes
void MyAwesomeObject::markChildren(MarkStack markStack)
{
Base::markChildren(markStack);
markStack.append(m_child);
}
And that's it, you're done.
It's important to note that you will never be in a position where you
call markChildren yourself, if you are that is an error.
--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can someone give current status for Webkit/GTK build under mingw
Hi, Im not sure if Im asking the right place yes :), such qestions should go to webkit-help Cheers, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] freeing static variables
Hi Adam, thank you for your suggestions. I have something similar in my mind. I have opened a bugzilla entry and submited an early patch draft about my concept: https://bugs.webkit.org/show_bug.cgi?id=27980 The patch frees memory objects in a reversed creation order, and seemed working well with QtLauncher (although only a subset of static variables are freed right now). Do you know about special cases when this approach is not enough? Actually it is hard to find real memory leaks in the output of valgrind because many of them are related to static variables. I hope this feature will help to the leak hunters in the future. Cheers, Zoltan On Thursday 30 July 2009 02:55:18 am Zoltan Herczeg wrote: Hi, any thoughts on this? I hope my qestion was clear :) I would like to pack the static declarations into wrapper classes, so we can add platform and/or compilation mode (debug/release) dependent functionality to all static variables (i.e: freeing them on exit). Zoltan I've tried this before and it didn't work out so well. The order in which you free them becomes very important and error prone. And, of course, whatever solution you make has to be optional and easy to maintain as the default policy in WebKit is to not care - by design - about cleaning up after static globals on exit as that is left to the OS. Another strategy for the embedded case where you want to free everything on exit is to create a custom memory handler that will do this for you. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] freeing static variables
Hi, any thoughts on this? I hope my qestion was clear :) I would like to pack the static declarations into wrapper classes, so we can add platform and/or compilation mode (debug/release) dependent functionality to all static variables (i.e: freeing them on exit). Zoltan Hi all, Valgrind reports a lot of memory leaks when QtLauncher quits, because many static local variables are not freed. I did a little research and realized there is no consistent way to define static variables in webkit: WebCore/css/CSSSelector.cpp: CSSSelector::extractPseudoType() using a DEFINE_STATIC_LOCAL() macro WebCore/bindings/js/JSDOMWindowBase.cpp: JSDOMWindowBase::commonJSGlobalData() static JSGlobalData* globalData; WebCore/platform/qt/CursorQt.cpp: Cursors* Cursors::s_self = 0; (no static keyword) I belive it would be a good thing to define a template for static variables, which can (optionally) free static variables (enabled in debug mode, but sometimes it would be good to enable it in release mode as well) And I am wondering whether it would be worth to free (some) static variables if they are used in a given time period. This may help to reduce the memory consumption in the long run. This would be an optional feature, an extra flag (or timeout value) for the template, which can be enabled or disabled at compile time. If disabled, the value of this flag is not used at all. Regards Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] freeing static variables
Hi all, Valgrind reports a lot of memory leaks when QtLauncher quits, because many static local variables are not freed. I did a little research and realized there is no consistent way to define static variables in webkit: WebCore/css/CSSSelector.cpp: CSSSelector::extractPseudoType() using a DEFINE_STATIC_LOCAL() macro WebCore/bindings/js/JSDOMWindowBase.cpp: JSDOMWindowBase::commonJSGlobalData() static JSGlobalData* globalData; WebCore/platform/qt/CursorQt.cpp: Cursors* Cursors::s_self = 0; (no static keyword) I belive it would be a good thing to define a template for static variables, which can (optionally) free static variables (enabled in debug mode, but sometimes it would be good to enable it in release mode as well) And I am wondering whether it would be worth to free (some) static variables if they are used in a given time period. This may help to reduce the memory consumption in the long run. This would be an optional feature, an extra flag (or timeout value) for the template, which can be enabled or disabled at compile time. If disabled, the value of this flag is not used at all. Regards Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Calling gc::collect() before the program exits
Hi, by default, gc::collect() is triggered by a timer at regular intervals. In QtLauncher, gc::collect() is not called in any other way, so the remaining JS objects cause memory leaks when QtLauncher exits. Although this approach may not be considered a bug, since the program soon quits, I would be curious what other ports do before they return to the OS? This question is more important, if we want to use WebKit as a library: in this case the closing of the last WebKit frame may not necessary means the end of the current program. thanks, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Iterating SunSpider
Hi, Can future versions of the SunSpider driver be made so that they won't become irrelevant over time? I feel the weighting is more of an issue here than the total runtime. Eventually some tests become dominant, and the gain (or loss) on them almost determine the final results. Besides, there was a discussion about SunSpider enhancements a year ago. We collected some new JS benchmarks and put it into an WindScorpion (it is another name of SunSpider) extension package. However, the topic died away after a short time. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JavaScriptCore enhancements
Hi, we hope the general arm-jit will soon go to mainline, so we could have enough time to countinue our work on other JSC enhancements. We would like to hear your opinion about them (Are they still valid? Has someone else already been working on it? Which one is important for you?): - runtime switching between JIT and interpreter: we still owe you a patch - which only choose between JIT and interpreter at the creation time of the global object - will post it soon. We plan to extend this mechanism as far as we can: real switch in both directions during runtime. Currently the JavaScript calls are not implemented as real function calls, since the JavaScript call stack is stored on the RegisterFile. Perhaps we should extend the entrly leave mechanism somehow. Requirements: - always keep the SF byte code - always generate the vPC vector - fast path for math functions (especially floor(a/b)): implementing in a similar way to the JS apply() function. Detecting in AST level. - threading: multi core (SMP) architectures are spreading, even for embedded systems. Is there any (large) parts of WebKit which can be readesigned to be thread safe? It would help to expolit the advantages of SMP architectures without significantly increase the memory consumption. - Could we help you in future JSC enhancements? Thanks, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ARM JIT and related issues
Hi, 1) The armv7 port is separate from the armv6 work, and uses the thumb2 instruction set. Both ports are (I hope!) useful. We hope it as well. 2) We would have liked to let the community know about the arm v7 port sooner. Unfortunately, we were not at liberty to disclose it until the iPhone 3G S announcement. We try to let the community know what we're up to and drop code into the public tree as soon as we can, but sometimes we are limited by confidentiality constraints. Corporate secrets are corporate secrects, that is understandable. 3) We'd definitely like to have a port for pre-v7 ARM in the main WebKit tree. I think everyone made this clear. That is great! 4) I think it would be good to see if more code and ideas can be shared between the two ARM ports. They were made independently, and originally in different ways, so let's see what exchange can happen. Right now the macro-assembler based ARM port is an x86 emulator. It translates x86 instructions into ARM instruction sequences (usually 1-5 instructions are enough). As ARMv7 port mostly does it, but thumb2 is much closer to x86 than a RISC architecture (Thumb2 looks like a CISC operation mode). 5) Gavin has been a strong proponent of using MacroAssembler as the primary CPU abstraction layer, and that approach has worked reasonably well so far. However, it seems at least to me that CPUs with very different instruction sets may want to do things differently at a higher level. x86 is a 2-operand instruction set with optional memory operands, and it seems to me a 3-operand load-store architecture might want to do things in a different way to get good performance. Making them go through a common assembler interface may not work. Ultimately, however, the proof is in the performance results. If doing things a different way delivers better performance, that is more important than maximizing code sharing or architectural purity. That has always been the WebKit way. In case of the ARM-port we have a native implementation and a MacroAssembler based implementation, and we have already posted comparisons between them to the bugzilla. Furthermore, we performed some tests on our XScale simulator, and the native jit'ed code executes 5-40% less instructions. However, the gain is smaller on the total runtime, since the jit'ed code takes only a fragment of the total runtime. Although native jit is faster, we are happy with MacroAssembler as well. 6) It seems like the intent with the Szeged arm port and the plan for getting it in the tree wasn't clear to all parties involved. For me personally, it wasn't clear that there was an intent to contribute it, or perhaps even an expectation that we'd just pick it up from the external repository where it was developed. Things would have been more clear if patches were submitted for review earlier. We know that such big patches requries several refactoring phases before they go to mainline, that is why we thought it is a good idea to create a branch on Staikos where you can take a look at them before we flooded the WebKit bugzilla with patches. 7) It seems like people said some intemperate things during the earlier discussion. It also seems like these remarks were based partly on misunderstanding. I hope everyone has gotten past that, and that we are all ready to work together productively. True. I feel the communication between us improved a lot. However, I am still thinking how can we involve others as well. I am pretty sure not only us are interested in the design decisions we discuss in bugzilla. Perhaps squirellfish-dev would be a good place for such discussions. 8) A number patches from the folks working at University of Szeged have been landed. But it seems to me like there has also been a fair amount of abandoned work and working at cross purposes. I feel like the people working on JavaScript at U of Szeged are not entirely in sync with the main JavaScriptCore hackers. You guys have done a lot of great work, and I'd like to explore what we can do to get more in sync on design direction. Does anyone have suggestions on this front? Again, this is true. We have no idea what is the general direction of JavaScriptCore. We can only see landed patches, and predict the ongoing and future works based on them. However, landed patches are completed works, and it is usually too late for any contributions when they are landed. It would be good to discuss things before a work started, especially design changes, which affects all-ports. We feel the design dicussions - such it was about ifdefs - would greatly improve the cooperation between all parties since everybody can feel as a part of the community. Thanks, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building WebKit on ARM
Hi, 1.Want to know the build instructions for building WebKit on OMAP 3530? WebKit is written in c++, so you don't need to do anything special for your CPU. Just run WebKitTools/Scripts/build-webkit 2.Does the WebKit source need to be changed(makefile) so that it builds for OMAP 3530? If you plan to use a cross-compiler, the answer is yes. However, you can use a scratchbox environment to avoid these modifications: http://freedesktop.org/wiki/Software/sbox2 Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Name of a JS function
Hi, how can I extract the name of a JS function in JIT.cpp? Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name of a JS function
Thank you. And how can I access it in JIT::privateCompileMainPass()? I could only find m_codeBlock-source()-url() and m_codeBlock-sourceOffset() methods, but I would prefer a readable identifier. Zoltan Function objects have a property named name, and also a property named displayName. Geoff On Jun 16, 2009, at 3:55 AM, Zoltan Herczeg wrote: Hi, how can I extract the name of a JS function in JIT.cpp? Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] arm jit
Hi guys at Apple, it looks we are in the way of the train. You have plans, we don't know about them, you have commit rights, we don't, so the tides are against us. Hints on the mailing lists are scarce, although a year ago someone from you asked whether others are interested in design discussions, we said 'yes', nothing really changed. Except some simple bugfixes, new patches of ours do not really get into the mainline (except some of our best ideas reimplemented by someone else). Partially this is due to the lack of information and roadmap of JavaScriptCore. That is why I feel the missing of the real openness. And here, I have to make a short comment on the non-acceptance of our ARM JIT implementation. In your mail you mention that you would remain reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. Well, did you check our ARM port? It has been rewritten to conform to the MacroAssembler interfaces more than a month ago and posted it into the bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986). Anyway, we have updated the MacroAssembler-based ARM port of ours, uploaded it to the bugzilla, and set the review flag on the patch. Regards, Zoltan On Jun 9, 2009, at 2:38 PM, Akos Kiss wrote: Dear Community, Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514 ) Congratulations on getting this working!, great job. Hi Akos, Thank you! Just to clarify, we have just landed a ARMv7 architecture (thumb2) JIT backend into ToT. I say ARMv7 to distinguish this port from the ARM application instruction set found in the ARMv6 architecture and earlier (as I believe would be a common understanding of the term ARM, and and which I believe your port targets). Thumb2 in ARMv7 is, of course, a very different instruction set to the traditional 32-bit instructions found in ARM – with completely different machine encodings, and significantly different capabilities (e.g. two operand versus three operand instructions, sizes of immediate operands, and options for instruction predication). For the JIT to be able to run on both ARM and ARMv7 platforms, it needs to be ported to both architectures – in much the same way the the JIT is ported to both the x86 and x86-64 platforms. Obviously there is a great deal of similarity on the surface between ARM and ARMv7, but in terms of the JIT implementation that may well only be true above the level of the MacroAssembler interface. There may be some limited opportunities to share code within the Assembler classes (register numbering enums, and possibly types describing immediate operands), but since the assembler is primarily concerned with formatting machine instructions, and since the instruction encodings are different, it seems likely the bulk of the code will have to remain separate. Again, the differences in instruction selection options available on the two architectures will likely make it hard to share code within the MacroAssember (different numbers of operands to many common instructions, and the options when working with large immediate values particularly spring to mind). We would certainly want to share code and avoid any duplication where ever it makes sense to do so. I cannot conceal how disappointed I am, as is the whole team at Szeged. I am very sorry to hear this. If you look at the patches that landed into ToT there were very few changes made outside of the new assembler classes which, for the reasons described above, I think are highly unlikely to have much in common on the two platforms. The changes that have been made to common code outside of the assemblers should only help in removing x86 dependencies and assumptions that had existed in the code. I strongly urge you to review the changes that have been made, as I hope and believe you will find that they will assist the team in integrating your ARM port. Of course, we've felt that you were reluctant to accept our implementation. We were (and remain) reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. We are concerned that it would be extremely difficult to continue to maintain such a port as we move the JIT technology forwards. Beyond that, they key barrier to the ARM JIT being accepted into WebKit is that there simply haven't been any patches put forwards for us to review! (I'm sorry, I'm aware you have provided a link to an external git repository, but I'm afraid we really can't seek through version control systems to find changes to review – we do need contributors to attach patches to bugs, and we need a review flag setting to indicate when the contributor believes their patch is ready. If there is any uncertainty as to the procedure, please see http://webkit.org/coding/contributing.html .) - Are you
Re: [webkit-dev] arm jit
If you're interested in review or commit rights, they're granted based on a track record of good work, good judgement, and good collaboration. You can read more about the policy here: http://webkit.org/coding/commit-review-policy.html . Please work on your collaboration skills. Right now, your tone stinks. I am sorry if I was not clear. I was talking about cooperation and openness, not about commit rights. Actually, I think it is unimportant who commit a patch, the important thing is that everyone should know what is happening. That is why I wrote those boring blog posts about technical details. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Memory usage for Webkit
Hi, http://webkit.sed.hu/node/15 As you can see on the charts there, you should consider the whole environment not just WebKit alone. Large amount of resources are allocated by other libs as well. Zoltan On 2009-06-11, at 12:50, James Howlett wrote: Hi, Is there any plan to reduce the memory usage of Webkit so that it uses less memory (runs better) on phone? if yes, where can I find ideas to reduce memory usage of Webkit (e.g. bug report, roadmap)? Memory footprint is an area that we are actively working on. If you have a scenario in which WebKit uses more memory than you would expect, please file a bug report with detailed information so that we can reproduce the problem, and it will be investigated. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] stack alignment bug
Hi, actually there was a bug which took me a day to find out what happened. It was somewhere deep in libc, called by a function in DateMath.cpp. It seemed that the stack was overwritten. By libc??? I can't belive it. Finally I realized that gcc's alloca realigned the stack (to 8 bytes on ARM), so everything was in a wrong place (looked overwritten at first sight). My fake stack pointer idea: fake_sp: any non-volatile general purpose register JIT_entry: mov fake_sp, sp sub sp, sp, 32 ; I belive this is enough for the JIT, ; correct me if I am wrong ; use fake_sp instead of sp for push/pops JIT_leava: add sp, sp, 32 I hope this even works for PPC (if someone ever wants to port the JIT to old macs). Zoltan Zoltan, I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=26164 Stack is originally aligned then jit code destroys it; and, some data structure or point to double is not aligned and I'm still trying to find where they are. I'm not sure how the fake stack would be, would you mind explains a bit more? Did you face same problem? Thanks also for your articles that gives new ideas. rgds joe --- On Wed, 6/3/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: From: Zoltan Herczeg zherc...@inf.u-szeged.hu Subject: Re: [webkit-dev] stack alignment bug To: x yz last...@yahoo.com Cc: webkit-dev@lists.webkit.org Date: Wednesday, June 3, 2009, 7:35 PM Hi, true, some architectures have strict policies for stack handling. Perhaps the worst one is PowerPC with its organized stack frame (back chains, pre-defined register save areas, etc). I think a fake stack pointer for JIT can solve the x86 compatibility problem. 1) allocate enough aligned stack space for the worst case when you enter to JIT 2) the fake stack pointer should use this pre-allocated stack frame. Zoltan I don't know how to file bug so I posted here. In privateCompileCTIMachineTrampolines() there are multiple align() to align code on 16byte margin, yet, the stack can be put on 32bit margin that causes crush. Suppose original stack is aligned to 8/16bytes, the above function frequently pop/push regT3 that makes stack mis-aligned. Then int to double conversion uses stack that will fail. rgds joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] stack alignment bug
Hi Gavin, the alignment error was not your fault. When you start porting the JIT, you need to keep many things in your head, and I totally forgot about stack alignment. The entry and exit functions are not portable, and you have to arrange the stack frame by yourself for your architecture. I am happy that pushes/pops are removed entirely from the code, but perhaps the new inline functions should be moved to macro assembler level. Pushes and pops are x86 helpers instructions, since x86-32 has only 8 general purpose registers. We have no idea when and how they are used (especially not in the future), that is why I came up with the fake stack. Of course it would be better to remove them. (And use the link register on non-x86 machines) By the way, could you take a look at our macro-assembler based ARM JIT port (bug #24986) Regards Zoltan Hi Zoltan, I'm a little confused – maybe I'm misunderstanding you, but the JIT does just subtract a fixed amount from the stack pointer on entry (28 on x86, for a total frame size including return address, caller frame pointer and callee preserved registers of 48, a multiple of 16 to preserve stack alignment). All JIT code then runs at the same stack depth. The only pops in the JIT are simply removing the the return address implicitly pushed on x86, and the only pushes (bar a function call in put property access transition realloc) are restoring the return address prior to a return (or a tail call). It is not clear to me what you're envisaging 'fake_sp' would be used for. I've just landed a patch to move the pushes pops in wrapper functions, and to switch put transition realloc to use a regular function call, hopefully this tidies things up a little. cheers, G. On Jun 4, 2009, at 1:19 AM, Zoltan Herczeg wrote: Hi, actually there was a bug which took me a day to find out what happened. It was somewhere deep in libc, called by a function in DateMath.cpp. It seemed that the stack was overwritten. By libc??? I can't belive it. Finally I realized that gcc's alloca realigned the stack (to 8 bytes on ARM), so everything was in a wrong place (looked overwritten at first sight). My fake stack pointer idea: fake_sp: any non-volatile general purpose register JIT_entry: mov fake_sp, sp sub sp, sp, 32 ; I belive this is enough for the JIT, ; correct me if I am wrong ; use fake_sp instead of sp for push/pops JIT_leava: add sp, sp, 32 I hope this even works for PPC (if someone ever wants to port the JIT to old macs). Zoltan Zoltan, I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=26164 Stack is originally aligned then jit code destroys it; and, some data structure or point to double is not aligned and I'm still trying to find where they are. I'm not sure how the fake stack would be, would you mind explains a bit more? Did you face same problem? Thanks also for your articles that gives new ideas. rgds joe --- On Wed, 6/3/09, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: From: Zoltan Herczeg zherc...@inf.u-szeged.hu Subject: Re: [webkit-dev] stack alignment bug To: x yz last...@yahoo.com Cc: webkit-dev@lists.webkit.org Date: Wednesday, June 3, 2009, 7:35 PM Hi, true, some architectures have strict policies for stack handling. Perhaps the worst one is PowerPC with its organized stack frame (back chains, pre-defined register save areas, etc). I think a fake stack pointer for JIT can solve the x86 compatibility problem. 1) allocate enough aligned stack space for the worst case when you enter to JIT 2) the fake stack pointer should use this pre-allocated stack frame. Zoltan I don't know how to file bug so I posted here. In privateCompileCTIMachineTrampolines() there are multiple align() to align code on 16byte margin, yet, the stack can be put on 32bit margin that causes crush. Suppose original stack is aligned to 8/16bytes, the above function frequently pop/push regT3 that makes stack mis-aligned. Then int to double conversion uses stack that will fail. rgds joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] stack alignment bug
Hi, true, some architectures have strict policies for stack handling. Perhaps the worst one is PowerPC with its organized stack frame (back chains, pre-defined register save areas, etc). I think a fake stack pointer for JIT can solve the x86 compatibility problem. 1) allocate enough aligned stack space for the worst case when you enter to JIT 2) the fake stack pointer should use this pre-allocated stack frame. Zoltan I don't know how to file bug so I posted here. In privateCompileCTIMachineTrampolines() there are multiple align() to align code on 16byte margin, yet, the stack can be put on 32bit margin that causes crush. Suppose original stack is aligned to 8/16bytes, the above function frequently pop/push regT3 that makes stack mis-aligned. Then int to double conversion uses stack that will fail. rgds joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Math.floor(expr1/expr2)
Hi, we plans to make a super instruction for floor(expr1/expr2), which is an integer division (if both operands are integer numbers). We hope it would be benficial for embedded systems. I think the implementation would be similar to the JS apply() function: the fast case detects whether both operands are integer numbers and the function JSCell refers to the native floor function. The slow case would be the original SF byte code (the fast case has a jump to the end of the slow case). Do other ports interested in such super instruction? Where would be easier to detect these kind of expressions: in AST level or in SF byte code level (as a peephole optimization)? Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to dump SquirrelFish opcode and machine code
Hi, How to dump SquirrelFish opcode and machine code? Here is what I would like to do, for each JS file that WebCore passes to SquirrelFish, configure SquirrelFish to dump opcode and machine code. Thank you for any tips. I am not sure you can do SF byte code dump out of the box since SF opcode dump is only availible if you build your standalone JavaScriptCore in debug mode. In that case you just have to pass -d option to jsc. Fortunately, all neccessary helper functions can be found here: JavaScriptCore/bytecode/CodeBlock.cpp : CodeBlock::dump You only need to do some hand coding to make it available under WebCore, and perhaps dump the output into a file instead of the console. Machine code dump is not supported by JavaScriptCore. However, all machine code goes through this function: JavaScriptCore/assembler/AssemblerBuffer.h : AssemblerBuffer::executableCopy You can dump the raw x86 code here, and a disassembler can do the rest of the work. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit JavaScript question
Hi, Historical reasons. SF byte code had been implemented a year ago than jit. SF byte code (interpreter) will never go away, since not all devices support jit, and it is easier to generate JIT code from SF byte code than from Abstract Syntax Tree. Perhaps the authors can tell you more about this decision. Zoltan Thanks. Can you please help me understand why SquirellFish needs to generate squirellFish byte code first before compile it to machine code? For v8, it compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter. http://code.google.com/apis/v8/design.html#mach_code Thank you. On Thu, May 21, 2009 at 2:12 PM, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Hi, The JavaScript engine does 3 steps: 1) Parse JS files 2) Generate SquirellFish byte code (ByteCodeGenerator.h is part of it) 3) Compile SF byte code to machine code by its JIT compiler (optional) The last step depends on the architecture (supported or not) and C++ compiler directives. If JIT is enabled (see wtf/Platform.h), it always generates machine code. Otherwise an interpreter executes the byte code. A mixed environment (both jit and interpreter) is not yet supported. Zoltan Hi, Can you please tell me what is the difference between ByteCodeGenerator.h and JIT.h? I assume ByteCodeGenerator is convert a raw .js file into JavaScript VM opecode and will be executed by Webkit JavaScript VM. and JIT convert a raw .js file into native machine code and will be executed by operating system of the browser? Is that correct? If yes, when/how does Webkit decide to use which approach? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit JavaScript question
Hi, I don't think so. It is not worth to do it on a desktop pc since interpreter is always slower than JIT. However, the story is different for embedded systems, when they enter low-memory mode. We made some experiments before, and it seems possible to switch between jit and interpreter, but I am not sure that the community is interested in such features. Zoltan The last step depends on the architecture (supported or not) and C++ compiler directives. If JIT is enabled (see wtf/Platform.h), it always generates machine code. Otherwise an interpreter executes the byte code. A mixed environment (both jit and interpreter) is not yet supported. Are there plans for that ? Mozilla's TraceMonkey supports triggering JIT execution at runtine already, iirc. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit JavaScript question
Hi, The JavaScript engine does 3 steps: 1) Parse JS files 2) Generate SquirellFish byte code (ByteCodeGenerator.h is part of it) 3) Compile SF byte code to machine code by its JIT compiler (optional) The last step depends on the architecture (supported or not) and C++ compiler directives. If JIT is enabled (see wtf/Platform.h), it always generates machine code. Otherwise an interpreter executes the byte code. A mixed environment (both jit and interpreter) is not yet supported. Zoltan Hi, Can you please tell me what is the difference between ByteCodeGenerator.h and JIT.h? I assume ByteCodeGenerator is convert a raw .js file into JavaScript VM opecode and will be executed by Webkit JavaScript VM. and JIT convert a raw .js file into native machine code and will be executed by operating system of the browser? Is that correct? If yes, when/how does Webkit decide to use which approach? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] random seg fault on MIPS platform
Hi,
I don't know anything about MIPS architecture (only x86, ARM and PowerPC),
but we have experienced similar things on ARM, until we have found the
gcc's __clear_cache(void* begin, void* end) function. It calls a kernel
utility, which flushes out the data cache (some mrc instructions can only
executed on kernel level).
1) The program always fails without gdb, because the instructions are not
flushed out to the SDRAM. Instruction cache always loads the instructions
directly form the SDRAM.
2) With gdb, it is sometimes work, sometimes not. GDB itself allocates a
big amount of memory, so the cache is partly flushed out when it stops at
a breakpoint. Note that, the disassembly shows the content of the data
cache, not the instruction cache.
Zoltan
Hi,
50% of time when I use gdb then arith functions works. it may fail at
1st, or 3rd try, and 100% fail w/o gdb. I just use jsc to do sth like
5%2, 5*3, etc.
It is with in call of ctiTrampoline(code, registerFile, callFrame,
jexception, pptr, globalData), jit code executed and may be in last line
of op_mod() when it tried to convert result, gdb simply shows segment
fault, or PC stops at an non-coded area, w/o gdb it says invalid
instruction. It may be in JITcell,h in
ALWAYS_INLINE double JSValuePtr::toNumber(ExecState* exec) const
{
return JSImmediate::isImmediate(asValue()) ?
JSImmediate::toDouble(asValue()) : asCell()-toNumber(exec);
}
due to exec pointer wrong.
if I continue to use same arithmatic function the generated jit code won't
call op_mod() unless it is the 1st time, I think it is because jit code is
already there. If another thread handles the real operation and not sync'd
then it may be the case. Note I use BCM chip with two CPUs - BCM
customized SMP and BCM Linux.
when it works, before and after ctiTrampoline() the stack is balanced and
registers are ok. where is the jit stack and how to check its balance?
when it fails, stacks shows we are nearby jit code - the code w/o calling
OP_mod() CPP function as it fails at 3rd try. But PC points to a data
structure:
any comments? thanks a lot!!
rgds
joe
//
(gdb) c
Continuing.
Program received signal SIGILL, Illegal instruction.
0x2aacd000 in ?? ()
(gdb) where
#0 0x2aacd000 in ?? ()
warning: GDB can't find the start of the function at 0x2aacd000.
...
#1 0x2aacd000 in ?? ()
warning: GDB can't find the start of the function at 0x2aaccfff.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) backtrace
#0 0x2aacd000 in ?? ()
#1 0x2aacd000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) p/x $sp
$1 = 0x7fa439d8
(gdb) p/x $pc
$2 = 0x2aacd000
(gdb) p/x $t9
$3 = 0x2aac9588
(gdb) x/10i $t9 = jit code, no actual call to op_mod() cpp function
0x2aac9588: sw ra,-40(s5)
0x2aac958c: lui s7,0x0
0x2aac9590: ori s7,s7,0xa
0x2aac9594: sw s7,0(s5)
0x2aac9598: lui s7,0x0
0x2aac959c: ori s7,s7,0xa
0x2aac95a0: sw s7,8(s5)
0x2aac95a4: lui v0,0x0
0x2aac95a8: ori v0,v0,0xa
0x2aac95ac: sw v0,32(s5)
(gdb)
0x2aac95b0: lui v0,0x
0x2aac95b4: ori v0,v0,0x
0x2aac95b8: sw v0,32(s5)
0x2aac95bc: lw at,-40(s5)
0x2aac95c0: nop
0x2aac95c4: addiu sp,sp,-4
0x2aac95c8: sw at,0(sp)
0x2aac95cc: lw ra,0(sp)
0x2aac95d0: addiu sp,sp,4
0x2aac95d4: jr ra
0x2aac95d8: nop
(gdb) p/x $ra //$ra = tobe returned addr after ctiTrampoline(), correct
$4 = 0x676d64
(gdb) x/10i $pc //sth not patched well??
0x2aacd000: 0x4941444a
0x2aacd004: jalx0x21a5a881
0x2aacd008: j 0x2984c8b4
0x2aacd00c: andiat,s3,0x3134
0x2aacd010: 0x6d202c30
0x2aacd014: 0x7a69735f
0x2aacd018: 0x66373d65
0x2aacd01c: xoris3,t1,0x3461
0x2aacd020: ori t0,t1,0x3864
0x2aacd024: addit4,at,10544
(gdb)
0x2aacd028: jalx0x25b185d9
0x2aacd02c: j 0x28c0f594
0x2aacd030: andis0,at,0x3030
0x2aacd034: 0x720a0a38
0x2aacd038: 0x64496765
0x2aacd03c: j 0x28e0c4f4
0x2aacd040: nop
0x2aacd044: nop
0x2aacd048: nop
0x2aacd04c: nop
0x2aacd028: jalx0x25b185d9
0x2aacd02c: j 0x28c0f594
0x2aacd030: andis0,at,0x3030
0x2aacd034: 0x720a0a38
0x2aacd038: 0x64496765
0x2aacd03c: j 0x28e0c4f4
0x2aacd040: nop
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Nitro-Extreme branch
Hi, I have made some measurements on ARM. You can read the results on our blog site: http://webkit.sed.hu/node/14 Zoltan Right now, the branch is about even with trunk on SunSpider. Geoff On May 5, 2009, at 6:11 AM, Zoltan Herczeg wrote: Hi, we have noticed that there is a new SquirellFish branch, called Nitro-Extreme. You mentioned before (perhaps a year ago), that you plan to change the JSNumber format to eliminate number (double) allocations. This is the aim of this branch, isn't it? Do you have any results? Is it faster than the old implementation? I'm afraid we have to change a lot of things in both (x86 and arm) jit ports, but it is worth the efforts if your results are encouraging. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Nitro-Extreme branch
Hi, we have noticed that there is a new SquirellFish branch, called Nitro-Extreme. You mentioned before (perhaps a year ago), that you plan to change the JSNumber format to eliminate number (double) allocations. This is the aim of this branch, isn't it? Do you have any results? Is it faster than the old implementation? I'm afraid we have to change a lot of things in both (x86 and arm) jit ports, but it is worth the efforts if your results are encouraging. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
