TeaVM TODOlist

[Ihromant]

Hi @konsoletyper . In the beginning I started using teavm and fixing bugs I spot during pet project development. After implementing Collectors.groupingBy I have everything for further development (for now). Still, often on tuesdays I have one activity where I have around 1-2 hours of free time with laptop. To spend this time, I just went to teavm.org, looked at not implemented methods from JDK and tried to implement it (I'm not using them, but someone would). So, according to this, next question appeared:

Does TeaVM has some TODOlist?

I am asking this from you because you are author of this framework and better know it weak parts which can be implemented by community members, but you have no time or desire for it.
Thanks in advance.

[konsoletyper]

TeaVM certainly has a todo list, but it's all in my head. I need some time and efforts to make this list available to community, but these efforts won't pay off due to following reasons: working on compiler core is a very difficult task and requires advanced programming skills and knowledge in compiler engineering. Since there are few compiler engineers, there's very little chance that someone of these guys just go and do all the work for free. Also, I have my own view on how TeaVM should evolve, and to share this view I need a lot of time. Also, I found that PR authors usually don't care about communication and just create PR, without asking me if I had my opinion about this or that feature. Then I try to start to communicate and PR authors argue and end up in calling me "not flexible enough" or "rude". Sometimes people start communicating, I invest my time into explanations and discussions and then they suddenly disappear. I hate this, because it's investment of my resources into nothing.

So, from my experience in Kotlin team I would say this: there's no way "community" would implement something significant within compiler core, even if it's Kotlin community. There's de-facto no such thing as "TeaVM community", there are just people who accidentally using TeaVM.

Sure, with Java standard library implementation things are much easier, and usually people able to implement features there. But as for Java standard library, there's no such "todo list" even in my head. There's only one principle here: the more of Java standard library is ported, the better. I think it happens in the following way: someone, who is really interested in TeaVM, tries to use it, encounters missing features and creates issue or PR, and that's it.

As for compiler core, that's a brief overview, incomplete, just what I remember:

1. Refactor IR.
   • MethodReference/FieldReference and class names as strings should be removed, instead all references to methods should be references to MethodHolder objects.
   • More compact representation of program. Perhaps, instead of having Program as a property of MethodHolder, IR should provide ways to query/save Program instance for MethodHolder, but actual representation of IR inside MethodHolder should be different.
   • Get rid of Variable, at least in SSA-form. Instead, certain instructions, that generate values, should be Definitions and all instructions that consume values should point on these definitions.
   • Introduce backend-specific attributes on IR objects (methods, classes, fields, etc).
   • Make better 'transformation' API, e.g. make it lazier, allow to transform separate methods, etc.
2. Refactor dependency analyzer.
   • Improve performance and reduce memory consumption. On small projects it's not an issue, but in the project I'm currently working on it's more than 500 KLOC, and it takes TeaVM 3 minutes and 5Gb RAM to compile. I have some ideas there.
   • Improve accuracy in some cases, for example, when there's if (value instanceof C) { body }, then body should not be visited until (if) subtype of C actually propagated to set of value types.
3. Optimize what I call (not 100% correct) 'register allocator', i.e. that part that converts IR out of SSA-form. Currently, it's the slowest part of compiler and it's based on building interference graphs, which are huge.
4. Improve JS BE: reduce memory consumption, reduce size of generated JS, improve architecture.
5. Make Wasm BE closer to production-ready state:
   • Fix remaining bugs
   • Ensure that all (reasonable) tests pass, review failing tests and mark them as skipped for Wasm
   • Implement JS interop
   • Figure out why generated DWARF does not work in Chrome
   • Implement hprof format generator from Wasm heap.
6. Introduce better inliner and optimizations, make inline decisions based on various heuristics, combine parts of inlining and optimization pipelines.
7. Implement better interop for JS: make it possible to produce modules with exported functions, to import declarations from modules, support native constructors and instanceof for non-interface declarations.

[Ihromant]

Thanks. For me for now it's like "rocket science" but once I have free time, I'll try to understand it.
My pet project is 30 KLOC, on my laptop I already have around 20 sec compilation. But I'm developing it mostly on PC where first compilation time is 4-5 sec and recompilation takes only 1 sec. Still, performance improvements are very important.
7th point I like very much, I suppose this feature is requested by random visitors like twice a year. :D