Zstd library should be compatible with static allocation about zstd

[Bulat-Ziganshin]

LZMA api allows to pass alloc/free functions provided by the library user. On embedded systems, this custom alloc function then should just return pointers to preallocated static buffer.

[Cyan4973]

Implemented in v1.3.0

[DCNMS]

Thanks Yann to take the static allocation in consideration.

This compatibily would allow embedded system use. I target use on STM32.

[Cyan4973]

This objective looks today a bit difficult.

For decompression, it looks remotely possible, but difficult.
ZSTD_Dctx currently has a static size, yes, but a fairly large one.

Should this amount of memory be considered too large for embedded systems, reducing this memory is possible, especially when working with small data blocks. But then, it makes the required Dctx memory variable, which is exactly what must be avoided.

Over the long term, it's possible to reduce sharply the size of Dctx, but that would require a "dedicated" version, handling compressed data differently. Nothing technically impossible, just a different version, with the charge to maintain it. So my feeling is that it must be carefully pondered if it needs to be part of the reference library.

For compression, it starts by being worse : the amount of memory to reserve depends on the size of data to compress, and selected compression level. So it is variable, by construction.

The only solution I can think of would be to allow maximum memory size enforcement. In which case, the compression algorithm would refuse to start if it requires more than allowed memory. Rather than selecting a compression level, the caller should better use _advanced() variants, which allow control over individual parameters, in order to precisely control the amount of memory spent.

That being said, using current source code, the final amount of memory reserved can still be quite high even for small blocks, from an embedded system perspective. I haven't made a precise calculation, but I suspect that it requires a minimum close to 100 KB. Going lower is possible, but once again, it would require a specific version, designed to be frugal on memory space. Technically achievable, but a specific effort, with dedicated maintenance. Same question than the decompression part.

For discussion

[Cyan4973]

That's a good point @Bulat-Ziganshin .

Also, as a noticeable progress to note on this front, v0.6 now makes it possible to select fairly small memory sizes for decompression. Decoding tables are a mere 5 KB, and work buffers are now guaranteed to be <= block size, so a block size of 4 KB for example induces a pretty small memory budget for the decompressor.

[DCNMS]

This is a great news for the future. I am not on the subject for now, but I am sure I will use it in near future.

[Cyan4973]

Indirectly related to this topic : latest update in dev branch uses a lot less stack memory.
Expected to be compatible with systems which tolerate only <= 10KB stack space usage.

[Cyan4973]

With latest update of dev branch, there is now a way to implement zstd compression and decompression using static allocation. A set of functions has been added for this usage :
ZSTD_initStaticCCtx() : https://github.com/facebook/zstd/blob/dev/lib/zstd.h#L525
ZSTD_initStaticDCtx() : https://github.com/facebook/zstd/blob/dev/lib/zstd.h#L635

They both work the same : provide a buffer of yours, and the compressor/decompressor will use that space to do its job. In order to know how much space the object will need, call the relevant ZSTD_estimate?CtxSize() function : https://github.com/facebook/zstd/blob/dev/lib/zstd.h#L502

The size needed by ZSTD_CCtx is variable. It depends primarily on compression level, and sometimes also on size of buffer to compress. If at any moment, ZSTD_CCtx requires more memory than it is allowed to use, it will simply fail, with a memory_allocation error.
Note that, as long as ZSTD_estimateCCtxSize() is called with parameters created with largest expected compression level and largest expected source size, the estimation will provide maximum possible memory requirement, so ZSTD_CCtx memory needs will remain within intended limit.

ZSTD_estimateCCtxSize() is currently a bit complex, as it requires compression parameters, which can be created from ZSTD_getCParams() (https://github.com/facebook/zstd/blob/dev/lib/zstd.h#L587). While this gives finer control, it's also more complex than just providing a compression level. I might have to revisit that design, so that there is at least one version easier to use.

Another internal change is that CCtx and CStream objects are now the same.
(Same thing for DCtx and DStream by the way).
So a ZSTD_initStaticCCtx() can also do streaming operations.
But the memory budget is different, due to additional buffers, so it's necessary to evaluate it using ZSTD_estimateCStreamSize() (https://github.com/facebook/zstd/blob/dev/lib/zstd.h#L509).
Having 2 different names (CStream, CCtx) might be confusing though.
So I'm wondering if it could be improved, by either providing a ZSTD_initStaticCStream(), which would technically be exactly the same, but would make the naming (CStream) more consistent,
or naming everything CCtx, and have an additional parameter, like streamingEnabled, in ZSTD_estimateCCtxSize() function.

The initStatic implementation has 2 limits :

• It's only compatible with single-thread mode. Multi-thread requires more memory and scatter it in a less predictable way, so there is no short-term adaptation. In the longer term though, it might be possible to be more restrictive/selective in the way memory is allocated and used, and thus become more compatible with a static allocation strategy. But nothing simple.
• It's not able to "create an internal dictionary for bulk operation". That's a complex concept, but to simplify, it's something which happens transparently in ZSTD_initCStream_usingDict(), so this function is not compatible.
  The work around is to create the dictionary explicitly, using ZSTD_createCDict(), and then just reference it with ZSTD_initCStream_usingCDict().
  I guess that if static allocation is needed for ZSTD_CCtx, it's likely going to be needed for ZSTD_CDict too. So there is another set of functions to create dictionaries into static memory :
  ZSTD_initStaticCDict() : https://github.com/facebook/zstd/blob/dev/lib/zstd.h#L568
  ZSTD_initStaticDDict() : https://github.com/facebook/zstd/blob/dev/lib/zstd.h#L675

Well, as you can guess, this API is in its infancy, and feedbacks are welcomed.

[Cyan4973]

The API has been slightly updated in latest dev branch update
to simplify its usage.

Most importantly, the associated ZSTD_estimate*Size() functions have been simplified, so that it's easier to request a size without detailed knowledge of the algorithm (a compression level is enough). More powerful and complex variants still exist, under the _advanced() label.

Also, ZSTD_initStaticCStream() and ZSTD_initStaticDStream() have been added. Even though they perform the same action as their {C,D}Ctx equivalent, it's cleaner from a naming perspective, since the code flow will be able to manipulate only {C,D}Stream names.