Interesting, agreed it's most likely caused by thread creation. FWIW, if thread creation jank is unavoidable, the ServiceThread is a pretty good place to have it (as opposed to synchronously during PostTask).

We think we can reduce thread creation by introducing a better detach strategy however and etiennep will be working on that.

The fix to create threads outside the pool lock landed in 73.0.3627.0 (https://chromiumdash.appspot.com/commit/611b929334504e26de879b7ea240162ff06fd0b0).

As etiennep@ said, crash/fb8677383d15d2df contains a 16 seconds AdjustMaxTasks(). Just before the AdjustMaxTasksEnd(), a "PostLaunchOnLauncherThread" task ends on the main thread. This task stays stuck in the following stack for a long time:

 NtSetValueKey
 kernelbase.pdb
 kernelbase.pdb
 base::win::RegKey::WriteValue(wchar_t const *,wchar_t const *)
 `anonymous namespace\'::WriteUserGoogleUpdateStrKey
 GoogleUpdateSettings::UpdateDidRunState(bool)
 content::NotificationServiceImpl::Notify(int,content::NotificationSource const &,content::NotificationDetails const &)
 content::RenderProcessHostImpl::OnProcessLaunched()
 content::ChildProcessLauncher::Notify(content::internal::ChildProcessLauncherHelper::Process,int)
 content::internal::ChildProcessLauncherHelper::PostLaunchOnClientThread(content::internal::ChildProcessLauncherHelper::Process,int)

What could make a write in the registry take so much time?

Interesting, I don't have symbolized stacks in this trace though? (How do I see the post-processed traces?)

I notice that
src_file	"../../net/disk_cache/blockfile/in_flight_backend_io.cc"
src_func	"OpenNextEntry"
also runs long and completes at the same time on CacheThread_BlockFile.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.