Client VM for 64 bit linux

David Holmes david.holmes at oracle.com
Thu Dec 27 12:20:33 UTC 2012


On 27/12/2012 7:14 PM, Aekold Helbrass wrote:
> Hi David,
>
> Thanx for your answer. Yes, patches are really small, I hope they will
> not be crippled by email renderer. See patches below.
>
> And about new build system, can you please link me where can I read more
> about it?

It is the build-infra project. It is a configure based build. See 
common/autoconf in the top-level repo and jdk/makefiles in the JDK repo.

> #######################################################################################
> #######################################################################################
> ### APPLY THIS PATCH ONTO HOTSPOT SUBFOLDER
> ###########################################
> #######################################################################################
> #######################################################################################
> Index: make/Makefile
> --- make/Makefile Base (BASE)
> +++ make/Makefile Locally Modified (Based On LOCAL)
> @@ -183,14 +183,10 @@
> @$(ECHO) "No compiler1 ($(VM_TARGET)) for
> ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)"
>     endif
>   else
> -  ifeq ($(ARCH_DATA_MODEL), 32)
> $(CD) $(OUTPUTDIR); \
>     $(MAKE) -f $(ABS_OS_MAKEFILE) \
>       $(MAKE_ARGS) $(VM_TARGET)
> -  else
> -@$(ECHO) "No compiler1 ($(VM_TARGET)) for
> ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)"
>     endif
> -endif

This part seems okay.

>   # Build compiler2 (server) rule, different for platforms
>   generic_build2:
> Index: make/linux/makefiles/defs.make
> --- make/linux/makefiles/defs.make Base (BASE)
> +++ make/linux/makefiles/defs.make Locally Modified (Based On LOCAL)
> @@ -116,15 +116,10 @@
>   # On 32 bit linux we build server and client, on 64 bit just server.
>   ifeq ($(JVM_VARIANTS),)
> -  ifeq ($(ARCH_DATA_MODEL), 32)
>       JVM_VARIANTS:=client,server
>       JVM_VARIANT_CLIENT:=true
>       JVM_VARIANT_SERVER:=true
> -  else
> -    JVM_VARIANTS:=server
> -    JVM_VARIANT_SERVER:=true
>     endif
> -endif

This change is unnecessary. It was setting the default VM(s) to build if 
none was set (eg by the configure based build). Juts because you can 
build 64-bit client VM it doesn't mean that by default you should build it.
>   # determine if HotSpot is being built in JDK6 or earlier version
>   #######################################################################################
>   #######################################################################################
>   ### APPLY THIS PATCH ONTO JDK SUBFOLDER
> ###############################################
>   #######################################################################################
>   #######################################################################################
> Index: make/java/redist/Makefile
> --- make/java/redist/Makefile Base (BASE)
> +++ make/java/redist/Makefile Locally Modified (Based On LOCAL)
> @@ -109,7 +109,6 @@
>   # Hotspot client is only available on 32-bit non-Zero builds
>   ifneq ($(ZERO_BUILD), true)
> -ifeq ($(ARCH_DATA_MODEL), 32)
>     IMPORT_LIST += $(LIB_LOCATION)/$(CLIENT_LOCATION)/$(JVM_NAME) \
>                    $(LIB_LOCATION)/$(CLIENT_LOCATION)/Xusage.txt
>     ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1)
> @@ -126,7 +125,6 @@
>       endif
>     endif
>   endif
> -endif

I'm not sure the above is correct. This seems to assume that the client 
VM must be available as opposed to may be available.

>   ifeq ($(PLATFORM), windows)
>   #  Windows     vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv  Windows
> @@ -159,7 +157,6 @@
>   # Add .map and .pdb files to the import path for client and kernel VMs.
>   # These are only available on 32-bit windows builds.
> -ifeq ($(ARCH_DATA_MODEL), 32)
>     ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1)
>       ifeq ($(ZIP_DEBUGINFO_FILES),1)
>         # the import JDK may not contain .diz files
> @@ -190,7 +187,6 @@
>         endif
>       endif
>     endif
> -endif
>   $(LIBDIR)/$(JVMLIB_NAME): $(HOTSPOT_LIB_PATH)/$(JVMLIB_NAME)
> $(install-import-file)
> @@ -311,7 +307,6 @@
>   endif
>   ifneq ($(ZERO_BUILD), true)
> -ifeq ($(ARCH_DATA_MODEL), 32)
>   IMPORT_LIST += $(LIB_LOCATION)/$(CLIENT_LOCATION)/$(LIBJSIG_NAME)
>   ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1)
> @@ -423,8 +418,6 @@
>   #  solaris   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ solaris
>   endif # 32bit solaris
> -endif # 32bit
> -
>   endif # ZERO_BUILD
>   #  NOT Windows ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> NOT Windows

Similar comment.

This is probably handled better in the new build where the set of VMs to 
build is part of a configuration, so the import lists only import what 
is needed for the given configuration.

I need to refresh my memory of what was discussed on this issue in the 
past. But oyu are not likely to find someone who can sponsor this change 
at the moment - there's just too much happening for the M6 milestone in 
January.

David
------

>
>
>
>
>
> On Thu, Dec 27, 2012 at 12:06 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi,
>
>     Attachments get stripped by the mailing software. If the patches are
>     small enough please include them inline, else post them somewhere
>     accessible. Changes would be needed for both the old and new build
>     systems.
>
>     Thanks,
>     David Holmes
>
>
>     On 27/12/2012 1:56 AM, Aekold Helbrass wrote:
>
>         Hi All,
>
>         So, last time when I asked about 64 bit ClientVM someone
>         explained me that
>         it's fully compatible, just not build.
>
>         I've made 2 patches to build system to build 64 bit client VM
>         for linux.
>         Unfortunately I do not have windows installation to check if it
>         works
>         there, but on linux it works fine, runs NetBeans without
>         problems, and for
>         NetBeans difference between 32 and 64 is huge: 4 seconds cold
>         start against
>         13 seconds cold start.
>
>         Please see 2 files in attachment, they should be applied to
>         hotspot and jdk
>         repositories.
>
>         Regards!
>
>



More information about the build-dev mailing list