De-universalizing hotspot in jdk8u

[David Holmes]

On 13/01/2015 5:20 AM, Alex Strange wrote:
>
>> On Jan 12, 2015, at 3:26 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> cc'ing macosx-port-dev and hotspot-dev
>>
>> On 12/01/2015 8:41 PM, Erik Joelsson wrote:
>>>
>>> On 2015-01-12 00:02, David Holmes wrote:
>>>> Hi David,
>>>>
>>>> On 10/01/2015 2:00 AM, David DeHaven wrote:
>>>>>
>>>>> We have this nice little comment in common/autoconf/jdk-options.m4:
>>>>>    # On Macosx universal binaries are produced, but they only contain
>>>>>    # 64 bit intel. This invalidates control of which jvms are built
>>>>>    # from configure, but only server is valid anyway. Fix this
>>>>>    # when hotspot makefiles are rewritten.
>>>>>    if test "x$MACOSX_UNIVERSAL" = xtrue; then
>>>>>      HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>>>>>    fi
>>>>>
>>>>>
>>>>> So.. I turned it off:
>>>>>    if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
>>>>> #    MACOSX_UNIVERSAL="true"
>>>>>      MACOSX_UNIVERSAL="false"
>>>>>    fi
>>>>>
>>>>> And in hotspot/make/bsd/makefiles/defs.make:
>>>>> # Universal build settings
>>>>> ifeq ($(OS_VENDOR), Darwin)
>>>>>    # Build universal binaries by default on Mac OS X
>>>>> #  MACOSX_UNIVERSAL = true
>>>>>    MACOSX_UNIVERSAL = false
>>>>>    ifneq ($(ALT_MACOSX_UNIVERSAL),)
>>>>>
>>>>> hotspot still seems to build happily (I'm kicking off tests now). Is
>>>>> there are particular reason this hasn't been done yet? I'd like to
>>>>> know before I pursue this as a means of eliminating our dependency on
>>>>> lipo which is causing an inordinate amount of grief when trying to
>>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some
>>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't
>>>>> help later in some "other" build target that ends up using '-arch
>>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc
>>>>> to do the fattening itself and so it fails even though I've gone to
>>>>> the effort of working around the broken lipo (and it isn't necessary
>>>>> anyways because it doesn't even build the i386 binaries even though
>>>>> it's supposed to be "universal").
>>>>
>>>> The hotspot makefiles still haven't been rewritten (though Magnus had
>>>> been working on it).
>>>>
>>>> Also I was under the impression that we used the universal stuff
>>>> because we had to deliver in a particular way on OSX. But I don't know
>>>> the details and the people who dealt with the original OSX port effort
>>>> are no longer here.
>>>>
>>> I don't know why Hotspot is packaged as a universal binary. In the jdk,
>>> only libJObjC was built as a universal binary and that lib was removed
>>> before JDK 8 shipped. What part of Macosx would need to interact
>>> directly with libjvm.dylib in a way that required a (fake) universal
>>> format, but no other libs in the jdk? I would say go ahead and change it.
>>
>> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature.
>>
>> David H.
>> -------
>
> I did the original universal binary work for hotspot when bringing up macosx-port.
>
> At the time we were building and testing JDK 7 as universal (i386+x86-64) since e.g. some apps had JNI code that was only built 32-bit.
> The other jdk components didn't need any makefile work, because the compiler can build them universal by itself, but hotspot autogenerates a lot of arch-specific code and it was easier to build it twice and glue them together in the makefile.
>
> As long as Java is only been shipped 64-bit these days, I personally don't see a reason to keep it.

Thanks for the info Alex. Based on that and Dan's response this proposed 
change seems good to go ahead.

David H.

>
>> /Erik
>>>
>>>> David H.
>>>>
>>>>>
>>>>> Quite frankly I'd rather just remove all the universal binary stuff
>>>>> from hotspot, but I'm trying my best to minimize the changes there...
>>>>> the "other" problem I can handle easily.
>>>>>
>>>>> -DrD-
>>>>>
>>>
>