Review request: Zero buildsystem changes

[Gary Benson]

Hi all,

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

  http://cr.openjdk.java.net/~gbenson/zero-11-build/
  http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/

The bulk of the changes are in the zero-11-hotspot webrev, which has
been through a couple of review cycles and is (hopefully!) about to
be tested with JPRT and pushed.

The zero-11-build webrev contains a small number of changes, mostly
to makefiles, that are required in order to build OpenJDK with Zero.
Is this the right list to review these changes?

Cheers,
Gary

--
http://gbenson.net/

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".

[Gary Benson]

Hi all,

As an update to my previous message, the HotSpot part of this patch
was tested and pushed to hotspot-comp last night, so the remaining
code for review is this:

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

I'm going on vacation on Friday 16, returning Monday 26, so could
anyone replying off-list please Cc gnu_andrew@..., who
is going to handle this in my absence.  We'd love to see this in
in time for Milestone 5, and we'd hate to miss the boat because
an email was sitting in my inbox unread!

Thanks,
Gary

Gary Benson wrote:

> Hi all,
>
> Zero is an interpreter-only port of HotSpot that uses no assembler and
> can trivially be built on any Linux system.  The following two webrevs
> add Zero support to OpenJDK:
>
>   http://cr.openjdk.java.net/~gbenson/zero-11-build/
>   http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/
>
> The bulk of the changes are in the zero-11-hotspot webrev, which has
> been through a couple of review cycles and is (hopefully!) about to
> be tested with JPRT and pushed.
>
> The zero-11-build webrev contains a small number of changes, mostly
> to makefiles, that are required in order to build OpenJDK with Zero.
> Is this the right list to review these changes?
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/
>
>
> 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".

--
http://gbenson.net/

[tim.bell]

Gary Benson wrote:

> As an update to my previous message, the HotSpot part of this patch
> was tested and pushed to hotspot-comp last night, so the remaining
> code for review is this:
>
>   http://cr.openjdk.java.net/~gbenson/zero-11-build/
>
> I'm going on vacation on Friday 16, returning Monday 26, so could
> anyone replying off-list please Cc gnu_andrew@..., who
> is going to handle this in my absence.  We'd love to see this in
> in time for Milestone 5, and we'd hate to miss the boat because
> an email was sitting in my inbox unread!

(Adding Andrew as requested).

These changes look OK to Kelly and myself.  Also, my test run on our
internal build farm called JPRT (a full control build of everything after
adding your patch) worked:

> JPRT: [sfbay] job notification - success with job 2009-10-14-203220.tbell.zero-11-build

How would you like to proceed?  With the hotspot work, Tom Rodriguez (AKA 'never')
did the push as an agent for you via JPRT because that is a hotspot requirement.

I am willing to do that as well for the JDK changes, or you could create
the changeset and push yourself.  We are not quite as strict about requiring
a JPRT grid build before pushing on the JDK side.  I wish we were, but so
far I have not won that contest :-)


I filed bug ID 6891677 "java/build integrate zero assembler JDK changes" for
this, but it may not be visible externally for a day or two.

Let me know - I'd be glad to help get this changeset in.

Tim

[gnu_andrew]

2009/10/15 Tim Bell <Tim.Bell@...>:

> Gary Benson wrote:
>
>> As an update to my previous message, the HotSpot part of this patch
>> was tested and pushed to hotspot-comp last night, so the remaining
>> code for review is this:
>>
>>   http://cr.openjdk.java.net/~gbenson/zero-11-build/
>>
>> I'm going on vacation on Friday 16, returning Monday 26, so could
>> anyone replying off-list please Cc gnu_andrew@..., who
>> is going to handle this in my absence.  We'd love to see this in
>> in time for Milestone 5, and we'd hate to miss the boat because
>> an email was sitting in my inbox unread!
>
> (Adding Andrew as requested).
>
> These changes look OK to Kelly and myself.  Also, my test run on our
> internal build farm called JPRT (a full control build of everything after
> adding your patch) worked:
>
>> JPRT: [sfbay] job notification - success with job 2009-10-14-203220.tbell.zero-11-build
>
> How would you like to proceed?  With the hotspot work, Tom Rodriguez (AKA 'never')
> did the push as an agent for you via JPRT because that is a hotspot requirement.
>
> I am willing to do that as well for the JDK changes, or you could create
> the changeset and push yourself.  We are not quite as strict about requiring
> a JPRT grid build before pushing on the JDK side.  I wish we were, but so
> far I have not won that contest :-)
>
>
> I filed bug ID 6891677 "java/build integrate zero assembler JDK changes" for
> this, but it may not be visible externally for a day or two.
>
> Let me know - I'd be glad to help get this changeset in.
>
> Tim
>
>

Pushed on Gary's behalf:

http://hg.openjdk.java.net/jdk7/build/rev/608937d41381
http://hg.openjdk.java.net/jdk7/build/corba/rev/34a68fa0680b
http://hg.openjdk.java.net/jdk7/build/jdk/rev/e2de121c27c4

Thanks,
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[Gary Benson]

Andrew John Hughes wrote:

> 2009/10/15 Tim Bell <Tim.Bell@...>:
> > Gary Benson wrote:
> > > As an update to my previous message, the HotSpot part of this
> > > patch was tested and pushed to hotspot-comp last night, so the
> > > remaining code for review is this:
> > >
> > >   http://cr.openjdk.java.net/~gbenson/zero-11-build/
> > >
> > > I'm going on vacation on Friday 16, returning Monday 26, so
> > > could anyone replying off-list please Cc
> > > gnu_andrew@..., who is going to handle this in my
> > > absence.  We'd love to see this in in time for Milestone 5, and
> > > we'd hate to miss the boat because an email was sitting in my
> > > inbox unread!
> >
> > (Adding Andrew as requested).
> >
> > These changes look OK to Kelly and myself.  Also, my test run on
> > our internal build farm called JPRT (a full control build of
> > everything after adding your patch) worked:
> >
> > > JPRT: [sfbay] job notification - success with job 2009-10-14-203220.tbell.zero-11-build
> >
> > How would you like to proceed?  With the hotspot work, Tom
> > Rodriguez (AKA 'never') did the push as an agent for you via JPRT
> > because that is a hotspot requirement.
> >
> > I am willing to do that as well for the JDK changes, or you could
> > create the changeset and push yourself.  We are not quite as
> > strict about requiring a JPRT grid build before pushing on the JDK
> > side.  I wish we were, but so far I have not won that contest :-)
> >
> > I filed bug ID 6891677 "java/build integrate zero assembler JDK changes" for
> > this, but it may not be visible externally for a day or two.
> >
> > Let me know - I'd be glad to help get this changeset in.
>
> Pushed on Gary's behalf:
>
> http://hg.openjdk.java.net/jdk7/build/rev/608937d41381
> http://hg.openjdk.java.net/jdk7/build/corba/rev/34a68fa0680b
> http://hg.openjdk.java.net/jdk7/build/jdk/rev/e2de121c27c4

Tim, Andrew, many thanks :)

Cheers,
Gary

--
http://gbenson.net/