Excellent points Steve. And good summary.

The hotspot nmake Makefiles are tied to the MS Visual Studio (VC) compilers,
and I'm pretty sure nmake.exe is now only delivered with the VC product.
It's not clear how you can match this build performance.
However, it's also not clear how much of this benefit comes from Hotspot's
use of VC pre-compiled headers (PCH). Windows builds with nmake/VC/PCH
takes a few minutes, versus 20-35min builds on equivalent Linux/Solaris
systems. So it's significant and something (the performance) that we want
to keep. If a GNU Makefile using VC/PCH can match nmake is an open question.

I have tried using parallel GNU make and batch compiles in the jdk
builds, and seen benefits on Linux and Solaris, but not much with
Windows. And the VC compiler isn't horribly helpful in doing multiple
compiles in parallel (options have non-unique filename defaults).
For some reason the big benefits on a Unix system of multiple processes
sharing library images, executable images, and pages, just doesn't seem
to happen with Windows. So this could be a challenge getting off of nmake.

The MigGW32 unix utilities change (not the compiler) for the hotspot
makefiles will probably not be a big deal and would likely not need
as much review. The dependency on the cygwin or MKS utilities is rather
minimal in the hotspot makefiles.

Hotspot compiler changes will need to be treated separately because any changes
to the hotspot builds will need to be treated very carefully with
regards to benchmark performance measurements.
If the free VC compiler really generates the same code as the purchased
VC compiler, then no big deal, but that would need to be verified.

As Steve points out, the issue with the free VC compiler was the missing
include and library files used by the rest of the jdk build.

-kto

Steve Bohne wrote:
Hi Ted,

Congratulations on getting accepted. Are you planning to include the Hotspot repository in this project? Some time ago, I was involved with a similar effort to build Hotspot under Visual C++ 2005 Express, so I'm familiar with some of this. Most of the immediate build issues were simple syntax problems. So the Hotspot repository should be pretty easy, with respect to source changes, at least for VC 2008.

For MinGW32, one issue might be that the current Hotspot/Windows makefiles are mostly nmake format. We still use that format because it provides an easy capability for so-called "batch" compiles, which makes Windows Hotspot builds extremely fast. It would be nice to have something equivalent if a new Makefile format is used.

Another thing to watch out for with Hotspot is performance. Some of the C++ subsystems, particularly GC, can be sensitive to the quality of the generated code. In the past we've seen noticeable changes in benchmark scores from C++ compiler upgrades (thankfully, mostly positive changes.) Just something to keep in mind, especially if the free version of VC 2008 or MinGW32 omits some optimizations that exists in the current compilers.

Finally, this isn't Hotspot related, but one other problem we had with the free VC 2005 compiler was lack of ATL support. One of the other repositories had a dependency on ATL that wasn't satisfied by the Express compiler. It may be the case that the dependency was removed since then, or that the 2008 product now includes the support. Just something to be aware of.

Others on this list can probably comment better on non-Hotspot issues.

Steve

Ted Neward wrote:
Given that it would appear that my proposal for updating the build process to use a free compiler has apparently been accepted (see below), is there a
good time to start thinking about doing the migration work? Are there any
major build changes up & coming? I know Kelly has said there's some plans to move the corba project out to an entirely Ant-driven process, so if that's
going to happen any time soon, I'll just leave it out of the migration
process. (I think the corba stuff still uses the C compiler for some of it,
no?)

There's a two-step process I want to take with this:
1) Let's leave most of the build infrastructure in place and just try to
swap in Visual C++ 2008 Express.
2) Let's see about moving over to MinGW32's infrastructure (instead of
Cygwin's) and see if that doesn't help reduce the path problems we're
currently facing in the Windows build of OpenJDK.
2) Let's see about moving over to the MinGW32 gcc compiler for building on windows, and thus remove the dependency on Microsoft's compiler completely,
in case VC++ ever moves out of a free (as in beer or as in speech) SKU.

My goal is to ensure that I hit #1 by the close of the project period
(August), and get as far down 2 and 3 as possible.

Any thoughts? Suggestions? Ideas for how best to tackle this? You (the guys at Sun) have a lot more experience with this codebase than I, so any tips,
pointers or suggestions are appreciated.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:announce-
[EMAIL PROTECTED] On Behalf Of Rich Sands
Sent: Monday, March 17, 2008 6:54 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Announcing Finalists for the OpenJDK Community Innovator's
Challenge

OpenJDK Community,

We're pleased to announce the finalists for the OpenJDK Community
Innovator's
Challenge. The judges have been meeting and discussing the 18 proposals
received
during the first phase of the Challenge, and evaluating these proposals
based on
their technical merit, and their likely impact on the OpenJDK Community
and the
adoption of OpenJDK-based implementations in new markets, for new
applications and
uses. It was not an easy decision, as most of the proposals were
thoughtful and
demonstrated passion and commitment to this code base and the
community. The seven
Finalists, in order of receipt of their proposals, are:


Closures for Java                                    Neal Gafter

Implement XRender pipeline for Java2D                Clemens Eisserer

Provide date and time library from JSR-310           Stephen
Colebourne,
                                                      Michael
Nascimento Santos

Portable GUI backends                                Roman Kennke,
Mario Torre

Virtual Machine Interface                            Andrew John Hughes

Free Software synthesizer implemention for
the OpenJDK project                                  Karl Helgason

OpenJDK on Windows                                   Ted Neward


The judges, all Sun employees, are Alan Bateman, Alex Buckley, Danny
Coward, Joe
Darcy, Ray Gans, James Gosling, Onno Kluyt, Jim Melvin, Alex Potochkin,
Phil Race,
Mark Reinhold, and Rich Sands.

We want to thank everyone who has entered their proposal into the
Challenge. It is
very exciting to see the level of enthusiasm and interest among
developers for the
OpenJDK code base. The finalists were chosen based on the completeness
and relevance
of their proposals and the degree to which the judges felt the end
results were both
achievable and valuable to the community at this time. Proposals that
were not
selected as finalists are still valuable and interesting but Sun could
not select
them all! The judges hope that everyone who has participated so far in
the Challenge
will consider continuing their efforts in the Community, and
collaborating with their
peers and with Sun to further the goals of the OpenJDK project.

One other thing to remember -- there is no guarantee that completed
Challenge
projects will be integrated into the main OpenJDK code base, or into
the Java SE
Platform specification (which is governed by the JCP). Being chosen as
a Finalist or
completing a project for the Challenge might help to demonstrate the
feasibility of a
particular API or language proposal but it does not say anything about
the likelihood
of such a project becoming an approved JSR, or about the code being
integrated into
the main branch of the OpenJDK code base. Both the spec and the code
are managed
under processes that are separate from the Challenge.

The finalists will be notified and project space set up for them if
needed in the
OpenJDK Community. As required by the Challenge rules, work must be
done in the open,
and the entire OpenJDK community is welcome to watch and comment as the
projects
progress. The Innovators Challenge will close on August 4th at which
time each
project will be reviewed to verify that it met the completion criteria
of its
proposal. Cash prizes will be awarded shortly afterwards.

Thanks again to everyone who has participated. Good luck to all
Finalists on your
projects!

Regards,

     --  rms

--
Rich Sands                     Phone: +1 781 881 4067 / x81524
Community Marketing Manager    Email: [EMAIL PROTECTED]
Java SE Marketing              SMS: [EMAIL PROTECTED]
Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1332 - Release Date:
3/17/2008 10:48 AM


No virus found in this outgoing message.
Checked by AVG. Version: 7.5.519 / Virus Database: 269.21.7/1333 - Release Date: 3/18/2008
8:10 AM

Reply via email to