Re: [webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU

2014-11-18 Thread Zoltan Herczeg
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

2014-11-13 Thread Zoltan Herczeg
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

2014-11-13 Thread Zoltan Herczeg
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

2014-11-12 Thread Zoltan Herczeg
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

2014-01-13 Thread Zoltan Herczeg
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

2013-09-12 Thread Zoltan Herczeg
 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

2013-04-13 Thread Zoltan Herczeg
 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

2013-04-12 Thread Zoltan Herczeg
 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

2013-04-04 Thread Zoltan Herczeg
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?

2013-02-12 Thread Zoltan Herczeg
 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

2013-01-22 Thread Zoltan Herczeg
 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

2013-01-21 Thread Zoltan Herczeg
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

2013-01-10 Thread Zoltan Herczeg
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

2013-01-10 Thread Zoltan Herczeg
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

2012-11-26 Thread Zoltan Herczeg
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

2012-11-21 Thread Zoltan Herczeg
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

2012-10-11 Thread Zoltan Herczeg
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

2012-07-23 Thread Zoltan Herczeg
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

2012-07-03 Thread Zoltan Herczeg
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

2012-06-23 Thread Zoltan Herczeg
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

2012-06-22 Thread Zoltan Herczeg
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

2012-06-22 Thread Zoltan Herczeg
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

2012-06-22 Thread Zoltan Herczeg
 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

2012-06-17 Thread Zoltan Herczeg
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?

2012-06-08 Thread Zoltan Herczeg
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?

2012-06-08 Thread Zoltan Herczeg
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

2012-05-21 Thread Zoltan Herczeg
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?

2012-03-21 Thread Zoltan Herczeg
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

2012-03-03 Thread Zoltan Herczeg
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

2012-03-03 Thread Zoltan Herczeg
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

2012-01-23 Thread Zoltan Herczeg
 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

2012-01-21 Thread Zoltan Herczeg
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

2011-12-12 Thread Zoltan Herczeg
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

2011-12-12 Thread Zoltan Herczeg
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)

2011-12-06 Thread Zoltan Herczeg
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)

2011-12-05 Thread Zoltan Herczeg
 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.

2011-11-26 Thread Zoltan Herczeg
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

2011-09-08 Thread Zoltan Herczeg
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

2011-06-30 Thread Zoltan Herczeg
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


Re: [webkit-dev] parallel painting

2011-06-10 Thread Zoltan Herczeg
Hi,

wow, your use case is really interesting. I have never thought about that.
Yeah, that would be a simple extension to the parallel painting system,
you could replay the commands anywhere, any times. It is basically a
vector graphics representation of the screen, you could scale it up.

Actually I am really happy that those techinques we were working on
eventually attracting others. We were the first one who played with
parallelization, SIMD instruction sets, and their usage is growing in
WebKit now. Devices (people) actually use them! It seems playing with new
approaches (even radical changes) are never a waste of time. We could
learn a lot from them.

Regards,
Zoltan

 On 6/9/2011 8:24 PM, Pierre-Antoine LaFayette wrote:

 Android uses a retain mode rendering approach as well; where paint
 operations are recorded on a WebCore thread and painting is actually
 done on the UI thread. It isn't necessarily the best approach. But I
 suppose it depends the platform whether or not there is much to gain.
 You still need to worry about synchronization.
 ...
 On 6 April 2010 03:24, Eric Seidel e...@webkit.org
 mailto:e...@webkit.org wrote:

 Parallel painting would only be useful if the graphics layer is
 incredibly slow.  In most WebKit ports we do not see very much time

 ...

 On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg
 zherc...@inf.u-szeged.hu mailto: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 this something that could be used to duplicate painting commands?

 I'm very interested in enabling secondary painting contexts,
 to enable better representation of Zoom, and other common assistive
 techniques.

 Example:
 If the recording is used, prefixed with scale and crop, a user could be
 presented with
 a crisp and clear magnification of a focused region or other sub-region.

 Such techniques could also be useful for remote viewing, via
 serialization,
 and for efficient screen dumps [assuming the render works, of course].

 It'd be great, if some time, secondary user agents, like the popular
 ZoomText Magnifier,
 were able to interact with WebKit and request regions to be painted at a
 higher resolution,
 so as to display the magnified image at native resolution.

 Does that make sense? Is that something that this technique might
 eventually provide?

 I suspect that screen mirroring and other forms of screen sharing will
 become more common
 in use, as more and more physical screens become common in our common
 lives.

 -Charles


___
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

2011-06-07 Thread Zoltan Herczeg
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

2010-12-27 Thread Zoltan Herczeg
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

2010-12-18 Thread Zoltan Herczeg
 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

2010-12-18 Thread Zoltan Herczeg
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

2010-12-17 Thread Zoltan Herczeg
 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

2010-12-17 Thread Zoltan Herczeg

 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

2010-11-25 Thread Zoltan Herczeg
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

2010-08-13 Thread Zoltan Herczeg
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

2010-07-22 Thread Zoltan Herczeg

 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

2010-07-20 Thread Zoltan Herczeg
 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.

2010-07-17 Thread Zoltan Herczeg
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

2010-06-28 Thread Zoltan Herczeg
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

2010-05-03 Thread Zoltan Herczeg
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

2010-04-09 Thread Zoltan Herczeg
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

2010-04-09 Thread Zoltan Herczeg

 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

2010-04-06 Thread Zoltan Herczeg
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

2010-04-06 Thread Zoltan Herczeg
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

2010-04-03 Thread Zoltan Herczeg
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

2010-03-10 Thread Zoltan Herczeg

 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)

2010-03-09 Thread Zoltan Herczeg
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

2010-02-20 Thread Zoltan Herczeg
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

2010-01-08 Thread Zoltan Herczeg
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

2010-01-07 Thread Zoltan Herczeg
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

2009-12-04 Thread Zoltan Herczeg
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()

2009-12-03 Thread Zoltan Herczeg
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

2009-11-17 Thread Zoltan Herczeg
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

2009-10-21 Thread Zoltan Herczeg
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

2009-10-21 Thread Zoltan Herczeg
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

2009-10-16 Thread Zoltan Herczeg
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

2009-10-12 Thread Zoltan Herczeg
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

2009-10-12 Thread Zoltan Herczeg
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

2009-10-07 Thread Zoltan Herczeg
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

2009-09-29 Thread Zoltan Herczeg
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

2009-09-23 Thread Zoltan Herczeg
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

2009-09-02 Thread Zoltan Herczeg
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

2009-09-01 Thread Zoltan Herczeg
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

2009-08-05 Thread Zoltan Herczeg
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

2009-08-04 Thread Zoltan Herczeg
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

2009-07-30 Thread Zoltan Herczeg
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

2009-07-29 Thread Zoltan Herczeg
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

2009-07-27 Thread Zoltan Herczeg
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

2009-07-06 Thread Zoltan Herczeg
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

2009-07-03 Thread Zoltan Herczeg
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

2009-06-17 Thread Zoltan Herczeg
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

2009-06-17 Thread Zoltan Herczeg
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

2009-06-16 Thread Zoltan Herczeg
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

2009-06-16 Thread Zoltan Herczeg
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

2009-06-11 Thread Zoltan Herczeg
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

2009-06-11 Thread Zoltan Herczeg


 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

2009-06-11 Thread Zoltan Herczeg
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

2009-06-04 Thread Zoltan Herczeg
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

2009-06-04 Thread Zoltan Herczeg
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

2009-06-03 Thread Zoltan Herczeg
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)

2009-05-28 Thread Zoltan Herczeg
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

2009-05-27 Thread Zoltan Herczeg

 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

2009-05-22 Thread Zoltan Herczeg
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

2009-05-22 Thread Zoltan Herczeg
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

2009-05-21 Thread Zoltan Herczeg
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

2009-05-08 Thread Zoltan Herczeg
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

2009-05-07 Thread Zoltan Herczeg
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


  1   2   >