[GSoC] Use a compact hash table for RubyHash instead of the buckets strategy by moste00 · Pull Request #3172 · oracle/truffleruby (original) (raw)

There's a lot of code to work through here. I haven't done a comprehensive pass on the core logic yet. I think if you apply some of the feedback I suggested, it'll be easier to follow the logic.

As a couple of other general notes:

You have several branches without a profile. That's fine for a first pass, but will likely limit your performance, unless all branches are equally likely.
You're missing some necessary boundaries.

An easy way to check if you're missing a necessary boundary is to run jt build --env native. It's slow, but if you end up with output like:

Deepest level call tree path (47 calls):
   62 ; com.sun.org.apache.xerces.internal.impl.xpath.regex.ParserForXMLSchema.getRange(ParserForXMLSchema.java:381) ; com.sun.org.apache.xerces.internal.impl.xpath.regex.ParserForXMLSchema.setupRange(Token, String)
  489 ; com.sun.org.apache.xerces.internal.impl.xpath.regex.ParserForXMLSchema.getTokenForShorthand(ParserForXMLSchema.java:321) ; com.sun.org.apache.xerces.internal.impl.xpath.regex.ParserForXMLSchema.getRange(String, boolean)
  145 ; com.sun.org.apache.xerces.internal.impl.xpath.regex.RegexParser.parseAtom(RegexParser.java:783) ; com.sun.org.apache.xerces.internal.impl.xpath.regex.ParserForXMLSchema.getTokenForShorthand(int) ; com.sun.org.apache.xerces.internal.impl.xpath.regex.RegexParser.getTokenForShorthand(int)
  440 ; com.sun.org.apache.xerces.internal.impl.xpath.regex.RegexParser.parseFactor(RegexParser.java:677) ; com.sun.org.apache.xerces.internal.impl.xpath.regex.RegexParser.parseAtom()

then you'll know you missed one. The output is letting you know the Native Image attempted to compile too many methods for runtime compilation. Now, that's a slow process, so you may find it more advantageous to go through the code and try to reason about it or add boundaries everywhere and work to eliminate them.

Another option available is to modify mx.truffleruby/native-image.properties to add the PrintRuntimeCompilationCallTree host option:

diff --git a/mx.truffleruby/native-image.properties b/mx.truffleruby/native-image.properties index 5be3cebd3b..72ade59fda 100644 --- a/mx.truffleruby/native-image.properties +++ b/mx.truffleruby/native-image.properties @@ -4,6 +4,7 @@ Requires = language:nfi language:llvm language:regex

Args = -H:MaxRuntimeCompileMethods=5400 \

  -H:+PrintRuntimeCompilationCallTree \
  -H:+AddAllCharsets \
  --initialize-at-build-time=org.truffleruby,org.jcodings,org.joni

That'll modify the output of jt build --env native to include the call tree for each method made available for runtime compilation. It's a ton of output, but if you see a deeply nested entry and work your way back to its root you can identify areas that need boundaries that way. Alternatively, since all of this code lives in CompactHashStore, you can search for that and look for long call trees stemming from that entry.