Re: [v8-users] ArrayBuffer BackingStore mutex causing high system load

[Andrew Johnston]

Hi Ulan,

Thanks for the response. I will do that over next couple days. It could be 
an edge case or could be related to something stupid I am doing when 
running isolates on threads in the same process 
(https://github.com/just-js/just/blob/main/just.cc#L2722). When i use 
separate processes I don't see the contention/syscall overhead. Will see if 
i can make a small and reproducible case for a bug report.

Andrew 

On Tuesday, October 20, 2020 at 1:12:06 PM UTC+1 Ulan Degenbaev wrote:

> Hi Andrew!
>
> Could you please file a bug at crbug.com/v8 with steps to reproduce? We 
> will take a look and see if we can optimize this case.
>
> Until it is fixed, I think caching the backing store pointer in the 
> internal field would work. Then you'd need to ensure that you keep a handle 
> to ArrayBuffer while using the pointer (to prevent ArrayBuffer from being 
> garbage collected). Additionally, the pointer may become invalid if 
> ArrayBuffer is detached. You can detect that case by checking ByteLength() 
> == 0. 
>
> Cheers,
> Ulan.
>
> On Sun, Oct 18, 2020 at 12:45 AM billywhizz  wrote:
>
>> Hi,
>>
>> I have put some details here on an issue i have come across while doing 
>> some benchmarking: 
>> https://gist.github.com/billywhizz/ff4c83c37142198d2e70992e438bf045
>>
>> I have a few questions around this:
>>
>> 1) Do we need a pthread_mutex_lock and pthread_mutex_unlock in every 
>> access to ArrayBuffer->GetBackingStore? In the absence of a deep dive into 
>> the code (which I will do soon hopefully) I am guessing this is in case the 
>> GC, which is running on another thread, has moved the backing data 
>> elsewhere.
>>
>> 2) If i want to access backing data at high frequency from JS (e.g. doing 
>> lots of writing or reading of an arraybuffer on a socket) is it possible 
>> (or advisable) to do something like this in order to avoid the lock 
>> contention in GetBackingStore? 
>> https://gist.github.com/billywhizz/ff4c83c37142198d2e70992e438bf045#file-test-cc.
>>  
>> i.e. cache the pointer to the backing data in an internal field, assuming 
>> it will not be moved.
>>
>> 3) If the approach in 2) is not possible, is there a known approach to 
>> this problem which can avoid all the syscall overhead of locking the mutex?
>>
>> If you need more info or something easy to reproduce please let me know.
>>
>> Many Thanks,
>>
>> Andrew
>>
>> -- 
>> -- 
>> v8-users mailing list
>> v8-u...@googlegroups.com
>> http://groups.google.com/group/v8-users
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to v8-users+u...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/v8-users/a4ea069b-4271-4590-af99-4446a6a041e4n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/81d904e2-5e8c-48ec-bef9-a8e2f8384b25n%40googlegroups.com.

Re: [v8-users] ArrayBuffer BackingStore mutex causing high system load

['Ulan Degenbaev' via v8-users]

Hi Andrew!

Could you please file a bug at crbug.com/v8 with steps to reproduce? We
will take a look and see if we can optimize this case.

Until it is fixed, I think caching the backing store pointer in the
internal field would work. Then you'd need to ensure that you keep a handle
to ArrayBuffer while using the pointer (to prevent ArrayBuffer from being
garbage collected). Additionally, the pointer may become invalid if
ArrayBuffer is detached. You can detect that case by checking ByteLength()
== 0.

Cheers,
Ulan.

On Sun, Oct 18, 2020 at 12:45 AM billywhizz  wrote:

> Hi,
>
> I have put some details here on an issue i have come across while doing
> some benchmarking:
> https://gist.github.com/billywhizz/ff4c83c37142198d2e70992e438bf045
>
> I have a few questions around this:
>
> 1) Do we need a pthread_mutex_lock and pthread_mutex_unlock in every
> access to ArrayBuffer->GetBackingStore? In the absence of a deep dive into
> the code (which I will do soon hopefully) I am guessing this is in case the
> GC, which is running on another thread, has moved the backing data
> elsewhere.
>
> 2) If i want to access backing data at high frequency from JS (e.g. doing
> lots of writing or reading of an arraybuffer on a socket) is it possible
> (or advisable) to do something like this in order to avoid the lock
> contention in GetBackingStore?
> https://gist.github.com/billywhizz/ff4c83c37142198d2e70992e438bf045#file-test-cc.
> i.e. cache the pointer to the backing data in an internal field, assuming
> it will not be moved.
>
> 3) If the approach in 2) is not possible, is there a known approach to
> this problem which can avoid all the syscall overhead of locking the mutex?
>
> If you need more info or something easy to reproduce please let me know.
>
> Many Thanks,
>
> Andrew
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/a4ea069b-4271-4590-af99-4446a6a041e4n%40googlegroups.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CABNJt2LxOnoPKOjKss-xMo0Dcxcg6HqsQfmMRGwMjF2CfSB1Gw%40mail.gmail.com.

[v8-users] ArrayBuffer BackingStore mutex causing high system load

[billywhizz]

Hi,

I have put some details here on an issue i have come across while doing 
some 
benchmarking: 
https://gist.github.com/billywhizz/ff4c83c37142198d2e70992e438bf045

I have a few questions around this:

1) Do we need a pthread_mutex_lock and pthread_mutex_unlock in every access 
to ArrayBuffer->GetBackingStore? In the absence of a deep dive into the 
code (which I will do soon hopefully) I am guessing this is in case the GC, 
which is running on another thread, has moved the backing data elsewhere.

2) If i want to access backing data at high frequency from JS (e.g. doing 
lots of writing or reading of an arraybuffer on a socket) is it possible 
(or advisable) to do something like this in order to avoid the lock 
contention in 
GetBackingStore? 
https://gist.github.com/billywhizz/ff4c83c37142198d2e70992e438bf045#file-test-cc.
 
i.e. cache the pointer to the backing data in an internal field, assuming 
it will not be moved.

3) If the approach in 2) is not possible, is there a known approach to this 
problem which can avoid all the syscall overhead of locking the mutex?

If you need more info or something easy to reproduce please let me know.

Many Thanks,

Andrew

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/a4ea069b-4271-4590-af99-4446a6a041e4n%40googlegroups.com.