For something simple like adler32 this is about 200x slower than using Java djberg96/pr-zlib#3 (comment), and I would imagine that gets worse for less tight code, so this is perhaps not the final code we'll use for zlib. However the functionality seems almost perfect for now.

It looks good to me. It's surprising the imported lib gets everything but CRC32 right, though.

Could we keep the few methods we already implement?
Particularly the highly numeric ones?

Could do. I removed them as they aren't being used in anything high performance yet and I felt like less code to maintain was better until we did. What does everyone else think? Of course the Java code is still there if we want it now, or in the future.

I'll merge this as is. The Java equivalents are not friendly to AOT, so removing them for now simplifies both our Java codebase and the SVM substitutions. We can put them back as soon as we see a high-performance use case.

@chrisseaton did you have time to investigate why is it that much slower? Bad algorithms or we do not optimise it well?

I haven't looked into it in any depth - but I just wanted it for the completeness rather than the performance for now.