De-universalizing hotspot in jdk8u

[Daniel D. Daugherty]

On 1/12/15 8:17 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.
> I hear you.
>
> My best guess is we'd initially planned on supporting 32 bit but (???) and the easiest way to deliver is in a universal binary. Note that we don't actually deliver universal binaries as the JVM is 64 bit only, or at least there are not nearly enough components there to run a full 32 bit JVM.
>
> -DrD-

We (Jim Melvin did the work) included universal support in HotSpot
to not preclude someone else from doing the 32-bit MacOS X port and
providing it via OpenJDK channels. The rest of the JDK did not
include universal support, but the hotspot code would have served
as an example way forward...

However, we never heard from anyone willing to do the 32-bit port...

Dan