Bug 33622 - javac runs out of heap space when compiling @classes
Summary: javac runs out of heap space when compiling @classes
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: 0.96
: P3 normal
Target Milestone: 0.97
Assignee: Andrew John Hughes
Depends on:
Reported: 2007-10-02 09:28 UTC by Klaus Kusche
Modified: 2008-02-20 21:08 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2008-01-02 03:34:29

Patch committed to Classpath (365 bytes, patch)
2007-10-12 14:20 UTC, Andrew John Hughes
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Kusche 2007-10-02 09:28:57 UTC
Building Classpath:

When making in subdirectory lib, Sun's original javac (version 1.6.0_02)
runs out of java heap memory when compiling "@classes".

Passing the option "-J-Xmx256m" (increasing the heap limit to 256 MB) 
solves the problem.

The makefile should automatically pass this option to javac.
Comment 1 Andrew Pinski 2007-10-02 09:31:07 UTC
Actually this sounds like a bug in Sun's javac rather than classpath.
Comment 2 Andrew John Hughes 2007-10-08 00:24:33 UTC
I thought we had come across and solved this problem already?
Comment 3 Andrew John Hughes 2007-10-08 01:51:40 UTC
The build will support passing options to javac:

2007-06-25  Dalibor Topic  <robilad@kaffe.org>

        * m4/acinclude.m4 (CLASSPATH_CHECK_JAVAC): If the user passes an
        explicit argument to configure, just use it, and don't attempt to
        run AC_CHECK_PROG. This makes --with-javac="javac -J-Xmx512M" work.
Comment 4 Klaus Kusche 2007-10-08 06:18:51 UTC
Most likely more users will come across this problem, and nobody will search the Changelog for the solution.

Could this be documented in a prominent place (like INSTALL)?
Comment 5 Dalibor Topic 2007-10-08 11:46:27 UTC
I think we should pass that option to javac, rather than frustrate users.
Comment 6 Dalibor Topic 2007-10-08 12:05:00 UTC
I think passing 512M would mean we'd be on the safe side of x86_64 heap explosion as well.
Comment 7 Andrew John Hughes 2007-10-12 12:31:38 UTC
Agreed.  I actually thought that's what your original patch had done until I saw this bug.  I ran into the same problem with ecj when we first ran it on the generics branch, but because people write scripts for this anyway or use the native version, we don't see this problem.
Comment 8 Andrew John Hughes 2007-10-12 14:20:52 UTC
Created attachment 14348 [details]
Patch committed to Classpath
Comment 9 Andrew John Hughes 2007-10-12 14:33:49 UTC
Can you confirm this now builds for you?
Comment 10 cvs-commit@developer.classpath.org 2007-10-12 21:38:14 UTC
Subject: Bug 33622

CVSROOT:	/cvsroot/classpath
Module name:	classpath
Changes by:	Andrew John Hughes <gnu_andrew>	07/10/12 21:37:44

Modified files:
	.              : ChangeLog 
	lib            : Makefile.am 
	m4             : acinclude.m4 

Log message:
	2007-10-12  Andrew John Hughes  <gnu_andrew@member.fsf.org>
		PR classpath/33622:
		* lib/Makefile.am: Use JAVAC_ARGS variable.
		* m4/acinclude.m4: Check javac is 1.5 compliant
		and whether it supports -J.


Comment 11 Klaus Kusche 2007-10-15 08:16:09 UTC
Works for me with classpath-latest dated 20071015:

javac is called with the correct option.

However, I noticed that JAVAC_OPTS is only used in lib/Makefile,
not in examples/Makefile and tools/Makefile.
Should javac be called with JAVAC_OPTS in all places?
Comment 12 Andrew John Hughes 2008-01-02 03:34:29 UTC
I didn't add it there because the larger heap isn't needed, but it doesn't do any harm (it's a maximum not an allocation request) so I'll add it there for consistency.  It also means tools and examples will be in line with lib should JAVAC_OPTS be used for something else.
Comment 13 Andrew John Hughes 2008-02-20 21:08:30 UTC
We've rejigged things again recently, and so there is now the option of setting the environment variable JAVACFLAGS to add further options in addition to the memory option which is still only present in lib.  I think this is the best solution for the time being, so closing this bug.