Re: Client VM for 64 bit linux

[Phil Race]

On 12/27/2012 12:26 PM, Helbrass wrote:
Hi Phil,
First of all, you're always building both server and client for 32 
bit, what's the big deal with always building it for 64 bit?

Its a huge deal. You are not just flipping an unimportant build switch.
You are adding a significant new feature to the product with its 
attendant costs
as well as benefits.


Second, I'm agree that in most cases server VM may be better, but in 
my case I'm programmer, not server administrator, and all day long I'm 
using NetBeans (which is awesome!). And it happened, that NetBeans 
cannot open full OpenJDK project on 64 bit VM because it fails with 
OutOfMemory, and when you're giving him 3GB RAM it still takes huge 
amount of time to scan everything.

I am not sure if/why a 64 bit client VM would solve that. Client assumes 
a smaller heap so would seem more likely to run into it.

While on 32 bit client vm it works without any problems whatsoever. 
Unfortunately, I don't know hotspot internals to explain why this is 
happening, but still, cold start on 32 bit client takes NetBeans 3 
seonds, and cold start on 32 bit server vm takes 12 seconds. You'll 
say it's just 10 seconds difference, I'd say it's 4 times difference.

That's the 32 bit VM. I don't know if the same ratio applies on 64 bit, 
but I wouldn't be surprised if it were similar.
64 bit Unix VMs have generally been assumed to be targeted at server use 
where near-instant startup is not the priority.



I agree that this is minor issue, and openjdk developer team would not 
want to take any responsibilities for this, but for me personally it's 
just a possibility to get client openjdk vm without doing chrooted 32 
bit install of full linux.

I am not sure why you need a chrooted install.
You can run 32 bit JDK on 64 bit Linux. Its just that the distros make 
it a bit of a pain as
you need to go and get the 32 bit X11 and other libs.

-phil.

On Thu, 27 Dec 2012 20:13:46 +0200, Phil Race <philip.r...@oracle.com> 
wrote:

I am fairly sure we do not want the build system to spit out a 64 bit 
client VM by default.
My recollection from many years ago is that the VM team and 
performance team determined
that the 64 bit server VM was as good as, or better than the 64 bit 
client VM on all the
metrics that mattered and thus there was no reason for the 64 bit 
client VM to be
supported.

If you want an option to enable it that's one thing, but below it 
looks like its always
built. Release engineering, product management, SQE and others will 
object.

-phil.

On 12/27/2012 1:14 AM, 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?

####################################################################################### 

####################################################################################### 

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

  # 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

  # 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

  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






On Thu, Dec 27, 2012 at 12:06 AM, David 
Holmes<david.hol...@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!