Thanks for the pointers! I had not connected these mapfile/reorder-*
files directly with the old rt.jar reordering - though I guessed they
served a similar purpose. As Tim later mentions the strange comments in
the file do seem to match up to the tests.
As these mapfiles are needed for the build to actually work they can't
be removed without changing the way the build is done. But it seems
likely that the order of the entries is no longer relevant.
David
On 9/12/2017 1:32 AM, Claes Redestad wrote:
I think the tool to generate these reorder files exist under
src/utils/reorder, but looking at
src/utils/reorder/Makefile it seems to have bit-rotted over the years..
the bootclasspath tricks
with rt.jar etc likely won't even work today:
# This Makefile is intended to produce new reordering files for the
# reordering of jar files and shared libraries. This is not part of the
# standard build. The objects produced by this Makefile must be copied
# into their standard locations and checked in.
I'm not sure any of this is relevant in the modular world (as most jar
files are now merged
into lib/modules, which has a separate reordering facility that is
automatically generated on
build and enforced by jlink).
File a bug to investigate and potentially remove it all?
/Claes
On 2017-12-08 10:53, Magnus Ihse Bursie wrote:
On 2017-12-08 07:26, David Holmes wrote:
Nobody?
I don't know. They existed long time before I started working on the
build system. I believe they were an attempt to optimize the layout
based on some test that ran years and years ago. It's likely that they
do nothing (at best) or worsen performance (at worst). Very few
libraries has these reorder files any more. If you think you need to
update one, I think a reasonable course of action is to remove it
instead.
Maybe Claes can help me confirm my speculation about performance..?
/Magnus
On 7/12/2017 8:15 PM, David Holmes wrote:
I have to add new entries to the mapfiles. How is the order in the
reorder-* files determined?
Thanks,
David
