public inbox for java-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@avtrex.com>
To: "Boehm, Hans" <hans.boehm@hp.com>
Cc: tromey@redhat.com, "Johannes P. Schmidt" <jschmidt@avtrex.com>,
		Java Patch List <java-patches@gcc.gnu.org>
Subject: Re: [Patch] Java: Add heap dump and analyze support.
Date: Tue, 30 Jan 2007 21:57:00 -0000	[thread overview]
Message-ID: <45BFBF37.9090405@avtrex.com> (raw)
In-Reply-To: <BDA38860DCFD334EAEA905E44EE8E7EF6DD409@G3W0067.americas.hpqcorp.net>

Boehm, Hans wrote:
> I think the only partial excuse for the ugly way this is handled in the
> GC is that it tries to avoid stdio, in order to avoid accidentally
> calling malloc.  This probably doesn't matter for gcj, but it's
> important if malloc is actually an alias for GC_malloc, which it
> sometimes is.
> 
> Nonetheless, this should probably be parameterized with respect to file
> descriptors (probably not FILE *) on Posix systems, and the approximate
> equivalent on other systems.
> 
> GC7 handles this slightly better, but not a lot.
> 

I would propose that we commit the patch much as it is.

If the GC could add an entry point to allow the information to be 
printed to an arbitrary FILE* or file descriptor, then we would adjust 
the heap dumper when that is imported into GCC.

Does that sound reasonable?

David Daney

> Hans
> 
>> -----Original Message-----
>> From: java-patches-owner@gcc.gnu.org 
>> [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of David Daney
>> Sent: Monday, January 29, 2007 3:58 PM
>> To: tromey@redhat.com
>> Cc: Java Patch List; gcc-patches@gcc.gnu.org; Johannes P. Schmidt
>> Subject: Re: [Patch] Java: Add heap dump and analyze support.
>>
>> New version of the patch:
>>
>> Tom Tromey wrote:
>>>>>>>> "David" == David Daney <ddaney@avtrex.com> writes:
>>>>>>>>             
>>> Nice.
>>>
>>> I read through this.  I don't see many issues -- a few formatting 
>>> things (on irc you said these are fixed).
>>>
>>> I'm a little concerned about the ad hoc approach to demangling, but 
>>> not enough to want to change it.
>>>
>>> I'm also worried about the GC private bits copied into the native 
>>> code.  My main concern is that if the GC changes, we won't notice.
>>>   
>> As I said before: I look at this quite a bit.  The GC has 
>> code that prints the needed information to stdout.  
>> Unfortunately we need it in a file.  I was thinking about 
>> modifying the GC so that you could supply a file descriptor, 
>> but that code has #ifdefs for every kind of OS known to man, 
>> and I was afraid I would break some obscure untestable configuration.
>>> My final high-level worry is about security.  Right now it 
>> is possible 
>>> for any program to call the code that dumps the memory map. 
>>  I suppose 
>>> we can just sweep this under the blanket we're putting 
>> 'gnu.classpath'
>>> stuff under.
>>>
>>>   
>> Fixed.
>>> I have a few more minor comments.
>>>
>>> David> +@item -p @var{tool-prefix}
>>> David> +Prefix added to the names of the @command{nm} and 
>> @command{readelf} commands.
>>> I'd prefer to compile in the target, but I suppose this tool isn't 
>>> built in non-native builds, so that wouldn't help.  Darn.
>>>
>>> David> +  // search all symbol tables
>>> David> +  // return -1 if none found
>>> David> +  long getAddress(SymbolLookup lookup, String 
>> symbol) throws 
>>> David> + IOException  {
>>> David> +    //    for (Iterator 
>> it=map.entrySet().iterator(); it.hasNext(); )
>>> David> +    //      {
>>>
>>> Why is this commented out?
>>>   
>> Unused code.  It has been removed.
>>> David> +        if (s.charAt(0) == '#')
>>> David> +          continue;
>>> David> +        if (s == null)
>>> David> +          break;
>>>
>>> These tests are in the wrong order.
>>>   
>> Fixed.
>>> David> +  static void usage()
>>> David> +  {
>>>
>>> Someday I suppose we should convert the tools in gcj to use the 
>>> classpath getopt code.
>>>   
>> Done.
>>> David> +              if 
>> (name.compareTo("gnu.gcj.runtime.MethodRef") 
>>> David> + == 0)
>>>
>>> What is this?
>>>   
>> Bogus code left over from 3.4.3 version.  It has been removed.
>>> David> +  public static String KindToName(int kind)
>>>
>>> Non-java name... method names should start with a lower case letter.
>>>   
>> Fixed.
>>> David> +namespace gnu
>>> David> +{
>>> David> +  namespace gcj
>>> David> +  {
>>> David> +    namespace util
>>> David> +    {
>>> David> +      class GC_enumerator
>>>
>>> This appears to be local to a single .cc file.  Do we need 
>> to put it 
>>> into a namespace like this?  I've always thought of these 
>> namespaces 
>>> as reserved for 'extern "Java"' code.
>>>   
>> My misunderstanding of namespaces.  Changed to anonymous 
>> namespace as suggested by Joel Dice and Chris Lattner.
>>
>> Tested on x86_64-pc-linux-gnu (FC6) with no regressions.  
>> Currently testing on i686-pc-linux-gnu.
>>
>> OK to commit if it passes?
>> 2007-01-29  David Daney  <ddaney@avtrex.com>
>> gcc/java:
>>     * Make-lang.in (JAVA_MANFILES): Added doc/gc-analyze.1.
>>     (java.maintainer-clean):Added gc-analyze.1.
>>     (.INTERMEDIATE): Added gc-analyze.pod.
>>     (gc-analyze.pod): New rule.
>>     (java.install-man): Install gc-analyze.1
>>     * gcj.texi: Added new section for the gc-analyze program.
>>
>> libjava:
>> 2007-01-29  Johannes Schmidt  <jschmidt@avtrex.com>
>>     David Daney  <ddaney@avtrex.com>
>>
>>     * configure.ac: Added check for /proc/self/maps.
>>     * Makefile.am (bin_PROGRAMS): Added gc-analyze.
>>     (AM_GCJFLAGS): Set classpath to $(srcdir)/classpath/tools/classes.
>>     (gcjh.stamp): Same.
>>     (gc_analyze_SOURCES): New.
>>     (gc_analyze_LDFLAGS): New.
>>     (gc_analyze_LINK): New.
>>     (gc_analyze_LDADD): New.
>>     (gc_analyze_DEPENDENCIES): New.
>>     (nat_source_files): Added gnu/gcj/util/natGCInfo.cc.
>>     * Makefile.in: Regenerated.
>>     * configure: Regenerated.
>>     * include/config.h.in: Regenerated.
>>     * sources.am: Regenerated.
>>     * scripts/makemake.tcl: Don't include gc-analyze classes 
>> in libgcj.
>>     * gnu/classpath/tools/getopt/Parser.h: New.
>>     * gnu/classpath/tools/getopt/FileArgumentCallback.h: New.
>>     * gnu/classpath/tools/getopt/Parser$1.h: New.
>>     * gnu/classpath/tools/getopt/Parser$2.h: New.
>>     * gnu/classpath/tools/getopt/Parser$3.h: New.
>>     * gnu/classpath/tools/getopt/OptionGroup.h: New.
>>     * gnu/classpath/tools/getopt/OptionException.h: New.
>>     * gnu/classpath/tools/getopt/Messages.h: New.
>>     * gnu/classpath/tools/getopt/Option.h: New.
>>     * 
>> gnu/gcj/tools/gc_analyze/MemoryAnalyze$SubstringComparator.h: New.
>>     * gnu/gcj/tools/gc_analyze/SymbolLookup.java: New.
>>     * gnu/gcj/tools/gc_analyze/BytePtr.h: New.
>>     * gnu/gcj/tools/gc_analyze/ItemList.h: New.
>>     * gnu/gcj/tools/gc_analyze/ToolPrefix.h: New.
>>     * gnu/gcj/tools/gc_analyze/MemoryAnalyze.h: New.
>>     * gnu/gcj/tools/gc_analyze/MemoryAnalyze$1.h: New
>>     * gnu/gcj/tools/gc_analyze/MemoryAnalyze$2.h: New
>>     * gnu/gcj/tools/gc_analyze/MemoryAnalyze$3.h: New
>>     * gnu/gcj/tools/gc_analyze/BlockMap$SizeKind.h: New.
>>     * gnu/gcj/tools/gc_analyze/ObjectMap.java: New.
>>     * gnu/gcj/tools/gc_analyze/SymbolLookup.h: New.
>>     * gnu/gcj/tools/gc_analyze/MemoryMap.java: New.
>>     * gnu/gcj/tools/gc_analyze/MemoryAnalyze$1$Info.h: New.
>>     * gnu/gcj/tools/gc_analyze/ObjectMap.h: New.
>>     * gnu/gcj/tools/gc_analyze/MemoryMap.h: New.
>>     * gnu/gcj/tools/gc_analyze/SymbolTable.java: New.
>>     * gnu/gcj/tools/gc_analyze/SymbolTable.h: New.
>>     * gnu/gcj/tools/gc_analyze/ObjectMap$ObjectItem.h: New.
>>     * gnu/gcj/tools/gc_analyze/MemoryMap$RangeComparator.h: New.
>>     * gnu/gcj/tools/gc_analyze/BlockMap$PtrMarks.h: New.
>>     * gnu/gcj/tools/gc_analyze/BlockMap.java: New.
>>     * gnu/gcj/tools/gc_analyze/BytePtr.java: New.
>>     * gnu/gcj/tools/gc_analyze/ItemList.java: New.
>>     * gnu/gcj/tools/gc_analyze/ToolPrefix.java: New.
>>     * gnu/gcj/tools/gc_analyze/MemoryAnalyze.java: New.
>>     * gnu/gcj/tools/gc_analyze/MemoryMap$Range.h: New.
>>     * gnu/gcj/tools/gc_analyze/BlockMap.h: New.
>>     * gnu/gcj/util/GCInfo.java: New.
>>     * gnu/gcj/util/GCInfo.h: New.
>>     * gnu/gcj/util/natGCInfo.cc: New.
>>     * gnu/gcj/util/UtilPermission.java: New.
>>     * gnu/gcj/util/UtilPermission.h: New.
>>     * classpath/lib/Makefile.am (gcj_tools_classpath): New variable.
>>     (compile_classpath): Add $(gcj_tools_classpath) to classpath.
>>     * classpath/lib/Makefile.in: Regenerated.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/SymbolTable.class: New.
>>     * 
>> classpath/lib/gnu/gcj/tools/gc_analyze/ObjectMap$ObjectItem.class: 
>> New.
>>     *
>> classpath/lib/gnu/gcj/tools/gc_analyze/MemoryMap$RangeComparat
>> or.class: New.
>>     * 
>> classpath/lib/gnu/gcj/tools/gc_analyze/BlockMap$PtrMarks.class: New.
>>     * 
>> classpath/lib/gnu/gcj/tools/gc_analyze/MemoryMap$Range.class: New.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/BlockMap.class: New.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/BytePtr.class: New.
>>     *
>> classpath/lib/gnu/gcj/tools/gc_analyze/MemoryAnalyze$Substring
>> Comparator.class: 
>> New.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/ItemList.class: New.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/ToolPrefix.class: New.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/MemoryAnalyze.class: New.
>>     * 
>> classpath/lib/gnu/gcj/tools/gc_analyze/BlockMap$SizeKind.class: New.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/SymbolLookup.class: New.
>>     * 
>> classpath/lib/gnu/gcj/tools/gc_analyze/MemoryAnalyze$1$Info.class: 
>> New.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/ObjectMap.class: New.
>>     * classpath/lib/gnu/gcj/tools/gc_analyze/MemoryMap.class: New.
>>     * classpath/lib/gnu/gcj/util/GCInfo.class: New.
>>     * classpath/lib/gnu/gcj/util/UtilPermission.class: New.
>>
>> As before machine generated files are omitted from the diff.
>>
>>

  parent reply	other threads:[~2007-01-30 21:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-17 23:47 David Daney
2007-01-23 22:19 ` Tom Tromey
2007-01-23 23:15   ` David Daney
2007-01-24  1:08     ` Joel Dice
2007-01-24  1:52       ` Tom Tromey
2007-01-24  1:58         ` Chris Lattner
2007-01-24  2:32           ` David Daney
2007-01-29 23:58   ` David Daney
     [not found]     ` <BDA38860DCFD334EAEA905E44EE8E7EF6DD409@G3W0067.americas.hpqcorp.net>
2007-01-30 21:57       ` David Daney [this message]
2007-01-30 22:21         ` Boehm, Hans
2007-02-07 22:37     ` Tom Tromey
2007-02-13  5:36       ` David Daney
2007-02-13 18:28         ` Tom Tromey
2007-02-13 19:38           ` David Daney
2007-02-13 20:27             ` Tom Tromey
2007-02-14 23:22           ` David Daney
2007-02-15  0:12             ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45BFBF37.9090405@avtrex.com \
    --to=ddaney@avtrex.com \
    --cc=hans.boehm@hp.com \
    --cc=java-patches@gcc.gnu.org \
    --cc=jschmidt@avtrex.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).