Announcement

Collapse
No announcement yet.

JIT Compiler Support Might Be Added To GCC 4.9

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by liam View Post
    Thanks for the great explanation.
    That sounds like a huge win for packagers.
    At a minimum they'd be able to get rid of the x32/x64 split and halve their repo size. Of course they'd still have to carry enough binaries to boot-strap the machine.
    Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.
    Last edited by JS987; 10-15-2013, 05:59 AM.

    Comment


    • #12
      Originally posted by JS987 View Post
      Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.
      Presumably they would only need to be jitted once then stored as binaries.

      Comment


      • #13
        Originally posted by liam View Post
        Presumably they would only need to be jitted once then stored as binaries.
        It should be possible to compile bytecode to native executable or library during installation of application or library, but that library doesn't seem to target such case.

        Comment


        • #14
          Originally posted by JS987 View Post
          It should be possible to compile bytecode to native executable or library during installation of application or library, but that library doesn't seem to target such case.
          I'm sure I'm missing something but that seems trivial. Perhaps it's something they intend to add shortly?

          Comment


          • #15
            Originally posted by JS987 View Post
            Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.
            Slower to start up the first time sure (assuming they're caching the binary), but High Memory consumption isn't going to happen. Excessive memory consumption is a language design issue related to things like how much metadata you're carrying around, whether the code is garbage collected or not, otherwise it's just pointer sizes and how much stuff is being optimized out... So no the memory consumption should be about the same as it is now not higher.

            Comment


            • #16
              Originally posted by Luke_Wolf View Post
              Slower to start up the first time sure (assuming they're caching the binary), but High Memory consumption isn't going to happen. Excessive memory consumption is a language design issue related to things like how much metadata you're carrying around, whether the code is garbage collected or not, otherwise it's just pointer sizes and how much stuff is being optimized out... So no the memory consumption should be about the same as it is now not higher.
              Caching isn't possible because all native code (libraries, executables) have to be stored in files (example: files in /usr/bin, /usr/lib) which are:
              - owned by root - read-only for user in order system would be secure - native code can't be easily modified
              - world readable, which enables memory sharing with mmap by every process of every user which is necessary to minimize size of private memory of every process

              Comment


              • #17
                Originally posted by JS987 View Post
                Caching isn't possible because all native code (libraries, executables) have to be stored in files (example: files in /usr/bin, /usr/lib) which are:
                - owned by root - read-only for user in order system would be secure - native code can't be easily modified
                - world readable, which enables memory sharing with mmap by every process of every user which is necessary to minimize size of private memory of every process
                The caching(compilation) could happen during installation. So you would have something like gentoo, but with bytecode (with bytecode I mean the IR). I am not sure whether one would save that much compared to direct source code distribution though. It is just the parsing step that would fall away.

                It would allow to mix bytecode independent of the source language(assuming the language is supported by gcc) I assume, which might be interesting.

                Comment


                • #18
                  Originally posted by liam View Post
                  Presumably they would only need to be jitted once then stored as binaries.
                  Wouldn't that undermine one of the advantages of JIT compilation? I always thought that the great thing about JIT compilers was that they can make optimizations that static compilers can't because they (JIT) have more information come runtime. But since the extra information is variable, a once-only compilation would have to skip such optimizations.
                  Last edited by nbtrap; 10-18-2013, 08:32 AM.

                  Comment

                  Working...
                  X