Unit Instance

HTTP 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "translation": "https://translate-dev.freebsd.org/api/translations/documentation/articlesvm-design_index/ru/?format=api",
    "source": [
        "FreeBSD solves the deep layering problem with a special optimization called the \"All Shadowed Case\".  This case occurs if either C1 or C2 take sufficient COW faults to completely shadow all pages in B.  Lets say that C1 achieves this.  C1 can now bypass B entirely, so rather then have C1->B->A and C2->B->A we now have C1->A and C2->B->A.  But look what also happened-now B has only one reference (C2), so we can collapse B and C2 together.  The end result is that B is deleted entirely and we have C1->A and C2->A.  It is often the case that B will contain a large number of pages and neither C1 nor C2 will be able to completely overshadow it.  If we fork again and create a set of D layers, however, it is much more likely that one of the D layers will eventually be able to completely overshadow the much smaller dataset represented by C1 or C2.  The same optimization will work at any point in the graph and the grand result of this is that even on a heavily forked machine VM Object stacks tend to not get much deeper then 4.  This is true of both the parent and the children and true whether the parent is doing the forking or whether the children cascade forks."
    ],
    "previous_source": "",
    "target": [
        "FreeBSD решает проблему с глубиной вложенности с помощью приема оптимизации, который называется \"All Shadowed Case\". Этот случай возникает, если в C1 либо C2 возникает столько случаев копирования страниц при записи, что они полностью закрывают все страницы в B. Допустим, что такое произошло в C1. C1 может теперь полностью заменить B, так что вместо цепочек C1->B->A и C2->B->A мы теперь имеем цепочки C1->A и C2->B->A. Но посмотрите, что получается-теперь B имеет только одну ссылку (C2), так что мы можем объединить B и C2. В конечном итоге B будет полностью удален и мы имеем цепочки C1->A и C2->A. Часто B будет содержать большое количество страниц, и ни C1, ни C2 не смогут полностью их заменить. Если мы снова породим процесс и создадим набор уровней D, при этом, однако, более вероятно, что один из уровней D постепенно сможет полностью заместить гораздо меньший набор данных, представленный C1 и C2. Та же самая оптимизация будет работать в любой точке графа и главным результатом этого является то, что даже на сильно загруженной машине с множеством порождаемых процессов стеки объектов VM не часто бывают глубже четырех уровней. Это так как для порождающего, так и для порожденного процессов, и остается в силе как в случае, когда ветвление делает родитель, так и в случае, когда ветвление выполняет потомок."
    ],
    "id_hash": 8401165672617129096,
    "content_hash": 8401165672617129096,
    "location": "documentation/content/en/articles/vm-design/_index.adoc:176",
    "context": "",
    "note": "type: Plain text",
    "flags": "",
    "labels": [],
    "state": 20,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 29,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 219,
    "source_unit": "https://translate-dev.freebsd.org/api/units/615391/?format=api",
    "priority": 100,
    "id": 1811487,
    "web_url": "https://translate-dev.freebsd.org/translate/documentation/articlesvm-design_index/ru/?checksum=f496efaaff8cb488",
    "url": "https://translate-dev.freebsd.org/api/units/1811487/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2025-05-25T08:24:32.466119Z"
}