-
Type:
Enhancement
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: 27
-
Component/s: hotspot
This is an umbrella issue. The work will also involve some refactorings which can be addressed separately to make it easier to review the changes.
Description:
We currently dump the C2 graphs in the Test VM to the hotspod_pid file by using -XX:+LogCompilation.
- We print many more things that are not used by the IR Framework
- We need to parse the relevant IR dumps again in the Driver VM in order to know on what we need to match the regexes on. This is more complex.
- This is also quite an overhead and limits future improvement possibilities to parallelize: The Driver VM is currently kept idle while the Test VM runs and only starts parsing once the Test VM is finished. By using sockets, the parsing/preparation of the received IR dumps can already be parsed and prepared to do start the IR matching as soon as the Test VM is finished. In the far future, it is also thinkable to already start IR matching while the Test VM still runs.
- With socket communication, we could experiment with leaving -Xbatch away for the Test VM to speed things up further. We could better synchronize over the socket to find the relevant compilation. This might be harder or even impossible by dumping to a file with LogCompilation.
- We had many problems in the past of interleaving dumps. This could be solved by using sockets.
- Currently, we look for the compilation enqueuing message first to find out the id of the compilation. This is used to map to the IR dump itself which only dumps the id and not the name of the method. This could be changed regardless of whether we use sockets or print to a file.
Therefore, this RFE proposes to change that to directly send the dumps to the dedicated TestFrameworkSocket. This means that each C2 compilation connects to the TestFrameworkSocket (in the Driver VM) to establish a unique connection to send the dumps.
Description:
We currently dump the C2 graphs in the Test VM to the hotspod_pid file by using -XX:+LogCompilation.
- We print many more things that are not used by the IR Framework
- We need to parse the relevant IR dumps again in the Driver VM in order to know on what we need to match the regexes on. This is more complex.
- This is also quite an overhead and limits future improvement possibilities to parallelize: The Driver VM is currently kept idle while the Test VM runs and only starts parsing once the Test VM is finished. By using sockets, the parsing/preparation of the received IR dumps can already be parsed and prepared to do start the IR matching as soon as the Test VM is finished. In the far future, it is also thinkable to already start IR matching while the Test VM still runs.
- With socket communication, we could experiment with leaving -Xbatch away for the Test VM to speed things up further. We could better synchronize over the socket to find the relevant compilation. This might be harder or even impossible by dumping to a file with LogCompilation.
- We had many problems in the past of interleaving dumps. This could be solved by using sockets.
- Currently, we look for the compilation enqueuing message first to find out the id of the compilation. This is used to map to the IR dump itself which only dumps the id and not the name of the method. This could be changed regardless of whether we use sockets or print to a file.
Therefore, this RFE proposes to change that to directly send the dumps to the dedicated TestFrameworkSocket. This means that each C2 compilation connects to the TestFrameworkSocket (in the Driver VM) to establish a unique connection to send the dumps.