RFR 8054717: SJavac should track changes in the public apis of classpath classes!

[Fredrik Öhrström]

The path to a super thin client is quite long with a lot of interesting
technical problems (I suppose that is why the royal we has not authorized
RFR:8044131 since that does not reach the thin client in one go, but is a
mere first step) however classpath dependency tracking is needed now.



2014-08-22 0:05 GMT+02:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:

> Fredrik,
>
> Can you please explain the following some more:
>
>  It is important that this public api scanning does not require a javac
>> server started though.
>>
>
> This is /not/ the direction we want to take sjavac.  We want to change
> sjavac from its current client/server split to a (very) thin client, with
> most of the work happening in the server.   In some version of an ideal
> world, the client would be so simple it could be written in C and not
> invoke a JVM at all.   The client should just locate the server (starting
> it if necessary) and then dispatch its command line args to be processed in
> the server.
>
> Doing more and more work in a cold unshared JVM to avoid doing work in a
> hot shared JVM seems like a bad way to go.
>
> -- Jon
>
>
>
>
> On 08/21/2014 01:42 AM, Erik Joelsson wrote:
>
>> I can't comment on the code quality of this patch, but I do think this
>> feature is important. I can't recommend people to try sjavac with a
>> straight face at the moment as it will no longer guarantee a correct
>> incremental build. The current behavior when I add a public field to
>> java/lang/Object is that all of java.base is recompiled, then the rest of
>> the modules are sent to sjavac (as make thinks they need to be recompiled)
>> and sjavac does nothing with them.
>>
>> /Erik
>>
>> On 2014-08-09 00:22, Fredrik Öhrström wrote:
>>
>>> Here is very useful feature addition to sjavac, in fact it is required
>>> for a modularized OpenJDK build (Jigsawified), where not all sources are
>>> sent to sjavac at the same time.
>>>
>>> sjavac should track the public apis of the classes in the classpath,
>>> that the previous compile has linked to. If the public api of the linked to
>>> classes has changed, then this should trigger a recompile of the
>>> appropriate sources.
>>>
>>> This is a very useful feature. Currently sjavac must be fed all sources
>>> that belong to the product in a single huge compile. The OpenJDK is already
>>> at the limit of what fits in a reasonable (of today) sized Java heap. Other
>>> products are significantly larger and therefore cannot make use of the
>>> incremental compile in sjavac.
>>>
>>> With this feature, it is possible to compile the product as separate jar
>>> files, as long as the build dependencies for the jar files are a directed
>>> acyclic graph, then each succesive compile will detect if there were any
>>> changes in the public apis of the dependency jar files. If the public apis
>>> of the dependencies were not changed, and there were no other source
>>> changes for that jar, it will not be recompiled! But if there were changes
>>> in the public apis of the dependencies, then only the appropriate parts of
>>> the jar will be recompiled!
>>>
>>> This is the first draft of this large patch. In particular the new file
>>> Compile.java is a misnamer, it does NOT compile, it is used to extract the
>>> public apis of the classes on the classpath. Somehowe Compile.java should
>>> perhaps be part of JavaService. It is important that this public api
>>> scanning does not require a javac server started though.
>>>
>>> http://cr.openjdk.java.net/~ohrstrom/webrev-8054717-classpathdep/ <
>>> http://cr.openjdk.java.net/%7Eohrstrom/webrev-8054717-classpathdep/>
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8054717
>>>
>>> //Fredrik
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140822/6142a2cc/attachment.html>