History data for "JDK-8058150: Compile for Specific Platform Version"

[Magnus Ihse Bursie]

Hi Jan,

On 2015-02-27 09:31, Jan Lahoda wrote:
> Hi,
>
> I have a question on JDK-8058150: "Compile for Specific Platform 
> Version". To support compilation for older versions of the platform, 
> javac will need some description of the APIs as they existed in the 
> target platforms.
>
> For this, the current proposal is to use lib/ct.sym file (similar, but 
> different, to the JDK 8 lib/ct.sym), containing classfiles of the 
> older APIs. This file would be constructed at build time from a 
> textual representation of the APIs stored in an OpenJDK repository 
> (currently called ct.sym.txt).
>
> The current ct.sym.txt is a single file that contains APIs for all 
> supported versions, reusing entries for multiple versions when needed. 
> An alternative would be to use ct7.sym.txt for JDK 7 APIs, ct8.sym.txt 
> for JDK 8 APIs, etc. Using a single file leads to a smaller total size 
> (as it reuses entries where it can), but needs to be considerably 
> changed when a new version is added or an obsolete version is removed.
>
> The size of the file is considerable: for the "ct.sym.txt" that 
> represents APIs from OpenJDK 7 and 8, the size of the checked-out file 
> in the working copy is (currently[2]) ~23MB, and inside the .hg 
> directory, the file has ~1.7MB (Mercurial is apparently able to 
> compress the ct.sym.txt file very well - but as all history is kept 
> inside .hg directory, the size of the file inside the .hg directory 
> increases when the ct.sym.txt is updated).

In my opinion, the only size that matters here is in the .hg directory. 
If the workspace takes 23 MB more or less is a non-issue when a full 
forest clone is in the gigabyte range. But I don't think 1.7 MB extra 
for the top-level repo is much of a problem either. Since the top-level 
repo currently is so tiny, it will grow noticably in percentage. But 
compare this with hotspot/.hg on 67 MB or jdk/.hg on 351 MB.

If you have a proper text format so future edits can be made as trivial 
diffs, then the mercurial storage will not grow noticable in the future 
either.

> Another alternative would be to partition the file into several 
> smaller files - would be easier to grasp, but if the files would be 
> too small, the compression would be worse (leading to bigger 
> repositories).
What is the actual difference? Having too large files can be burdensome 
on other tools as well, eg. if you open it (mistakenly or not) in a text 
editor. I would tend to prefer several smaller files than one huge.
> Currently, the proposal is to place the ct.sym.txt file into the 
> top-level repository. A prototype of this feature is currently in the 
> jdk9/sandbox forest, on branch JDK-8058150-branch. The current 
> ct.sym.txt file is <top-level-repository>/make/data/symbols/ct.sym.txt.
Sounds like a good place to put such a file. I assume it will be 
processed during building?

/Magnus