I took a quick trace with WorkerTest.zip. I see many V8 GCs. I don't see any solo BlinkGCs. It is likely a V8 GC scheduling issue.

Deleted: trace_worker-test.json.gz 487 KB

trace_worker-test.json.gz 487 KB Download

Shubhie: This might inform microbenchmark design?

Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 17.10 using chrome reported version #68.0.3440.106 and latest canary #71.0.3540.0.

Bisect Information:
=====================
Good build: 65.0.3323.0
Bad Build : 65.0.3324.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/16f4b01dc203028c7c04efe83ba81f17abd5f9eb..da7248b830fcf503ab0fd0e4292c367bb5244ab9

From the above change log suspecting below change
Change-Id: If4fa5082579629fb5f4c3c0666e704bd14bb5ec0
Reviewed-on: https://chromium-review.googlesource.com/868019

mlippautz@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

The CL fixed a bug where we would not properly notify the receiving Isolate of external memory that it is now owning.

You mention 5M arrays but the repro is actually 50M arrays. V8 will trigger a GC at ~64M for external memory (which this category falls into). 

Logs show that external memory gets cleaned up, so it might "just" be an issue of being very close to the incremental GC limit in an micro benchmark. 

The problematic part seems the back-to-back GCs. I can imagine that this is because of delayed (concurrent) freeing of buffers. We might hit the next allocation before the buffer has been freed and thus trigger two GCs instead of one.

Verifying my understanding now.

I mentioned bigger than 5Mb. I choose 50 for the repro to be more apparent. It can be reproduced with lower values.

I've investigated this a bit more.

Repro: 
- The example ping-pongs a single AB between main thread and worker. 
- Assuming that the single AB size is below V8's internal GC triggers (1) and ignoring any internal or additional allocations (2) necessary, there should not be a single GC observable.
- In other words, for anything below some V8 internal GC heuristic, we should be able to get away without copy and without GC.

That unknown V8 internal GC heuristic is 64M for AB, so the repro shouldn't trigger any GCs.

I see that we properly increment and decrement external memory for ABs when transferring objects.

Currently looking into the exact GC triggers.

There's a bug in the way we adjust the external limit downwards in [1]. Essentially, it is assume that explicit AdjustAmountOfExternalAllocatedMemory can always decrease the limit by that amount.

We should never go below the initial limit though. Otherwise, those explicit calls could bring down the limit to 0 (Adjust(+5), Adjust(-5), ...). 

The suspected CL just fixes adjusting so that this bug is now observable (previously, we would double increment for a single buffer).

[1] https://cs.chromium.org/chromium/src/v8/include/v8.h?q=AdjustAmountOfExternalAllocatedMemory&sq=package:chromium&g=0&l=10682

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/ad832c4145ba5a9accc219123d7d307fda0e5c09

commit ad832c4145ba5a9accc219123d7d307fda0e5c09
Author: Michael Lippautz <mlippautz@chromium.org>
Date: Thu Sep 06 15:44:37 2018

[heap, api] Keep lower limit when adjusting external memory

Previously explicit calls to external memory adjustment could yield in lowering
the limit below the initial default limit. The consequence is repeated useless
garbage collections when e.g. passing around ArrayBuffers.

Bug:  chromium:880036 
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I429f5adcd9ae523e5ac7621cf7976686b0dec71b
Reviewed-on: https://chromium-review.googlesource.com/1209784
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55694}
[modify] https://crrev.com/ad832c4145ba5a9accc219123d7d307fda0e5c09/include/v8.h
[modify] https://crrev.com/ad832c4145ba5a9accc219123d7d307fda0e5c09/src/globals.h
[modify] https://crrev.com/ad832c4145ba5a9accc219123d7d307fda0e5c09/src/heap/heap.h
[modify] https://crrev.com/ad832c4145ba5a9accc219123d7d307fda0e5c09/test/unittests/heap/heap-unittest.cc

sounds great 

Re: falken's comment in #4 - the microbenchmark only captures time in each hop / round trip; although jason's worker benchmark suite could capture excessive CPU usage and GC rate.