Allow JITServer to ignore line number requests - #19999
Conversation
|
Attn @mpirvu. This environment variable did seem to improve the failure rate of #14755, though the failures (at the client and server) are strange enough that full logs weren't of as much help as I would have liked. I originally implemented (and tested) this as a new |
|
The line endings check error looks like a network failure. |
mpirvu
left a comment
mpirvu
left a comment
There was a problem hiding this comment.
LGTM. The only caveat I see is that we have to remember to use the env var at the server and not at the client.
I think there is some doc about how to debug JITServer issues. Could you please update that doc with this env var?
The method getLineNumberForMethodAndByteCodeIndex, in the base VM frontend, is supposed to retrieve the line number corresponding to a method and byte codex index from the method's associated ROM method. At the server, these line numbers are not directly accessible, so the server must request this information from the client whenever that method is called. These line numbers appear to be used only when generating compilation logs. The most notable use of this method for that purpose is in dumping IL trees - for every line of this dump, this method will be called. Even this network overhead is not usually significant. However, if the method being compiled at the server is very large, at a high optimization level, and has many trace options enabled, these line number messages can slow the compilation significantly. This can make some test failures more difficult to reproduce, if they are timing-sensitive. The environment variable TR_JITServerShouldIgnoreLineNumbers will, if set in the server environment, cause the server to skip consulting the client for line numbers, and instead return -1 from this method always. This results in a moderate decrease in remote compilation time in the scenario outlined above, and can improve test failure reproducibility. Compilations of large methods will still be much slower at high optimization and trace levels, however, so this won't necessarily solve the issue fully. Signed-off-by: Christian Despres <despresc@ibm.com>
45b1432 to
870fe54
Compare
|
jenkins test sanity zlinuxjit,xlinuxjit jdk21 |
2 participants
The method getLineNumberForMethodAndByteCodeIndex, in the base VM frontend, is supposed to retrieve the line number corresponding to a method and byte codex index from the method's associated ROM method. At the server, these line numbers are not directly accessible, so the server must request this information from the client whenever that method is called.
These line numbers appear to be used only when generating compilation logs. The most notable use of this method for that purpose is in dumping IL trees - for every line of this dump, this method will be called. Even this network overhead is not usually significant. However, if the method being compiled at the server is very large, at a high optimization level, and has many trace options enabled, these line number messages can slow the compilation significantly. This can make some test failures more difficult to reproduce, if they are timing-sensitive.
The environment variable TR_JITServerShouldIgnoreLineNumbers will, if set in the server environment, cause the server to skip consulting the client for line numbers, and instead return -1 from this method always. This results in a moderate decrease in remote compilation time in the scenario outlined above, and can improve test failure reproducibility. Compilations of large methods will still be much slower at high optimization and trace levels, however, so this won't necessarily solve the issue fully.