shannah
commented
8 months ago In ParparVm we faced similar issues for strings. Strings frequently needed to be converted to native strings (NSString). Our solution was to cache a reference to the corresponding NSString in the Java String object so that it was cheap to do the conversion. There were several places where we needed to implement special native implementations for string functionality (e.g. StringBuilder, substrings, and pretty much any place where the default implementation operates on the underlying char[] array).
konsoletyper
Ihromant
Currently, TeaVM implements strings as objects which have
char[]field inside, right how old versions of OpenJDK did. However, for JavaScript it produces several performance issues. First, some of string methods could have been implemented via corresponding JavaScript methods, but need to copy between native string and char arrays makes this not reasonable WRT performance. Second, JS interop also suffers from bad performance. Another mechanism should be used for JavaScript BE: instead ofchar[]actual container for chars should be native string (i.e.JSString). This is currently impossible to express with current architecture, so either a new approach to specialize classes for backends should be introduces or in existing String implementation all communication with actual storage should be abstracted into methods and intrinsified in backends.