Skip to main content

Getting the JDK to use gcc

39 replies [Last post]
atripp
Offline
Joined: 2003-07-15

Having spent the last few days trying to compile the JDK on Windows, I now have a real answer to Ray Gans' question: "What can Sun do to encourage more outside JDK contributions"? The answer: move the standard JDK compilation to use gcc on all platforms.

There was talk of this back in late 2004:
http://forums.java.net/jive/thread.jspa?threadID=246&start=0&tstart=0
where it even sounded like serious efforts were underway to support some free compiler on Windows. Having to buy and install MSVC++6.0sp2 is just a huge burden.

See my feeble efforts to compile hotspot:
http://forums.java.net/jive/thread.jspa?threadID=15632&tstart=0

and Mike Atkinson's efforts to compile the JDK:
http://forums.java.net/jive/thread.jspa?threadID=15423&tstart=0

If Sun could just get onto a fairly recent gcc for Windows, Linux, and Solaris, that would make everyone's lives easier. Keep officially supporting only one version of Linux as you do today, that's ok.

Yes, doing so would be difficult. But it would not only clean up Sun's current build process, it would do a better job of enforcing standards-compliant code, and probably a performance boost too. But most important, it would make it feasible for mere-mortal outsiders to compile the JDK.

Thoughts?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwenting
Offline
Joined: 2003-12-02

> heh, that does raise an interesting question... does
> compiling source from someone else constitute a
> violation of the license?
>
no, but letting others use your machine concurrently to do so (which is what making the compiler available through a webservice would amount to) would be.

It's the same with (most) database servers. When running as a backend for a webapplication most will require the license holder to have licenses for the expected number of concurrent users of the web application, not the number of concurrent connections the web application makes (through connection pools for example) to the database server).
This to prevent the common scenario of a web application with a thousand users needing only 10 or so database connections.

atripp
Offline
Joined: 2003-07-15

> no, but letting others use your machine concurrently
> to do so (which is what making the compiler available
> through a webservice would amount to) would be.

Does that imply that allowing serial access would be ok? We'd surely only want one JDK build going at a time anyway. I know, I know, I should check with a lawyer :( The good news is, I am meeting with a lawyer next week, so I will :)

kellyohair
Offline
Joined: 2004-09-03

Well, funny you should suggest the JDK-compilation idea.

I won't go into details, but in the past such a thing didn't exist, even for internal JDK developers, but I've been working on the basics of such a system for internal use and have recently got it up and running, providing builds and smoke testing on 4 Solaris platforms, 2 Linux platforms, and 2 Windows platforms. It's hobbling along now.

The Hotspot team has had such a system for a long time, but just for internal use. It greatly simplifies the Hotspot developer's job. I'm hoping that this new system will also help out the j2se developer too.

Making such a system available to external people would be an interesting idea, and something that I have had in the back of my head as I've worked on it. At a minimum I'm hoping it will help the Sun engineers deal with the contributions quicker. But as to making it externally available, I can't really commit to that, but it's a really interesting idea.

-kto

atripp
Offline
Joined: 2003-07-15

There may be a licensing issue with providing a compilation service to the general public using MSVC++. My EULA for MSVC++ .net 2003 says:

"... for the purposes of designing developing testing and demonstrating your software products provided that you are the only individual using the Software..."

IANAL, but that might be saying that you can't provide access to MSVC++ as a web service. Having said that, if you do get permission to make it available, I'll be happy to make it available unless/until MS tells me it's a violation of the license :)

leouser
Offline
Joined: 2005-12-12

heh, that does raise an interesting question... does compiling source from someone else constitute a violation of the license?

leouser

kellyohair
Offline
Joined: 2004-09-03

Not being (or wanting to be) a lawyer or legal expert :^), I don't have any definite answers here. But if you needed a MSVC license to run anything built by MSVC compilers, then we are all in big trouble :^(.

I'm assuming such a build beast would accept JDK source changes or diffs (based on a particular build number), and you would get back JDK install images for all platforms (or the ones you ask for), not *.obj files. But it's just a dream, it's not real. ;^)

-kto

robilad
Offline
Joined: 2004-05-05

You're probably confusing "Software" and "your software". They are most likely not the same thing, i.e. everyone is allowed to run 'your software', but only you are allowed to run Microsoft's 'Software'. ;)

atripp
Offline
Joined: 2003-07-15

> You're probably confusing "Software" and "your
> software". They are most likely not the same thing,
> i.e. everyone is allowed to run 'your software', but
> only you are allowed to run Microsoft's 'Software'. ;)

I think it's pretty clear. "...your software" means the JDK here, and "...you are the only individual using the Software" is referring to the MSVC++ compiler. Whether the JDK is "my software" or not is very questionable, and whether I'm the only individual using the MSVC++ compiler is *VERY* questionable.

robilad
Offline
Joined: 2004-05-05

Andy: yeah, we're in violent agreement. :)

atripp
Offline
Joined: 2003-07-15

> Andy: yeah, we're in violent agreement. :)

Oops, I see now. You were responding to Kelly, not me :)

kellyohair
Offline
Joined: 2004-09-03

> OK, let's look at hprof_md.c as an example. Comparing
> the win32 and solaris versions, we see first see that
> some functions are identical (md_getpid, md_connect,
> md_recv, etc). Why have two versions of a function
> when the two are identical?

Initially, they weren't identical, or I assumed that they would need to be different. PID's on windows are a little strange at times. I guess I must have wanted to allow for a difference.

>
> Of the functions that do have platform-specifics in
> them, why aren't there a system-wide libraries to
> hide these platform-specifics from each developer?

Good question. I don't know. But I suspect it was tried before and became hard to maintain, or perhaps hard to keep all the code using it.

> Surely hprof isn't the only one who needs to open a
> file, call seek and get back a 64-bit int, etc.
>

The hprof and debugger backend are VM JVMTI/JNI agents, and as VM agents they have restrictions on them that normal JNI libraries might not have. All JNI native libraries also have certain things they need to watch out for, because they all are running inside a VM process. I suspect that sometimes, protectionism may have been considered wise in some of these libraries, and perhaps the platform needs were so unusual that the shared code didn't make sense. I really don't know for sure, this is a bit of guess work because I don't have the history with these sources like others.

In any case, yes, you are right. But is it really worth changing? These areas of the source are not troublesome and changing it drastically can cause more grief for the many who have already ported the code (needless diffs?).

> You've done a great job of isolation for hprof, but
> now every other JDK developer must do the same.
> Wouldn't it be better to put ALL platform-specifics
> for all of the JDK in one place? I know this is how
> I've always seen it done on the large projects that
> I've been on. I recall vaguely how Mozilla does it.
>
> I know it's easy for me to just say "you should do it
> this way", and I know it would be a royal pain to do
> this (that's one of the major reasons we all love
> Java, right?).

I've been mucking with software for over 25 years now, and I know from experience that sometimes you just need to stop, step back and say 'it's not perfect, but that's good enough', ideally you get multiple reviewers to agree too :^). Deep down you don't want to say that, but everybody has to at some point. Perhaps some people do it too soon, and a few wait too long. I decided that hprof was good enough, and I at least got hprof and the debugger backend to share the ugly UTF8 conversion code, but I had to draw the line somewhere.

>
> >
> > In Mustang I created a library called npt
> (libnpt.so
> > or npt.dll) located in j2se/src/*/npt, mostly
> because
> > I needed a pure native means of converting UTF8 to
> > the default system character encoding. This UTF8
> > conversion logic is really ugly stuff, and I
> didn't
> > want this code copied. I wanted to try and isolate
> > more of this type of code in the JDK to npt, but
> > never got the chance. It's a major cleanup task.
> >
> > It's easy to say you want to reduce the number of
> > compiler-specific and platform-specific
> constructs,
> > but in real life it can be very difficult. It's a
> > good goal, and I agree completely that we need to
> > try, it's just not as easy as it should be. I feel
> > that it needs to be isolated, and have tried to do
> > that, but going in and changing old dusty code
> that
> > has worked fine for many years isn't always the
> best
> > thing to do.
>
> Yea, I realize that this is one of those things that
> is just never "worth the effort". But once done, it
> really does seem worth it. See the Mozilla NSPR
> library as an example of what I'm talking about:
> http://www.mozilla.org/projects/nspr/

Converting the j2se to use this library would not go over well (ignoring the GPL issue). Yes, it's well done, and complete, but I could never see this conversion happening. You just can't justify a major software re-write or re-structuring when the benefits aren't visible from a product perspective, and the quality/performance risks are significant.

However, if you can divide up this kind of work and minimize or localize the risks, then you have something you can get approval for. So from my perspective, anything we would do in this area needs to be incremental.

>
> >
> > I suspect that the above components (hprof &
> backend)
> > I could say "should just compile with a standard C
> > compiler", but I would have to add "except for gcc
> on
> > windows". :^(
>
> Why doesn't gcc on windows work?

Actually, I take that back, I don't know if it would compile with gcc on Windows. I assume it wouldn't because of the windows (MSVC specific/) #include files it might be using. I have never tried it.

-kto

atripp
Offline
Joined: 2003-07-15

> You just can't justify a major software re-write or re-structuring when the benefits aren't visible from a product perspective, and the quality/performance risks are significant.

This is the key issue. Long ago, I had done all the work to get a large app to use a C++ compiler instead of C. They wouldn't let me make the change because it would require a "code freeze" over a weekend while I made the change. Today, 15 years later, they *still* are stuck on C, because it's never worth the effort to freeze the code for a couple of days to go from C to C++ (adding no tangible benefit).

How about an alternative to cleaning up the JDK build: how about a web-based JDK-compilation servlet? Let me upload my changed/added file(s), have the servlet incorporate those changes into a "clean build" on my platform of choice. Send me to a results page where I can see the
make output and download the resulting jar files.

I had thought of trying to do this myself, but alas, too busy.

This would allow Sun outsiders to build the JDK without all the setup headaches.

leouser
Offline
Joined: 2005-12-12

that's an intriguing idea, if you have compilation servers that work then you do escape the problem of getting the darn thing to compile on your platform. Id guess Id be curious as to how feasible the idea is if a large group of people start relying on the service?

leouser

alexlamsl
Offline
Joined: 2004-09-02

At that point you will ended up with a compilation and testing farm - how large is SourceForge's at the moment?

atripp
Offline
Joined: 2003-07-15

> At that point you will ended up with a compilation
> and testing farm - how large is SourceForge's at the
> moment?

100,000 sourceforge projects and getting pretty darn slow.

I would think Sun could cover 80% of the need with 20% of the work: only support compiling the latest Mustang build with a single version of Win32, a single version of Solaris, and a single version of a particular Linux distro. Make the source for the servlet available, and others will no doubt provide the same service if there's a demand (and assuming the JDK license allows it).

mthornton
Offline
Joined: 2003-06-10

>
> Hmmm...so you're saying that there's no IPC mechanism
> that can be used across Linux, Solaris, and Windows?
> Or is it more likely that one individual developer
> hit some issues that he couldn't resolve?
>

In my experience there are many cases where functions that would be used in *nix also exist in Windows, but if you do use them there is some sort of performance or quality penalty. In other words although you could use the same mechanism, that mechanism is noticably less good than the Windows preferred implementation. Sometimes the preferred implementation isn't even the same for all versions of Windows. Issues with file paths greater than 260 characters in length would be one simple example.

scotthutinger
Offline
Joined: 2005-08-25

I have found that the biggest gain in performance is in jit/hotspot. But yes, compilers and java/and the OS are really good for checking how good they really are :-) Both the OS and compilers have always had major problems. Cool it's running under that compiler, as I always had major problems with it in the past. (years ago, not lately). And yes, in gcc, you have to turn off opt's in certain crash areas that are found in debugging. Sort of a pain...

I think the runtime native code makes everything move a bit faster, major... I don't think an initial port is easy when you don't follow the x86 path. Template based assembly language isn't all that easy to get up running. The fun part is the C2 :-)

kellyohair
Offline
Joined: 2004-09-03

I worked in two areas dominated by native C code in the JDK in the 5.0 and Mustang releases. So I'll air some of my dirty laundry here... ;^)

I did lots of work on the debugger backend jdwp and also hprof in the Tiger release, and tried to isolate the OS specific code as best I could. The hprof code probably has a higher OS dependence than much of the code in the JDK, but it's a good example. Take a look at the sources j2se/src/*/demo/jvmti/hprof/hprof_md.*. I'm not holding this up as perfect by any means, but getting this right (and I'm sure it's not 100% right either) was very difficult. With hprof the code was a complete re-write from the old hprof, but needed to match the original functionality (which wasn't documented well). With the debugger backend (j2se/src/*/back) it was more like surgery. Both these involved converting from JVMDI or JVMPI to JVM TI. In the process I saw some common issues, but could not address them in 5.0.

In Mustang I created a library called npt (libnpt.so or npt.dll) located in j2se/src/*/npt, mostly because I needed a pure native means of converting UTF8 to the default system character encoding. This UTF8 conversion logic is really ugly stuff, and I didn't want this code copied. I wanted to try and isolate more of this type of code in the JDK to npt, but never got the chance. It's a major cleanup task.

It's easy to say you want to reduce the number of compiler-specific and platform-specific constructs, but in real life it can be very difficult. It's a good goal, and I agree completely that we need to try, it's just not as easy as it should be. I feel that it needs to be isolated, and have tried to do that, but going in and changing old dusty code that has worked fine for many years isn't always the best thing to do.

I suspect that the above components (hprof & backend) I could say "should just compile with a standard C compiler", but I would have to add "except for gcc on windows". :^(

-kto

P.S. By the way, the 3 implementations of attachListener.cpp was very necessary, and although I can't speak to the specifics, each platform had unique issues. As to whether there is a better coding layout for this type of code, perhaps, but I tend to avoid religious wars. ;^)

atripp
Offline
Joined: 2003-07-15

> I worked in two areas dominated by native C code in
> the JDK in the 5.0 and Mustang releases. So I'll air
> some of my dirty laundry here... ;^)

Cool. Please take my comments below as constructive criticism.

>
> I did lots of work on the debugger backend jdwp and
> also hprof in the Tiger release, and tried to isolate
> the OS specific code as best I could. The hprof code
> probably has a higher OS dependence than much of the
> code in the JDK, but it's a good example. Take a look
> at the sources
> j2se/src/*/demo/jvmti/hprof/hprof_md.*. I'm not
> holding this up as perfect by any means, but getting
> this right (and I'm sure it's not 100% right either)
> was very difficult. With hprof the code was a
> complete re-write from the old hprof, but needed to
> match the original functionality (which wasn't
> documented well). With the debugger backend
> (j2se/src/*/back) it was more like surgery. Both
> these involved converting from JVMDI or JVMPI to JVM
> TI. In the process I saw some common issues, but
> could not address them in 5.0.

OK, let's look at hprof_md.c as an example. Comparing the win32 and solaris versions, we see first see that some functions are identical (md_getpid, md_connect, md_recv, etc). Why have two versions of a function when the two are identical?

Of the functions that do have platform-specifics in them, why aren't there a system-wide libraries to hide these platform-specifics from each developer? Surely hprof isn't the only one who needs to open a file, call seek and get back a 64-bit int, etc.

You've done a great job of isolation for hprof, but now every other JDK developer must do the same. Wouldn't it be better to put ALL platform-specifics for all of the JDK in one place? I know this is how I've always seen it done on the large projects that I've been on. I recall vaguely how Mozilla does it.

I know it's easy for me to just say "you should do it this way", and I know it would be a royal pain to do this (that's one of the major reasons we all love Java, right?).

>
> In Mustang I created a library called npt (libnpt.so
> or npt.dll) located in j2se/src/*/npt, mostly because
> I needed a pure native means of converting UTF8 to
> the default system character encoding. This UTF8
> conversion logic is really ugly stuff, and I didn't
> want this code copied. I wanted to try and isolate
> more of this type of code in the JDK to npt, but
> never got the chance. It's a major cleanup task.
>
> It's easy to say you want to reduce the number of
> compiler-specific and platform-specific constructs,
> but in real life it can be very difficult. It's a
> good goal, and I agree completely that we need to
> try, it's just not as easy as it should be. I feel
> that it needs to be isolated, and have tried to do
> that, but going in and changing old dusty code that
> has worked fine for many years isn't always the best
> thing to do.

Yea, I realize that this is one of those things that is just never "worth the effort". But once done, it really does seem worth it. See the Mozilla NSPR library as an example of what I'm talking about:
http://www.mozilla.org/projects/nspr/

>
> I suspect that the above components (hprof & backend)
> I could say "should just compile with a standard C
> compiler", but I would have to add "except for gcc on
> windows". :^(

Why doesn't gcc on windows work?

>
> -kto
>
> P.S. By the way, the 3 implementations of
> attachListener.cpp was very necessary, and although I
> can't speak to the specifics, each platform had
> unique issues.

Hmmm...so you're saying that there's no IPC mechanism that can be used across Linux, Solaris, and Windows? Or is it more likely that one individual developer hit some issues that he couldn't resolve?

> As to whether there is a better
> coding layout for this type of code, perhaps, but I
> tend to avoid religious wars. ;^)

Yea, let's not go there.

robilad
Offline
Joined: 2004-05-05

> > In Mustang I created a library called npt
> (libnpt.so
> > or npt.dll) located in j2se/src/*/npt, mostly
> because
> > I needed a pure native means of converting UTF8 to
> > the default system character encoding.

The joys of proprietary software development. Tried librecode? (GPLd, of course)

> Yea, I realize that this is one of those things that
> is just never "worth the effort". But once done, it
> really does seem worth it. See the Mozilla NSPR
> library as an example of what I'm talking about:
> http://www.mozilla.org/projects/nspr/

Yeah. Such wrapper libs are neat. I prefer glib, myself, as it has less cruft, and integrates well with the rest of the GNOME stuff. If you are doing C++, Qt also offers a great abstraction over common OS differences. GPLd, but worth it.

> Hmmm...so you're saying that there's no IPC mechanism
> that can be used across Linux, Solaris, and Windows?
> Or is it more likely that one individual developer
> hit some issues that he couldn't resolve?

Assuming what you need is a callback mechanism, see libsig++.

binkley
Offline
Joined: 2003-08-01

Use the -mno-cygwin flag.

atripp
Offline
Joined: 2003-07-15

> Porting the jdk windows code to gcc will be a huge undertaking, especially I asssume for hotspot.

I see the main goal as reducing the number of compiler-specific and platform-specific constructs in the source. This would reduce the headaches of compiling with different compilers. So it's not so much that gcc itself is the goal, but to change the phrase "we've never tried to compile with that compiler/version, so it's very unlikely it will work" to "...it's very likely that it will work."

FWIW, I remembered that I had bought a copy of visual studio 7 (aka "MSVC++ .NET 2003) Standard Edition (not Professional). That works much better than VS .NET 2005.

> We've had lots of problems migrating from one MSVC version to another, I can't imagine what we would run into when porting to gcc..

Right. Again, the main point is to reduce this headache by having the code be vanilla standard C/C++ as much as possible.

> Porting the jdk windows code to gcc will be a huge undertaking, especially I asssume for hotspot.

I've started trying to list the differences in the various platform-specific JDK code: http://jazillian.com/articles/nativeJDKNotes.html

Perhaps this could serve as talking points for what the effort would entail. For example, we see that we have 3 different implementations of attachListener.cpp: win32 uses pipes, linux uses domain sockets, and solaris uses "doors" IPC. Is there a good reason for this? Couldn't we change things to the same mechanism on all 3 platforms? Maybe not, but it's a good question :)

atripp
Offline
Joined: 2003-07-15

Just want to mention...though making the JDK be far more portable would be a large task, others have obviously been here before. Just google for "writing portable c++", and you'll see lots of examples. One classic is this from Mozilla:

http://www.mozilla.org/hacking/portable-cpp.html

What I'd really like to see is someone who knows the native parts of the JDK to look at it and say "if we just follow all these well-known rules for writing standard C++, how far will that get us?" It may come down to a small set of fairly small set of platform-specific issues (threading, fork/exec, file I/O, signal handling), which can be isolated from the rest of the code.

atripp
Offline
Joined: 2003-07-15

For what it's worth, the Kaffe VM claims to have been ported to a zillion different platforms:
http://www.kaffe.org/ports.shtml
...and says "Much of the work on these ports have not been merged into the main Kaffe tree."

And you can download Kaffe binaries for FreeBSD, Linux and NextStep:
http://www.kaffe.org/ftp/pub/kaffe/binaries/

robilad
Offline
Joined: 2004-05-05

More than 80 ports so far, with 60 in-tree ports atm. For the next release, I'm working on a port to SESC, a simple-scalar simulator architecture, based on mipseb-linux, and there will be a port to amd64-openbsd merged in that's already used to build Sun's JDK on that platform, etc.

Kaffe is a rather well-designed project, it cross-compiles nicely to most platforms, for example. That keeps it working with a fraction of time & money of other projects. Help is always welcome, and I would not mind sharing some of our build code or the portable gc with Sun, when they actually decide to go free software with their implementation.

jwenting
Offline
Joined: 2003-12-02

gcc isn't the best of compilers.
Relatively poor standards compliance, not the best optimisation, etc.

And of course the linkage to cygwin is a major problem.
mingw sounds nice but AFAIK isn't kept up to date with the other releases causing rapid source incompatibility between platforms.

A better option would be for Sun to create a C++ compiler for Windows and Linux that's source compatible with their Solaris compilers and use that.

But that would be a massive program as well.

linuxhippy
Offline
Joined: 2004-01-07

I would be also very happy if java would build using gcc also on windows. VC++ is a burden!
HOwever to be honest I would not contribute patches anyhow as long as java isn't somehow open (at least guaranteed to be available under the current terms).

> gcc isn't the best of compilers.
> Relatively poor standards compliance, not the best
> optimisation, etc.
Well exactly the same applies to MSVC++, escpecially in the currently used 6.0 version.
Gcc generates code which is about overall 10% slower than Intel's C compiler which is what I would call quite good, keeping in mind the amout of platforms supported.

> mingw sounds nice but AFAIK isn't kept up to date
> with the other releases causing rapid source
> incompatibility between platforms.
Well, MinGW catches up from time to time and if you don't use abscurce language features its much easier to stay gcc-compatible over some releases than to support completly different compilers.
Furthermore no one forces you to use the latest gcc, sun also does not use VC++ 8.0.

Same for Sun, what would be less work - to keep MinGW up to date or to prot/produce their compilers for many different platforms.

lg Clemens

>
> A better option would be for Sun to create a C++
> compiler for Windows and Linux that's source
> compatible with their Solaris compilers and use
> that.
>
> But that would be a massive program as well.

alexlamsl
Offline
Joined: 2004-09-02

> Gcc generates code which is about overall 10% slower
> than Intel's C compiler which is what I would call
> quite good, keeping in mind the amout of platforms
> supported.

I think the crucial factor here is the amount of customers it covers, rather than the quanitity of hardware configurations that it supports.

> Furthermore no one forces you to use the latest gcc,
> sun also does not use VC++ 8.0

But I think they do try to come up to the latest if possible. BTW, isn't the Mustang codebase built with VS 2003 (which reads 7.1 on my version here) these days?

kellyohair
Offline
Joined: 2004-09-03

Mustang is built with Visual Studio .NET 2003 (VS2003 or VC7.1). It did generate faster code than VC6.2 (used in JDK 5), but the performance increase was hard to see. The larger runtime (msvcr71.dll) also increased our footprint a bit. But both were not major issues. Probably the biggest factor was the increased performance of the VM and AWT, but again, this is really hard to measure and see. We saw small percentages in the benchmarks we ran, some more than others, but many showed no change.

Code quality is a primary concern for any compiler used to build the JDK, performance of the code is important but often it's not the code generated by the C/C++ compiler that ends up being the bottleneck in Java apps. Most Java benchmarks (and I suspect most Java apps) are dominated by the Java code and how well the VM generates code from the class bytecode. So depending on the Java app, the C/C++ code quality may or may not make a difference.

In any case, there is a concern about what happens to performance on Windows if you don't use VS2003 or VS2005, so any switch will need to be carefully measured. I suspect that we would stick with VS2003 or VS2005 for the official builds, and just allow for building with gcc (assuming we took this task on, or someone on the outside took it on).

The BIGGEST issue we have had with changing compilers is having to track down buggy compilers or optimizers, or bugs in our own code that start manifesting themselves under new optimizations from those compilers. It usually requires getting specific engineering teams involved that understand the code details, and although these kinds of problems get solved, the logistics of co-ordinating the teams and getting their dedicated time can be overall, very slow. Initial ports can skip optimizations and have an easier start, but ultimately things like the VM do need to get fully optimized.

-kto

robilad
Offline
Joined: 2004-05-05

> The BIGGEST issue we have had with changing compilers
> is having to track down buggy compilers or
> optimizers, or bugs in our own code that start
> manifesting themselves under new optimizations from
> those compilers.

From my experience with different toolchains, that largely due to bugs in one's own C code. Does Mustang compile warning-free on gcc 4.1.1 with optimisations turned on?

kellyohair
Offline
Joined: 2004-09-03

Don't forget, the VM code is not just vanilla C++ code, it also contains highly customized assembly code. The VM coding is highly optimized code, much more so that your generic C/C++ application. Remember the VM generates code too, and when that generated code meets the C/C++ generated code, well, sometimes things just don't work, sometimes it's just bad assumptions on the VM part, sometimes it's questionable optimizations on the C/C++ compiler part. Sometimes it's just bad karma.

And yes, the VM in particular compiles cleanly, but I'm not sure if anyone is using gcc 4.1.1. The rest of the JDK could use some warning message cleanup, but the VM has always been pretty clean with regards to all compiler warning diagnostics.

-kto

m_r_atkinson
Offline
Joined: 2003-08-29

Having got the source to compile using the Microsoft Visual C++ compiler (Visual C++ Compiler 2005 Express Edition), I am not too optimistic about using gcc for Windows. I suspect it will be a quite a lot of work.

We need to compare generated code quality as well, it is no use making gcc the standard for Windows if it produces worse quality code than the Microsoft VC++ Express compiler.

I would recommend going to the Microsoft VC++ Express compiler for Dolphin, always assuming they have not crippled it in some way, being one release higher than that currently in the default build system (it is 14.x, while I beleived 13.x is used by Sun) it is likely to better conform to the C++ specification and maybe produce better code.

xmirog
Offline
Joined: 2003-10-09

Just another link, free compilers:

http://www.thefreecountry.com/compilers/cpp.shtml

Regards,

Xavi

xmirog
Offline
Joined: 2003-10-09

I haven't used gcc to compile in Windows a lot, but I also think it would be difficult to change the compiler in the JDK scripts.

But there's a free Microsoft Visual C++ compiler (Visual C++ Compiler 2005 Express Edition) here:

http://msdn.microsoft.com/vstudio/express/visualc/download/

It seems to be free. I don't know if it will compile with the same JDK scripts...but perhaps it works.

I hope this helps.

Xavi

kellyohair
Offline
Joined: 2004-09-03

Speaking as someone that has bloody fingers from building on Windows, I cannot disagree with you. There are concerns here, but we won't know until we try. Solaris builds using Solaris compilers is probably not going to change, but then again building Solaris with gcc is just a small mountain to climb. Getting the Windows builds to use gcc would be a big mountain to climb. But perhaps this mountain needs to be conquered, or at least scoped out.

IF (note the big "if") we started to consider this, what version of gcc/g++ on Windows would provide us the best chance of success? We need to find the most stable and best performance (in comparison to Visual Studio C++), does anyone have any suggestions? I've never used gcc on Windows before, so any help or suggestions would be helpful.

No promises here. But even if we ended up with a list of potential problems it would be worth it.

-kto

alexlamsl
Offline
Joined: 2004-09-02

Wait a minute - does gcc build executables that are runnable without cygwin?

And even if this is the case, I'd expect the compiler optimisations to be minimal...

kellyohair
Offline
Joined: 2004-09-03

Well... I just tried a hello world C program with cygwin, and it creates an "a.exe" that only runs from the cygwin environment. The Windows dumpbin /dependents utility says it has a cygwin1.dll dependency. I can't find any documentation on this dll, I suspect it's the main<->CRT startup code.

In any case, it looks like I need a gcc built for plain old Windows maybe, one that might use the standard windows libraries? Any ideas anyone anyone? Looking for a gcc on Windows expert... ;^)

The object file format appears to be the same at least, although the filename suffix is '.o' instead of '.obj'.

-kto

robilad
Offline
Joined: 2004-05-05

Kelly,

check out mingw32. It's a gcc toolchain that does uses MSVCRT.DLL rather than cygwin's newlib, i.e. creates native executables without using (and providing) a POSIX/GNU emulation layer.

trembovetski
Offline
Joined: 2003-12-31

Well, this is definitely something we would like to see, but I seriously doubt that we have the resources to throw at it.

Porting the jdk windows code to gcc will be a huge undertaking, especially I asssume for hotspot.

We've had lots of problems migrating from one MSVC version to another, I can't imagine what we would run into when porting to gcc..

Thanks,
Dmitri