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 <apjo...@gmail.com> 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 >> >> <https://groups.google.com/d/msgid/v8-users/a4ea069b-4271-4590-af99-4446a6a041e4n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- -- 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.
