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.


> On Feb 15, 2019, at 6:54 AM, Werner Sharp <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<Parent>::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://lists.webkit.org/mailman/listinfo/webkit-dev>
webkit-dev mailing list

Reply via email to