@@ -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 : Japanese (https://app.transifex.com/python-doc/teams/5390/ "
@@ -264,3 +264,193 @@ msgid ""
264264"catch_warnings` modifies the global filters list, which is not thread-safe. "
265265"See the :mod:`warnings` module for more details."
266266msgstr ""
267+
268+ #: ../../howto/free-threading-python.rst:171
269+ msgid "Increased memory usage"
270+ msgstr ""
271+
272+ #: ../../howto/free-threading-python.rst:173
273+ msgid ""
274+ "The free-threaded build will typically use more memory compared to the "
275+ "default build. There are multiple reasons for this, mostly due to design "
276+ "decisions."
277+ msgstr ""
278+
279+ #: ../../howto/free-threading-python.rst:178
280+ msgid "All interned strings are immortal"
281+ msgstr ""
282+
283+ #: ../../howto/free-threading-python.rst:180
284+ msgid ""
285+ "For modern Python versions (since version 2.3), interning a string (e.g. "
286+ "with :func:`sys.intern`) does not cause it to become immortal. Instead, if "
287+ "the last reference to that string disappears, it will be removed from the "
288+ "interned string table. This is not the case for the free-threaded build and "
289+ "any interned string will become immortal, surviving until interpreter "
290+ "shutdown."
291+ msgstr ""
292+
293+ #: ../../howto/free-threading-python.rst:188
294+ msgid "Non-GC objects have a larger object header"
295+ msgstr ""
296+
297+ #: ../../howto/free-threading-python.rst:190
298+ msgid ""
299+ "The free-threaded build uses a different :c:type:`PyObject` structure. "
300+ "Instead of having the GC related information allocated before the :c:type:"
301+ "`PyObject` structure, like in the default build, the GC related info is part "
302+ "of the normal object header. For example, on the AMD64 platform, ``None`` "
303+ "uses 32 bytes on the free-threaded build vs 16 bytes for the default build. "
304+ "GC objects (such as dicts and lists) are the same size for both builds since "
305+ "the free-threaded build does not use additional space for the GC info."
306+ msgstr ""
307+
308+ #: ../../howto/free-threading-python.rst:200
309+ msgid "QSBR can delay freeing of memory"
310+ msgstr ""
311+
312+ #: ../../howto/free-threading-python.rst:202
313+ msgid ""
314+ "In order to safely implement lock-free data structures, a safe memory "
315+ "reclamation (SMR) scheme is used, known as quiescent state-based reclamation "
316+ "(QSBR). This means that the memory backing data structures allowing lock-"
317+ "free access will use QSBR, which defers the free operation, rather than "
318+ "immediately freeing the memory. Two examples of these data structures are "
319+ "the list object and the dictionary keys object. See ``InternalDocs/qsbr."
320+ "md`` in the CPython source tree for more details on how QSBR is "
321+ "implemented. Running :func:`gc.collect` should cause all memory being held "
322+ "by QSBR to be actually freed. Note that even when QSBR frees the memory, "
323+ "the underlying memory allocator may not immediately return that memory to "
324+ "the OS and so the resident set size (RSS) of the process might not decrease."
325+ msgstr ""
326+
327+ #: ../../howto/free-threading-python.rst:216
328+ msgid "mimalloc allocator vs pymalloc"
329+ msgstr ""
330+
331+ #: ../../howto/free-threading-python.rst:218
332+ msgid ""
333+ "The default build will normally use the \" pymalloc\" memory allocator for "
334+ "small allocations (512 bytes or smaller). The free-threaded build does not "
335+ "use pymalloc and allocates all Python objects using the \" mimalloc\" "
336+ "allocator. The pymalloc allocator has the following properties that help "
337+ "keep memory usage low: small per-allocated-block overhead, effective memory "
338+ "fragmentation prevention, and quick return of free memory to the operating "
339+ "system. The mimalloc allocator does quite well in these respects as well "
340+ "but can have some more overhead."
341+ msgstr ""
342+
343+ #: ../../howto/free-threading-python.rst:227
344+ msgid ""
345+ "In the free-threaded build, mimalloc manages memory in a number of separate "
346+ "heaps (currently four). For example, all GC supporting objects are "
347+ "allocated from their own heap. Using separate heaps means that free memory "
348+ "in one heap cannot be used for an allocation that uses another heap. Also, "
349+ "some heaps are configured to use QSBR (quiescent-state based reclamation) "
350+ "when freeing the memory that backs up the heap (known as \" pages\" in "
351+ "mimalloc terminology). The use of QSBR creates a delay between all memory "
352+ "blocks for a page being freed and the memory page being released, either for "
353+ "new allocations or back to the OS."
354+ msgstr ""
355+
356+ #: ../../howto/free-threading-python.rst:237
357+ msgid ""
358+ "The mimalloc allocator also defers returning freed memory back to the OS. "
359+ "You can reduce that delay by setting the environment variable :envvar:`!"
360+ "MIMALLOC_PURGE_DELAY` to ``0``. Note that this will likely reduce the "
361+ "performance of the allocator."
362+ msgstr ""
363+
364+ #: ../../howto/free-threading-python.rst:244
365+ msgid "Free-threaded reference counting can cause objects to live longer"
366+ msgstr ""
367+
368+ #: ../../howto/free-threading-python.rst:246
369+ msgid ""
370+ "In the default build, when an object's reference count reaches zero, it is "
371+ "normally deallocated. The free-threaded build uses \" biased reference "
372+ "counting\" , with a fast-path for objects \" owned\" by the current thread and "
373+ "a slow path for other objects. See :pep:`703` for additional details. Any "
374+ "time an object's reference count ends up in a \" queued\" state, deallocation "
375+ "can be deferred. The queued state is cleared from the \" eval breaker\" "
376+ "section of the bytecode evaluator."
377+ msgstr ""
378+
379+ #: ../../howto/free-threading-python.rst:254
380+ msgid ""
381+ "The free-threaded build also allows a different mode of reference counting, "
382+ "known as \" deferred reference counting\" . This mode is enabled by setting a "
383+ "flag on a per-object basis. Deferred reference counting is enabled for the "
384+ "following types:"
385+ msgstr ""
386+
387+ #: ../../howto/free-threading-python.rst:259
388+ msgid "module objects"
389+ msgstr ""
390+
391+ #: ../../howto/free-threading-python.rst:260
392+ msgid "module top-level functions"
393+ msgstr ""
394+
395+ #: ../../howto/free-threading-python.rst:261
396+ msgid "class methods defined in the class scope"
397+ msgstr ""
398+
399+ #: ../../howto/free-threading-python.rst:262
400+ msgid "descriptor objects"
401+ msgstr ""
402+
403+ #: ../../howto/free-threading-python.rst:263
404+ msgid "thread-local objects, created by :class:`threading.local`"
405+ msgstr ""
406+
407+ #: ../../howto/free-threading-python.rst:265
408+ msgid ""
409+ "When deferred reference counting is enabled, references from Python function "
410+ "stacks are not added to the reference count. This scheme reduces the "
411+ "overhead of reference counting, especially for objects used from multiple "
412+ "threads. Because the stack references are not counted, objects with deferred "
413+ "reference counting are not immediately freed when their internal reference "
414+ "count goes to zero. Instead, they are examined by the next GC run and, if "
415+ "no stack references to them are found, they are freed. This means these "
416+ "objects are freed by the GC and not when their reference count goes to zero, "
417+ "as is typical."
418+ msgstr ""
419+
420+ #: ../../howto/free-threading-python.rst:276
421+ msgid "Per-thread reference counting can delay freeing objects"
422+ msgstr ""
423+
424+ #: ../../howto/free-threading-python.rst:278
425+ msgid ""
426+ "To avoid contention on the reference count fields of frequently shared "
427+ "objects, the free-threaded build also uses \" per-thread reference counting\" "
428+ "for a few selected object types. Rather than updating a single shared "
429+ "reference count, each thread maintains its own local reference count array, "
430+ "indexed by a unique id assigned to the object. The true reference count is "
431+ "only computed by summing the per-thread counts when the object's local count "
432+ "drops to zero. Per-thread reference counting is currently used for:"
433+ msgstr ""
434+
435+ #: ../../howto/free-threading-python.rst:286
436+ msgid "heap type objects (classes created in Python)"
437+ msgstr ""
438+
439+ #: ../../howto/free-threading-python.rst:287
440+ msgid "code objects"
441+ msgstr ""
442+
443+ #: ../../howto/free-threading-python.rst:288
444+ msgid "the ``__dict__`` of module objects"
445+ msgstr ""
446+
447+ #: ../../howto/free-threading-python.rst:290
448+ msgid ""
449+ "Because the per-thread counts must be merged back to the object before it "
450+ "can be deallocated, objects using per-thread reference counting are "
451+ "typically freed later than they would be in the default build. In "
452+ "particular, such an object is usually not freed until the thread that "
453+ "referenced it reaches a safe point (for example, in the \" eval breaker\" "
454+ "section of the bytecode evaluator) or exits. Running :func:`gc.collect` "
455+ "will merge the per-thread counts and allow these objects to be freed."
456+ msgstr ""
0 commit comments