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

[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

[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

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

[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

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

[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

[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

[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

[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

[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

[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?

[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

[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

[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

[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  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  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] Feature Announcement: Moving HTML Parser off the Main 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  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] WebKit + OpenCL

[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  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  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

[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

[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 
> 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

[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=153479&action=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

[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

[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  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

[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] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[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  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
>>>>> MIP

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

[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] DFG, inline functions compileing

[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  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?

[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

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

[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

[webkit-dev] Transformations precision: double -> float

[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?

[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  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

Re: [webkit-dev] Grafikus teamnek

[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

[webkit-dev] Grafikus teamnek

[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] Top 100 sites browsing tests proprosal

[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

[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 
> 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

[webkit-dev] Custom written css lexer

[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] Arm conditional instructions support

[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

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

[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)

[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.

[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

[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

[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  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

[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 > <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
>> 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

[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

[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

[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 (= B),
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 "T" is enough to enter the Tools directory
> feature :P I like the "L" 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

[Zoltan Herczeg]

> LayoutTests => Tests

That would kill the new "T" is enough to enter the Tools directory
feature :P I like the "L" 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

[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] Stability problems involving Javascript GC

[Zoltan Herczeg]

>> On 6 December 2010 22:31, Zoltan Herczeg 
>> 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

[Zoltan Herczeg]

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".

Regards,
Zoltan

>>> And here is a common sort of stack trace I'm getting (this one from
>>> 10.6)
>>> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
>>> 0   com.apple.JavaScriptCore0x9489f766 WTF::fastFree(void*)
>>> + 134
>>> 1   com.apple.WebCore   0x929be825
>>> WebCore::CSSSelectorList::deleteSelectors() + 389
>>> 2   com.apple.WebCore   0x92a38269
>>> WebCore::CSSStyleRule::~CSSStyleRule() + 57
>>> 3   com.apple.WebCore   0x929c3a04
>>> WTF::Vector, 0ul>::shrink(unsigned
>>> long) + 84
>>> 4   com.apple.WebCore   0x92a38193
>>> WebCore::StyleSheet::~StyleSheet() + 179
>>> 5   com.apple.WebCore   0x92a38066
>>> WebCore::CSSStyleSheet::~CSSStyleSheet() + 102
>>> 6   com.apple.WebCore   0x92a91074
>>> WTF::Vector, 0ul>::shrink(unsigned
>>> long) + 84
>>> 7   com.apple.WebCore   0x92a29243
>>> WebCore::StyleSheetList::~StyleSheetList() + 67
>>> 8   com.apple.WebCore   0x92a28cd9
>>> WebCore::Document::~Document() + 3529
>>> 9   com.apple.WebCore   0x92a27f01
>>> WebCore::HTMLDocument::~HTMLDocument() + 129
>>> 10  com.apple.WebCore   0x92a27def
>>> WebCore::Node::~Node() + 431
>>> 11  com.apple.WebCore   0x92c05a21
>>> WebCore::HTMLIFrameElement::~HTMLIFrameElement() + 129
>>> 12  com.apple.WebCore   0x92b356fe
>>> WebCore::JSNode::~JSNode() + 382
>>> 13  com.apple.JavaScriptCore0x9495a0d2 JSC::Heap::sweep() +
>>> 274
>>>
>>> I find it odd that main isn't seen in the stack, but it never is.
>>
>>> The crash nearly ALWAYS occurs in WTF::fastFree(), very
>>> occasionally occurring instead in some other memory management
>>> function.
>>
>> In the backtrace you've pasted, there's no direct link to JavaScript
>> GC. GC only appears in the backtrace because a JavaScript object
>> held the last reference to the DOM document object.
>>
>> There's a small chance that you've run into this bug, or one of its
>> relations: https://bugs.webkit.org/show_bug.cgi?id=50165.
>>
>> The best way to diagnose this is to provide a sample application
>> that demonstrates the crash in Bugzilla.
>>
>> Thanks,
>> Geoff
>
>
> Thought I'd post two other backtraces that differ from the above but
> are caused in the same way, in case someone here can see something in
> them I cannot.
>
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   com.apple.JavaScriptCore  0x9489e536
> WTF::TCMalloc_Central_FreeList::RemoveRange(void**, void**, int*) + 198
> 1   com.apple.JavaScriptCore  0x9489d258 WTF::fastMalloc(unsigned
> long) + 488
> 2   com.apple.WebCore 0x929850b2
> WebCore::StringWrapperCFAllocator::allocate(long, unsigned long,
> void*) + 66
> 3   com.apple.CoreFoundation  0x94d99a13 _CFRuntimeCreateInstance
> + 179
> 4   com.apple.CoreFoundation  0x94d9c1f5
> __CFStringCreateImmutableFunnel3 + 789
> 5   com.apple.CoreFoundation  0x94da3bd0
> CFStringCreateWithCharactersNoCopy + 96
> 6   com.apple.WebCore 0x929807bc
> WebCore::StringImpl::createCFString() + 124
> 7   com.apple.WebCore 0x92a0c547
> WebCore::ResourceRequest::doUpdatePlatformRequest() + 1159
> 8   com.apple.WebCore 0x92a0c0ab
> WebCore::ResourceRequestBase::updatePlatformRequest() const + 27
> 9   com.apple.WebCore 0x92a0c05d
> WebCore::ResourceRequest::nsURLRequest() const + 29
> 10  com.apple.WebKit  0x998a22f3
> WebFrameLoaderClient
> ::dispatchWillSendRequest(WebCore::DocumentLoader*, unsigned long,
> WebCore::ResourceRequest&, WebCore::ResourceResponse const&) + 163
> 11  com.apple.WebCore 0x93329151
> WebCore
> ::ResourceLoadNotifier
> ::dispatchWillSendRequest(WebCore::DocumentLoader*, unsigned long,
> WebCore::ResourceRequest&, WebCore::ResourceResponse const&) + 145
> 12  com.apple.WebCore 0x92a10ab2
> WebCore
> ::ResourceLoadNotifier::willSendRequest(WebCore::ResourceLoader*,
> WebCore::ResourceRequest&, WebCore::ResourceResponse const&) + 82
> 13  com.apple.WebCore 0x92a106d2
> WebCore::ResourceLoader::willSendRequest(WebCore::ResourceRequest&,
> WebCore::ResourceResponse const&) + 98
> 14  com.apple.WebCore 0x92abe8e0
> WebCore::SubresourceLoader::willSendRequest(WebCore::ResourceRequest&,
> WebCore::ResourceResponse const&) + 80
> 15  com.apple.WebCore 0x92abe084
> WebCore::ResourceLoader::load(WebCore::ResourceRequest const&) + 580
> 16  com.apple.WebCore 0x9334345e
> WebCore::SubresourceLoader::create(WebCore::Frame*,
> WebCore::SubresourceLoaderClient*, WebCore::ResourceRequest const&,

Re: [webkit-dev] WebKit/Cairo build errors

[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
> "" and it shouldn't (right? this is part of
> the
> Apple CoreGraphics). So I replaced this include by "". 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

[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

[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

[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.

[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

[Zoltan Herczeg]

Hi,

why don't you simply use a workaround?


 function success()
 {
alert("Success");
continueTask(true);
 }

 function failure()
 {
alert("Failure");
continueTask(false);
 }

 function continueTask(success)
 {
  x= 10+1;
 }


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,
> *
> 
> function success()
> {
>alert("Success");
> }
>
> function failure()
> {
>alert("Failure");
> }
>
> MyObject.postMessage(success,failure,"hello, How r u?");
> MyObject.wait();
> x= 10+1;
> *
>
> 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

[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] Disabling the JIT

[Zoltan Herczeg]

When your code compiles, do you see -DENABLE_JIT=0 option passed to gcc?
Anyway, this discussion should go to webkit-help.

Zoltan

>
>>> Another way would be to set export QMAKEARGS="$QMAKEARGS
> DEFINES+=ENABLE_JIT=0" before building.
>
> Ok. I tried this approach. I have a build script that looks like this:
>
> QTDIR=/usr/share/qt4/
> export QMAKEARGS="$QMAKEARGS DEFINES+=ENABLE_JIT=0"
> WebKit/WebKitTools/Scripts/build-webkit --qt
>
> It builds, but the JIT is not disabled. It seems that the new argument is
> simply ignored.
>
> I also tried adding "#define ENABLE_JIT 0" at the top of the
> Interpreter.cpp
> file in JavaScriptCore. This builds, but produces a segmentation fault.
>
> I will try doing the "WebKit/WebKitTools/Scripts/build-webkit --qt
> JAVASCRIPTCORE_JIT=no" with a fresh SVN checkout... Is there any
> equivalent
> of make clean script, as a completment to build-webkit?
> --
> View this message in context:
> http://old.nabble.com/Disabling-the-JIT-tp28378562p28382091.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] Coming Soon: new-run-webkit-tests

[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] Announcing WebKit2

[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] parallel painting

[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
>  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

Re: [webkit-dev] parallel painting

[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 
> 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

[webkit-dev] parallel painting

[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

[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)

[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

[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

[webkit-dev] parallel rendering in WebKit

[Zoltan Herczeg]

Hi,

as all of you probably know, smp based systems are getting widespread even
in the embedded domain, and we hope we can speed up webkit on these
systems. We did some profiling, and seemed the platform dependent
rendering took 50% of the total runtime (at least on our test platforms).
We are thinking about adding some parallel rendering support for WebKit,
probably mostly platform dependent code, but the threading support could
be reused by different ports.

The plan is opening a rendering thread for each document object. This
thread is dedicated to rendering, the resource management is still done by
the main thread. In other words, functions like drawRect (in
GraphicsContext.h) creates a small object, which contains the arguments of
the called function, and passing this object to the thread. The thread
would do the painting, and send back the object after it is processed. The
main thread can free the memory space of the object later, and dereference
the resources (we hope resources like fonts and images are not need to be
duplicated).

This is still a vague idea, and we are still investigating the
possibilities. What is your opinion? Do you know about any major blockers
we should know about?

Thanks in advance,
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

[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

[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::RefPtr::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   

[webkit-dev] TARGET_OS_EMBEDDED

[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()

[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

[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

[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 for arm is dependant on gcc

[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, unordered compare

[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

Re: [webkit-dev] jit, unordered compare

[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] jit, unordered compare

[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

[webkit-dev] compileOpCallSetupArgs

[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] Purging as much memory as possible

[Zoltan Herczeg]

Hi,

see QWebSettings::clearMemoryCaches() (WebKit/qt/Api/qwebsettings.cpp) to
clear memory caches and qt_drt_garbageCollector_collect
(WebKit/qt/Api/qwebframe.cpp) to call the garbage collector.

Zoltan

> On Oct 1, 2009, at 6:24 PM, Peter Kasting wrote:
>
>> * Does anyone already know the likely footprint of the Glyph cache,
>> or how to clear it?
>
> FontCache::purgeInactiveFontData().
>
> If you’re using Safari then you can see Font and Glyph Caches
> statistics in its Caches window, which also includes a Purge Inactive
> Font Data button that calls through to purgeInactiveFontData().
> ___
> 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] Leak reports during shutdown

[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

[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

[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] unwritten rules of webkit style

[Zoltan Herczeg]

Hi,

I am actually working on a patch which can frees global variables before
the program exit. https://bugs.webkit.org/show_bug.cgi?id=27980 As you can
see in the current patch, a standard naming convention is not really used
for global variables (I have to change the types for all of them). They
can sometimes written like a member name (defaultStyle), or a 'g'
(gNameCache) prefix. For static members sometimes an 's_' prefix is used
(s_styleNotYetAvailable), sometimes nothing (nullBaseString). If you wish,
I can do the renaming to something standardized along with the patch.

Zoltan

> On Sep 2, 2009, at 9:59 AM, Yong Li wrote:
>
>> I think global variables should start with "g_".
>>
>> -Yong
>
> I actually agree fairly strongly that constants and global/static
> variables should have consistent, identifiable prefixes.
>
> For globals, having a prefix code easier to understand with a quick
> scan. If the global has no prefix, you have to search for it and
> discover that it's not a local variable, member variable or parameter
> before understanding where it comes from. This is a particular problem
> in Xcode, which does not use a different syntax highlight color for
> globals (unlike the venerable CodeWarrior). I also think that globals
> are a particular concern because they impact thread safety, and
> misunderstanding their scope of influence can have bad ramifications.
>
> Using a prefix for constants also reduces brainprint when scanning
> code; you know that its value is never going to change.
>
> Simon
>
> ___
> 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

[Zoltan Herczeg]

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

Re: [webkit-dev] New marking model for GC collected objects

[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

[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

[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

[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

[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

[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

[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

[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] Building WebKit on ARM

[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

Re: [webkit-dev] ARM JIT and related issues

[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] Name of a JS function

[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

[webkit-dev] Name of a JS function

[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] Memory usage for Webkit

[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] arm jit

[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] arm jit

[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
> procedu

Re: [webkit-dev] stack alignment bug

[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  wrote:
>>>
>>>> From: Zoltan Herczeg 
>>>> Subject: Re: [webkit-dev] stack alignment bug
>>>> To: "x yz" 
>>>> 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

[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  wrote:
>
>> From: Zoltan Herczeg 
>> Subject: Re: [webkit-dev] stack alignment bug
>> To: "x yz" 
>> 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

[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

Re: [webkit-dev] does jit uses self-modifying code?

[Zoltan Herczeg]

Hi,

I don't know what is happening there, but since JSObject->put() is
connected with property caching, and property caching does use
self-modifying code, perhaps you should look around at
JITStubs::tryCachePutByID.

I wrote a little text about property caching in JIT last week. You can
find it here: http://webkit.sed.hu/node/18

Zoltan

> Hi,
> Appreciate for help. If the answer is yes may I know here are they.
>
> MIPS webkit-1.1.1, cmd using: jsc shell.js
> In JavaScriptCore/runtime/JSObject.h:527
>   asCell()->put(exec, propertyName, value, slot);
> this one will call a function, yet the function entry address got is
> invalid.
> 0x006b17ec527 asCell()->put(exec, propertyName, value, slot);
> (gdb) x/10i $pc
> 0x6b17ec
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+196>:
>  lw  gp,24(s8)
> 0x6b17f0
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+200>:
>  movev1,v0
> 0x6b17f4
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+204>:
>  lw  a0,0(v1)
> 0x6b17f8
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+208>:
>  lw  a3,60(s8)
> 0x6b17fc
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+212>:
>  lw  v0,64(s8)
> 0x6b1800
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+216>:
>  sw  v0,16(sp)
> 0x6b1804
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+220>:
>  lw  t9,68(a0)
> 0x6b1808
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+224>:
>  movea0,v1
> 0x6b180c
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+228>:
>  lw  a1,52(s8)
> 0x6b1810
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+232>:
>  lw  a2,56(s8)
>
>
> the entry got is $t9=0x2bc that is wrong.
> rgds
> joe
> --- On Sat, 5/9/09, x yz  wrote:
>
>> From: x yz 
>> Subject: Re: [webkit-dev] random seg fault on MIPS platform
>> To: webkit-dev@lists.webkit.org
>> Date: Saturday, May 9, 2009, 1:24 AM
>>
>> 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: