Re: [webkit-dev] SquirrelFish Extreme for non x-86 platforms
This way the engine will run without JIT support. However, what to do with memory allocation functions like VirtualAlloc() that are only available on Windows? I mean to say, to run on embedded platforms, what alternate has to exist that may provide the facility of VirtualAlloc(). As far I have seen, the virtualAlloc() calls can be disabled even on Windows by setting HAVE_VIRTUAL_ALLOC to 0 in JSC/wtf/Platform.h. However, the garbage collection implementation uses this particular call inside JSC/runtime/Collector.cpp irrespective of HAVE_VIRTUAL_ALLOC being 0 or 1. Any suggestions on this front? I have built Windows port with HAVE_VIRTUAL_ALLOC set to 0. But the VirtualAlloc() call inside JSC/runtime/Collector.cpp if replaced with fastMalloc() causes the WebKit to crash even on Windows. Regards, J R Shah On Thu, Dec 25, 2008 at 2:22 AM, Maciej Stachowiak m...@apple.com wrote: On Dec 24, 2008, at 1:52 PM, Javed Rabbani wrote: That means the current JS Engine (SquirrelFish Extreme) can be run on embedded/mobile platforms in bytecode mode without JIT. Correct me if I am wrong? If I am correct, then how to enable the engine's bytecode mode? There are number of ENABLE switches related to current JS engine... It should compile with JIT disabled on platforms that do not support the JIT. - Maciej Regards, J R Shah On Thu, Dec 25, 2008 at 12:49 AM, Maciej Stachowiak m...@apple.com wrote: On Dec 24, 2008, at 6:46 AM, Holger Freyther wrote: On Wednesday 24 December 2008 14:00:19 Javed Rabbani wrote: I want to know whether WebKit JavaScript Engine SquirrelFish Extreme (SFX) has been reported to work on any embedded, non-x86 platform? No, the extreme variant is only working on x86 and work on progress on the amd64... To be more specific: 1) The JS engine should work on any CPU and on most reasonable operating systems in bytecode mode. It's still pretty fast as bytecode - nearly an order of magnitude faster than the old WebKit JS engine. 2) Currently the JIT only fully works on x86 and will soon also work on x86_64 (currently some basic tests pass but neither performance nor correctness are where we want them to be). 3) We are considering ports of the JIT to other CPU architectures. For mobile platforms, it's not entirely clear whether the JIT will turn out to be better than the bytecode interpreter - the memory cost might outweigh the speed benefit. Regards, Maciej ___ 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] SquirrelFish Extreme for non x-86 platforms
On Dec 25, 2008, at 12:54 AM, Javed Rabbani wrote: This way the engine will run without JIT support. However, what to do with memory allocation functions like VirtualAlloc() that are only available on Windows? I mean to say, to run on embedded platforms, what alternate has to exist that may provide the facility of VirtualAlloc(). As far I have seen, the virtualAlloc() calls can be disabled even on Windows by setting HAVE_VIRTUAL_ALLOC to 0 in JSC/wtf/Platform.h. However, the garbage collection implementation uses this particular call inside JSC/runtime/Collector.cpp irrespective of HAVE_VIRTUAL_ALLOC being 0 or 1. Any suggestions on this front? That call to VirtualAlloc is inside a PLATFORM(WIN_OS) guard -- you should not be hitting it on a non-windows platform I have built Windows port with HAVE_VIRTUAL_ALLOC set to 0. But the VirtualAlloc() call inside JSC/runtime/Collector.cpp if replaced with fastMalloc() causes the WebKit to crash even on Windows. This is basically expected -- as the code for other platforms should have also indicated the collector has important alignment requirements that fastMalloc does not guarantee. I think to fix your issues you should work out why your platform is being reported as windows (PLATFORM(WIN_OS)) --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SquirrelFish Extreme for non x-86 platforms
Oliver, That call to VirtualAlloc is inside a PLATFORM(WIN_OS) guard -- you should not be hitting it on a non-windows platform You are absolutely right about that. The VirtualAlloc() should never be hit on non-Windows platform. Let me clarify, I am not hitting the VirtualAlloc call on a non-Windows platform. I was just referring to the point that what can be a possible alternative to VirtualAlloc on embedded platforms. Looking through the code, the VirtualAlloc is enabled for WIN_OS only as expected. For other platforms like SYMBIAN for example, the fastMalloc() is enabled with a comment that VirtualAlloc is not available on Symbian, so hack with fastMalloc. What are specific memory requirements that VirtualAlloc() fulfills and fastMalloc() does not? What can be the workaround for VirtualAlloc() on embedded platforms? I hope my point of concern is clearely stated now. Regards, J R Shah On Thu, Dec 25, 2008 at 2:07 PM, Oliver Hunt oli...@apple.com wrote: On Dec 25, 2008, at 12:54 AM, Javed Rabbani wrote: This way the engine will run without JIT support. However, what to do with memory allocation functions like VirtualAlloc() that are only available on Windows? I mean to say, to run on embedded platforms, what alternate has to exist that may provide the facility of VirtualAlloc(). As far I have seen, the virtualAlloc() calls can be disabled even on Windows by setting HAVE_VIRTUAL_ALLOC to 0 in JSC/wtf/Platform.h. However, the garbage collection implementation uses this particular call inside JSC/runtime/Collector.cpp irrespective of HAVE_VIRTUAL_ALLOC being 0 or 1. Any suggestions on this front? That call to VirtualAlloc is inside a PLATFORM(WIN_OS) guard -- you should not be hitting it on a non-windows platform I have built Windows port with HAVE_VIRTUAL_ALLOC set to 0. But the VirtualAlloc() call inside JSC/runtime/Collector.cpp if replaced with fastMalloc() causes the WebKit to crash even on Windows. This is basically expected -- as the code for other platforms should have also indicated the collector has important alignment requirements that fastMalloc does not guarantee. I think to fix your issues you should work out why your platform is being reported as windows (PLATFORM(WIN_OS)) --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas API in Webkit
On Dec 24, 2008, at 7:48 PM, Lucius Fox wrote: Thanks. I think Safari has a 'history' feature or Nokia S60 browser which shows each url in history as a preview image. Not the desktop version of Safari, but yes, the mobile Safari has something like this. I think the Nokia browser does too. Can you please tell me how if that is true and how is that implement? Well, those browsers aren't open source, so there's no real way for you to find out how they implemented the feature. I think it's safe to assume that they draw the web pages into a bitmap and then shrink the image. It certainly has nothing to do with the HTML canvas element in either case. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit.lib link error
Those are most likely version skew problems with the ICU library. If you compile against headers for the 3.8 version of ICU and try to link against a different version, you'd get errors like that. I don't know the specifics about how you could get a configuration that was broken that way. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About renderer
On Dec 24, 2008, at 2:16 AM, zhenghe zhang wrote: I know how to create a render object , but I don't know that the condition about create the render object ,could you tell me? The process of creating and properly setting up the objects in the render tree is called layout. It starts with functions like FrameView::layout() and Document::attach(). One way to learn about when they're called is to get a running web browser and set breakpoints in these functions. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas API in Webkit
Well, those browsers aren't open source, so there's no real way for you to find out how they implemented the feature. I think it's safe to assume that they draw the web pages into a bitmap and then shrink the image. It certainly has nothing to do with the HTML canvas element in either case. -- Darin The function below indicates that s60 browser is using a bitmap to implement the history feature. void CHistoryController::UpdateHistoryEntryThumbnailL(const CFbsBitmap* aBitmap); http://trac.webkit.org/browser/S60/trunk/HistoryProvider/inc/HistoryController.h#L190 Zalan. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Moving methods from Frame to various other classes
Hey, there are some comments in Frame.h regarding moving functionality to different classes and on IRC it was confirmed that the comments are old but current. I have decided to do something about it. I have created a git branch[1] on George's server that will contain the work in progress of the moving. I'm currently moving stuff around, it will be followed by build fixes and speculative changes for Qt, Mac and then regression testing on the mac. I hope to be finished with this by the start of the yearly CCC event. Meanwhile I would like to start some discussion on how this patch should be put into the bugtracker and comments on the moving. I wonder if I should put each move up for separate review and then land it in one go? Should I create a bug report for that? Moving comments: Zoom and FrameView: - Currently on history navigation (back/forward) we create a new FrameView. When storing the Zoom information in the FrameView instead of the Frame the Kit parts need to properly restore the Zoom Information? Is that wanted? should we leave this functionality in the frame? Status and Chrome: - For statusBarText and defaultStatusBarText? Do we really need to store the defaults? If yes should we do it in Chrome? Would the DOMWindow be a better place to store them? What I have difficulties with is that the information is set on the Chrome/Kit but that we can have a per frame default... Editing: - I have killed Frame::removeEditingStyleFromElement and Frame::removeEditingStyleFromBodyElement they have been no-ops since the end of 2006. z. [1] http://code.staikos.net/cgi- bin/gitweb.cgi?p=webkit;a=shortlog;h=holger/frame-refactor ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving methods from Frame to various other classes
On Dec 25, 2008, at 2:46 PM, Holger Freyther wrote: Hey, there are some comments in Frame.h regarding moving functionality to different classes and on IRC it was confirmed that the comments are old but current. I have decided to do something about it. I have created a git branch[1] on George's server that will contain the work in progress of the moving. I'm currently moving stuff around, it will be followed by build fixes and speculative changes for Qt, Mac and then regression testing on the mac. I hope to be finished with this by the start of the yearly CCC event. It's great that you are doing this! Meanwhile I would like to start some discussion on how this patch should be put into the bugtracker and comments on the moving. I wonder if I should put each move up for separate review and then land it in one go? Should I create a bug report for that? It would be better to break the changes down instead of submitting as one big patch. Perhaps breaking things up by target class being moved to would be best. Moving comments: Zoom and FrameView: - Currently on history navigation (back/forward) we create a new FrameView. When storing the Zoom information in the FrameView instead of the Frame the Kit parts need to properly restore the Zoom Information? Is that wanted? should we leave this functionality in the frame? I think it would be best to leave it for now. If we had more than one piece of view state that persists across navigations like this, it might be worth making a new class to hold that state, but not for zoom alone in my opinion. Status and Chrome: - For statusBarText and defaultStatusBarText? Do we really need to store the defaults? If yes should we do it in Chrome? Would the DOMWindow be a better place to store them? What I have difficulties with is that the information is set on the Chrome/Kit but that we can have a per frame default... This is a somewhat confusing area. JS may set status bar text but there may also be a message set by the app. Other browsers have been changing to restrict or remove the ability for JS in the web page to set status bar text as a security measure. In my opinion we should review what they do and make the appropriate restrictions and simplifications here, separate from any refactorings. Editing: - I have killed Frame::removeEditingStyleFromElement and Frame::removeEditingStyleFromBodyElement they have been no-ops since the end of 2006. Removing is the best kind of moving. :-) - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SquirrelFish Extreme for non x-86 platforms
On Dec 25, 2008, at 3:54 AM, Oliver Hunt wrote: On Dec 25, 2008, at 2:18 AM, Javed Rabbani wrote: Oliver, That call to VirtualAlloc is inside a PLATFORM(WIN_OS) guard -- you should not be hitting it on a non-windows platform You are absolutely right about that. The VirtualAlloc() should never be hit on non-Windows platform. Let me clarify, I am not hitting the VirtualAlloc call on a non-Windows platform. I was just referring to the point that what can be a possible alternative to VirtualAlloc on embedded platforms. Looking through the code, the VirtualAlloc is enabled for WIN_OS only as expected. For other platforms like SYMBIAN for example, the fastMalloc() is enabled with a comment that VirtualAlloc is not available on Symbian, so hack with fastMalloc. It's perfectly possible it's broken in symbian -- the last symbian release was from more than two years ago. A bit of digging showed that Simon Hausmann added the SYMBIAN fastMalloc branch, which implies this was for WebKit/Qt which builds with fastMalloc disabled. So that call to fastMalloc is actually just a call to standard system malloc, which i would guess, just by pure luck allocates adequately aligned memory. What are specific memory requirements that VirtualAlloc() fulfills and fastMalloc() does not? What can be the workaround for VirtualAlloc() on embedded platforms? Alignment -- VirtualAlloc, mmap, vm_map all produce page aligned memory (which is at least 4k aligned), and the posix_memalign version appears to actually over align memory (my following of the code makes me thinks it's requesting 64k alignment :-/ ) All of the #if branches allocateBlock will guarantee 64k alignment, which is what is required. That's with the exception of the PLATFORM(SYMBIAN) branch, which appears to be incorrect. I would expect it to lead to crashes as a result of incorrect garbage collection. Does anyone know if Symbian has an official way to get an aligned chunk of memory? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SquirrelFish Extreme for non x-86 platforms
On Dec 25, 2008, at 4:51 AM, Oliver Hunt wrote: You can manually align the memory, eg. char* memory = malloc(size + alignment - 1); memory += alignment; memory = ~(alignment - 1) return memory; The obvious problem with this is that you can't directly free the result as it will not necessarily represent the start of the allocation, but there are mechanisms for working around that (storing the initial allocation address inline in the allocation itself for instance) but there are various trade offs involved. Doing it this way would also waste memory, specifically it would allocate nearly twice the requested size for a block. (It should also work on Symbian though). --Oliver On Dec 25, 2008, at 3:14 AM, Javed Rabbani wrote: Oliver, Thanks a great deal for this explanation. I am considering running JS SquirrelFish extreme engine on an ARM-based embedded platform. You are right that posix systems should provide mmap or posix_memalign that will serve the purpose. I am concerned about this issue because in my case, there is no mmap, vm_map etc. to do the job. The only available option is to use standard memory allocation routines. What is the way out for me to deal with such a situation? Obviously, standard malloc() call from within fastMalloc() is not doing anything good for me. Regards, J R Shah ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SquirrelFish Extreme for non x-86 platforms
On Dec 25, 2008, at 4:34 PM, Maciej Stachowiak wrote: All of the #if branches allocateBlock will guarantee 64k alignment, which is what is required. That's with the exception of the PLATFORM(SYMBIAN) branch, which appears to be incorrect. I would expect it to lead to crashes as a result of incorrect garbage collection. Does anyone know if Symbian has an official way to get an aligned chunk of memory? From some cursory Google searching it appears to me you could probably get a 64k-aligned chunk of memory on Symbian using the RChunk API, specifically by creating a double-ended chunk and then adjusting its top and bottom to provide the proper size and alignment. I think someone familiar with Symbian development should fix this code properly. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] crash in WebKit.dll when debuging WinLauncher
#if USE(SAFARI_THEME) #if !defined(NDEBUG) defined(USE_DEBUG_SAFARI_THEME) SOFT_LINK_DEBUG_LIBRARY(SafariTheme) #else SOFT_LINK_LIBRARY(SafariTheme)---breaks here #endif (..\WebKitClassFactory.cpp:67 SafariThemeLibrary) First-chance exception at 0x5ec2a3a8 (WebKit.dll) in WinLauncher_debug.exe: 0xC005: Access violation writing location 0xbbadbeef. Unhandled exception at 0x5ec2a3a8 (WebKit.dll) in WinLauncher_debug.exe: 0xC005: Access violation writing location 0xbbadbeef. The program '[3856] WinLauncher_debug.exe: Native' has exited with code -1073741819 (0xc005). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] crash in WebKit.dll when debuging WinLauncher
You most likely do not have the SafarTheme.dll file in the directory of your application, OR you are missing the set of Safari Theme resources. These can be copied from the Safari instance. I believe they are held in a directory called Safari.resources or SafariTheme.resources. -Brent On Dec 25, 2008, at 8:27 PM, yin xiaobing wrote: #if USE(SAFARI_THEME) #if !defined(NDEBUG) defined(USE_DEBUG_SAFARI_THEME) SOFT_LINK_DEBUG_LIBRARY(SafariTheme) #else SOFT_LINK_LIBRARY(SafariTheme)---breaks here #endif (..\WebKitClassFactory.cpp:67 SafariThemeLibrary) First-chance exception at 0x5ec2a3a8 (WebKit.dll) in WinLauncher_debug.exe: 0xC005: Access violation writing location 0xbbadbeef. Unhandled exception at 0x5ec2a3a8 (WebKit.dll) in WinLauncher_debug.exe: 0xC005: Access violation writing location 0xbbadbeef. The program '[3856] WinLauncher_debug.exe: Native' has exited with code -1073741819 (0xc005). ___ 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] ASSERTION FAILED:stackBase
I have a problem on webkit. I have checked out webkit-r39293 and cross complie it for Xscale (one kind of ARM) Platform. When I run it on the Platform, webkit prints ASSERTION FAILED: stackBase (../../../JavaScriptCore/runtime/Collector.cpp:447 void* JSC::currentThreadStackBase()) Segmentation fault Anyone konws what is the problem and how to fixed it? PS: My ENV is : Linux 2.6 arm-linux-gcc 3.4.3 Configured with: /home/bridge/toolchain/crosstool/driscoll-sim/build/arm-linux/gcc-3.4.3-glibc-2.3.2/gcc-3.4.3/configure --target=arm-linux --host=i686-host_pc-linux-gnu --prefix=/usr/local/arm-linux --with-cpu=iwmmxt --enable-cxx-flags=-mcpu=iwmmxt --with-headers=/usr/local/arm-linux/arm-linux/include --with-local-prefix=/usr/local/arm-linux/arm-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long --without-fp Thread model: posix gcc version 3.4.3 ZOUGW ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] can i draw a url Edit by webkit API in the drawing area?
hi, i am thinking of draw components by webkit APIs, anyone knows how? thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
