Open mkustermann opened 3 years ago
I think in your snippet above you meant symbols_lock
, not program_lock
when you dump stats ?
Removing read lock symbols_lock
seems to increase contention around much more expensive write lock and running with stopped mutators in the example where many compilers start and run through the same compilation process together.
Example procedure to investigate:
Step 1) Create app into
pkg/compiler/lib/src/d2js.dart
Step 2) Patch in simple lock contention measuring logic:
Step 3) Build SDK & app to kernel
Step 4) Run with/without isolate groups:
As can be seen without isolate groups it spends around 0.4 seconds per isolate trying to acquire read lock and 0.2 seconds per isolate trying to acquire write lock - making a total of around 5.6 seconds.
As can be seen the second one spends 12.4 seconds waiting to acquire read lock and 18.4 seconds to acquire write lock - making it a total of 30.8 seconds.
Attaching with
gdb
to the second one and breaking in random places, suggest we spend a lot of time acquiring the lock for symbol lookup.=> Would be nice to have an optimistic lookup in symbol table without holding even the read lock - since often the symbol will be there already and only acquire locks if that fails.
/cc @aam