| Message ID | mcrocaa18nt.fsf@google.com |
|---|---|
| State | New |
| Headers | show |
On 10/31/2010 07:09 PM, Ian Lance Taylor wrote: > This patch should not of course change whether or not distros choose to > package the Java compiler; undoubtedly they would continue to do so, > just as they package the Ada compiler today. > > Comments? Approvals? I see your point, but this will lead to some quality regressions in gcc itself. libgcj is a good stress test for gcc, and has revealed some bugs in the past. It might be possible to mitigate some of this with autotesters that run a full libgcj bootstrap every night. Andrew.
On 31/10/2010 19:09, Ian Lance Taylor wrote: > Java in the same category as Ada and Objective C++. The main argument > in favor of this proposal is twofold: 1) building libjava is a large > component of gcc bootstrap time, and thus a large component in the > amount of time it takes to test changes; Proposing to change the compiler as a solution to that problem seems to be a category error to me. You can achieve the same end-result by social rather than technical means: just change the rules for patch submission to say "You don't have to test your patch against Java". > 2) it is in practice very > unusual for middle-end or back-end changes to cause problems with Java > without also causing problems for C/C++, This seems like false reasoning as well. It may (or may not - I don't suppose anyone's actually done the number on this, have they?) be unusual, but the bugs that meet this criterion are nonetheless real bugs that we do not want to put into our compiler if we can possibly help it, they will subsequently need discovering, analysing and fixing, and will require manpower and resources to do so. I find it hard not to expect that the long-term outcome will be a gradual decline in quality of gcj if we do this. Particularly on minority platforms, which are exactly the ones that have the least manpower available to fix problems. For these reasons, my "vote" is against making this change. cheers, DaveK
Dave Korn <dave.korn.cygwin@gmail.com> writes: > On 31/10/2010 19:09, Ian Lance Taylor wrote: > >> Java in the same category as Ada and Objective C++. The main argument >> in favor of this proposal is twofold: 1) building libjava is a large >> component of gcc bootstrap time, and thus a large component in the >> amount of time it takes to test changes; > > Proposing to change the compiler as a solution to that problem seems to be a > category error to me. You can achieve the same end-result by social rather > than technical means: just change the rules for patch submission to say "You > don't have to test your patch against Java". I think the two statements are essentially equivalent. These days, when most ordinary users get their compiler from a distro or other binary form, the set of default languages is most important for gcc developers. We currently say that for middle-end or backend patches you must bootstrap with all default languages. Changing the set of default languages is a way of changing that statement. It's not, in my opinion, a category error. Ian
On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor <iant@google.com> wrote:
> Comments? Approvals?
FWIW, I agree with this patch for the same reasons stated by Ian.
Other than massively increasing build times, I have not seen
substantial benefits for having java enabled by default. Ada, on the
other hand, has shown more usefulness in exposing bugs (particularly,
middle end) and is many times faster.
This is the kind of patch that requires more consensus or agreement
from the java maintainers. aph, are you dead set against disabling
java? Is there anything we could do to change your mind?
Thanks. Diego.
On 11/01/2010 06:16 PM, Diego Novillo wrote: > On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor <iant@google.com> wrote: > >> Comments? Approvals? > > FWIW, I agree with this patch for the same reasons stated by Ian. > Other than massively increasing build times, I have not seen > substantial benefits for having java enabled by default. Ada, on the > other hand, has shown more usefulness in exposing bugs (particularly, > middle end) and is many times faster. > > This is the kind of patch that requires more consensus or agreement > from the java maintainers. aph, are you dead set against disabling > java? No. > Is there anything we could do to change your mind? Yes, if we have an autotester that runs the libgcj test suite and mails maintainers (or the list) when they break things. Andrew.
On Mon, Nov 1, 2010 at 11:58 AM, Andrew Haley <aph@redhat.com> wrote: > >> Is there anything we could do to change your mind? > > Yes, if we have an autotester that runs the libgcj test suite and > mails maintainers (or the list) when they break things. > I don't mind enabling Java in my autotesters for Linux/ia32 and Linux/x86-64.
On 11/01/10 12:16, Diego Novillo wrote: > On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor<iant@google.com> wrote: > >> Comments? Approvals? > FWIW, I agree with this patch for the same reasons stated by Ian. > Other than massively increasing build times, I have not seen > substantial benefits for having java enabled by default. Ada, on the > other hand, has shown more usefulness in exposing bugs (particularly, > middle end) and is many times faster. > > This is the kind of patch that requires more consensus or agreement > from the java maintainers. aph, are you dead set against disabling > java? Is there anything we could do to change your mind? Building libjava (at least for me) is primarily painful due to 2 files (the names escape me) and the rather poor coarse level parallelism (can't build the 32bit and 64bit multilibs in parallel for example). Has anyone looked at fixing the build machinery for libjava to make it more sensible? I'd personally prefer java over ada as I'm able to understand java code easier, thus when something does go wrong I'm able to debug it much faster. Jeff
On Mon, Nov 1, 2010 at 8:39 PM, Jeff Law <law@redhat.com> wrote: > On 11/01/10 12:16, Diego Novillo wrote: >> >> On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor<iant@google.com> wrote: >> >>> Comments? Approvals? >> >> FWIW, I agree with this patch for the same reasons stated by Ian. >> Other than massively increasing build times, I have not seen >> substantial benefits for having java enabled by default. Ada, on the >> other hand, has shown more usefulness in exposing bugs (particularly, >> middle end) and is many times faster. >> >> This is the kind of patch that requires more consensus or agreement >> from the java maintainers. aph, are you dead set against disabling >> java? Is there anything we could do to change your mind? > > Building libjava (at least for me) is primarily painful due to 2 files (the > names escape me) and the rather poor coarse level parallelism (can't build > the 32bit and 64bit multilibs in parallel for example). > > Has anyone looked at fixing the build machinery for libjava to make it more > sensible? > > I'd personally prefer java over ada as I'm able to understand java code > easier, thus when something does go wrong I'm able to debug it much faster. > FWIW, it takes about 33minutes to bootstap gcc trunk on Fedora 13/Intel Core i7 870 with both 32bit and 64bit libraries. I configure gcc with -enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enab le-shared --enable-threads=posix --enable-haifa --prefix=/usr/gcc-4.6.0 --with- local-prefix=/usr/local --with-fpmath=sse --with-plugin-ld=ld.gold --enable-gold --with-fpmath=sse
On 31.10.2010 20:09, Ian Lance Taylor wrote: > Currently we build the Java frontend and libjava by default. At the GCC > Summit we raised the question of whether should turn this off, thus only > building it when java is explicitly selected at configure time with > --enable-languages. Among the people at the summit, there was general > support for this, and nobody was opposed to it. > > Here is a patch which implements that. I'm sending this to the mailing > lists gcc@ and java@, as well as the relevant -patches@ lists, because > it does deserve some broader discussion. > > This is not a proposal to remove the Java frontend nor is it leading up > to that. It is a proposal to not build the frontend by default, putting > Java in the same category as Ada and Objective C++. The main argument > in favor of this proposal is twofold: 1) building libjava is a large > component of gcc bootstrap time, and thus a large component in the > amount of time it takes to test changes; 2) it is in practice very > unusual for middle-end or back-end changes to cause problems with Java > without also causing problems for C/C++, thus building and testing > libjava does not in practice help ensure the stability of the compiler. > A supporting argument is since Sun has released their Java tools under > the GPL, community interest seems to have shifted toward the Sun tools; > gcc's Java frontend is in maintenance mode, with little new development > currently planned. please note that gcj is still required for a bootstrap of openjdk on platforms which don't yet have a working openjdk. At least for this purpose it is still maintained. > This patch should not of course change whether or not distros choose to > package the Java compiler; undoubtedly they would continue to do so, > just as they package the Ada compiler today. > > Comments? Approvals? if build speed is the only issue, why not - disable the static libgcj build, if not explicitely enabled? - disable the biarch build for libgcj? most distributions don't have all of the depending libraries available for biarch builds. Matthias
> I'd personally prefer java over ada as I'm able to understand java code > easier, thus when something does go wrong I'm able to debug it much faster. If this can make any difference: even if Ada is enabled by default, we (I at least) will still be there to analyze hard-to-debug problems exposed by Ada.
On Mon, 2010-11-01 at 08:59 +0000, Andrew Haley wrote: > On 10/31/2010 07:09 PM, Ian Lance Taylor wrote: > > > This patch should not of course change whether or not distros choose to > > package the Java compiler; undoubtedly they would continue to do so, > > just as they package the Ada compiler today. > > > > Comments? Approvals? > > I see your point, but this will lead to some quality regressions in gcc > itself. libgcj is a good stress test for gcc, and has revealed some > bugs in the past. It might be possible to mitigate some of this with > autotesters that run a full libgcj bootstrap every night. Hi, Let's imagine we have a reliable tool on a distributed build farm that accepts set of patches (via mail and web with some authentification) and does automatic regression testing and report on selected platform. This would enable more ambitious in our testing requirements without having developpers invest in powerful machines to avoid being slowed down but would GCC developpers go as far as setting a requirement that patches must be validated by such a tool before commit for example by giving the URL of the tester result with suitable exceptions for trivial patches and tester being unavailable or overloaded, etc...? Sincerely, Laurent http://gcc.gnu.org/wiki/CompileFarm
>>>>> "Jeff" == Jeff Law <law@redhat.com> writes:
Jeff> Building libjava (at least for me) is primarily painful due to 2 files
Jeff> (the names escape me) and the rather poor coarse level parallelism
Jeff> (can't build the 32bit and 64bit multilibs in parallel for example).
Jeff> Has anyone looked at fixing the build machinery for libjava to make it
Jeff> more sensible?
Nope. AFAIK it is already as parallelized as possible, but it has been
a while since I looked at it.
I thought the really bad file (HTML_401F.java, IIRC) had some functions
split up so that it wasn't so evil any more.
The multilib thing sounds like a top-level problem of some kind.
At least, I don't recall that libjava does anything special here.
Tom
>>>>> "Laurent" == Laurent GUERBY <laurent@guerby.net> writes:
Laurent> Let's imagine we have a reliable tool on a distributed build
Laurent> farm that accepts set of patches (via mail and web with some
Laurent> authentification) and does automatic regression testing and
Laurent> report on selected platform.
Can we have it for gdb as well?
Tom
On 11/02/10 09:35, Tom Tromey wrote: >>>>>> "Jeff" == Jeff Law<law@redhat.com> writes: > Jeff> Building libjava (at least for me) is primarily painful due to 2 files > Jeff> (the names escape me) and the rather poor coarse level parallelism > Jeff> (can't build the 32bit and 64bit multilibs in parallel for example). > > Jeff> Has anyone looked at fixing the build machinery for libjava to make it > Jeff> more sensible? > > Nope. AFAIK it is already as parallelized as possible, but it has been > a while since I looked at it. > > I thought the really bad file (HTML_401F.java, IIRC) had some functions > split up so that it wasn't so evil any more. It's the libgcj_tools_la-tools which gets built twice for each architecture and its build seems to always fire off last and takes a few minutes for each compilation. > The multilib thing sounds like a top-level problem of some kind. > At least, I don't recall that libjava does anything special here. Yea, I suspect the way multilibs are handled is far from ideal from a parallel make standpoint. Fixing the underlying multilib goop may be ugly, but probably would have a nice benefit across the various runtime libraries we utilize. jeff
On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor <iant@google.com> wrote: > Currently we build the Java frontend and libjava by default. At the GCC > Summit we raised the question of whether should turn this off, thus only > building it when java is explicitly selected at configure time with > --enable-languages. Among the people at the summit, there was general > support for this, and nobody was opposed to it. > > Here is a patch which implements that. I'm sending this to the mailing > lists gcc@ and java@, as well as the relevant -patches@ lists, because > it does deserve some broader discussion. I count 33 messages on the topic and it is clear that there is no consensus. I am withdrawing this proposed patch. Ian
On 11/11/2010 3:20 PM, Ian Lance Taylor wrote: > On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor <iant@google.com> wrote: >> Currently we build the Java frontend and libjava by default. At the GCC >> Summit we raised the question of whether should turn this off, thus only >> building it when java is explicitly selected at configure time with >> --enable-languages. Among the people at the summit, there was general >> support for this, and nobody was opposed to it. > I count 33 messages on the topic and it is clear that there is no > consensus. I am withdrawing this proposed patch. I think that's a mistake. The arguments raised, such as the fact that Java tests non-call exceptions, are just not persuasive to me. If we need tests for a middle-end feature, we can almost always write them in C or C++. The bottom line is that libjava takes a very long time to build and that the marginal benefit is out of proportion to the cost. Building zillions of Java class files cannot be the best way to test non-call exceptions. If we have no tests for non-call exceptions in the C/C++ testsuite, perhaps you (Ian) could write a few in C++? Ian, I was prepared to approve the patch. I certainly won't do that if you now think it's a bad idea, but if you still think it's a good idea, I think you should go for it. I think that it should still be the case that if you break Java, and one of the Java testers catches you, you still have an obligation to fix the problem. All we're changing is whether you build Java by default; nothing else. Thank you,
On 11/18/2010 09:23 AM, Mark Mitchell wrote: > On 11/11/2010 3:20 PM, Ian Lance Taylor wrote: >> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor <iant@google.com> wrote: >>> Currently we build the Java frontend and libjava by default. At the GCC >>> Summit we raised the question of whether should turn this off, thus only >>> building it when java is explicitly selected at configure time with >>> --enable-languages. Among the people at the summit, there was general >>> support for this, and nobody was opposed to it. > >> I count 33 messages on the topic and it is clear that there is no >> consensus. I am withdrawing this proposed patch. > > I think that's a mistake. > > The arguments raised, such as the fact that Java tests non-call > exceptions, are just not persuasive to me. If we need tests for a > middle-end feature, we can almost always write them in C or C++. > > The bottom line is that libjava takes a very long time to build and that > the marginal benefit is out of proportion to the cost. Building > zillions of Java class files cannot be the best way to test non-call > exceptions. If we have no tests for non-call exceptions in the C/C++ > testsuite, perhaps you (Ian) could write a few in C++? > > Ian, I was prepared to approve the patch. I certainly won't do that if > you now think it's a bad idea, but if you still think it's a good idea, > I think you should go for it. > > I think that it should still be the case that if you break Java, and one > of the Java testers catches you, you still have an obligation to fix the > problem. All we're changing is whether you build Java by default; > nothing else. I made it pretty clear that as long as the autotesters build java, and I get emails when something breaks, and you have the obligation to fix whatever broke, I have no objection. Andrew.
On Thu, Nov 18, 2010 at 2:00 AM, Andrew Haley <aph@redhat.com> wrote: > On 11/18/2010 09:23 AM, Mark Mitchell wrote: >> On 11/11/2010 3:20 PM, Ian Lance Taylor wrote: >>> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor <iant@google.com> wrote: >>>> Currently we build the Java frontend and libjava by default. At the GCC >>>> Summit we raised the question of whether should turn this off, thus only >>>> building it when java is explicitly selected at configure time with >>>> --enable-languages. Among the people at the summit, there was general >>>> support for this, and nobody was opposed to it. >> >>> I count 33 messages on the topic and it is clear that there is no >>> consensus. I am withdrawing this proposed patch. >> >> I think that's a mistake. >> >> The arguments raised, such as the fact that Java tests non-call >> exceptions, are just not persuasive to me. If we need tests for a >> middle-end feature, we can almost always write them in C or C++. >> >> The bottom line is that libjava takes a very long time to build and that >> the marginal benefit is out of proportion to the cost. Building >> zillions of Java class files cannot be the best way to test non-call >> exceptions. If we have no tests for non-call exceptions in the C/C++ >> testsuite, perhaps you (Ian) could write a few in C++? >> >> Ian, I was prepared to approve the patch. I certainly won't do that if >> you now think it's a bad idea, but if you still think it's a good idea, >> I think you should go for it. >> >> I think that it should still be the case that if you break Java, and one >> of the Java testers catches you, you still have an obligation to fix the >> problem. All we're changing is whether you build Java by default; >> nothing else. > > I made it pretty clear that as long as the autotesters build java, and I > get emails when something breaks, and you have the obligation to fix > whatever broke, I have no objection. > > Andrew. > FYI, this testsuite regression is only seen in libjava: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515
On 11/18/10 02:23, Mark Mitchell wrote: > On 11/11/2010 3:20 PM, Ian Lance Taylor wrote: >> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor<iant@google.com> wrote: >>> Currently we build the Java frontend and libjava by default. At the GCC >>> Summit we raised the question of whether should turn this off, thus only >>> building it when java is explicitly selected at configure time with >>> --enable-languages. Among the people at the summit, there was general >>> support for this, and nobody was opposed to it. >> I count 33 messages on the topic and it is clear that there is no >> consensus. I am withdrawing this proposed patch. > [ ... ] > > The bottom line is that libjava takes a very long time to build and that > the marginal benefit is out of proportion to the cost. Building > zillions of Java class files cannot be the best way to test non-call > exceptions. If we have no tests for non-call exceptions in the C/C++ > testsuite, perhaps you (Ian) could write a few in C++? To put this in perspective, eliminating java cuts my build cycle time by more than 50%. > I think that it should still be the case that if you break Java, and one > of the Java testers catches you, you still have an obligation to fix the > problem. All we're changing is whether you build Java by default; > nothing else. Agreed. I'd really like to see java removed from the default languages; I just don't see the cost vs benefit justifies keeping java in the default languages. Jeff
On 11/18/2010 2:00 AM, Andrew Haley wrote: > I made it pretty clear that as long as the autotesters build java, and I > get emails when something breaks, and you have the obligation to fix > whatever broke, I have no objection. Great. In contrast to Ian's statement, then, I think we *do* have a consensus: remove Java from default languages, but do leave it in autotesters (with consequences as above). Thank you,
On Thu, Nov 18, 2010 at 07:37, Mark Mitchell <mark@codesourcery.com> wrote: > On 11/18/2010 2:00 AM, Andrew Haley wrote: > >> I made it pretty clear that as long as the autotesters build java, and I >> get emails when something breaks, and you have the obligation to fix >> whatever broke, I have no objection. > > Great. In contrast to Ian's statement, then, I think we *do* have a > consensus: remove Java from default languages, but do leave it in > autotesters (with consequences as above). I agree as well. Diego.
Mark Mitchell <mark@codesourcery.com> writes: > On 11/11/2010 3:20 PM, Ian Lance Taylor wrote: >> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor <iant@google.com> wrote: >>> Currently we build the Java frontend and libjava by default. At the GCC >>> Summit we raised the question of whether should turn this off, thus only >>> building it when java is explicitly selected at configure time with >>> --enable-languages. Among the people at the summit, there was general >>> support for this, and nobody was opposed to it. > >> I count 33 messages on the topic and it is clear that there is no >> consensus. I am withdrawing this proposed patch. > > I think that's a mistake. > > The arguments raised, such as the fact that Java tests non-call > exceptions, are just not persuasive to me. If we need tests for a > middle-end feature, we can almost always write them in C or C++. > > The bottom line is that libjava takes a very long time to build and that > the marginal benefit is out of proportion to the cost. Building > zillions of Java class files cannot be the best way to test non-call > exceptions. If we have no tests for non-call exceptions in the C/C++ > testsuite, perhaps you (Ian) could write a few in C++? > > Ian, I was prepared to approve the patch. I certainly won't do that if > you now think it's a bad idea, but if you still think it's a good idea, > I think you should go for it. > > I think that it should still be the case that if you break Java, and one > of the Java testers catches you, you still have an obligation to fix the > problem. All we're changing is whether you build Java by default; > nothing else. I still think it would be a good idea to remove Java from the set of languages which are built by default. What I meant by withdrawing the patch is that I felt that we needed consensus and I don't feel that we have it. I wrote the patch to express what I felt was the sense of the discussion of the summit, so that the idea wasn't simply dropped. Andrew has asked for autotesters for Java; I don't run any autotesters and I don't want to sign up for that. Can somebody volunteer for that? Presumably anybody currently running an autotester could add an explicit --enable-languages option with java. Andrew has also asked to receive e-mail when there is a Java bug. I count 38 existing tests for -fnon-call-exceptions with C/C++ in the testsuite. We could also get more coverage by adding -fnon-call-exceptions to the list of testsuite torture options, though that would of course slow down running the torture testsuite. Any opinions? At this point does anybody strongly object to committing the patch. Ian
On 18/11/2010 17:18, Ian Lance Taylor wrote:
> At this point does anybody strongly object to committing the patch.
Nah, I've been persuaded by the arguments advanced and withdraw my previous
objection.
cheers,
DaveK
On Thu, 2010-11-18 at 09:18 -0800, Ian Lance Taylor wrote: > Andrew has asked for autotesters for Java; I don't run any autotesters > and I don't want to sign up for that. Can somebody volunteer for that? > Presumably anybody currently running an autotester could add an explicit > --enable-languages option with java. Andrew has also asked to receive > e-mail when there is a Java bug. We have a machine doing GCC builds for GNU Classpath. Are there scripts for official autotesters that can automatically detect regressions and send email to the right people? Thanks, Mark
Index: gcc/java/config-lang.in =================================================================== --- gcc/java/config-lang.in (revision 166080) +++ gcc/java/config-lang.in (working copy) @@ -36,5 +36,7 @@ gtfiles="\$(srcdir)/java/java-tree.h \$( target_libs=${libgcj_saved} lang_dirs="fastjar" -#build_by_default=no lang_requires=c++ + +# Do not build java by default. +build_by_default=no Index: gcc/doc/install.texi =================================================================== --- gcc/doc/install.texi (revision 166080) +++ gcc/doc/install.texi (working copy) @@ -1320,7 +1309,7 @@ Currently, you can use any of the follow Building the Ada compiler has special requirements, see below. If you do not pass this flag, or specify the option @code{all}, then all default languages available in the @file{gcc} sub-tree will be configured. -Ada and Objective-C++ are not default languages; the rest are. +Java, Ada and Objective-C++ are not default languages; the rest are. Re-defining @code{LANGUAGES} when calling @samp{make} @strong{does not} work anymore, as those language sub-directories might not have been configured! @@ -1763,7 +1741,9 @@ tools. @subheading Java-Specific Options -The following option applies to the build of the Java front end. +The following option applies to the build of the Java front end. Note +that the Java front end is not built by default; in order to build it, +use the @option{--enable-languages} option described above. @table @code @item --disable-libgcj