Tom Tromey - Re: [Patch] Java: Add heap dump and analyze support. (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

• From: Tom Tromey
• To: David Daney
• Cc: Java Patch List , gcc-patches at gcc dot gnu dot org, "Johannes P. Schmidt"
• Date: 07 Feb 2007 13:25:25 -0700
• Subject: Re: [Patch] Java: Add heap dump and analyze support.
• References: 45AEB57B.5090807@avtrex.com m3y7ntld3x.fsf@localhost.localdomain 45BE8A03.6040101@avtrex.com
• Reply-to: tromey at redhat dot com

"David" == David Daney ddaney@avtrex.com writes:

David> New version of the patch:

Thanks. I'm afraid I have one blocking concern.

David> Index: libjava/classpath/lib/Makefile.am [...] David> +gcj_tools_classpath = $(top_srcdir)/tools/classes David> +compile_classpath = (vmclasses):(vm_classes):(vmc​lasses):(top_srcdir):$(top_srcdir)/external/w3c_dom:$(top_srcdir)/external/sax:$(top_srcdir)/external/relaxngDatatype:$(top_srcdir)/external/jsr166:.:$(USER_CLASSLIB):$(PATH_TO_ESCHER):$(gcj_tools_classpath)

We purposely avoid putting the tools classes into the core class path. This avoids any chance of a dependency on tools stuff by the core; this would be bad due to the use of ASM in the tools.

I wonder if we could fix this by putting the new tool code into standard.omit, and then compile it separately using a special rule of some kind, with a classpath pointing to the tools zip.

David> + if (rest.length != 1) David> + { David> + optionParser.printHelp(); David> + System.exit(1); David> + }

It is somewhat better to put checking code like this into a validate() method which throws OptionException. This yields more "GNU like" output.

Tom

• Follow-Ups:
  • Re: [Patch] Java: Add heap dump and analyze support.
    * From: David Daney