@@ -11,7 +11,7 @@ msgid ""
1111msgstr ""
1212"Project-Id-Version : Python 3.15\n "
1313"Report-Msgid-Bugs-To : \n "
14- "POT-Creation-Date : 2026-05-13 16 :14+0000\n "
14+ "POT-Creation-Date : 2026-05-31 15 :14+0000\n "
1515"PO-Revision-Date : 2025-09-16 00:00+0000\n "
1616"Last-Translator : python-doc bot, 2025\n "
1717"Language-Team : Indonesian (https://app.transifex.com/python-doc/teams/5390/ "
@@ -224,3 +224,166 @@ msgid ""
224224"catch_warnings` modifies the global filters list, which is not thread-safe. "
225225"See the :mod:`warnings` module for more details."
226226msgstr ""
227+
228+ msgid "Increased memory usage"
229+ msgstr ""
230+
231+ msgid ""
232+ "The free-threaded build will typically use more memory compared to the "
233+ "default build. There are multiple reasons for this, mostly due to design "
234+ "decisions."
235+ msgstr ""
236+
237+ msgid "All interned strings are immortal"
238+ msgstr ""
239+
240+ msgid ""
241+ "For modern Python versions (since version 2.3), interning a string (e.g. "
242+ "with :func:`sys.intern`) does not cause it to become immortal. Instead, if "
243+ "the last reference to that string disappears, it will be removed from the "
244+ "interned string table. This is not the case for the free-threaded build and "
245+ "any interned string will become immortal, surviving until interpreter "
246+ "shutdown."
247+ msgstr ""
248+
249+ msgid "Non-GC objects have a larger object header"
250+ msgstr ""
251+
252+ msgid ""
253+ "The free-threaded build uses a different :c:type:`PyObject` structure. "
254+ "Instead of having the GC related information allocated before the :c:type:"
255+ "`PyObject` structure, like in the default build, the GC related info is part "
256+ "of the normal object header. For example, on the AMD64 platform, ``None`` "
257+ "uses 32 bytes on the free-threaded build vs 16 bytes for the default build. "
258+ "GC objects (such as dicts and lists) are the same size for both builds since "
259+ "the free-threaded build does not use additional space for the GC info."
260+ msgstr ""
261+
262+ msgid "QSBR can delay freeing of memory"
263+ msgstr ""
264+
265+ msgid ""
266+ "In order to safely implement lock-free data structures, a safe memory "
267+ "reclamation (SMR) scheme is used, known as quiescent state-based reclamation "
268+ "(QSBR). This means that the memory backing data structures allowing lock-"
269+ "free access will use QSBR, which defers the free operation, rather than "
270+ "immediately freeing the memory. Two examples of these data structures are "
271+ "the list object and the dictionary keys object. See ``InternalDocs/qsbr."
272+ "md`` in the CPython source tree for more details on how QSBR is "
273+ "implemented. Running :func:`gc.collect` should cause all memory being held "
274+ "by QSBR to be actually freed. Note that even when QSBR frees the memory, "
275+ "the underlying memory allocator may not immediately return that memory to "
276+ "the OS and so the resident set size (RSS) of the process might not decrease."
277+ msgstr ""
278+
279+ msgid "mimalloc allocator vs pymalloc"
280+ msgstr ""
281+
282+ msgid ""
283+ "The default build will normally use the \" pymalloc\" memory allocator for "
284+ "small allocations (512 bytes or smaller). The free-threaded build does not "
285+ "use pymalloc and allocates all Python objects using the \" mimalloc\" "
286+ "allocator. The pymalloc allocator has the following properties that help "
287+ "keep memory usage low: small per-allocated-block overhead, effective memory "
288+ "fragmentation prevention, and quick return of free memory to the operating "
289+ "system. The mimalloc allocator does quite well in these respects as well "
290+ "but can have some more overhead."
291+ msgstr ""
292+
293+ msgid ""
294+ "In the free-threaded build, mimalloc manages memory in a number of separate "
295+ "heaps (currently four). For example, all GC supporting objects are "
296+ "allocated from their own heap. Using separate heaps means that free memory "
297+ "in one heap cannot be used for an allocation that uses another heap. Also, "
298+ "some heaps are configured to use QSBR (quiescent-state based reclamation) "
299+ "when freeing the memory that backs up the heap (known as \" pages\" in "
300+ "mimalloc terminology). The use of QSBR creates a delay between all memory "
301+ "blocks for a page being freed and the memory page being released, either for "
302+ "new allocations or back to the OS."
303+ msgstr ""
304+
305+ msgid ""
306+ "The mimalloc allocator also defers returning freed memory back to the OS. "
307+ "You can reduce that delay by setting the environment variable :envvar:`!"
308+ "MIMALLOC_PURGE_DELAY` to ``0``. Note that this will likely reduce the "
309+ "performance of the allocator."
310+ msgstr ""
311+
312+ msgid "Free-threaded reference counting can cause objects to live longer"
313+ msgstr ""
314+
315+ msgid ""
316+ "In the default build, when an object's reference count reaches zero, it is "
317+ "normally deallocated. The free-threaded build uses \" biased reference "
318+ "counting\" , with a fast-path for objects \" owned\" by the current thread and "
319+ "a slow path for other objects. See :pep:`703` for additional details. Any "
320+ "time an object's reference count ends up in a \" queued\" state, deallocation "
321+ "can be deferred. The queued state is cleared from the \" eval breaker\" "
322+ "section of the bytecode evaluator."
323+ msgstr ""
324+
325+ msgid ""
326+ "The free-threaded build also allows a different mode of reference counting, "
327+ "known as \" deferred reference counting\" . This mode is enabled by setting a "
328+ "flag on a per-object basis. Deferred reference counting is enabled for the "
329+ "following types:"
330+ msgstr ""
331+
332+ msgid "module objects"
333+ msgstr ""
334+
335+ msgid "module top-level functions"
336+ msgstr ""
337+
338+ msgid "class methods defined in the class scope"
339+ msgstr ""
340+
341+ msgid "descriptor objects"
342+ msgstr ""
343+
344+ msgid "thread-local objects, created by :class:`threading.local`"
345+ msgstr ""
346+
347+ msgid ""
348+ "When deferred reference counting is enabled, references from Python function "
349+ "stacks are not added to the reference count. This scheme reduces the "
350+ "overhead of reference counting, especially for objects used from multiple "
351+ "threads. Because the stack references are not counted, objects with deferred "
352+ "reference counting are not immediately freed when their internal reference "
353+ "count goes to zero. Instead, they are examined by the next GC run and, if "
354+ "no stack references to them are found, they are freed. This means these "
355+ "objects are freed by the GC and not when their reference count goes to zero, "
356+ "as is typical."
357+ msgstr ""
358+
359+ msgid "Per-thread reference counting can delay freeing objects"
360+ msgstr ""
361+
362+ msgid ""
363+ "To avoid contention on the reference count fields of frequently shared "
364+ "objects, the free-threaded build also uses \" per-thread reference counting\" "
365+ "for a few selected object types. Rather than updating a single shared "
366+ "reference count, each thread maintains its own local reference count array, "
367+ "indexed by a unique id assigned to the object. The true reference count is "
368+ "only computed by summing the per-thread counts when the object's local count "
369+ "drops to zero. Per-thread reference counting is currently used for:"
370+ msgstr ""
371+
372+ msgid "heap type objects (classes created in Python)"
373+ msgstr ""
374+
375+ msgid "code objects"
376+ msgstr ""
377+
378+ msgid "the ``__dict__`` of module objects"
379+ msgstr ""
380+
381+ msgid ""
382+ "Because the per-thread counts must be merged back to the object before it "
383+ "can be deallocated, objects using per-thread reference counting are "
384+ "typically freed later than they would be in the default build. In "
385+ "particular, such an object is usually not freed until the thread that "
386+ "referenced it reaches a safe point (for example, in the \" eval breaker\" "
387+ "section of the bytecode evaluator) or exits. Running :func:`gc.collect` "
388+ "will merge the per-thread counts and allow these objects to be freed."
389+ msgstr ""
0 commit comments