From 44fedddc11c3f6ec2f7fe35a3e38f15ca93f90eb Mon Sep 17 00:00:00 2001 From: Lasse Collin Date: Mon, 22 Aug 2022 18:13:56 +0300 Subject: [PATCH] Add NEWS for 5.3.3alpha. --- NEWS | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) diff --git a/NEWS b/NEWS index ae97caca..18bee15a 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,125 @@ XZ Utils Release Notes ====================== +5.3.3alpha (2022-08-22) + + * All fixes from 5.2.6. + + * liblzma: + + - Fixed 32-bit build. + + - Added threaded .xz decompressor lzma_stream_decoder_mt(). + It can use multiple threads with .xz files that have multiple + Blocks with size information in Block Headers. The threaded + encoder in xz has always created such files. + + Single-threaded encoder cannot store the size information in + Block Headers even if one used LZMA_FULL_FLUSH to create + multiple Blocks, so this threaded decoder cannot use multiple + threads with such files. + + If there are multiple Streams (concatenated .xz files), one + Stream will be decompressed completely before starting the + next Stream. + + - A new decoder flag LZMA_FAIL_FAST was added. It makes the + threaded decompressor report errors soon instead of first + flushing all pending data before the error location. + + * xz: + + - Using -T0 (--threads=0) will now use multi-threaded encoder + even on a single-core system. This is to ensure that output + from the same xz binary is identical on both single-core and + multi-core systems. + + - A default soft memory usage limit is now used for compression + when -T0 is used and no explicit limit has been specified. + This soft limit is used to restrict the number of threads + but if the limit is exceeded with even one thread then xz + will continue with one thread using the multi-threaded + encoder and this limit is ignored. If the number of threads + is specified manually then no default limit will be used; + this affects only -T0. + + This change helps on systems that have very many cores and + using all of them for xz makes no sense. Previously xz -T0 + could run out of memory on such systems because it attempted + to reserve memory for too many threads. + + This also helps with 32-bit builds which don't have a large + amount of address space that would be required for many + threads. The default limit is 1400 MiB on all 32-bit + platforms with -T0. + + Now xz -T0 should just work. It might use too few threads + in some cases but at least it shouldn't easily run out of + memory. It's possible that this will be tweaked before 5.4.0. + + - Changes to --memlimit-compress and --no-adjust: + + In single-threaded mode, --memlimit-compress can make xz + scale down the LZMA2 dictionary size to meet the memory usage + limit. This obviously affects the compressed output. However, + if xz was in threaded mode, --memlimit-compress could make xz + reduce the number of threads but it wouldn't make xz switch + from multi-threaded mode to single-threaded mode or scale + down the LZMA2 dictionary size. This seemed illogical. + + Now --memlimit-compress can make xz switch to single-threaded + mode if one thread in multi-threaded mode uses too much + memory. If memory usage is still too high, then the LZMA2 + dictionary size can be scaled down too. + + The option --no-adjust was also changed so that it no longer + prevents xz from scaling down the number of threads as that + doesn't affect compressed output (only performance). After + this commit --no-adjust only prevents adjustments that affect + compressed output, that is, with --no-adjust xz won't switch + from multithreaded mode to single-threaded mode and won't + scale down the LZMA2 dictionary size. + + - Added a new option --memlimit-decompress-mt=LIMIT. This is + used to limit the number of decompressor threads (possibly + falling back to single-threaded mode) but it will never make + xz refuse to decompress a file. This has a system-specific + default value because without any limit xz could end up + allocating memory for the whole compressed input file, the + whole uncompressed output file, multiple thread-specific + decompressor instances and so on. Basically xz could + attempt to use an insane amount of memory even with fairly + common files. + + The new option works together with the existing option + --memlimit-decompress=LIMIT. The old option sets a hard limit + that must not be exceeded (xz will refuse to decompress) + while the new option only restricts the number of threads. + If the limit set with --memlimit-mt-decompress is greater + than the limit set with --memlimit-compress, then the latter + value is used also for --memlimit-mt-decompress. + + * Tests: + + - Added a few more tests. + + - Added tests/code_coverage.sh to create a code coverage report + of the tests. + + * Build systems: + + - Automake's parallel test harness is now used to make tests + finish faster. + + - Added the CMake files to the distribution tarball. These were + supposed to be in 5.2.5 already. + + - Added liblzma tests to the CMake build. + + - Windows: Fix building of liblzma.dll with the included + Visual Studio project files. + + 5.3.2alpha (2021-10-28) This release was made on short notice so that recent erofs-utils can