Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Michael Saboff via webkit-dev]

0 
> /usr/lib/system/libsystem_malloc.dylib 
> [ 30] F32A2564-6ED1-3DB9-8987-DCF48DBB8BE1 0x0001a6764000 
> /usr/lib/system/libsystem_networkextension.dylib 
> [ 31] C6B67595-08FF-3268-A400-0C0C89F541A8 0x0001a4ddf000 
> /usr/lib/system/libsystem_notify.dylib 
> [ 32] 4593512A-A84B-3D4A-B95A-860679313411 0x0001abd4 
> /usr/lib/system/libsystem_sandbox.dylib 
> [ 33] 09FD13E7-266A-38B8-B797-EA32EDFBFB7F 0x0001ad1b6000 
> /usr/lib/system/libsystem_secinit.dylib 
> [ 34] 3DCD49B9-B3C5-3D90-BE40-A3B807CB9CD7 0x0001a1ad5000 
> /usr/lib/system/libsystem_kernel.dylib 
> [ 35] 4CF75103-429D-3AAE-BA13-2C1F67E47DBB 0x0001a1b4 
> /usr/lib/system/libsystem_platform.dylib 
> [ 36] 9F3B729A-ED04-3E65-ADAC-D75AD06EBBDC 0x0001a1b0f000 
> /usr/lib/system/libsystem_pthread.dylib 
> [ 37] FFDC0C2D-5E65-32F7-B687-99313DD7CCD0 0x0001a7fb9000 
> /usr/lib/system/libsystem_symptoms.dylib 
> [ 38] E71E8D9E-3A87-33E0-B198-31666F5A6FF1 0x0001a18ba000 
> /usr/lib/system/libsystem_trace.dylib 
> [ 39] 3C7E16C5-77E1-3F26-B016-63D485708187 0x0001ad19 
> /usr/lib/system/libunwind.dylib 
> [ 40] 413746C4-9C63-3DC4-A7C4-BBE90CF7D6B3 0x0001a1876000 
> /usr/lib/system/libxpc.dylib 
> [ 41] 871CF1B2-BA2C-385B-8F92-E41F4966C38D 0x0001a1abd000 
> /usr/lib/libc++abi.dylib 
> [ 42] 951F5871-2D10-31AC-999D-7584AD121FA6 0x0001a17a 
> /usr/lib/libobjc.A.dylib 
> [ 43] 01904D2A-57A5-3B53-8751-D6CBCA281FF3 0x0001ad19b000 
> /usr/lib/liboah.dylib 
> [ 44] E2679357-B2AF-30D4-8130-50D31765AF88 0x0001a1a56000 
> /usr/lib/libc++.1.dylib 
> [ 45] AFE750D8-70E2-3DD8-9822-4CD1285CDA39 0x0001a46be000 
> /usr/lib/libicucore.A.dylib 
> 
> Laurence
> 
> On Mar 28, 2023 at 8:13:55 AM, Michael Saboff  <mailto:msab...@apple.com>> wrote:
>> Laurence,
>> 
>> When you try to run the jsc command, are you setting DYLD_FRAMEWORK_PATH to 
>> the location of the built frameworks?  You can either set it and export it 
>> in your shell environment, e.g.
>> 
>>  % export DYLD_FRAMEWORK_PATH=/Users/lrowe/scratch/WebKit/WebKitBuild/Release
>> 
>> Or prepend the setting of it in your command string:
>> 
>>  % DYLD_FRAMEWORK_PATH=/Users/lrowe/scratch/WebKit/WebKitBuild/Release lldb 
>> ./WebKitBuild/Release/bin/jsc
>> 
>> I that doesn’t work, a backtrace at the time of the crash and the output of 
>> the lldb command “image list” would be helpful.
>> 
>> - Michael
>> 
>> 
>>> On Mar 27, 2023, at 11:11 PM, Laurence Rowe via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> Hi, I’m trying to build jsc on my M1 Mac following the instructions at 
>>> https://trac.webkit.org/wiki/JSCOnly and 
>>> https://webkit.org/getting-started/ . However when I run the built binary 
>>> it exits immediately with a bus error which lldb shows to be EXC_BAD_ACCESS.
>>> 
>>> lrowe@Laurences-MacBook-Air WebKit % git reset --hard origin/main
>>> HEAD is now at b2362a5d6b [UI-side compositing] Safari occasionally crashes 
>>> when scrolling underneath `NSScrollerImpPair` 
>>> https://bugs.webkit.org/show_bug.cgi?id=254484 rdar://107139674
>>> lrowe@Laurences-MacBook-Air WebKit % git clean -Xf
>>> lrowe@Laurences-MacBook-Air WebKit % sudo xcode-select -s 
>>> /Applications/Xcode.app/Contents/Developer
>>> lrowe@Laurences-MacBook-Air WebKit % Tools/Scripts/build-jsc --jsc-only
>>> # build log below
>>> lrowe@Laurences-MacBook-Air WebKit % ./WebKitBuild/Release/bin/jsc 
>>> zsh: bus error  ./WebKitBuild/Release/bin/jsc
>>> 
>>> lrowe@Laurences-MacBook-Air WebKit % lldb ./WebKitBuild/Release/bin/jsc
>>> (lldb) target create "./WebKitBuild/Release/bin/jsc"
>>> Current executable set to 
>>> '/Users/lrowe/scratch/WebKit/WebKitBuild/Release/bin/jsc' (arm64).
>>> (lldb) run
>>> Process 73062 launched: 
>>> '/Users/lrowe/scratch/WebKit/WebKitBuild/Release/bin/jsc' (arm64)
>>> Process 73062 stopped
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
>>> (code=2, address=0x10d5ac000)
>>> frame #0: 0x0001a1b43f78 libsystem_platform.dylib`_platform_memmove 
>>> + 168
>>> libsystem_platform.dylib`:
>>> ->  0x1a1b43f78 <+168>: stpq2, q3, [x0]
>>> 0x1a1b43f7c <+172>: subs   x2, x2, #0x40
>>> 0x1a1b43f80 <+176>: b.ls <http://b.ls/>   0x1a1b43f9c   ; 
>>> <+204>
>>> 0x1a1b43f84 <+180>: stpq0, q1, [x3]
>>> Target 0: (jsc) stopped.
>&g

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Michael Saboff via webkit-dev]

Laurence,

When you try to run the jsc command, are you setting DYLD_FRAMEWORK_PATH to the 
location of the built frameworks?  You can either set it and export it in your 
shell environment, e.g.

 % export DYLD_FRAMEWORK_PATH=/Users/lrowe/scratch/WebKit/WebKitBuild/Release

Or prepend the setting of it in your command string:

 % DYLD_FRAMEWORK_PATH=/Users/lrowe/scratch/WebKit/WebKitBuild/Release lldb 
./WebKitBuild/Release/bin/jsc

I that doesn’t work, a backtrace at the time of the crash and the output of the 
lldb command “image list” would be helpful.

- Michael


> On Mar 27, 2023, at 11:11 PM, Laurence Rowe via webkit-dev 
>  wrote:
> 
> Hi, I’m trying to build jsc on my M1 Mac following the instructions at 
> https://trac.webkit.org/wiki/JSCOnly and https://webkit.org/getting-started/ 
> . However when I run the built binary it exits immediately with a bus error 
> which lldb shows to be EXC_BAD_ACCESS.
> 
> lrowe@Laurences-MacBook-Air WebKit % git reset --hard origin/main
> HEAD is now at b2362a5d6b [UI-side compositing] Safari occasionally crashes 
> when scrolling underneath `NSScrollerImpPair` 
> https://bugs.webkit.org/show_bug.cgi?id=254484 rdar://107139674
> lrowe@Laurences-MacBook-Air WebKit % git clean -Xf
> lrowe@Laurences-MacBook-Air WebKit % sudo xcode-select -s 
> /Applications/Xcode.app/Contents/Developer
> lrowe@Laurences-MacBook-Air WebKit % Tools/Scripts/build-jsc --jsc-only
> # build log below
> lrowe@Laurences-MacBook-Air WebKit % ./WebKitBuild/Release/bin/jsc 
> zsh: bus error  ./WebKitBuild/Release/bin/jsc
> 
> lrowe@Laurences-MacBook-Air WebKit % lldb ./WebKitBuild/Release/bin/jsc
> (lldb) target create "./WebKitBuild/Release/bin/jsc"
> Current executable set to 
> '/Users/lrowe/scratch/WebKit/WebKitBuild/Release/bin/jsc' (arm64).
> (lldb) run
> Process 73062 launched: 
> '/Users/lrowe/scratch/WebKit/WebKitBuild/Release/bin/jsc' (arm64)
> Process 73062 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=2, address=0x10d5ac000)
> frame #0: 0x0001a1b43f78 libsystem_platform.dylib`_platform_memmove + 
> 168
> libsystem_platform.dylib`:
> ->  0x1a1b43f78 <+168>: stpq2, q3, [x0]
> 0x1a1b43f7c <+172>: subs   x2, x2, #0x40
> 0x1a1b43f80 <+176>: b.ls    0x1a1b43f9c   ; 
> <+204>
> 0x1a1b43f84 <+180>: stpq0, q1, [x3]
> Target 0: (jsc) stopped.
> 
> Versions:
> WebKit main (b2362a5d6b)
> Xcode 14.2 (14C18)
> macOS 13.2.1
> CMake.app 3.26.1 (not mentioned at https://webkit.org/build-tools/ but 
> required)
> 
> I’ve also tried variously with Xcode command line tools, homebrew cmake, 
> WebKit tag WebKit-7615.1.26.10.23, and adding the —debug flag to the build 
> but I see the same error.
> 
> Is there anything else I should be doing to build jsc?
> 
> Thanks,
> 
> Laurence Rowe
> 
> 
> # build log
> +  cmake --build /Users/lrowe/scratch/WebKit/WebKitBuild/Release --config 
> Release -- jsc testb3 testair testapi testmasm testdfg -j8
> [  0%] Built target JavaScriptCore_CopyHeaders
> [  1%] Built target JavaScriptCoreSharedScripts
> [  1%] Built target JSCBuiltins
> [  1%] Built target Bytecodes
> [ 35%] Built target WTF_CopyHeaders
> [ 38%] Built target bmalloc_CopyHeaders
> [ 46%] Built target bmalloc
> [ 53%] Built target WTF
> [ 53%] Built target LLIntSettingsExtractor
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o
> [ 53%] Linking CXX executable ../../bin/LLIntOffsetsExtractor
> [ 53%] Built target LLIntOffsetsExtractor
> [ 53%] Generating ../../JavaScriptCore/DerivedSources/LLIntAssembly.h
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/LowLevelInterpreterLib.dir/llint/LowLevelInterpreter.cpp.o
> [ 53%] Built target LowLevelInterpreterLib
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-f0a787a9-7.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-f0a787a9-11.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-bfc896e1-4.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-bfc896e1-3.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-bfc896e1-9.cpp.o
> [ 53%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/dfg/DFGSpeculativeJIT.cpp.o
> [ 54%] Building CXX object 
> Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/dfg/DFGSpeculativeJIT32_64.cpp.o
> [ 54%] Building CXX object 
> 

Re: [webkit-dev] Platform.h vs. makefiles

[Michael Saboff]

> On May 10, 2020, at 11:11 PM, Darin Adler  wrote:
> 
>> On May 10, 2020, at 10:07 PM, Maciej Stachowiak  wrote:
>> 
>> I think the best way to configure WebKit is to use a separate data file, 
>> neither a header nor a makefile or similar, that defines the options in a 
>> single place with clear syntax. Then everything else is generated from that. 
>> Such a system could cover runtime flags as well, which are even more 
>> scattered around the project than compile-time flags.
> 
> Sounds OK. I worry a little about defining yet another language, but 
> otherwise I do find this appealing. Perhaps some people would say that 
> FeatureDefines.props from cmake could be that file?
> 
> Not sure literally a single data file is the best way to do this across 
> multiple platforms/ports. I think PlatformEnableCocoa.h shows us that 
> breaking this down can be helpful.
> 
> One file that has the master list of all the settings, and all the default 
> values. Then other files that contain overlays for each port/configuration 
> where they are different from the default.
> 
> My worry is that it could become complicated, like our TestExpectations 
> files, which were once simple.

One challenge with a data file approach is that all build systems need to be 
aware that it is the root dependency for most targets.  As such I don’t think 
it make sense to invent a new format, but to possibly refine the 
PlatformEnable*.h hierarchy.  Perhaps a new PlatformOverrides.h file that would 
only contain the overrides while the current PlatformEnable*.h contain the 
defaults.

>> Moving logic from build files to the header is probably a move in the right 
>> direction, though of course it carries risk, particularly for less tested 
>> configurations.
> 
> Yes, I’m not suggesting rushing to do it all at once in a mass change.
> 
> But for new things especially on Apple’s Cocoa platforms, I’d like to avoid 
> FeatureDefines.xcconfig and see new things in the PlatformEnableCocoa.h 
> header file instead. Unless the defines need to affect the build system and 
> not just the C++ code, I think the header file is superior.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Offline Assembler build step always computes hashes even when nothing changes

[Michael Saboff]

Darin,

I can take a look at this.

Filed > “Offline assembler always 
computes hashes even when nothing changes"

- Michael

> On Sep 16, 2018, at 4:03 PM, Darin Adler  > wrote:
> 
> I noticed that the “Offline Assembler” build step was taking between 5 and 30 
> seconds every time I build. Really stands out in incremental builds. I 
> realized that this step does not do any dependency analysis. Every time, it 
> builds a hash of the input to see if it needs to recompute the assembly.
> 
> That’s probably not the best pattern; normally we like to use file 
> modification dates to avoid doing any work when files haven’t changed.
> 
> Is there someone who can help me fix this so we get faster incremental builds?
> 
> — Darin
> ___
> 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] Proposal: Do not support Windows fibers

[Michael Saboff]

Here is the reply from iTunes for the WebKit-Dev list

- Michael

——

From an iTunes perspective, WebKit can eliminate any remaining Windows Fiber 
API support.

iTunes still uses some cooperative threading, but implements its own mechanism 
on top of regular preemptive Windows threads. And we believe we've fixed all 
occurrences of calling WebKit/JSC from our non-main cooperative threads.

- John

> On Dec 5, 2017, at 10:26 AM, Michael Saboff <msab...@apple.com> wrote:
> 
> [Bringing John Lehner from the iTunes team into the discussion]
> 
> Last I knew, the iTunes team uses fibers.  IIRC, the thread they use to call 
> into WebKit/JSC only has one fiber, other parts of the app use multiple 
> fibers on one thread but don’t have JS objects active in those threads / 
> fibers.
> 
> John, have things changed for iTunes on Windows such that we can eliminate 
> support for fibers?
> 
> - Michael
> 
>> On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa <rn...@webkit.org 
>> <mailto:rn...@webkit.org>> wrote:
>> 
>> Yeah, I don't think there is much need to support fibers. With features like 
>> web workers, supporting fibers doesn't make much sense.
>> 
>> - R. Niwa
>> 
>> On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI <utatane@gmail.com 
>> <mailto:utatane@gmail.com>> wrote:
>> Hi, Webkittens,
>> 
>> I would like to make sure OR declare that WebKit does not support Windows 
>> fibers.
>> While fiber related functions are used in WTF, I believe that it is because 
>> fiber local storage (FLS) can have destructors. And it is not intended to 
>> support fibers explicitly.
>> 
>> Actually, I believe the current WebKit does not work well with Windows 
>> fibers right now.
>> For example, our JSC GC is conservative for stack and registers. It means 
>> that GC needs to scan stack and registers to gather conservative roots. But 
>> if your fiber is not executed at that time, JSC GC will miss to scan the 
>> stack and registers of those inactive fibers. As a result, managed objects 
>> will be collected if it is only referenced from the roots in the inactive 
>> fibers.
>> 
>> And I think we can potentially improve performance of our TLS by using 
>> thread_local implementation in VC++ instead of using FLS. FLS is slow and it 
>> causes some problems[1]. I'm not sure the performance characteristics and 
>> implementation details of thread_local in VC++, but it's worth checking.
>> 
>> So, I think we should not support Windows fibers. I would like to hear 
>> opinions about it.
>> 
>> [1]: https://bugs.webkit.org/show_bug.cgi?id=146448 
>> <https://bugs.webkit.org/show_bug.cgi?id=146448>
>> 
>> Best regards,
>> Yusuke Suzuki
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto: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] Proposal: Do not support Windows fibers

[Michael Saboff]

[Bringing John Lehner from the iTunes team into the discussion]

Last I knew, the iTunes team uses fibers.  IIRC, the thread they use to call 
into WebKit/JSC only has one fiber, other parts of the app use multiple fibers 
on one thread but don’t have JS objects active in those threads / fibers.

John, have things changed for iTunes on Windows such that we can eliminate 
support for fibers?

- Michael

> On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa  wrote:
> 
> Yeah, I don't think there is much need to support fibers. With features like 
> web workers, supporting fibers doesn't make much sense.
> 
> - R. Niwa
> 
> On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI  > wrote:
> Hi, Webkittens,
> 
> I would like to make sure OR declare that WebKit does not support Windows 
> fibers.
> While fiber related functions are used in WTF, I believe that it is because 
> fiber local storage (FLS) can have destructors. And it is not intended to 
> support fibers explicitly.
> 
> Actually, I believe the current WebKit does not work well with Windows fibers 
> right now.
> For example, our JSC GC is conservative for stack and registers. It means 
> that GC needs to scan stack and registers to gather conservative roots. But 
> if your fiber is not executed at that time, JSC GC will miss to scan the 
> stack and registers of those inactive fibers. As a result, managed objects 
> will be collected if it is only referenced from the roots in the inactive 
> fibers.
> 
> And I think we can potentially improve performance of our TLS by using 
> thread_local implementation in VC++ instead of using FLS. FLS is slow and it 
> causes some problems[1]. I'm not sure the performance characteristics and 
> implementation details of thread_local in VC++, but it's worth checking.
> 
> So, I think we should not support Windows fibers. I would like to hear 
> opinions about it.
> 
> [1]: https://bugs.webkit.org/show_bug.cgi?id=146448 
> 
> 
> Best regards,
> Yusuke Suzuki
> 
> ___
> 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] Building WebKit for an iOS device

[Michael Saboff]

I’ll add a little to Alex’s comments.

I doubt you could build all of WebKit with the public iOS SDK.  You certainly 
can’t sign JavaScriptCore to use JIT memory.  Even if could build WebKit and 
statically linked your code with what you built, there will likely be some 
mismatch between the WebKit you built and the System frameworks that WebKit 
links against, such as UIKit, that will cause your app to crash on startup.

- Michael

> On Jul 12, 2017, at 10:19 AM, Alex Christensen  wrote:
> 
> WebKit can be built and run on the iOS simulator by anyone with the public 
> iOS SDK.  I use 
> https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ 
>  when I 
> forget how to do this.
> 
> I guess WebKit can be built for device, but I’m pretty sure WebKit cannot be 
> put as the system framework on an iOS device without Apple-internal tools.  
> With a lot of work you might be able to statically link everything into a 
> custom app for local debugging, but I’m pretty sure such an app would be 
> rejected by the App Store based on section 2.5.6 of 
> https://developer.apple.com/app-store/review/guidelines/ 
> 
> 
>> On Jul 12, 2017, at 8:31 AM, Frédéric WANG > > wrote:
>> 
>> Hello,
>> 
>> For development and testing purpose, I was wondering if there is a way
>> to produce a build of WebKit/Safari-mobile and to install it on a device
>> (instead of using the iOS simulator)? And is there any specific
>> requirement like having an Apple developer license and a registered device?
>> 
>> I know that we have a builder [1] and I just noticed the "--ios-device"
>> parameter for the build-webkit script but I can't find any information
>> on the official documentation [2] or on the WebKit wiki. I also tried
>> searching this mailing list about the topic but could not find any
>> relevant thread.
>> 
>> Thanks,
>> 
>> Frédéric
>> 
>> [1] https://build.webkit.org/builders/Apple%20iOS%2010%20Release%20(Build) 
>> 
>> [2] https://webkit.org/building-webkit/ 
>> 
>> 
>> ___
>> 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] Stack Alignment error in LLINT

[Michael Saboff]

Rodney,

JavaScriptCore assumes that the stack is 16 byte aligned.  This may be more 
restrictive than some OS / ABIs, but there is code to pad appropriately for 
some platforms. You didn’t say what OS you are running on, but maybe there 
needs to be a code added for your OS.  Turning on C++ exceptions could be 
responsible, as that could be changing stack layout.  I don’t know of any 
platform that turns on C++ exceptions, so you may be in uncharted waters.

Your build is 2 months old, the current revision is 187434.  You could also try 
a more recent build.

- Michael

 On Jul 27, 2015, at 8:07 AM, Rodney Dowdall rdowd...@cranksoftware.com 
 wrote:
 
 Hello
 
 I am seeing a SIGTRAP generated in the LLINT code when I try and load up a 
 page.  It happens as soon as the page tries to execute JavaScript.  The 
 target is an 32 bit x86 machine.  The SIGTRAP appears to happen when it is 
 checking the stack alignment.  I have tried compiling the code with the gcc 
 option -mstackrealign and without it.  The SIGTRAP is generated in the same 
 spot with or without the option.  C++ exceptions are turned on (they have to 
 be with this particular compiler.  The compiler is gcc based).  The version 
 of Webkit that I am building from is 184845.
 
 
 Here is the assembly execution that causes the SIGTRAP:
 
  vmEntryToJavaScript:
 b9a80ef7:   push %ebp
 b9a80ef8:   mov %esp,%ebp
 b9a80efa:   push %esi
 b9a80efb:   push %edi
 b9a80efc:   push %ebx
 b9a80efd:   mov 0xc(%ebp),%ebx
 b9a80f00:   mov 0x8(%ebp),%edi
 b9a80f03:   mov %ebp,%esp
 b9a80f05:   sub $0x20,%esp
 b9a80f08:   mov %ebx,(%esp)
 b9a80f0b:   mov 0x1498(%ebx),%edx
 b9a80f11:   mov %edx,0x4(%esp)
 b9a80f15:   mov 0x1494(%ebx),%edx
 b9a80f1b:   mov %edx,0x8(%esp)
 b9a80f1f:   mov 0x10(%ebp),%esi
 b9a80f22:   mov 0x20(%esi),%edx
 b9a80f25:   add $0x4,%edx
 b9a80f28:   shl $0x3,%edx
 b9a80f2b:   mov %esp,%eax
 b9a80f2d:   sub %edx,%eax
 b9a80f2f:   cmp 0x2384(%ebx),%eax
 b9a80f35:   jae 0xb9a80f71 vmEntryToJavaScript+122
 
 b9a80f71:   mov %eax,%esp
 b9a80f73:   mov $0x4,%eax
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f9e:   sub $0x1,%ecx
 b9a80fa1:   movl $0xfffc,0x2c(%esp,%ecx,8)
 b9a80fa9:   movl $0x0,0x28(%esp,%ecx,8)
 b9a80fb1:   cmp %ecx,%edx
 b9a80fb3:   jne 0xb9a80f9e vmEntryToJavaScript+167
 b9a80fb5:   mov 0x28(%esi),%eax
 b9a80fb8:   test %edx,%edx
 b9a80fba:   je 0xb9a80fd0 vmEntryToJavaScript+217
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 b9a80f8e:   mov 0x10(%esi),%edx
 b9a80f91:   sub $0x1,%edx
 b9a80f94:   mov 0x20(%esi),%ecx
 b9a80f97:   sub $0x1,%ecx
 b9a80f9a:   cmp %ecx,%edx
 b9a80f9c:   je 0xb9a80fb5 vmEntryToJavaScript+190
 
 b9a80fd0:   mov %esp,0x1498(%ebx)
 b9a80fd6:   mov %ebp,0x1494(%ebx)
 b9a80fdc:   add $0x8,%esp
 b9a80fdf:   mov %esp,%ecx
 b9a80fe1:   and $0xf,%ecx
 b9a80fe4:   test %ecx,%ecx
 b9a80fe6:   je 0xb9a80fee vmEntryToJavaScript+247
 b9a80fe8:   mov $0xbad0dc02,%ecx
 b9a80fed:   int3
 
 So using the LLintAssembly.h I tracked this too:
 
\tjz  
 LOCAL_LABEL_STRING(_offlineasm_doVMEntry__makeCall__checkStackPointerAlignment__stackPointerOkay
 
 Which leads me to believe that the alignment on my stack is wrong. The value 
 of esp is 0x7db9284.  The value of ecx after the and is 4, so that looks 
 right.
 
 I don't have a lot of experience with the LLINT, so I was wondering if there 
 was a specific place I should start to look to see why this error is beign 
 generated.
 
 Thanks,
 Rodney
 
 ___
 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] Stack Alignment error in LLINT

[Michael Saboff]

Rodney,

The “align the stack” code for 32 bit platforms is found in 
Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm 
(http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm)
 beginning at line 218.  There isn’t an if / elsif for Linux or QNX.  This 
stack aligning code is at the top of the code that I think is generating your 
SIGTRAP.  Unfortunately I don’t think that the offline assembler that 
“assembles” the LLINT code has an OS specific type for X86 QNX.  You can try 
locally in your build adding “or X86” to the end of the “if X86_WIN” to see if 
that takes care of your issue.

It would also be interesting to know if Linux build with exceptions has the 
problem as well.

- Michael

 On Jul 27, 2015, at 8:50 AM, Rodney Dowdall rdowd...@cranksoftware.com 
 wrote:
 
 Thanks for the response Michael.  Where does the code that does the padding 
 live?  It may be that I need to add something in there.  I can try changing 
 what the stack alignment should be, but from what I understand the QNX OS 
 should align to 16.  Maybe it is the exceptions that are causing the problem. 
  I could try building a 32 bit Linux build with exceptions on to see if I get 
 the same problem.
 
 Regards,
 Rodney
 
 On 07/27/2015 11:24 AM, Michael Saboff wrote:
 Rodney,
 
 JavaScriptCore assumes that the stack is 16 byte aligned.  This may be more 
 restrictive than some OS / ABIs, but there is code to pad appropriately for 
 some platforms. You didn’t say what OS you are running on, but maybe there 
 needs to be a code added for your OS.  Turning on C++ exceptions could be 
 responsible, as that could be changing stack layout.  I don’t know of any 
 platform that turns on C++ exceptions, so you may be in uncharted waters.
 
 Your build is 2 months old, the current revision is 187434.  You could also 
 try a more recent build.
 
 - Michael
 
 On Jul 27, 2015, at 8:07 AM, Rodney Dowdall rdowd...@cranksoftware.com 
 wrote:
 
 Hello
 
 I am seeing a SIGTRAP generated in the LLINT code when I try and load up a 
 page.  It happens as soon as the page tries to execute JavaScript.  The 
 target is an 32 bit x86 machine.  The SIGTRAP appears to happen when it is 
 checking the stack alignment.  I have tried compiling the code with the gcc 
 option -mstackrealign and without it.  The SIGTRAP is generated in the same 
 spot with or without the option.  C++ exceptions are turned on (they have 
 to be with this particular compiler.  The compiler is gcc based).  The 
 version of Webkit that I am building from is 184845.
 
 
 Here is the assembly execution that causes the SIGTRAP:
 
  vmEntryToJavaScript:
 b9a80ef7:   push %ebp
 b9a80ef8:   mov %esp,%ebp
 b9a80efa:   push %esi
 b9a80efb:   push %edi
 b9a80efc:   push %ebx
 b9a80efd:   mov 0xc(%ebp),%ebx
 b9a80f00:   mov 0x8(%ebp),%edi
 b9a80f03:   mov %ebp,%esp
 b9a80f05:   sub $0x20,%esp
 b9a80f08:   mov %ebx,(%esp)
 b9a80f0b:   mov 0x1498(%ebx),%edx
 b9a80f11:   mov %edx,0x4(%esp)
 b9a80f15:   mov 0x1494(%ebx),%edx
 b9a80f1b:   mov %edx,0x8(%esp)
 b9a80f1f:   mov 0x10(%ebp),%esi
 b9a80f22:   mov 0x20(%esi),%edx
 b9a80f25:   add $0x4,%edx
 b9a80f28:   shl $0x3,%edx
 b9a80f2b:   mov %esp,%eax
 b9a80f2d:   sub %edx,%eax
 b9a80f2f:   cmp 0x2384(%ebx),%eax
 b9a80f35:   jae 0xb9a80f71 vmEntryToJavaScript+122
 
 b9a80f71:   mov %eax,%esp
 b9a80f73:   mov $0x4,%eax
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f9e:   sub $0x1,%ecx
 b9a80fa1:   movl $0xfffc,0x2c(%esp,%ecx,8)
 b9a80fa9:   movl $0x0,0x28(%esp,%ecx,8)
 b9a80fb1:   cmp %ecx,%edx
 b9a80fb3:   jne 0xb9a80f9e vmEntryToJavaScript+167
 b9a80fb5:   mov 0x28(%esi),%eax
 b9a80fb8:   test %edx,%edx
 b9a80fba:   je 0xb9a80fd0 vmEntryToJavaScript+217
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 
 b9a80f78:   sub $0x1,%eax
 b9a80f7b:   mov 0x4(%esi,%eax,8),%ecx
 b9a80f7f:   mov %ecx,0xc(%esp,%eax,8)
 b9a80f83:   mov (%esi,%eax,8),%ecx
 b9a80f86:   mov %ecx,0x8(%esp,%eax,8)
 b9a80f8a:   test %eax,%eax
 b9a80f8c:   jne 0xb9a80f78 vmEntryToJavaScript+129
 b9a80f8e:   mov 0x10(%esi),%edx
 b9a80f91:   sub $0x1,%edx
 b9a80f94:   mov 0x20(%esi),%ecx
 b9a80f97:   sub $0x1,%ecx
 b9a80f9a:   cmp %ecx,%edx
 b9a80f9c:   je 0xb9a80fb5 vmEntryToJavaScript+190
 
 b9a80fd0:   mov %esp,0x1498(%ebx)
 b9a80fd6:   mov

Re: [webkit-dev] Tagged assertions...

[Michael Saboff]

This will add a step that developers will have to remember when changing an 
ASSERT.  There may be developers that want to knowingly keep the same tag.  
What about creating my own tag values?  How will we guard against reusing a tag?

So what would be an appropriate tag for an ASSERT in a templated class that is 
in a .h file?  An example would be the at() method in Vector.h:
T at(Checkedsize_t i)
{
RELEASE_ASSERT(i  size());
return Base::buffer()[i];
}
I question having hundreds of ASSERTs in the code all with the same tag 
provides any benefit.  These identically tagged ASSERTs are for guarding 
against unrelated out-of-bounds access checks.

If you say that we aren’t going to handle RELEASE_ASSERTs, these are the 
asserts that developers have said are the most important, in that we want to 
assert in a production build.  In fact you might have an argument for tagging 
RELEASE_ASSERTs if we think it would improve debugging post release crashes.

- Michael

 On Nov 6, 2014, at 12:34 PM, Said Abou-Hallawa sabouhall...@apple.com wrote:
 
 When the logical expression in the ASSERT is changed, you should do the 
 following:
 
 -   ASSERT_TAG(condition, “abcde”);
 +  ASSERT(new_condition);
 
 Then the pre-build tagging tool will generate a new tag for the new assertion:
 
 +  ASSERT(new_condition, “fghij”);
 
 So the assertions do not get messed up with Bugzailla.
 
 The pre-build tool runs periodically only on Bot, maybe once every day and 
 only on the touched files since it was last run.  Then it commits only the 
 changed files because of tagging.  This should not add much to the build 
 process.
 
 Both ASSERT and ASSERT_TAG should be supported.  Since the developer should 
 only add ASSERT and leave the tagging for the pre-build tagging tool.
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using OfflineAsm

[Michael Saboff]

Christopher,

Let me add a little to Phil’s comments.

As Phil says, you shouldn’t expect much if any performance gain going from the 
C LOOP to one of the assembler back ends if you also don’t plan on enabling 
JITs.

The architectures / OS combinations that work with the LLInt is nearly the same 
as what is supported by the baseline JIT.  Basically X86 (32  64), ARM 
(traditional, thumb2 and 64) and to a lessor degree MIPS and SH4.  These work 
as appropriate on Mac OS X, Windows, Linux, iOS and a couple other OSes.  If 
you have a processor and/or OS, or combination of the two that is not 
supported, it will likely require work in the offline assembler and / or LLInt 
code for it to work.  The effort is probably won’t payoff unless you plan on 
eventually supporting one or more of the JITs.

What processor(s) and OS(es) are you targeting?

- Michael

On Sep 5, 2014, at 3:47 PM, Filip Pizlo fpi...@apple.com wrote:

 
 
 On Sep 5, 2014, at 3:23 PM, Vienneau, Christopher cvienn...@ea.com wrote:
 
 Hello,
  
 I’m looking for some information about the Java script interpreter ASM 
 backend, aka OfflineAsm.  
  
 First a bit of background information; the code I have been using is about a 
 year old, on several platforms we don’t run with JIT and won’t be able to 
 enable it.  This means that we’ve been using the LLINT_C_LOOP path in these 
 cases.  It was considered that the ASM backend may be able to improve 
 performance in this case, currently I’m taking a look at how things are done 
 in a more recent snapshot of the trunk to be sure this development effort 
 will be going in the right direction on what is done there.  As a side note 
 I see that LLINT_C_LOOP has been replaced with #if !ENABLE(JIT) which I 
 guess is pretty much how it has always behaved.
  
 So my questions are:
 1)  How is the ASM backend intended to be used?
 
 As a bottom tier for a mixed mode execution VM. We compile to assembly to be 
 able to get an ABI that is compatible with our JITs and to be able to do OSR. 
 
 Is there a doc that covers this?
 
 No. 
 
 2)  Can I essentially move from the “C LOOP” to neither “C LOOP” nor 
 “JIT”? or is the ASM backend dependent on JIT itself?  
 
 You should be able to use the asm backend without the JIT. We do this if we 
 compiled with the JIT but we failed to allocate writable+executable memory at 
 run time. With some hacks you could probably compile webkit to always do 
 this. 
 
 It appears this would be handled by the defines in 
 Source\JavaScriptCore\llint\LLIntOfflineAsmConfig.h
 3)  If JIT is expected to use the ASM backend is there a way this can be 
 worked around?
 
 The JIT doesn't use offlineasm.
 
 4)  Should I actually expect a performance increase compared to the “C 
 LOOP”?
 
 Not really, unless your C compiler sucks. 
 
 5)  Are there any other suggestions on how to improve performance of 
 Java script code in a non-JIT port?
 
 Not really but contributions are welcome. 
 
  
 Thanks for any feedback
  
 Chris Vienneau
 ___
 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] lldb scripted command for JavaScript backtrace

[Michael Saboff]

A new python scripted javascript backtrace command and supporting C++ code now 
exists starting with change set r170432.  This is only for lldb and may be 
replaced in the future when a JIT interface is made available for lldb.  The 
new command is btjs and it can take an optional frame count, just like the bt 
command.  To use the new JavaScript enabled backtrace, import 
Tools/lldb/lldb_webkit.py with the command:
(lldb) command script import ../OpenSource/Tools/lldb/lldb_webkit.py
You can make bt an alias to btjs with the lldb command:
(lldb) command alias bt btjs
These commands can be added to your ~/.lldbinit file so they are available for 
every lldb session.

Here is a comparison of the builtin “bt” with the scripted “btjs”:

(lldb) bt
* thread #1: tid = 0x18b67e, 0x0001004df3b4 
JavaScriptCore`JSC::genericUnwind(vm=0x00010280, 
callFrame=0x7fff5fbfdf00, exceptionValue=JSValue at 0x7fff5fbfde68) + 
20 at JITExceptions.cpp:45, queue = 'com.apple.main-thread, stop reason = 
breakpoint 1.1
frame #0: 0x0001004df3b4 
JavaScriptCore`JSC::genericUnwind(vm=0x00010280, 
callFrame=0x7fff5fbfdf00, exceptionValue=JSValue at 0x7fff5fbfde68) + 
20 at JITExceptions.cpp:45
frame #1: 0x00010063c35a 
JavaScriptCore`llint_slow_path_handle_exception(exec=0x7fff5fbfdf00, 
pc=0x000101e00100) + 170 at LLIntSlowPaths.cpp:1390
frame #2: 0x000100645d77 JavaScriptCore`llint_entry + 18661
frame #3: 0x2cbc7c804595
frame #4: 0x000100647a4f JavaScriptCore`llint_entry + 26045
frame #5: 0x00010064122a JavaScriptCore`callToJavaScript + 346

(lldb) btjs
* thread #1: tid = 0x18b67e, 0x0001004df3b4, queue = 
'com.apple.main-thread, stop reason = breakpoint 1.1
frame #0: 0x0001004df3b4 
JavaScriptCore`JSC::genericUnwind(vm=0x00010280, 
callFrame=0x7fff5fbfdf00, exceptionValue=JSValue at 0x7fff5fbfde68) + 
20 at JITExceptions.cpp:45
frame #1: 0x00010063c35a 
JavaScriptCore`llint_slow_path_handle_exception(exec=0x7fff5fbfdf00, 
pc=0x000101e00100) + 170 at LLIntSlowPaths.cpp:1390
frame #2: 0x000100645d77 #BXj6qv [LLInt](Undefined)
frame #3: 0x2cbc7c804595 bar#DHjEHv [DFG](Cell[global ID: 359]: 
0x1030df970, Cell[Function ID: 36]: 0x1033b94b0)
frame #4: 0x000100647a4f global#BMvYzp [LLInt](Cell[JSProxy ID: 322]: 
0x1030ffb90)
frame #5: 0x00010064122a JavaScriptCore`callToJavaScript + 346

- Michael___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging back the jsCStack branch

[Michael Saboff]

The branch has been merged back to trunk in change set r163027: 
http://trac.webkit.org/changeset/163027.

- Michael

On Jan 27, 2014, at 6:00 PM, mhahnenb...@apple.com wrote:

 Hello WebKitters,
 
 The JavaScriptCore team is planning on merging back our temporary development 
 branch (at http://trac.webkit.org/browser/branches/jsCStack) that we’ve been 
 working on for the past couple of months.
 
 The primary features that this branch will bring to trunk are:
 
 (1) JavaScript code in JavaScriptCore now runs exclusively on the C stack. 
 Previously JavaScriptCore made use of the C stack only for calls into its C++ 
 runtime, and it used a separate custom stack data structure for execution of 
 compiled JavaScript code. Now it’s all C stack all the time. This work was 
 primarily in support of the next feature...
 
 (2) More FTL goodness. The FTL already existed in trunk, but the most recent 
 bleeding edge work has been done on the branch since that work depended on 
 the other C-stack-related work. It will still be behind #ifdefs, and it won’t 
 be compiled by default.
 
 The plan is to merge back early tomorrow morning so that if there are any 
 major issues they won’t cause any significant impact. I’ll be available via 
 IRC and email to help with any problems. Let me know if this plan doesn’t 
 work for you.
 
 Thanks!
 -Mark
 ___
 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] JavaScriptCore Merge of C Stack Work

[Michael Saboff]

The JavaScriptCore team at Apple has been doing work on a branch 
(http://svn.webkit.org/repository/webkit/branches/jsCStack) to move JavaScript 
processing to use the native C stack for all engines (LLInt, Baseline JIT, DFG 
JIT, and the new FTL JIT).  We are in the end stages of merging the work of 
that branch to trunk (tracked in 
https://bugs.webkit.org/show_bug.cgi?id=127763).  When this merge is complete 
and the patch is landed, ports that use the LLInt and/or any JIT will use the 
native call-return stack to make calls to/from JavaScript.  The LLINT C-Loop 
will be the only code that uses the separate JSStack, and only while in the 
C-Loop.

We are relying on the EWS bots to test ports that we can’t test directly.  
There are some ports where there aren’t any EWS bots (SH4 and MIPS).  Although 
we have made what we think are the correct changes for all ports, the changes 
for those we can’t test are speculative at best.

Obviously, if there are any issues we will support the work of others to get 
the ports they support working.

- Michael Saboff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Michael Saboff]

On Jan 3, 2014, at 11:28 AM, Geoffrey Garen gga...@apple.com wrote:

 However I also feel the harm here is debatable enough that people working 
 on/reviewing the code should make decisions instead of there being a project 
 level dictate. It is a new thing, the appropriate usage hasn't yet settled 
 and people should be allowed to experiment.
 
 The experiment has been going on for some time now. We have over 1000 unique 
 uses of “auto” in the codebase. I think it’s time to clarify and collect what 
 we’ve learned.
 
 One reason I’m eager to produce a guideline is the patches I’ve seen Andreas 
 writing. A whole new kind of pointer in one of the most error-prone pointer 
 areas of our codebase (as measured by security exploits) deserves a clear 
 guideline for readability and understandability.
 
 Note that a coding style guideline does not prevent reviewers from exercising 
 good judgement — either by accepting or rejecting an edge case, or by 
 proposing a modification to the guidelines. 
 
 I'm not sure how much rules we really need beyond use 'auto' when it 
 improves code. I gather from this thread that especially people working on 
 JSC are not comfortable using it so they shouldn’t.
 
 I strongly object to varying coding style arbitrarily based on author or 
 project file. That's a recipe for an unreadable polyglot codebase.
 
 It’s very common for WebKit engineers to work across different pieces of the 
 engine, and that is a strength in our project that I’d like to preserve and 
 extend.
 
 If we start making rules I'd add the following:
 
 - Use auto when the type name is already mentioned on a line:
 
 Agreed.
 
 auto cell = toRenderTableCell(*renderer); // right
 RenderTableCell cell = toRenderTableCell(*renderer);  // wrong
 
 Not sure.
 
 These lines of code do not include a verbatim type name, and so they are not 
 friendly to cmd-click/select-and-search. Changing the function signature to 
 “toRenderTableCell”, or something like that, might help.
 
 There seems to be consensus that “auto cell = 
 *static_castRenderTableCell*(renderer)” would be correct — setting aside 
 the fact that we usually don’t cast like that in the render tree.
 
 for (auto source : descendantsOfTypeHTMLSourceElement(*this)) // right
 for (const HTMLSourceElement source : 
 descendantsOfTypeHTMLSourceElement(*this)) // wrong
 
 OK.
 
 auto properties = std::make_uniquePropertiesVector();  //right
 std::unique_ptrPropertiesVector properties = 
 std::make_uniquePropertiesVector(); //wrong
 
 OK.
 
 This rule is already widely deployed and I think the code readability has 
 improved.
 
 Agreed. I especially liked reading auto buffer = 
 std::make_uniqueUniChar[](length)” when I found it. It’s a shame that mutex 
 types and other unmovable types can’t work this way.
 
 - Use auto when the type is irrelevant. This covers things like iterators 
 and adapter classes:
 
 auto sourceDescendants = descendantsOfTypeHTMLSourceElement (*this));
 
 I’m not sure what you mean by type being irrelevant. I’d want to make a list 
 of examples where we think type is or is not relevant.
 
 For example, one could argue that type is irrelevant for any pointer-style 
 class, since you just use “-” and “*”, which work for any pointer-style 
 classes, and the name conveys the interface. But I disagree. The pointer type 
 conveys the lifetime and passing semantics, and those are essential, and need 
 to be called out.
 
 - Use auto when type is obvious for people with basic familiarity with a 
 subsystem:
 
 auto style = renderer.style();
 
 I don’t like this. I want code to be clear even to folks who are not super 
 familiar.
 
 For example, recently, Michael had to fix a buffer overrun bug in low-level 
 render tree / image code, simply because the ultimate consequence was a crash 
 in JIT code. I won’t speak for Michael’s specific coding style preferences, 
 but I will say that in general we need to keep our code accessible even to 
 unfamiliar folks in order to accommodate work like that.

I think you are referring to rdar://problem/13207901 Improper copying of 
image data in ImageBufferData::getData cause crash in fastMalloc below 
JSC::FunctionBodyNode::finishParsing. That was a fun bug to track down!  This 
was a malloc overrun where the allocation site did some math with one set of 
width and height and the use site used different width and height value for 
writing to the buffer.  The root of this issue could have been prevented with 
better local variable names.  For example, there was some confusion between 
width and destw.  Looking back, several local variable name were not 
descriptive enough.  t think the code was eliminated shortly after the fix I 
did went in so it is no longer an issue.

Back to the “auto discussion, I have been following closely and like where we 
are heading.  The use of auto should make the code easier to read.  If we have 
to rely on a tools to find the type, then we should use the type and not auto.  

[webkit-dev] JavaScript Stack Changes

[Michael Saboff]

We have been making changes to the JavaScript native stack layout in order to 
align the layout more closely with native C/C++ stack layout. This is being 
done as part of integrating LLVM as a back-end for the FTL JIT.  This is being 
tracked with the umbrella bug https://bugs.webkit.org/show_bug.cgi?id=116888.

We have already changed the stack direction from growing up in address to 
growing down.  We are in the process of changing calls from JavaScript to C 
helpers to be compliant with native calling conventions by changing calls using 
JITStubCall.h to use CCallHelpers.h (tracked with 
https://bugs.webkit.org/show_bug.cgi?id=122287).  Other tasks that remain are 
to rearrange the layout of JSStack so that the CallerFrame and ReturnPC frame 
location are consistent with native C stack conventions, using the native stack 
pointer register instead of reserving our own register, and modifying the 
thunks used to invoke JavaScript from C/C++ code.

The JavaScript team at Apple will make and test the changes to support X86 and 
X86_64 for Mac OS X and Windows, and ARM Thumb 2.  We will likely make 
speculative changes for the other ports (ARM Traditional, MIPS and SH4), but 
have no means to test those changes. If you maintain the processor specific 
JavaScript code for one of those ports, send me a reply so we can coordinate 
changes to minimize breakage.

- Michael Saboff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] LLInt alignment problem on ARM

[Michael Saboff]

I’m wondering if the alignment is the traditional ARM vs Thumb 2.  The movw 
after lint_begin with hex  0xe30b3eef is a Thumb 2 instruction.

- Michael

On Sep 26, 2013, at 9:24 AM, Oliver Hunt oli...@apple.com wrote:

 I believe that there’s a mnemonic that forces alignment that we could 
 (arguably should?) be using before these labels.
 
 IIRC it’s something like .align N — if we aren’t doing this already we could 
 make the lint assembler backend emit a .align 16 prior to each global symbol.
 
 —Oliver
 
 On Sep 26, 2013, at 1:09 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu wrote:
 
 Hello!
 
 I'm fighting with a strange LLInt alignment problem on ARM. As I see we put 
 the LLInt code into .rodata section instead of .text.
 Is there a specific reason why we are doing this? If there is not I would 
 put them to the .text section.
 
 Here is the objdump:
 
 ./Source/JavaScriptCore/.obj/release-shared/llint/LowLevelInterpreter.o: 
 file format elf32-littlearm
 
 Disassembly of section .rodata:
 
  _ZStL19piecewise_construct:
  0:   andeq   r0, r0, r0
 
 0004 _ZStL13allocator_arg:
  4:   andeq   r0, r0, r0
 
 0008 _ZStL6ignore:
   ...
 
 0009 llint_begin:
  9:   e30b3eefmovwr3, #48879  ; 0xbeef
  d:   e34b3badmovtr3, #48045  ; 0xbbad
 11:   e583str r0, [r3]
 15:   e3a0mov r0, #0
 19:   e12fff30blx r0
 
 001d llint_program_prologue:
 1d:   e1a0200emov r2, lr
 21:   e5852010str r2, [r5, #16]
 25:   e5951008ldr r1, [r5, #8]
 ...
 
 
 The problem is that these traditional instructions are lying on odd adresses 
 in the .rodata section.
 
 Regards,
 Gabor
 
 ___
 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] Instrumenting the LLint interpreter

[Michael Saboff]

The LLint is used to execute Javascript the first time a function is run.  If 
code is executed multiple times, the baseline JIT will come into play.  For 
Javascript that executes once or very few times, only the LLint is used.

- Michael

On Jul 11, 2013, at 12:51 AM, Abhishek Bichhawat 
abhishek_bichha...@yahoo.co.in wrote:

 Thanks Filip.
 Is it the case that the LLInt would be used in applications? Or it is just 
 going to be confined to the JIT opcodes?
 
 Thanks and Regards,
 Abhishek
 
 From: Filip Pizlo fpi...@apple.com
 To: Abhishek Bichhawat abhishek_bichha...@yahoo.co.in 
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org 
 Sent: Wednesday, 10 July 2013 4:31 PM
 Subject: Re: [webkit-dev] Instrumenting the LLint interpreter
 
 It is possible to edit the LLInt and make it behave differently. 
 
 -Filip
 
 On Jul 10, 2013, at 2:22 AM, Abhishek Bichhawat 
 abhishek_bichha...@yahoo.co.in wrote:
 
 Hi,
 
 With the classical interpreter being put off, is it possible to instrument 
 the llint interpreter to make the opcodes work in a different way or behave 
 differently. 
 Alternatively, is there any other method to instrument our own 
 functionalities in the bytecode generated.
 
 Thanks and Regards,
 Abhishek
 ___
 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] Should we create an 8-bit path from the network stack to the parser?

[Michael Saboff]

Maciej,

*I* deemed using a character type template for the HTMLTokenizer as being 
unwieldy.  Given there was the existing SegmentedString input abstraction, it 
made logical sense to put the 8/16 bit coding there.  If I would have moved the 
8/16 logic into the tokenizer itself, we might have needed to do 8-16 up 
conversions when a SegmentedStrings had mixed bit-ness in the contained 
substrings.  Even if that wasn't the case, the patch would have been far larger 
and likely include tricky code for escapes.

As I got into the middle of the 8-bit strings, I realized that not only could I 
keep performance parity, but some of the techniques I came up with offered good 
performance improvement.  The HTMLTokenizer ended up being one of those cases.  
This patch required a couple of reworks for performance reasons and garnered a 
lot of discussion from various parts of the webkit community.  See 
https://bugs.webkit.org/show_bug.cgi?id=90321 for the trail.  Ryosuke noted 
that this patch was responsible for a 24% improvement in the url-parser test in 
their bots (comment 47).  My performance final results are in comment 43 and 
show between 1 and 9% progression on the various HTML parser tests.

Adam, If you believe there is more work to be done in the HTMLTokenizer, file a 
bug and cc me.  I'm interested in hearing your thoughts.

- Michael

On Mar 9, 2013, at 4:24 PM, Maciej Stachowiak m...@apple.com wrote:

 
 On Mar 9, 2013, at 3:05 PM, Adam Barth aba...@webkit.org wrote:
 
 In retrospect, I think what I was reacting to was msaboff statement
 that an unnamed group of people had decided that the HTML tokenizer
 was too unwieldy to have a dedicated 8-bit path.  In particular, it's
 unclear to me who made that decision.  I certainly do not consider the
 matter decided.
 
 It would be good to find out who it was that said that (or more specifically: 
 Using a character type template approach was deemed to be too unwieldy for 
 the HTML tokenizer.) so you can talk to them about it.
 
 Michael?
 
 Regards,
 Maciej
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

[Michael Saboff]

No complaints with the long term direction.  I agree that it is a tall order to 
implement.

- Michael

On Mar 11, 2013, at 9:54 AM, Adam Barth aba...@webkit.org wrote:

 Oh, Ok.  I misunderstood your original message to say that the project
 as a whole had reached this conclusion, which certainly isn't the
 case, rather than that you personally had reached that conclusion.
 
 As for the long-term direction of the HTML parser, my guess is that
 the optimum design will be to deliver the network bytes to the parser
 directly on the parser thread.  On the parser thread, we can merge
 charset decoding, input stream pre-processing, and tokenization to
 move directly from network bytes to CompactHTMLTokens.  That approach
 removes a number of copies, 8-bit-to-16-bit, and 16-bit-to-8-bit
 conversions.  Parsing directly into CompactHTMLTokens also means we
 won't have to do any copies or conversions at all for well-known
 strings (e.g., div and friends from HTMLNames).
 
 If you're about to reply complaining about the above, please save your
 complaints for another time.  I realize that some parts of that design
 will be difficult or impossible to implement on some ports due to
 limitations on how then interact with their networking stack.  In any
 case, I don't plan to implement that design anytime soon, and I'm sure
 we'll have plenty of time to discuss its merits in the future.
 
 Adam
 
 
 On Mon, Mar 11, 2013 at 8:56 AM, Michael Saboff msab...@apple.com wrote:
 Maciej,
 
 *I* deemed using a character type template for the HTMLTokenizer as being
 unwieldy.  Given there was the existing SegmentedString input abstraction,
 it made logical sense to put the 8/16 bit coding there.  If I would have
 moved the 8/16 logic into the tokenizer itself, we might have needed to do
 8-16 up conversions when a SegmentedStrings had mixed bit-ness in the
 contained substrings.  Even if that wasn't the case, the patch would have
 been far larger and likely include tricky code for escapes.
 
 As I got into the middle of the 8-bit strings, I realized that not only
 could I keep performance parity, but some of the techniques I came up with
 offered good performance improvement.  The HTMLTokenizer ended up being one
 of those cases.  This patch required a couple of reworks for performance
 reasons and garnered a lot of discussion from various parts of the webkit
 community.  See https://bugs.webkit.org/show_bug.cgi?id=90321 for the trail.
 Ryosuke noted that this patch was responsible for a 24% improvement in the
 url-parser test in their bots (comment 47).  My performance final results
 are in comment 43 and show between 1 and 9% progression on the various HTML
 parser tests.
 
 Adam, If you believe there is more work to be done in the HTMLTokenizer,
 file a bug and cc me.  I'm interested in hearing your thoughts.
 
 - Michael
 
 On Mar 9, 2013, at 4:24 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 On Mar 9, 2013, at 3:05 PM, Adam Barth aba...@webkit.org wrote:
 
 
 In retrospect, I think what I was reacting to was msaboff statement
 that an unnamed group of people had decided that the HTML tokenizer
 was too unwieldy to have a dedicated 8-bit path.  In particular, it's
 unclear to me who made that decision.  I certainly do not consider the
 matter decided.
 
 
 It would be good to find out who it was that said that (or more
 specifically: Using a character type template approach was deemed to be too
 unwieldy for the HTML tokenizer.) so you can talk to them about it.
 
 Michael?
 
 Regards,
 Maciej
 
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?

[Michael Saboff]

There is an all-ASCII case in TextCodecUTF8::decode().  It should be keeping 
all ASCII data as 8 bit.  TextCodecWindowsLatin1::decode() has not only an 
all-ASCII case, but it only up converts to 16 bit in a couple of rare cases.  
Is there some other case you don't think we are handling?

- Michael

On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote:

 Hi folks.
 
 Today, bytes that come in from the network get turned into UTF-16 by the 
 decoding process. We then turn some of them back into Latin-1 during the 
 parsing process. Should we make changes so there’s an 8-bit path? It might be 
 as simple as writing code that has more of an all-ASCII special case in 
 TextCodecUTF8 and something similar in TextCodecWindowsLatin1.
 
 Is there something significant to be gained here? I’ve been wondering this 
 for a while, so I thought I’d ask the rest of the WebKit contributors.
 
 -- Darin
 ___
 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] Should we create an 8-bit path from the network stack to the parser?

[Michael Saboff]

The various tokenizers / lexers work various ways to handle LChar versus UChar 
input streams.  Most of the other tokenizers are templatized on input character 
type. In the case of HTML, the tokenizer handles a UChar character at a time.  
For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. 
 There may be additional performance to be gained by doing all other possible 
handling in 8 bits, but an 8 bit stream can still contain escapes that need a 
UChar representation as you point out.  Using a character type template 
approach was deemed to be too unwieldy for the HTML tokenizer.  The HTML 
tokenizer uses SegmentedString's that can consist of sub strings with either 
LChar and UChar.  That is where the LChar to UChar zero extension happens for 
an 8 bit sub string.

My research showed that at the time showed that there were very few UTF-16 only 
resources (5% IIRC), although I expect the number to grow.

- Michael


On Mar 7, 2013, at 11:11 AM, Adam Barth aba...@webkit.org wrote:

 The HTMLTokenizer still works in UChars.  There's likely some
 performance to be gained by moving it to an 8-bit character type.
 There's some trickiness involved because HTML entities can expand to
 characters outside of Latin-1. Also, it's unclear if we want two
 tokenizers (one that's 8 bits wide and another that's 16 bits wide) or
 if we should find a way for the 8-bit tokenizer to handle, for
 example, UTF-16 encoded network responses.
 
 Adam
 
 
 On Thu, Mar 7, 2013 at 10:11 AM, Darin Adler da...@apple.com wrote:
 No. I retract my question. Sounds like we already have it right! thanks for 
 setting me straight.
 
 Maybe some day we could make a non copying code path that points directly at 
 the data in the SharedBuffer, but I have no idea if that'd be beneficial.
 
 -- Darin
 
 Sent from my iPhone
 
 On Mar 7, 2013, at 10:01 AM, Michael Saboff msab...@apple.com wrote:
 
 There is an all-ASCII case in TextCodecUTF8::decode().  It should be 
 keeping all ASCII data as 8 bit.  TextCodecWindowsLatin1::decode() has not 
 only an all-ASCII case, but it only up converts to 16 bit in a couple of 
 rare cases.  Is there some other case you don't think we are handling?
 
 - Michael
 
 On Mar 7, 2013, at 9:29 AM, Darin Adler da...@apple.com wrote:
 
 Hi folks.
 
 Today, bytes that come in from the network get turned into UTF-16 by the 
 decoding process. We then turn some of them back into Latin-1 during the 
 parsing process. Should we make changes so there’s an 8-bit path? It might 
 be as simple as writing code that has more of an all-ASCII special case in 
 TextCodecUTF8 and something similar in TextCodecWindowsLatin1.
 
 Is there something significant to be gained here? I’ve been wondering this 
 for a while, so I thought I’d ask the rest of the WebKit contributors.
 
 -- Darin
 ___
 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] YARR example

[Michael Saboff]

Ognian,

For the search to be case insensitive, you add an 'i' to the end of the regular 
expression.  The replace will be whatever string to have for the second 
argument.  See http://www.w3schools.com/jsref/jsref_replace.asp for an example 
of case-insensitive search/replace.

- Michael

On Jan 4, 2013, at 1:57 AM, Ognian Milanov ogi.andr...@gmail.com wrote:

 Thanks for your reply!
 
 I already figured out how to make a case sensitive replacement with 
 String::replace, which works exactly as I wanted. However case-insensitive 
 replacement with (?i) doesn't work at all. Is this implementation specific, 
 do I need to use other notation to indicate case insensitive matching?
 
 Regards,
 Ognian
 
 On Thu, Jan 3, 2013 at 6:28 PM, Michael Saboff msab...@apple.com wrote:
 Ognian,
 
 YARR is the regular expression engine for the JavaScriptCore part of webkit.  
 It can find the matches, but you would need to write other C++ code to do the 
 replacement.  The String.replace() method will do what you want in JavaScript.
 
 - Michael
 
 
 On Jan 3, 2013, at 4:16 AM, Ognian Milanov ogi.andr...@gmail.com wrote:
 
  Hello! I need info how to use YARR to replace all matches of a given 
  regular expression in a string with another string. For example in Java 
  this is achieved by String.replaceAll method.
 
  I will appreciate if someone leads me to the solution, thanks!
  ___
  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] YARR example

[Michael Saboff]

Ognian,

YARR is the regular expression engine for the JavaScriptCore part of webkit.  
It can find the matches, but you would need to write other C++ code to do the 
replacement.  The String.replace() method will do what you want in JavaScript.

- Michael


On Jan 3, 2013, at 4:16 AM, Ognian Milanov ogi.andr...@gmail.com wrote:

 Hello! I need info how to use YARR to replace all matches of a given regular 
 expression in a string with another string. For example in Java this is 
 achieved by String.replaceAll method.
 
 I will appreciate if someone leads me to the solution, thanks!
 ___
 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] question about jsc

[Michael Saboff]

The output of undefined is normal.  It is the result of the expression you 
entered.  jsc is basically returning the result of the expressions you enter.  
Both var and print themselves evaluate to undefined.  If you try x = 1; 
you'll get 1 as that expression returns 1.  

Concerning testing,  If you have successfully built testapi, from the webkit 
top directory you can run Tools/Scripts/run-javascriptcore-tests.  This script 
will first run testapi, which tests the JavaScript APIs and then run a 
collection of javascript tests.  If you have successfully built testRegExp, you 
can run run-regexp-tests which will test the regular expression engine.  Both 
testapi and testRegExp should be built along with jsc when you run the script 
Tools/Scripts/build-jsc.

- Michael

On Oct 29, 2012, at 2:39 AM, yuqing cai yuqingc...@gmail.com wrote:

 hi, all, I try to port the webkit to a new platform(the platform is
 linux based run with glibc  glib, but not gtk), now I have build the
 jsc project successfully, but when I run the jsc program, something
 happend show as below:
 
 qing@HAHA:/data/project/webOS/WebKit/Source/JavaScriptCore/JavaScriptCore.catwalk$
 ./jsc
 var string=hello world :);
 undefined
 print(string);
 hello world :)
 undefined
 
 
 now I have 2 questions:
 1. Why the word undefined comes up?
 2. How to test the jsc program?
 
 qing
 2012-10-29
 ___
 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] 8 Bit String Handling in Render Text Code

[Michael Saboff]

Got a patch for review to change the macro to ENABLE_8BIT_TEXTRUN.  
(https://bugs.webkit.org/attachment.cgi?id=168988action=review)

- Michael

On Oct 15, 2012, at 2:44 PM, Maciej Stachowiak m...@apple.com wrote:

 
 On Oct 15, 2012, at 9:56 AM, Michael Saboff msab...@apple.com wrote:
 
 I recently landed r131311 which adds code to handle 8-bit strings in the 
 render text path.  The code also puts HTML text into 8-bit strings.
 
 The reason for this announcement is that the handling of 8-bit text on the 
 render path is disabled on non-Mac platforms.  Most platforms have platform 
 specific text rendering code and that code needs to be updated to handle 
 8-bit text.  For Mac, the platform specific changes are for the complex text 
 rendering path only.  The changes involved converting the 8-bit text to a 
 16-bit String, adding the 16-bit string to the ComplexTextController so the 
 string won't be freed and using the contained 16-bit text with the rest of 
 the complex code unchanged.  See 
 ComplexTextController::collectComplexTextRuns() in 
 WebCore/platform/graphics/mac/ComplexTextController.cpp.
 
 The new define WTF_USE_8BIT_TEXTRUN is used to control the creation of 8-bit 
 TextRun objects.  When this define is not enabled, TextRun's will only 
 contain 16-bit text and current code should work correctly.  After platform 
 code is added to handle 8-bit text in platform specific code, that platform 
 should enable WTF_USE_8BIT_TEXTRUN.  Note that all platforms compile with 
 that define enabled, but it is likely they'll crash when running the tests.
 
 Minor technicality, but this should be an ENABLE flag, not USE. ENABLE is for 
 optional code in WebKit itself, USE is for optional external dependencies.
 
 Regards,
 Maciej
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] 8 Bit String Handling in Render Text Code

[Michael Saboff]

I recently landed r131311 which adds code to handle 8-bit strings in the render 
text path.  The code also puts HTML text into 8-bit strings.

The reason for this announcement is that the handling of 8-bit text on the 
render path is disabled on non-Mac platforms.  Most platforms have platform 
specific text rendering code and that code needs to be updated to handle 8-bit 
text.  For Mac, the platform specific changes are for the complex text 
rendering path only.  The changes involved converting the 8-bit text to a 
16-bit String, adding the 16-bit string to the ComplexTextController so the 
string won't be freed and using the contained 16-bit text with the rest of the 
complex code unchanged.  See ComplexTextController::collectComplexTextRuns() in 
WebCore/platform/graphics/mac/ComplexTextController.cpp.

The new define WTF_USE_8BIT_TEXTRUN is used to control the creation of 8-bit 
TextRun objects.  When this define is not enabled, TextRun's will only contain 
16-bit text and current code should work correctly.  After platform code is 
added to handle 8-bit text in platform specific code, that platform should 
enable WTF_USE_8BIT_TEXTRUN.  Note that all platforms compile with that define 
enabled, but it is likely they'll crash when running the tests.

- Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Michael Saboff]

It seems to me that there are two issues here.  One is Chromium specific about 
process conformity.  It seems to me that should stay a Chromium issue without 
making the mechanism more complex for all ports.  The other ports seem to make 
things work using the existing framework.

The other broader issue is failing tests.  If I understand part of Filip's 
concern it is a signal to noise issue.  We do not want the pass / fail signal 
to be lost in the noise of expected failures.  Failing tests should be fixed as 
appropriate for failing platform(s).  That fixing might involve splitting off 
or removing a failing sub-test so that the remaining test adds value once 
again.  Especially a pass becoming a fail edge.  For me, a test failing 
differently provides unknown value as the noise of it being a failing test 
likely exceeds the benefit of the different failure mode signal.  It takes a 
non-zero effort to filter that noise and that effort is likely better spent 
fixing the test.

- Michael

On Aug 15, 2012, at 12:48 PM, Dirk Pranke dpra...@chromium.org wrote:

 I've received at least one bit of feedback off-list that it might not
 have been clear what problems I was trying to solve and whether the
 solution would add enough benefit to be worth it. Let me try to
 restate things, in case this helps ...
 
 The problems I'm attempting to solve are:
 
 1) Chromium does things differently from the other WebKit ports, and
 this seems bad :).
 
 2) the TestExpectations syntax is too complicated
 
 3) When you suppress or skip failures (as chromium does), you can't
 easily tell when test changes behavior (starts failing differently).
 
 4) We can't easily tell if a test's -expected output is actually
 believed to be correct or not, which makes figuring out whether to
 rebaseline or not difficult, and makes figuring out if your change
 that is causing a test to fail is actually introducing a new
 problem, just failing differently, or even potentially fixing
 something.
 
 I agree that it's unclear how much churn there will be and how much
 benefit there will be, but we've been talking about these problems for
 years and I think without actually trying *something* we won't know if
 there's a better way to solve this or not, and I personally think it's
 worth trying. The solution I've described is the least intrusive
 mechanism we can try that I've yet come up with.
 
 -- Dirk
 
 On Wed, Aug 15, 2012 at 12:22 PM, Dirk Pranke dpra...@chromium.org wrote:
 Hi all,
 
 As many of you know, we normally treat the -expected files as
 regression tests rather than correctness tests; they are intended
 to capture the current behavior of the tree. As such, they
 historically have not distinguished between a correct failure and an
 incorrect failure.
 
 The chromium port, however, has historically often not checked in
 expectations for tests that are currently failing (or even have been
 failing for a long time), and instead listed them in the expectations
 file. This was primarily motivated by us wanting to know easily all of
 the tests that were failing. However, this approach has its own
 downsides.
 
 I would like to move the project to a point where all of the ports
 were basically using the same workflow/model, and combine the best
 features of each approach [1].
 
 To that end, I propose that we allow tests to have expectations that
 end in '-passing' and '-failing' as well as '-expected'.
 
 The meanings for '-passing' and '-failing' should be obvious, and
 '-expected' can continue the current meaning of either or both of
 what we expect to happen and I don't know if this is correct or
 not :).
 
 A given test will be allowed to only have one of the three potential
 results at any one time/revision in a checkout. [2]
 
 Because '-expected' will still be supported, this means that ports can
 continue to work as they do today and we can try -passing/-failing on
 a piecemeal basis to see if it's useful or not.
 
 Ideally we will have some way (via a presubmit hook, or lint checks,
 or something) to be able to generate a (checked-in) list (or perhaps
 just a dashboard or web page) of all of the currently failing tests
 and corresponding bugs from the -failing expectations, so that we
 can keep one of the advantages that chromium has gotten out of their
 TestExpectations files [3].
 
 I will update all of the tools (run-webkit-tests, garden-o-matic,
 flakiness dashboard, etc.) as needed to make managing these things as
 easy as possible. [4]
 
 Thoughts? I'm definitely open to suggestions/variants/other ideas/etc.
 
 -- Dirk
 
 Notes:
 
 [1] Both the check in the failures and the suppress the failures
 approaches have advantages and disadvantages:
 
 Both approaches have their advantages and disadvantages:
 
 Advantages for checking in failures:
 
 * you can tell when a test starts failing differently
 * the need to distinguish between different types of failures (text
 vs. image vs. image+text) in the expectations file drops; 

[webkit-dev] 8 Bit Strings Turned On in JavaScriptCore

[Michael Saboff]

With the recently landed changes in http://trac.webkit.org/changeset/100510 
(and two subsequent fixes in http://trac.webkit.org/changeset/100523 and 
http://trac.webkit.org/changeset/100729), strings in JavaScriptCore are 
stored internally in either 8 bit or 16 bit forms.  This is implemented in the 
StringImpl class and the classes based upon it like JSC::UString and 
WTF::String. Since most platforms have a signed char type while a few have an 
unsigned char type or char signedness is selectable via a compiler option, we 
added typedef unsigned char LChar in wtf/unicode/Unicode.h.

Changes to Using Strings

Although the UChar* characters() method for the various string classes still 
works, all new code should check what flavor a string is constructed by using 
the new is8Bit() method on the various string classes.  After determining the 
flavor, a call to either LChar* characters8() or UChar* characters16() as 
appropriate should be done to access the raw characters of a string.  The call 
to characters() on an 8 bit string will create a 16 bit buffer and convert the 
native 8 bit string, keeping the conversion for future use, before returning 
the 16bit result.  Obviously the expense of this conversion grows with a 
string's length and it increases the memory footprint beyond what was required 
by the original 16 bit string implementation.

The various string construction methods as well as Identifier constructors have 
been modified to create natively sized strings.  The JavaScriptCore lexers and 
parsers favor making 8 bit strings where possibly, even if the source text is 
16 bit.  There are cases where parsing an 8 bit native source string will 
produce a 16 bit string, e.g. the string literal abc\u1234.

Future Work

This change and it's prior dependent changes are not the end of the 8 bit 
string work.  In fact it should be seen as the foundation for the real 8 bit 
string work tuning JavaScriptCore and also in WebCore. The goal is to make 
WebCore's processing of text use appropriately sized strings. For Latin-1 based 
documents, string processing will be done using 8 bits except where string 
escapes require 16 bit strings. 

- Michael Saboff
msab...@apple.com

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] 8 Bit Strings Turned On in JavaScriptCore

[Michael Saboff]

On Nov 18, 2011, at 11:18 AM, Adam Roben wrote:

 On Nov 18, 2011, at 2:14 PM, Michael Saboff wrote:
 
 Although the UChar* characters() method for the various string classes still 
 works, all new code should check what flavor a string is constructed by 
 using the new is8Bit() method on the various string classes.  After 
 determining the flavor, a call to either LChar* characters8() or UChar* 
 characters16() as appropriate should be done to access the raw characters of 
 a string.  The call to characters() on an 8 bit string will create a 16 bit 
 buffer and convert the native 8 bit string, keeping the conversion for 
 future use, before returning the 16bit result.  Obviously the expense of 
 this conversion grows with a string's length and it increases the memory 
 footprint beyond what was required by the original 16 bit string 
 implementation.
 
 I wonder what we could do to make it more obvious what the correct usage is. 
 For example, we could rename characters() to make it clear that it might 
 allocate a new buffer. And we could make it an error to call characters8() or 
 characters16() on the wrong kind of string.

We have talked about renaming and ultimately eliminating characters(), At this 
point, it may make sense to keep it but drastically reduce its use (error 
messages and the like).  I think a little more progress will help sort this out.

Concerning characters8() and characters16(), they have appropriate ASSERTS() if 
they are called incorrectly.

 -Adam
 

- Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev