Re: [webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

[Mark Lam]

JF and I took a cursory look at this before, but I think it warrants a more 
rigorous check before we commit to this change.  I’ll do the due diligence.

> On Jan 3, 2017, at 2:54 PM, Geoffrey Garen  wrote:
> 
> EncodedJSValue was always just a work-around to convince the compiler to put 
> a JSValue in registers (instead of on the stack, with different compilers 
> disagreeing about where on the stack).
> 
> I agree with removing EncodedJSValue if possible.
> 
> Did something change to make this possible? For example, are you sure that 
> Windows and 32bit are OK with this change?
> 
> I don’t understand why C linkage would affect things: Either the compiler 
> puts structs in registers or it doesn’t.
> 
> Geoff
> 
>> On Jan 3, 2017, at 2:44 PM, Filip Pizlo > > wrote:
>> 
>> I think that this is great!
>> 
>> I agree with the policy that we should use JSValue everywhere that it would 
>> give us the same codegen/ABI (args in registers, return in registers, etc). 
>> 
>> -Filip
>> 
>> On Jan 3, 2017, at 14:33, Mark Lam > > wrote:
>> 
>>> Over the holiday period, I looked into the possibility of giving 
>>> EncodedJSValue a default constructor (because I didn’t like having to 
>>> return encodedJSValue() instead of { } in lots of places), and learned why 
>>> we had EncodedJSValue in the first place (i.e. for C linkage).  This led me 
>>> to discover (in my reading of the code) that we don’t really need to use 
>>> EncodedJSValue for most of our host functions (those of type 
>>> NativeFunction, GetValueFunc, and PutValueFunc).  
>>> 
>>> I propose that we switch to using JSValue directly where we can.  This has 
>>> the benefit of:
>>> 1. better type safety with the use of JSValue (EncodedJSValue is a int64_t 
>>> typedef).
>>> 2. more readable code (less marshaling back and forth with 
>>> JSValue::encode()/decode()).
>>> 
>>> The patch for this change can be found here:
>>> https://bugs.webkit.org/show_bug.cgi?id=166658 
>>> 
>>> 
>>> Perf is neutral.  Any opinions?
>>> 
>>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

Hi WebKittens!

Recently, I started naming threads in Linux. And I also started naming
threads created by WTF::AutomaticThread.
Previously, all the thread is not named in Linux. It makes difficult to
find problematic threads when using GDB in Linux.
For example, if you run the JSC shell, all the threads are named as "jsc"
(this is the name of the process).

The problem raised here is that we have no consistent policy for thread
names.
I picked several names in WebKit.

In WebCore,
IDB server is "IndexedDatabase Server"
AsyncAudioDecoder is "Audio Decoder"
GCController is "WebCore: GCController"
Icon Database is "WebCore: IconDatabase"
Audio's ReverbConvolver is "convolution background thread"
The thread name used by WorkQueue in WebCore is,
Crypto Queue is "com.apple.WebKit.CryptoQueue"
Image decoder is "org.webkit.ImageDecoder"
Blob utility is "org.webkit.BlobUtility"
Data URL decoder is "org.webkit.DataURLDecoder"
In JSC
Before this patch, all the AutomaticThreads (including JIT worklist /
DFG worklist) is "WTF::AutomaticThread"
Super Sampler thread is "JSC Super Sampler"
Asychronous Disasm is "Asynchronous Disassembler"
Sampling profiler is "jsc.sampling-profiler.thread"
WASM compiler thread is "jsc.wasm-b3-compilation.thread"
In WebKit2
Network Cache is "IOChannel::readSync"
IPC workqueue is "com.apple.IPC.ReceiveQueue"

To choose the appropriate naming policy, there are two requirements.
This is discussed in https://bugs.webkit.org/show_bug.cgi?id=166678 and
https://bugs.webkit.org/show_bug.cgi?id=166684

1. We should have super descriptive name including the iformation "This
thread is related to WebKit".
If we use WebKit as the framework, WebKit will launch several threads along
with the user application's threads.
So if the thread name does not include the above information, it is quite
confusing: Is this crash related to WebKit OR user's applications?
This should be met at least in macOS port. In the Linux port, this
requirement is a bit difficult to be met due to the second requirement.

2. The thread name should be <= 15 characters in Linux. <= 31 characters in
Windows.
This is super unfortunate. But we need this requirement. But in macOS, I
think we do not have any limitation like that (correct?)
I cannot find "PTHREAD_MAX_NAMELEN_NP" definition in macOS.

To meet the above requirements as much as possible, I suggest the name, "
org.webkit.MODULE.NAME(15characters)".
This policy is derived from the WorkQueue's naming policy, like
"org.webkit.ImageDecoder".
For example, we will name DFG compiler worklist thread as
"org.webkit.jsc.DFGCompiler" or "org.webkit.JavaScriptCore.DFGCompiler".

In Linux / Windows, we have the system to normalize the above name to
"NAME(15characters)".
For example, when you specify "org.webkit.jsc.DFGCompiler", it will be
shown as "DFGCompiler" in Linux.
This naming policy meets (1) in macOS. And (2) in all the environments. In
macOS, the name is not modified.
So we can see the full name "org.webkit.jsc.DFGCompiler".
In Linux, we can see "DFGCompiler", it is quite useful compared to nameless
threads.

What do you think of?

Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Filip Pizlo]

This sounds great to me!

-Filip

> On Jan 4, 2017, at 20:28, Yusuke SUZUKI  wrote:
> 
> Hi WebKittens!
> 
> Recently, I started naming threads in Linux. And I also started naming 
> threads created by WTF::AutomaticThread.
> Previously, all the thread is not named in Linux. It makes difficult to find 
> problematic threads when using GDB in Linux.
> For example, if you run the JSC shell, all the threads are named as "jsc" 
> (this is the name of the process).
> 
> The problem raised here is that we have no consistent policy for thread names.
> I picked several names in WebKit.
> 
> In WebCore,
> IDB server is "IndexedDatabase Server"
> AsyncAudioDecoder is "Audio Decoder"
> GCController is "WebCore: GCController"
> Icon Database is "WebCore: IconDatabase"
> Audio's ReverbConvolver is "convolution background thread"
> The thread name used by WorkQueue in WebCore is,
> Crypto Queue is "com.apple.WebKit.CryptoQueue"
> Image decoder is "org.webkit.ImageDecoder"
> Blob utility is "org.webkit.BlobUtility"
> Data URL decoder is "org.webkit.DataURLDecoder"
> In JSC
> Before this patch, all the AutomaticThreads (including JIT worklist / DFG 
> worklist) is "WTF::AutomaticThread"
> Super Sampler thread is "JSC Super Sampler"
> Asychronous Disasm is "Asynchronous Disassembler"
> Sampling profiler is "jsc.sampling-profiler.thread"
> WASM compiler thread is "jsc.wasm-b3-compilation.thread"
> In WebKit2
> Network Cache is "IOChannel::readSync"
> IPC workqueue is "com.apple.IPC.ReceiveQueue"
> 
> To choose the appropriate naming policy, there are two requirements.
> This is discussed in https://bugs.webkit.org/show_bug.cgi?id=166678 and 
> https://bugs.webkit.org/show_bug.cgi?id=166684
> 
> 1. We should have super descriptive name including the iformation "This 
> thread is related to WebKit".
> If we use WebKit as the framework, WebKit will launch several threads along 
> with the user application's threads.
> So if the thread name does not include the above information, it is quite 
> confusing: Is this crash related to WebKit OR user's applications?
> This should be met at least in macOS port. In the Linux port, this 
> requirement is a bit difficult to be met due to the second requirement.
> 
> 2. The thread name should be <= 15 characters in Linux. <= 31 characters in 
> Windows.
> This is super unfortunate. But we need this requirement. But in macOS, I 
> think we do not have any limitation like that (correct?)
> I cannot find "PTHREAD_MAX_NAMELEN_NP" definition in macOS.
> 
> To meet the above requirements as much as possible, I suggest the name, 
> "org.webkit.MODULE.NAME(15characters)".
> This policy is derived from the WorkQueue's naming policy, like 
> "org.webkit.ImageDecoder".
> For example, we will name DFG compiler worklist thread as 
> "org.webkit.jsc.DFGCompiler" or "org.webkit.JavaScriptCore.DFGCompiler".
> 
> In Linux / Windows, we have the system to normalize the above name to 
> "NAME(15characters)".
> For example, when you specify "org.webkit.jsc.DFGCompiler", it will be shown 
> as "DFGCompiler" in Linux.
> This naming policy meets (1) in macOS. And (2) in all the environments. In 
> macOS, the name is not modified.
> So we can see the full name "org.webkit.jsc.DFGCompiler".
> In Linux, we can see "DFGCompiler", it is quite useful compared to nameless 
> threads.
> 
> What do you think of?
> 
> 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