Multithreading in JS. Myth or reality?
- 1. Многопоточность в JS : Миф или реальность? 1
- 2. SAFE HARBOR • Контент этого доклада не является единственной истинной в последней инстанции. • Если вы увидели что-то, что считаете неправдой - не бойтесь сказать об этом докладчику. 2
- 3. Кто я такой • Меня зовут Александр. • Software Engineer в Aeneas Platform. • Студент в КНУ, кибернетика. • Пишу на Scala, Java/Kotlin, C++ и JS. • github.com/Fly-Style 3
- 4. О чем доклад • Многопоточность + производительности - сложность кода • JS и многопоточность 4
- 5. План доклада Memory Model Synchronization Actions Thread Design Allocations Garbage Collection DOM Interaction 5
- 6. Текущее положение дел • JS-engines – однопоточные. • Неблокирующий I/O в одном потоке. • Web-worker – не панацея. • ChakraCore !-> napa.js. 6
- 7. Thread support : Pros • Несколько выполняемых задач одновременно на железе. • Скорость выполнения программы увеличивается. 7
- 8. Пример !// 1 new Thread(function() { console.log("Hello, threads!"); }).join(); !// 2 new Thread(() !=> { console.log("Hello, lambdas inside!"); }).join(); 8
- 9. Thread support : Pros • Специальные структуры данных в языке для пользовательских приложений. • Многопоточность в помощь асинхронному программированию. 9
- 10. Пример async function task1() = { … }; async function task2() = { … }; const finalResult = task(await task1(), await task2()); 10
- 11. Пример const threadPool = new ThreadPool(2); const result1 = threadPool.accept(task1); const result2 = threadPool.accept(task2); const finalResult = task(await result1,await result2); 11
- 12. Thread support : Cons • Усложняется код. • Синхронизация потоков над общими данными. • Сложно для восприятия. 12
- 13. Давайте пофантазируем… • Что делать инженерам V8 (JSCore, ChakraCore, SpiderMonkey, TeaVM)? • Сначала обратимся к основам CS. 13
- 14. Архитектура фон Неймана • Память однородна : команды и данные хранятся в одной памяти. • Адресность памяти : память разделена на нумерованные ячейки. • Программное управление памятью : все вычисления должны быть представлены в виде программы, состоящей из последовательности управляющих слов — команд. 14
- 15. Как устроена память • Процессор (708 байт в x86-64) • Кэши L1-L3 (1 - 16 Mб) • RAM (4 - 64 Гб) – доступна разработчикам. • Внешние накопители 15
- 16. Но люди не пишут прямые команды процессору! 16
- 18. Абстрактная машина • Абстрактная машина исполняет код на высокоуровневом языке. • Вас не должно волновать, каким именно образом достигается результат. • А вот инженеров этой самой машины - как раз очень должно волновать. 18
- 19. Memory Model Synchronization Actions Thread Design Allocations Garbage Collection DOM Interaction 19
- 20. Memory Model • В последовательных программах все команды исполняются последовательно. • Обращения к памяти тоже происходят последовательно. • В многопоточных же программах все иначе : потоки обращаются к общей памяти, из-за чего ожидаемого результата может и не быть! 20
- 21. Memory Model • Формализованная модель памяти нужна для того, чтобы специфицировать поведение программы отношениями порядка записи и чтения. • А именно ответить на вопрос : • Какое конкретное значение может увидеть конкретное чтение в программе? 21
- 22. IRIW atomic var a, b Thread 1 Thread 2 Thread 3 Thread 4 a = 1 b = 1 let r1 = a let r2 = b let r3 = b let r4 = a • Какие допустимые значения кортежа (r1, r2, r3, r4)? 22
- 23. IRIW atomic var a, b Thread 1 Thread 2 Thread 3 Thread 4 a = 1 b = 1 let r1 = a let r2 = b let r3 = b let r4 = a • Например, (r1, r2, r3, r4) = (0, 1, 0, 1) нежелателен, потому что теряется порядок применения операций load / store. 23
- 24. IRIW atomic var a, b Thread 1 Thread 2 Thread 3 Thread 4 a = 1 b = 1 let r1 = a let r2 = b let r3 = b let r4 = a • В зрелых моделях памяти это ограничение называется «multiple copy atomicity» – запись видят или все потоки, или никакой из потоков. 24
- 25. Memory Model • Модель памяти про определение отношений порядков между действиями чтения/записи в программе • … и наложения ограничений на исполнение программы через т.н. «барьеры чтения/записи». 25
- 26. Без ограничений на исполнение программы в каждом из перечисленных типов порядков, получим С89 в миниатюре. Поэтому это нам нужно (глава 27) 26
- 27. Memory Model Synchronization Actions Thread Design Allocations Garbage Collection DOM Interaction 27
- 28. Lock • Для блокировки необходимы объекты синхронизации. • Такими объектами являются локи. 28
- 29. 29
- 30. Lock • Для блокировки необходимы объекты синхронизации. • Такими объектами являются локи. • Примерами локов являются : mutex, lock_guard, unique_lock из С++. 30
- 31. Пример Lock let lock = new Mutex(); !//… lock.lock(); doSomeTask(); lock.unlock(); 31
- 32. Monitors • Условные переменные (conditional variable) или монитор. • Храним информацию о блокировке в метаинформации объекта, например. 32
- 33. Пример let condVar = new СonditionalVariable(); condVar.wait(lock); doSomeTask(); condVar.notify(); !// Notify one thread or promise. condVar.notifyAll(); !// Notify all threads and promises. 33
- 34. Lockless / Atomic • Хитрые хардверщики в своих изыскахЪ подвезли нам возможность за одну инструкцию дешево, безопасно и почти безболезненно сделать запись в память. • Правда есть одно «но» : применимо только для примитивов и ссылок. 34
- 35. Пример let atomicInt = new AtomicInteger(); atomicInt.compareAndExchange(1, 2); !// !=> true, atomic = 2. atomicInt.compareAndExchange(1, 3); !// !=> false, atomic = 2. 35
- 36. Lockless / Atomic mov %eax, 0х1 mov %rbx, 0х2 mov %rcx, 0х1 cmpxchg %rcx, %rbx 36
- 37. Lockless / Atomic : Pros • Лучше масштабируемость. • Применяется в lock-free структурах данных, где важна производительность. 37
- 38. Transactional Memory • Технология транзакционной памяти упрощает параллельное программирование, выделяя группы инструкций в атомарные транзакции. • В этом случае мы считаем, что потоки работают независимо друг от друга и в редких случаях изменяют одни и те же данные. 38
- 39. И вот если принести вот это все абстрактному инженеру этой самой виртуальной машины для JS, то … 39
- 40. 40
- 41. Lock`и & Atomic`и - необходимая часть языка для того, чтобы работа с многопоточностью не напоминала АДЪ. Посему, оно нам надо. 41
- 42. Memory Model Synchronization Actions Thread Design Allocations Garbage Collection DOM Interaction 42
- 43. Дизайн потоков • Поток – это отдельная единица выполнения кода, связанная с остальными только общей памятью. • Каждый поток должен иметь свои виртуальные регистры, stack pointer и program counter. 43
- 44. Выбор «бэкэнда» для потока • Есть два варианта : • Kernel thread – полноценная и отдельная нить исполнения. • Fiber a.k.a. Волокна – легкая нить, не выполняется явно параллельно! 44
- 45. Варианты реализации • Нативная вытесняющая многопоточность (Java, C#) • Кооперативная многопоточность внутри VM (Erlang). • Виртуальная многопоточность (Python, Ruby) 45
- 46. Варианты реализации • Нативная вытесняющая многопоточность (Java, C#) • Кооперативная многопоточность внутри VM (Erlang). • Виртуальная многопоточность (Python, Ruby) 46
- 47. Нативная вытесняющая многопоточность • Каждый поток выполняется поверх назначенному ему нативному потоку ОС. • Переключение и планировка потоков осуществляется планировщиком ОС. • Так как переключения VM не контролирует, часто внутри кода VM нужны критические секции. 47
- 48. Дизайн класса потока • Если дизайнить Thread как класс, то в прототипе необходимо определить : 1. конструктор с функцией в качестве параметра, в которой будет определён блок с параллельным кодом. 2. метод, который будет исполнять параллельный код. 3. метод, который будет дожидаться конца исполнения и «парковать» освободившийся поток. 48
- 49. Дизайн класса потока class Thread { constructor(runner: function) {…} join(thread: Thread) {…} start() {…} } 49
- 50. Пример !// 1 new Thread(() !=> { console.log("Hello, Thread!"); }).join(); !// !=> Hello, Thread! !// 2 let print = () !=> console.log("Hello"); let thread = new Thread(print).start(); thread.join(); !// !=> Hello! 50
- 51. Memory Model Synchronization Actions Thread Design Allocations Garbage Collection DOM Interaction 51
- 52. Выделение памяти : проблемы • Диспетчеры памяти обычно пишутся на языке, отличном от языка таргета (С++ и JS). • Поэтому выделение памяти одному потоку имеет более-менее оправданную скорость, а вот многим - скорее всего нет. 52
- 53. Выделение памяти : проблемы • Для оптимизации надо позволить потокам выделять целые блоки памяти для своих нужд. • Такие блоки памяти называются Thread-Local Allocation Buffers (a.k.a. TLAB). 53
- 54. Bump pointer allocation • Аллоцируем по адресу текущего указателя TLAB + размер объекта. • Если мы запрашиваем выделение объекта, который превышает размер TLAB, мы выделяем напрямую. 54
- 55. TLAB уже реализованы. Осталось только научить V8 отдавать эти TLAB в рантайм, а не только GC. 55
- 56. Memory Model Synchronization Actions Thread Design Allocations Garbage Collection DOM Interaction 56
- 57. VM safepoint : Ideas • Иметь безопасный доступ к памяти. • Кооперативно остановить потоки. • Знать, когда нам точно надо уйти на GC паузу. 57
- 58. VM safepoint : Problems • Остановить потоки не так-то и просто. • Во время критической секции, например. • Или во время т.н. «короткого» цикла. 58
- 59. GC : Problems • Определение rootset становится еще большей проблемой : надо сканировать стеки всех потоков. • Анализ достижимости объектов и hidden классов. • Достижимость кода из Code Space. 59
- 60. Reachability Analysis function f() { let person = {age: 21, name: "Alex"}; !// GC safepoint register(person); } 60
- 61. Это не полный список изменений. Полный список вызовет у вас желание плакать и плавать в Океане Отчаянья. Инженеров тоже. 61
- 62. Memory Model Synchronization Actions Thread Design Allocations Garbage Collection DOM Interaction 62
- 63. DOM Interaction • ConcurrentAccessError при попытке записи из пользовательских потоков. • Также запретить concurrent доступ ко всем глобальным объектам. • Но console, пожалуй, стоит пожалеть :) 63
- 64. В моде глобальное состояние приложения. Concurrent DOM Interaction не нужен 🙁. 64
- 65. Conclusion 65
- 66. • Создавать виртуальные машины сложно! • Вносить изменения в VM ещё сложнее! • Мечтать – приятно и очень познавательно! • Многопоточность – сложно! • Бенефит от использования перевешивает минусы! 66
- 67. Useful books and links 1. Блог WebKit о JS Concurrency. 2. Xiao Feng Li – Advanced Design and Implementation of VM. 3. Richard Jones, Antony Hosking, Eliot Moss – GC Handbook. 67
- 68. Q/A? 68