Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6890308

integrate zero assembler hotspot changes

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P3 P3
    • hs17
    • hs17
    • hotspot
    • b04
    • sparc
    • solaris_9

        Zero is an interpreter-only port of HotSpot that uses no assembler and
        can trivially be built on any Linux system. The following webrev adds
        Zero support to OpenJDK:

         http://cr.openjdk.java.net/~gbenson/zero-10/

        Building is largely the same as the previous webrev (zero-07) except
        for the following changes:

         - The variable CORE_BUILD is no longer used.
         - The variable ZERO_BITSPERWORD has been replaced with ARCH_DATA_MODEL

        Summary of changes
        ==================

        - The code has been reformatted to better match HotSpot's coding
          conventions. Notably, all opening braces have been moved to the
          end of the previous line, rather than being on their own lines.

        - The variable CORE_BUILD is no longer required. Setting ZERO_BUILD
          is all that is required to enable Zero.

        - The Zero build process no longer hijacks the core rules in the
          makefiles, but provides its own rules. A consequence of this is
          that the build directory is now linux_zero_zero rather than
          linux_zero_core. Another consequence is that Zero now has its
          own includeDB file, into which all direct #includes have been
          moved.

        - The variable ZERO_BITSPERWORD has been replaced with the existing
          ARCH_DATA_MODEL.

        - The type definition ZeroEntry::method_entry_t has been renamed.
          Tom Rodriguez suggested MethodEntryFunc, but Zero now supports
          OSR, which requires a different calling convention, so there is
          now ZeroEntry::NormalEntryFunc and ZeroEntry::OSREntryFunc.

        - Zero no longer hijacks C2_BASE_DIR in hotspot/make/Makefile.
          ZERO_BASE_DIR is used instead.

        - A duplicate definition of STATIC_CXX was removed.

        - Zero's ICache now overrides some AbstractICache methods with
          empty methods, avoiding conditionals in icache.cpp. Comments
          in icache_zero.hpp explain this rationale.

        - JNIHandles::clear is now protected on all platforms, not just Zero.

        - Code from the ZeroStackPrinter class has been migrated to methods
          in ZeroFrame and its subclasses. stackPrinter_zero.hpp (previously
          directly included from vmError.cpp) has been removed, and most of
          the Zero-specific code in VMError::report has likewise been
          replaced. There is still a small amount of conditional code in
          VMError::report, but this could be removed entirely if it is not
          acceptable (at the expense of losing the super-detailed stack
          traces that Zero emits, eg http://tinyurl.com/y9rp4r3).

        - frame::frame uses find_blob_unsafe instead of find_blob.

        - All stubs contain ShouldNotCallThis() instead of Unimplemented().

        Summary of non-changes
        ======================

        - The variable ZERO_ENDIANNESS remains unchanged. I haven't renamed
          it as ENDIANNESS because it's only used during Zero builds. It's
          possible that the makefiles could be refactored such that, for
          example, existing platforms set ENDIANNESS (leaving Zero requiring
          it to be set externally) but I wasn't sure I should be doing this
          in this patch.

        - The build directory is linux_zero_zero (or linux_zero_shark) rather
          than linux_$(ARCH)_zero. There is no variable defining the name of
          the build directory as such, it's always referenced as
          $(OSNAME)_$(BUILDARCH)_whatever, and in addition to specifiying the
          build directory, BUILDARCH is used in conditionals in various
          makefiles to add extra compiler flags, etc. If BUILDARCH is set to
          "i486", for example, then extra compiler flags are added which are
          unnecessary (and possibly problematic) for Zero.

        - The variable ZERO_LIBARCH remains. It's used in several different
          places, and I couldn't figure out a place to put the logic to
          convert a uname string to the correct ZERO_LIBARCH value where the
          result would be accessible everywhere it is required.

        Build Instructions
        ==================

         There are a number of environment variables that need setting before
         running make, but if you are using jdk/make/jdk_generic_profile.sh
         to set up your environment then you only need to set one, and a build
         can be as simple as:

           export ZERO_BUILD=true
           . jdk/make/jdk_generic_profile.sh
           gmake sanity && gmake

         The mandatory environment variable does the following:

           ZERO_BUILD
             Setting ZERO_BUILD to "true" will cause the Zero interpreter to
             be used. If ZERO_BUILD is unset, or set to any other value than
             "true", the standard, platform-specific interpreter will be used.

         Of the other environment variables the following are required when
         ZERO_BUILD is set to "true". These are set by
         jdk/make/jdk_generic_profile.sh based on the result of uname -m:

           ZERO_LIBARCH
             This is the name of the architecture-specific subdirectory under
             $JAVA_HOME/jre/lib. Typically this will be the same as the output
             of uname -m, although there are some exceptions: "amd64" instead
             of "x86_64", for example, and "i386" instead of "i686".

           ZERO_ARCHDEF
             The value of ZERO_ARCHDEF will be passed to the C++ compiler using
             -D${ZERO_ARCHDEF} to allow conditionalized platform-specific code.
             This is typically set to ZERO_LIBARCH converted to uppercase but,
             again, there are exceptions. "i386" becomes "IA32", to match what
             HotSpot already does, and on platforms with both 32- and 64-bit
             variants ZERO_ARCHDEF corresponds to the 32-bit version, so both
             ppc and ppc64 have ZERO_ARCHDEF set to "PPC".

           ZERO_ENDIANNESS
             This is set to "little" or "big".

           ARCH_DATA_MODEL
             This is set to "32" or "64".

           ZERO_ARCHFLAG
             This is a flag that will be passed to the C++ compiler and to the
             linker to instruct them to generate code for the particular
             platform. This is required for platforms with both 32- and 64-bit
             variants where the compiler needs to be told which variant to
             build for. ZERO_ARCHFLAG will typically be set to "-m32" or
             "-m64", except on 31-bit zSeries where it will be set to "-m31".

         Zero uses one external library, libffi, for JNI method invocation.
         The following two variables are used to tell the compiler and linker
         how to find libffi. These can be set by the user, but if left unset
         then jdk/make/jdk_generic_profile.sh will attempt to set them using
         pkg-config or, failing that, by supplying defaults pointing to the
         standard locations:

           LIBFFI_CFLAGS
             Flags to be passed to the C++ compiler to build against libffi.
             If unset (and pkg-config is not installed, or if libffi is not
             built with pkg-config) then this defaults to "".

           LIBFFI_LIBS
             Flags to be passed to the linker to link against libffi. If
             unset (and pkg-config is not installed, or if libffi is not
             built with pkg-config) then this defaults to "-lffi".

              never Tom Rodriguez
              never Tom Rodriguez
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: