Message-ID: <1691450716.209.1419020546635.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_208_1490574653.1419020546635" ------=_Part_208_1490574653.1419020546635 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The primordial class list indicates which classes should be comp= iled and baked into the boot image. The bare minimum set of classes needed = in the primordial list includes;=20
For increased performance and decreased startup time it is possible to i= nclude extra classes that are expected to be needed. i.e. the optimizing co= mpiler or the adaptive system. There are some pieces of these components th= at would be awkward to load dynamically (there's a core subset of the opt c= ompiler, the classes in the org.jikesrvm.compilers.opt.runtimesupport packa= ges, the must be loaded and fully compiled before any opt-compiled code can= be allowed to executed), but it's theoretically possible to do so.=20
If you took a full closure of the classes referenced by things that have= to be in the bootimage you'd actually end up with a lot more in the bootim= age than we currently have. The culprit here would I think mainly be java.*= classes that we need in the bootimage, but only use in restricted ways, so= we don't actually have to drag in everything they depend on to meet the &q= uot;real" constraints of what has to go in the bootimage. It is unknow= n how much difference there is between hand-crafted include lists and what = an automated tool would discover.