Client VM for 64 bit linux

[Helbrass]

On Fri, 28 Dec 2012 01:04:05 +0200, David Holmes <david.holmes at oracle.com>  
wrote:

> On 28/12/2012 6:26 AM, 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?
>
> Time and space.
>
> But the main point here is that 64-bit client VM is not a supported VM  
> configuration. As discussed in the past you can easily modify things to  
> build this yourself for your own usage.
>
> In the new build system you only get the VMs that you ask for at  
> configure time. So I'm not opposed to changes that simply make it  
> possible to ask for the 64-bit client VM (perhaps with a suitable  
> warning that it is unsupported?). But it can never be a default as long  
> as it is an unsupported configuration.

That would be great! Tell me please, new build infrastructure targets only  
openjdk8, or it will be ported to openjdk7 as well?


>
> David
> -----
>
>>
>> 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. 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.
>>
>> 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.
>>
>> On Thu, 27 Dec 2012 20:13:46 +0200, Phil Race <philip.race at 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.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!
>>>>>>
>>>
>>
>>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/