Binary size #71

So this is pretty much expected, isn't it. Not only the compiled projects are slow (which we talked about in the other issue), their binary is also about 20 times bigger than wasm->chicory coupling.

The other issue talks about how generics will improve the binary size compared to monomorphisation, and that is probably true, but I wouldn't treat it as a primary solution, I expect monomorphed version to be significantly faster than generic one (unless we get Valhalla, of course). So here are a few places to cut the size.

• String constants. Really.
  • For example, this code:

  NEW java.lang.RuntimeException
  DUP
  LDC "Unreachable code reached"
  INVOKESPECIAL java.lang.RuntimeException.<init>(Ljava/lang/String;):V
  

  is repeated in a lot of places. So why not create a org.rustlang.Unreachable extending RuntimeException? I suspect there might be more cases like this.
  • Type names. As far as I see, Pointer methods take a lot of String arguments. It might go away if you just reduce Pointer usage, but still. I might be wrong on this, I am only reader here, but I don't see why those have to be Strings, because all I could find is either using them for equality, and using them for obtaining some typeinfo like "is it zero-size", "is it built-in" etc, which might be encoded into something less weighty, like bitmaps. I would propose interning: enumerate them with longs and use longs to carry those type names. You can then:
    • Simply store a file with typename list in classpath, and resolve only when needed. I imagine, they repeat across files a lot.
    • Use LDC with dynamic descriptor to load those strings by long identifiers
    • Introduce a dedicated type descriptor class and create with by LDC-descriptor, but the parameters are said unique id and bitmaps.
    • Probably something even smarter I didn't think of
• And speaking of LDC, there are sure a lot of PointerCodecs. Each of them an empty constructor, two methods -- encode and decode into/from bytes -- and implements RustCopy with a call to that empty constructor. And I am pretty sure those encode-decode methods are generated automatically based on the type layout, right? So I would think about creating a metafactory that creates those classes when needed. Honestly I don't know, might be difficult to do on earlier jdks without classfile api, but I assume the code can be accurately plucked from the stdlib and downgraded to lower bytecode versions.
• ... and speaking of LDC, there are sure a lot of Closures. From what I see, they usually implement some functional interface, rustcopy and that's it. Plus, call is usually (or always) just a wrapper to call some Mono method. So I would think about writing an alternative to lambda metafactory (stdlib one won't cooperate with RustCopy), and use INDY to create them. I assume the same can be done about TraitObjectCarrier and other interfaces that have ridiculously many implementations.