How can I see where the sjavac_server is started?
jonathan.gibbons at oracle.com
Wed Feb 27 16:41:41 UTC 2019
What Erik stated regarding javac and sjavac is not entirely correct:
currently, javac does not itself support starting a background server,
although that is a goal that we (javac team) would like to achieve.
Instead, it is the case that sjavac provides various facilities,
including the ability to start a background server, and to do "smart
compilation" by determining the reduced set of files that need to be
recompiled. The current build uses the first point (the ability to
start a background server) but not the second. It is my understanding
that the background server is started by the first invocation of sjavac,
which is given suitable parameters to enable it to do so.
On 2/27/19 7:51 AM, Erik Joelsson wrote:
> Hello Andrew,
> On 2019-02-26 12:09, Andrew Haley wrote:
>> I'm seeing a crash in the javac server while building openjdk.
> We are seeing this too intermittently.
>> I want to run the exact same command that started the server running,
>> but even with LOG=debug I cannot find the command line that starts
>> it. The command seems not to be there at all.
>> So, how exactly does the javac server get started, and how do I find
>> the command line that started it?
> The server is started lazily by the first javac invocation that needs
> it. There is a parameter given to javac that describes how it should
> be started, but to get the exact command line, you would have to
> instrument javac java source. You should be able to add additional
> parameters to that JVM, at least by editing spec.gmk, that could help
> you with diagnostics.
>> And, incidentally, given that I'f configured with --disable-sjavac,
>> why is the build running a javac server? Thanks.
> The "smart javac" and the javac server are not one the same. The
> server was introduced in sjavac, but the server part was later ported
> over to javac proper (I think). So now we have two configure
> arguments, --enable-sjavac and --disable-javac-server. The latter is
> what you are looking for.
> I think we should really get rid of sjavac since the relevant benefits
> are already present in the default build, with the javac server and
> the dependency plugin. The only possible benefit of sjavac today would
> be more fine grained incremental build support, but I doubt it works
> very well given that it's not being maintained.
More information about the build-dev