Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: JIT Compiler Support Might Be Added To GCC 4.9

  1. #11
    Join Date
    Sep 2012
    Posts
    343

    Default

    Quote 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 at 05:59 AM.

  2. #12
    Join Date
    Jan 2009
    Posts
    1,402

    Default

    Quote 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.

  3. #13
    Join Date
    Sep 2012
    Posts
    343

    Default

    Quote 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.

  4. #14
    Join Date
    Jan 2009
    Posts
    1,402

    Default

    Quote 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?

  5. #15
    Join Date
    Jun 2011
    Posts
    922

    Default

    Quote 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.

  6. #16
    Join Date
    Sep 2012
    Posts
    343

    Default

    Quote 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

  7. #17
    Join Date
    Jul 2010
    Posts
    490

    Default

    Quote 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.

  8. #18
    Join Date
    Oct 2013
    Posts
    3

    Default

    Quote 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 at 08:32 AM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •