Loading ...
Sorry, an error occurred while loading the content.

Re: [javax_compiler] Re: sun.tools.javac.Main will be removed from JDK1.4

Expand Messages
  • Neal M Gafter
    ... I was part of the source for this rumor, but I d like to comment. There was a bug in the internal version of javac for the past month or two in which the
    Message 1 of 2 , Jul 20, 2001
    • 0 Attachment
      > > Craig R. McClanahan wrote:
      > > > An additional note of interest to Ant developers - there is evidence that
      > > > running the compiler (either old or new) leaves a fair amount of cruft
      > > > lying around in static variables, after the compile has completed. The
      > > > recommended solution is to load the compiler itself in its own class
      > > > loader, so that you can throw it all away afterwards. That's the approach
      > > > we'll take when modifying Jasper.

      I was part of the source for this rumor, but I'd like to comment.

      There was a bug in the internal version of javac for the past month or two
      in which the compiler failed to clean up after itself. I fixed that today.
      The symbol tables, trees, etc are definitely cleaned up now. If you're a
      source licensee getting weekly releases of Merlin (1.4) your most recent
      versions will definitely have this bug. It may be a couple of weeks before
      this fix gets back to you.

      There are two categories of things that are NOT cleaned up between compiles:

      (1) Objects that are essentially constants, like symbol table entries for
      the root package, built-in types, etc. While its true that these stick
      around, its better that they do because javac runs faster the second time.
      These are fixed size.

      (2) Names in the name table. javac maintains its own version of an interned
      string table, and all the names that it sees are entered into it and remain
      in it forever. The representation was custom designed for the compiler and
      it's much more compact than strings. This table does appear to approach an
      asymptotic limit when you use the compiler repeatedly; when all of JDK (1.2)
      was compiled using javac this table reaches a maximum of about 500K.

      I have to admit a likely third category - bugs in the compiler. But if you
      find any, tell me and I'll fix it.

      In short, I don't think it's necessary to load the compiler into its own
      class loader in most circumstances, but you're welcome to try it either
      way you please. If you try it both ways and can share some data on the
      relative performance (space and time) I'd love to hear from you.

      I plan to try an experiment replacing the name table with actual interned
      String objects. That will probably slow things down a bit and use more space,
      but it has the advantage that otherwise unreachable interned strings are
      reclaimed, so this would remove a "leak" from the compiler.
    • Conor MacNeill
      Neal, ... I am considering what will be involved in loading javac into its own classloader. For this to be effective, I believe tools.jar cannot be on the
      Message 2 of 2 , Jul 24, 2001
      • 0 Attachment
        Neal,

        > -----Original Message-----
        > From: neal@... [mailto:neal@...]On Behalf Of Neal M Gafter
        >
        > In short, I don't think it's necessary to load the compiler into its own
        > class loader in most circumstances, but you're welcome to try it either
        > way you please. If you try it both ways and can share some data on the
        > relative performance (space and time) I'd love to hear from you.

        I am considering what will be involved in loading javac into its own
        classloader. For this to be effective, I believe tools.jar cannot be on the
        system classpath as the classloader will just delegate to the system loader.
        We can play some tricks around that, I guess, but they are a little risky.

        What I would like to know is whether there is any standard for where the
        compiler classes are located. Are they always in tools.jar. Also is there
        some standard for where to find tools.jar. I had the impression that on some
        OSs (Mac OSX?), the compiler classes are in the boot classpath. Not sure
        exactly.

        Thanks
        Conor
      Your message has been successfully submitted and would be delivered to recipients shortly.