3 ms·

Sumatra is dead, AFAIK. But why would graal depend on sumatra for integration? Bigger challenge is how to bootstrap graal itself such that compilation time and

by vitalyd 11y ago

Sumatra is dead, AFAIK. But why would graal depend on sumatra for integration? Bigger challenge is how to bootstrap graal itself such that compilation time and thus time to peak perf isn't degraded substantially.

pjmlp 11y ago
Really?! > But why would graal depend on sumatra for integration? The other way around. Since Sumatra depends on Graal, it being integrated, means Graal also has to be. Pity, since I learned about Maxime and JikesRVM back in the day, I have looked forward to the day the reference JVM would be meta-circular.
- pron 11y ago
  But why do you think Graal wouldn't be integrated? They've already started the process with Sumatra or without.
  - pjmlp 11y ago
    Maybe with Sumatra the integration would be deeper than just an API, e.g. replacing HotSpot completely and also add SubtrateVM into it. I don't know, lets see how it turns out.
    - vitalyd 11y ago
      I don't think you want a production/industrial JVM written in java :).
      - pron 11y ago
        It's not the whole JVM -- just the JIT. What difference does it make what language the JIT is written in? It is my understanding that if Graal proves itself, it will replace C2 (if not C1 as well).
        vitalyd 11y ago
        I was replying to pjmlp's comment: >Maybe with Sumatra the integration would be deeper than just an API, e.g. replacing HotSpot completely and also add SubtrateVM into it.
      - pjmlp 11y ago
        There are a few commercial ones. :)
        vitalyd 11y ago
        Which ones?
    - pron 11y ago
      Graal is not a HotSpot replacement. It's a JIT for HotSpot or an AOT compiler for SubstrateVM which is a separate JVM altogether. If Graal matures and proves itself, it will become HotSpot's JIT. And Substrate may or may not become a product regardless. And project Sumatra -- while cool -- was never a big influence over OpenJDK's plans. Being able to run streams on GPUs is absolutely awesome, but not the number one priority for the majority of Java users. My point is that Sumatra wouldn't have played a significant role in the decision of when to make Graal HotSpot's default JIT. BTW, you don't even need Graal to be the default JIT in order to support Sumatra, anyway. Graal as a plugin (JEP 243) is good enough for that.
- vitalyd 11y ago
  Sumatra was about GPU offload, not so much metacircular JVM. If you look at sumatra dev mailing list archive, you'll see the last email there states it's not in active development. The project appeared to have been driven by AMD, but they may have re-prioritized things. I also don't think it's currently possible to write the bulk of the JVM in java, if you want comparable performance and memory footprint to Hotspot.
  - pjmlp 11y ago
    Sumatra was using Graal. > I also don't think it's currently possible to write the bulk of the JVM in java, if you want comparable performance and memory footprint to Hotspot. Better check Graal and JikesRVM research papers then. One reason why reference JDK JIT doesn't get rewritten is the ROI. Just check how long has taken to rewrite C# and VB.NET compilers while keeping the new compilers 1:1 compatible or the new RyuJIT and the multiple AOT compiler iterations in .NET land.
    - vitalyd 11y ago
      As already mentioned, Graal is just the JIT compiler, it's not the entire VM. JikesRVM is a research VM, which has different needs/characteristics from production JVMs.
pron 11y ago
I think Java 9 paves the way to (or actually includes) JIT caching.
- vitalyd 11y ago
  Don't think there's anything in 9 for JIT caching unless I missed it - do you have a reference? JIT caching is non trivial problem for Hotspot due to the nature of speculative optimization, so it may take quite some time for that to appear. Having said that, Azul has some form of it in its ReadyNow feature, but I don't know the details. I think likely some form of AOT will be needed.
  - pjmlp 11y ago
    Yes there is, the JEP 197 - Segmented Code Cache. http://openjdk.java.net/jeps/197 http://openjdk.java.net/jeps/197 This is just the early work to be improved in later versions. However there are commercial JVMs, like J9 that already do JIT caching.
    - vitalyd 11y ago
      Segmented Code Cache has nothing to do with JIT caching. Or rather, it has as much to do with it as the existing homogenous code cache.
  - pron 11y ago
    It's related to Project Jigsaw, but I don't know if it's actually scheduled for Java 9. I assumed the idea is to cache C1 output, not C2. I think I saw it in one of Paul Sandoz's videos. I'll look for it, and if I can't find it, I'll ask Paul.

by vitalyd 11y ago

pjmlp 11y ago

Really?! > But why would graal depend on sumatra for integration? The other way around. Since Sumatra depends on Graal, it being integrated, means Graal also has to be. Pity, since I learned about Maxime and JikesRVM back in the day, I have looked forward to the day the reference JVM would be meta-circular.

pron 11y ago
But why do you think Graal wouldn't be integrated? They've already started the process with Sumatra or without.
- pjmlp 11y ago
  Maybe with Sumatra the integration would be deeper than just an API, e.g. replacing HotSpot completely and also add SubtrateVM into it. I don't know, lets see how it turns out.
  - vitalyd 11y ago
    I don't think you want a production/industrial JVM written in java :).
    - pron 11y ago
      It's not the whole JVM -- just the JIT. What difference does it make what language the JIT is written in? It is my understanding that if Graal proves itself, it will replace C2 (if not C1 as well).
      - vitalyd 11y ago
        I was replying to pjmlp's comment: >Maybe with Sumatra the integration would be deeper than just an API, e.g. replacing HotSpot completely and also add SubtrateVM into it.
    - pjmlp 11y ago
      There are a few commercial ones. :)
      - vitalyd 11y ago
        Which ones?
  - pron 11y ago
    Graal is not a HotSpot replacement. It's a JIT for HotSpot or an AOT compiler for SubstrateVM which is a separate JVM altogether. If Graal matures and proves itself, it will become HotSpot's JIT. And Substrate may or may not become a product regardless. And project Sumatra -- while cool -- was never a big influence over OpenJDK's plans. Being able to run streams on GPUs is absolutely awesome, but not the number one priority for the majority of Java users. My point is that Sumatra wouldn't have played a significant role in the decision of when to make Graal HotSpot's default JIT. BTW, you don't even need Graal to be the default JIT in order to support Sumatra, anyway. Graal as a plugin (JEP 243) is good enough for that.
vitalyd 11y ago
Sumatra was about GPU offload, not so much metacircular JVM. If you look at sumatra dev mailing list archive, you'll see the last email there states it's not in active development. The project appeared to have been driven by AMD, but they may have re-prioritized things. I also don't think it's currently possible to write the bulk of the JVM in java, if you want comparable performance and memory footprint to Hotspot.
- pjmlp 11y ago
  Sumatra was using Graal. > I also don't think it's currently possible to write the bulk of the JVM in java, if you want comparable performance and memory footprint to Hotspot. Better check Graal and JikesRVM research papers then. One reason why reference JDK JIT doesn't get rewritten is the ROI. Just check how long has taken to rewrite C# and VB.NET compilers while keeping the new compilers 1:1 compatible or the new RyuJIT and the multiple AOT compiler iterations in .NET land.
  - vitalyd 11y ago
    As already mentioned, Graal is just the JIT compiler, it's not the entire VM. JikesRVM is a research VM, which has different needs/characteristics from production JVMs.

pron 11y ago

I think Java 9 paves the way to (or actually includes) JIT caching.

vitalyd 11y ago
Don't think there's anything in 9 for JIT caching unless I missed it - do you have a reference? JIT caching is non trivial problem for Hotspot due to the nature of speculative optimization, so it may take quite some time for that to appear. Having said that, Azul has some form of it in its ReadyNow feature, but I don't know the details. I think likely some form of AOT will be needed.
- pjmlp 11y ago
  Yes there is, the JEP 197 - Segmented Code Cache. http://openjdk.java.net/jeps/197 http://openjdk.java.net/jeps/197 This is just the early work to be improved in later versions. However there are commercial JVMs, like J9 that already do JIT caching.
  - vitalyd 11y ago
    Segmented Code Cache has nothing to do with JIT caching. Or rather, it has as much to do with it as the existing homogenous code cache.
- pron 11y ago
  It's related to Project Jigsaw, but I don't know if it's actually scheduled for Java 9. I assumed the idea is to cache C1 output, not C2. I think I saw it in one of Paul Sandoz's videos. I'll look for it, and if I can't find it, I'll ask Paul.