History data for "JDK-8058150: Compile for Specific Platform Version"
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Fri Feb 27 13:48:00 UTC 2015
On 2015-02-27 09:31, Jan Lahoda wrote:
> 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) ~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
> 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
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?
More information about the build-dev