JDK-6184224 : function reorder (mapfiles) should be enabled for solaris amd64 platform
  • Type: Enhancement
  • Component: performance
  • Sub-Component: libraries
  • Affected Version: 6
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2004-10-25
  • Updated: 2014-02-27
  • Resolved: 2012-12-05
Related Reports
Relates :  
JDK-4771277 - Improve jar file reordering
Relates :  
JDK-7176825 - NPG: Redo mapfile ordering optimization
Relates :  
JDK-5094505 - Launcher needs to support amd64 on Solaris
Description
Name :- vj102386                                    Date :- 2004-10-25
----------------------------------------------------------------------

As part of the solaris amd64 reordering is disabled for solaris amd64 platform.

Following files are affected. We need to enable the reorder for solaris amd64 platform.

make/java/hpi/native/Makefile
make/java/java/Makefile
make/java/verify/Makefile
make/java/zip/Makefile
make/sun/awt/mawt.gmk
make/sun/jpeg/Makefile
###@###.### 10/25/04 23:21 GMT
Comments
With JDK-7176825 a decision was made to drop mapfile function reordering. That makes this request invalid. Being closed as will not fix.
05-12-2012
EVALUATION Support for AMD platform was not the target of the original mapfiles work. This request to implement AMD function reorder should be an RFE. So, I'm changing it toand RFE. Given Alejandro's recent data that suggests updated function reording isn't showing a noticeable performance difference on current arch/OS, we need to dive deeper into whether this is a benefit at all anymore; looking across a wider set of platforms. If it's not, there are gains to be had in the build process if the mapfiles support is removed. The benefit of mapfiles should be re-examined for JDK8 and the 7-updates.
15-03-2011
EVALUATION This is indeed a performance related issue, however, before anything else, the most important problem that has to be resolved here is the making the process of creating the mapfiles more straight forward and perhaps incorporating it to the JPRT building process if possible. In nut shell these are the steps needed to create the mapfiles: (1) First one has to build the JDK in place and a profiled version of hotspot (client, server and sparcv9) ... (2) Once that's done, there is a reorder.sh script on HOTSPOT_HOME/make/solaris that can be executed to create the map files. As of now, this script has 3 arguments: a target JDK, a profiled VM and a pointer to a JBB install ... This script will create a map file for the client and server VMs. The client one is obtained by running several client like apps and the server one by running specjbb2005. (3) To run the script one must provide a target JDK install, and a pointer to a profiled Hotspot VM, these will be used to run the experiments. The output of this script are 2 mapfiles, one for the client VM and one for the server VM. (4) after the mapfiles are obtained, they should be placed in the hotspot/makefiles directory to build a new hotspot that will be linked using the information in those new maps files. These VM are then used to test the impact on performance. Maps files need to be created for each platform and VM flavor. There are several options to run the reorder.sh script (different command line options for JBB, or even using a different benchmark) ... so this process needs to be automated, as much as possible, to be able to select the mapfiles that will provide the best performance ... I created a few mapfiles, for sparc platforms, following that process and tested the resulting VMs with specjvm2008 and some startup workloads and did not see significant gains, but given the complecity of the process to create them, I did not test with different mapfiles ... So, as I mentioned above, once the process to create maofiles and build VMs with then is made easier we can produce VMs with new map files and test them thoroughly via aurora.
10-03-2011
EVALUATION Moving this to performance. These build issues directly relate to performance and the function lists are stale. The lists being used are stale, and the Solaris amd64 ones are effectively missing. Changing or correcting these lists could have ramifications to performance, positive or negative. One option would be to just remove this complication to the build process. This relates to Solaris and Linux only, and native code only.
13-01-2011
EVALUATION When the shared libraries are built for solaris, and the compiler option -Xf (sp?) is supplied at compile time, a linker mapfile can be supplied to put the code of the various native functions in a particular order. If that order reflects the usage of the functions properly, then it can optimize the performance, minimizing the number of pages needed in memory to use the library. The native library ideally needs to be able to have a completely read-only text section and the order needs to be determined through some kind of performance analysis or intelligent guesswork, moving hot functions early in the list, little or rarely used functions at the end. See jdk/make/tools/reorder and look for FILES_reorder and mapfiles named reorder-* in the jdk/make directories. Keep in mind that hotspot is probably the most critical shared library to reorder, and I suspect that has been done already in the hotspot repository. Keep in mind that the class file reorder of the jar files is a separate thing, similar in concept, but completely different from this. These are the current reorder mapfiles in the jdk repository. ./jdk/make/java/hpi/native/reorder-i586 ./jdk/make/java/hpi/native/reorder-sparc ./jdk/make/java/hpi/native/reorder-sparcv9 ./jdk/make/java/java/reorder-i586 ./jdk/make/java/java/reorder-sparc ./jdk/make/java/java/reorder-sparcv9 ./jdk/make/java/nio/reorder-i586 ./jdk/make/java/nio/reorder-sparc ./jdk/make/java/nio/reorder-sparcv9 ./jdk/make/java/verify/reorder-i586 ./jdk/make/java/verify/reorder-sparc ./jdk/make/java/verify/reorder-sparcv9 ./jdk/make/java/zip/reorder-i586 ./jdk/make/java/zip/reorder-sparc ./jdk/make/java/zip/reorder-sparcv9 ./jdk/make/sun/font/reorder-i586 ./jdk/make/sun/font/reorder-sparc ./jdk/make/sun/font/reorder-sparcv9 ./jdk/make/sun/headless/reorder-i586 ./jdk/make/sun/headless/reorder-sparc ./jdk/make/sun/headless/reorder-sparcv9 ./jdk/make/sun/jpeg/reorder-i586 ./jdk/make/sun/jpeg/reorder-sparc ./jdk/make/sun/jpeg/reorder-sparcv9 ./jdk/make/sun/motif12/reorder-i586 ./jdk/make/sun/motif12/reorder-sparc ./jdk/make/sun/motif12/reorder-sparcv9
18-08-2010