Client VM for 64 bit linux
Kelly O'Hair
kelly.ohair at oracle.com
Thu Dec 27 20:47:39 UTC 2012
Sorry, I have to agree with Phil here.
It has been my experience that using a server VM might add a few seconds to startup and will use more
memory, but I found that the NetBeans GUI interactions were zippier once the VM warmed up.
Since NetBeans startups are fairly rare, it's not a good determining decision factor here.
I remember when NetBeans 3.X took 5mins to startup. Now that was painful. :^(
The memory consumption could be an issue we need to track down. If you are getting OOM's and slowdowns
in 64bit mode, at 3GB, it's possible you are thrashing and should try 4GB.
In 32bit mode you could have been right on the edge and not known it.
The organizational effort needed to support another VM is pretty high, so any official builds of new VMs
is not likely to happen. If the hotspot team had some testcases or demonstrations of memory consumption
issues with the 64bit server VM, that could get some traction.
Regardless, new VMs builds should be first discussed on the hotspot-dev AT openjdk.java.net alias.
-kto
On Dec 27, 2012, at 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?
>
> 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/
More information about the build-dev
mailing list