minor fixes

1-js/04-object-basics/03-garbage-collection/article.md

@@ -145,7 +145,7 @@ family = null;
 
 Объекты John и Ann всё ещё связаны, оба имеют входящие ссылки, но этого недостаточно.
 
-Бывший объект `family` был отсоединён от корня, на него больше нет ссылки, поэтому весь "остров" становится недоступным и будет удалён.
+Бывший объект `family` был отсоединён от корня, на него больше нет ссылки, поэтому весь "остров" становится недостижимым и будет удалён.
 
 ## Внутренние алгоритмы
 
@@ -163,17 +163,17 @@ family = null;
 
 ![](garbage-collection-1.svg)
 
-Мы ясно видим "недостижимый остров" справа. Теперь давайте посмотрим, как будет работать "разметка и зачистка" сборщика мусора.
+Мы ясно видим "недостижимый остров" справа. Теперь давайте посмотрим, как будет работать "алгоритм пометок" сборщика мусора.
 
 На первом шаге помечаются корни:
 
 ![](garbage-collection-2.svg)
 
-Затем помечаются их ссылки:
+Затем помечаются объекты по их ссылкам:
 
 ![](garbage-collection-3.svg)
 
-...И их ссылки, пока это вообще возможно:
+...А затем объекты по их ссылкам и так далее, пока это возможно:
 
 ![](garbage-collection-4.svg)
 
@@ -183,27 +183,27 @@ family = null;
 
 Мы также можем представить себе этот процесс как выливание огромного ведра краски из корней, которая течёт по всем ссылкам и отмечает все достижимые объекты. Затем непомеченные удаляются.
 
-Это концепция того, как работает сборка мусора. Движки JavaScript применяют множество оптимизаций, чтобы он работал быстрее и не влиял на выполнение.
+Это концепция того, как работает сборка мусора. Движки JavaScript применяют множество оптимизаций, чтобы она работала быстрее и не задерживала выполнение кода.
 
 Вот некоторые из оптимизаций:
 
-- **Сборка по поколениям (Generational collection)** – объекты разделены на два набора: "новые" и "старые". Многие объекты появляются, выполняют свою работу и быстро умирают, их можно агрессивно очищать. Те, которые выживают достаточно долго, становятся "старыми" и проверяются реже.
-- **Инкрементальная сборка (Incremental collection)** – если объектов много, и мы пытаемся обойти и пометить весь набор объектов сразу, это может занять некоторое время и привести к видимым задержкам в выполнения скрипта. Таким образом, движок пытается разделить сборку мусора на части. Затем части выполняются одна за другой, по отдельности. Это требует дополнительного учёта для отслеживания изменений между частями, но у нас много крошечных задержек вместо одной большой.
+- **Сборка по поколениям (Generational collection)** – объекты делятся на два набора: "новые" и "старые". В типичном коде многие объекты имеют короткую жизнь: они появляются, выполняют свою работу и быстро умирают, так что имеет смысл отслеживать новые объекты и, если это так, быстро очищать от них память. Те, которые выживают достаточно долго, становятся "старыми" и проверяются реже.
+- **Инкрементальная сборка (Incremental collection)** – если объектов много, и мы пытаемся обойти и пометить весь набор объектов сразу, это может занять некоторое время и привести к видимым задержкам в выполнения скрипта. Так что движок делит всё множество объектов на части, и далее очищает их одну за другой. Получается несколько небольших сборок мусора вместо одной всеобщей. Это требует дополнительного учёта для отслеживания изменений между частями, но зато получается много крошечных задержек вместо одной большой.
 - **Сборка в свободное время (Idle-time collection)** - чтобы уменьшить возможное влияние на производительность, сборщик мусора старается работать только во время простоя процессора.
 
-Существуют и другие способы оптимизации и разновидности алгоритмов сборки мусора. Но как бы мне ни хотелось описать их здесь, я должен воздержаться, потому что разные движки реализуют разные хитрости и методы. И, что ещё более важно, все меняется по мере развития движков, поэтому изучать глубже "заранее", без реальной необходимости, вероятно, не стоит. Если, конечно, это не вопрос чистого интереса, то для вас будет несколько ссылок ниже.
+Существуют и другие способы оптимизации и разновидности алгоритмов сборки мусора. Но как бы мне ни хотелось описать их здесь, я должен воздержаться, потому что разные движки реализуют разные хитрости и методы. И, что ещё более важно, все меняется по мере развития движков, поэтому изучать тему глубоко "заранее", без реальной необходимости, вероятно, не стоит. Если, конечно, это не вопрос чистого интереса, тогда для вас будет несколько ссылок ниже.
 
 ## Итого
 
 Главное, что нужно знать:
 
 - Сборка мусора выполняется автоматически. Мы не можем ускорить или предотвратить её.
 - Объекты сохраняются в памяти, пока они достижимы.
-- Наличие ссылки - это не то же самое, что быть достижимым (из корня): свора взаимосвязанных объектов может стать недоступна в целом.
+- Если на объект есть ссылка - вовсе не факт, что он является достижимым (из корня): набор взаимосвязанных объектов может стать недоступен в целом, как мы видели в примере выше.
 
-Современные движки реализуют передовые алгоритмы сборки мусора.
+Современные движки реализуют разные продвинутые алгоритмы сборки мусора.
 
-Общие сведения о некоторых из них освещены в книге "The Garbage Collection Handbook: The Art of Automatic Memory Management" (R. Jones и др.).
+О многих из них рассказано в прекрасной книге о сборке мусора "The Garbage Collection Handbook: The Art of Automatic Memory Management" (R. Jones и др.).
 
 Если вы знакомы с низкоуровневым программированием, то более подробная информация о сборщике мусора V8 находится в статье [A tour of V8: Garbage Collection](http:https://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection).