Order of entries in make/mapfiles/reorder-*

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Order of entries in make/mapfiles/reorder-*

David Holmes
I have to add new entries to the mapfiles. How is the order in the
reorder-* files determined?

Thanks,
David
Reply | Threaded
Open this post in threaded view
|

Re: Order of entries in make/mapfiles/reorder-*

David Holmes
Nobody?

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
Reply | Threaded
Open this post in threaded view
|

Re: Order of entries in make/mapfiles/reorder-*

Magnus Ihse Bursie
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

Reply | Threaded
Open this post in threaded view
|

Re: Order of entries in make/mapfiles/reorder-*

David Holmes
On 8/12/2017 7:53 PM, 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.

If an exported API is not in the reorder file then the build fails. So I
have to add the new methods to it. The content of the files is very
mysterious with apparent comments that make no sense

# Test Null
# Test Hello

etc.

I'll just add them close to existing related entries.

Thanks,
David

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Order of entries in make/mapfiles/reorder-*

Claes Redestad
In reply to this post by Magnus Ihse Bursie
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Order of entries in make/mapfiles/reorder-*

Tim Bell
In reply to this post by David Holmes
Hi David, Magnus:

 > On 8/12/2017 7:53 PM, Magnus Ihse Bursie wrote:
>> On 2017-12-08 07:26, David Holmes wrote:
>>> Nobody?

Remember Fred Oliver?

>> 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.

Looks like that was back in the 1.5 timeframe, if not before.  In those
days, startup and footprint were a Very Big Deal.

Mailfinder uncovered this:
   http://mailfinder.us.oracle.com/message/9422570

See also:

JDK-5075487 Update jar reordering for 1.5
https://bugs.openjdk.java.net/browse/JDK-5075487

The description on 5075487 implies that reordering and class data
sharing go hand in hand:

     The reordering mechanism for the jar files in the JRE should change
     to use the same classlist data needed by the class data sharing.

>> 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.
>
> If an exported API is not in the reorder file then the build fails. So I
> have to add the new methods to it.


> The content of the files is very mysterious with apparent comments that make no sense
>
> # Test Null
> # Test Hello

That could line up with .java files here:
    <jdk>/open/src/utils/reorder/tests

This pre-dates OpenJDK.  You have to go back to the SCCS history for
more information:

> sccs prs /java/re/jdk/6/promoted/latest/ws/j2se/make/tools/reorder/JarReorder.java

The /java/re/jdk/6/... mountpoint is still available from
nightsvr.us.oracle.com if you do not have it.  So is /usr/xpg4/bin/sccs

Tim


>
> etc.
>
> I'll just add them close to existing related entries.
>
> Thanks,
> David
>
>> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: Order of entries in make/mapfiles/reorder-*

Tim Bell
On 12/08/17 08:25, Tim Bell wrote:
> Looks like that was back in the 1.5 timeframe, if not before.

My mistake.  All this predates OpenJDK, so not appropriate for the open
list.  I'll remove it.

My apologies.

Tim

Reply | Threaded
Open this post in threaded view
|

Re: Order of entries in make/mapfiles/reorder-*

David Holmes
In reply to this post by Claes Redestad
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
>>
>