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
