Client VM for 64 bit linux
Phil Race
philip.race at oracle.com
Thu Dec 27 20:52:42 UTC 2012
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.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!
>>>>>
>>
>
>
More information about the build-dev
mailing list