Re: [webkit-dev] JavaScriptCore to C++ JSLock questions

[Werner Sharp]

Thanks Geoff.

Do you think it’s a reasonable request that if 
JSCallbackObject::customHasInstance fails to find a 
JSObjectHasInstanceCallback that it would fall back and call the 
JSObject::defaultHasInstance routine?  And if so, where would I open a bug for 
it?

For general performance numbers, my C++ based hasInstance is about 9x slower 
than if I could just use the built-in one.  One written in JS doing the same 
prototype chain walking is about 3-5 slower depending on depth of prototype 
walking than the built in one.

Thanks.

-Werner


From:  on behalf of Geoffrey Garen 
Date: Friday, February 15, 2019 at 1:46 PM
To: Werner Sharp 
Cc: "webkit-dev@lists.webkit.org" 
Subject: Re: [webkit-dev] JavaScriptCore to C++ JSLock questions

Hi Werner.

There’s no API around this. If you’re sure you don’t need thread safety, you 
can probably manually change JavaScriptCore not to do that locking.

Geoff


On Feb 15, 2019, at 6:54 AM, Werner Sharp 
mailto:wsh...@adobe.com>> wrote:

Hi everyone,

I’m working on a project that uses JavaScriptCore in interpreted mode along 
with a lot of C++ classes referenced from JS based upon the JSClassRef concept. 
 From doing some profiles, the transition from JSC to C++ (or vice-versa) is 
quite costly because of JSLockHolder, JSLock::dropAllLocks, etc.  I assume 
there is no way around this in a single threaded single instance of the VM?  Or 
no way from C++ to wrap a set of JSObjectGet* type of calls in a block somehow 
allowing only one lock to happen. For example, I need to query 6 properties of 
a pure JS object from C++.  That takes 6 round trips into JSC so 6 locks unless 
I do something like return a string representation of the 6 properties and 
parse them in my C++ code.

On a related note, one thing I’ve found slow is my own implementation of my C++ 
class’s hasInstance because of the locking.  I tried to leave the JSClassRef 
hasInstance NULL assuming that the internal instanceOf would work properly.  
But that doesn’t appear to work because the JSCallbackObject always sets the 
ImplementsHasInstance flag but not the ImplementsDefaultHasInstance flag. I 
would think that “JSCallbackObject::customHasInstance” could be 
enhanced to call defaultHasInstance if JSObjectHasInstanceCallback hasInstance 
always returns false?

Or if there is some way that defautHasInstance can be called for a 
JSCallbackObject I’d appreciate to hear about it.

Thanks for your time.

Werner Sharp


___
webkit-dev mailing list
webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.webkit.org%2Fmailman%2Flistinfo%2Fwebkit-dev=02%7C01%7Cwsharp%40adobe.com%7Ca392498cf8b744232fde08d69375d3ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636858531607246337=InCPy0RJnsLqHng7tVbu6aHJrrH59JgMzu7PiYNBnsI%3D=0>

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

Re: [webkit-dev] JavaScriptCore to C++ JSLock questions

[Geoffrey Garen]

Hi Werner.

There’s no API around this. If you’re sure you don’t need thread safety, you 
can probably manually change JavaScriptCore not to do that locking.

Geoff

> On Feb 15, 2019, at 6:54 AM, Werner Sharp  wrote:
> 
> Hi everyone,
>  
> I’m working on a project that uses JavaScriptCore in interpreted mode along 
> with a lot of C++ classes referenced from JS based upon the JSClassRef 
> concept.  From doing some profiles, the transition from JSC to C++ (or 
> vice-versa) is quite costly because of JSLockHolder, JSLock::dropAllLocks, 
> etc.  I assume there is no way around this in a single threaded single 
> instance of the VM?  Or no way from C++ to wrap a set of JSObjectGet* type of 
> calls in a block somehow allowing only one lock to happen. For example, I 
> need to query 6 properties of a pure JS object from C++.  That takes 6 round 
> trips into JSC so 6 locks unless I do something like return a string 
> representation of the 6 properties and parse them in my C++ code.
>  
> On a related note, one thing I’ve found slow is my own implementation of my 
> C++ class’s hasInstance because of the locking.  I tried to leave the 
> JSClassRef hasInstance NULL assuming that the internal instanceOf would work 
> properly.  But that doesn’t appear to work because the JSCallbackObject 
> always sets the ImplementsHasInstance flag but not the 
> ImplementsDefaultHasInstance flag. I would think that 
> “JSCallbackObject::customHasInstance” could be enhanced to call 
> defaultHasInstance if JSObjectHasInstanceCallback hasInstance always returns 
> false?
>  
> Or if there is some way that defautHasInstance can be called for a 
> JSCallbackObject I’d appreciate to hear about it.
>  
> Thanks for your time.
>  
> Werner Sharp
>  
>  
> ___
> 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 to C++ JSLock questions

[Werner Sharp]

Hi everyone,

I’m working on a project that uses JavaScriptCore in interpreted mode along 
with a lot of C++ classes referenced from JS based upon the JSClassRef concept. 
 From doing some profiles, the transition from JSC to C++ (or vice-versa) is 
quite costly because of JSLockHolder, JSLock::dropAllLocks, etc.  I assume 
there is no way around this in a single threaded single instance of the VM?  Or 
no way from C++ to wrap a set of JSObjectGet* type of calls in a block somehow 
allowing only one lock to happen. For example, I need to query 6 properties of 
a pure JS object from C++.  That takes 6 round trips into JSC so 6 locks unless 
I do something like return a string representation of the 6 properties and 
parse them in my C++ code.

On a related note, one thing I’ve found slow is my own implementation of my C++ 
class’s hasInstance because of the locking.  I tried to leave the JSClassRef 
hasInstance NULL assuming that the internal instanceOf would work properly.  
But that doesn’t appear to work because the JSCallbackObject always sets the 
ImplementsHasInstance flag but not the ImplementsDefaultHasInstance flag. I 
would think that “JSCallbackObject::customHasInstance” could be 
enhanced to call defaultHasInstance if JSObjectHasInstanceCallback hasInstance 
always returns false?

Or if there is some way that defautHasInstance can be called for a 
JSCallbackObject I’d appreciate to hear about it.

Thanks for your time.

Werner Sharp


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