5 ms·

HotSpot has four tiers huh? That’s just one snarky example. There are lots of others. I’m sure you could identify them easily, if you are familiar with HotSpot

HotSpot has four tiers huh? That’s just one snarky example. There are lots of others. I’m sure you could identify them easily, if you are familiar with HotSpot and you read the post.

monocasa 6y ago
Last time I checked it had five tiers. Like, really one non snarky example is all I'm looking for. As someone who does know the internals of hotspot fairly well and read the post.
- pizlonator 6y ago
  JSC has four in the sense that hot enough functions go through LLInt, then Baseline, then DFG, and then FTL. They go through three lower optimization levels before the max one. HotSpot has three in the sense that you get interpreter, client, then server. Both VMs have additional execution engines available behind flags. JSC has a different interpreter (CLoop, based on LLInt but different) for some systems, so it’s like a “fifth tier” if you think of “tier” as just an available execution engine. I think of tier as a stage of optimization that you get adaptively, without having to specifically configure for it. I get that HotSpot can alternatively AOT or Graal, but those aren’t tiered with the rest to my knowledge (like there is no interpreter->client->server->graal config but if there was then that would be four tiers).
  - monocasa 6y ago
    HotSpot definitely uses five tiers (including the interpreter, so same as JSC). https://github.com/openjdk/jdk/blob/0aefe6f20ae719c9793c790dbf5993a6edd9a746/src/hotspot/share/compiler/tieredThresholdPolicy.hpp#L37 https://github.com/openjdk/jdk/blob/0aefe6f20ae719c9793c790d... I'll give you that levels 1-3 use the same IR, but that says more about the generality of the C1 IR than JSC being more advanced for using different IRs IMO.
    - chrisseaton 6y ago
      I don't think it's reasonable to describe those as five independent tiers. Two of them just add (slower) code to collect profiling information.
    - pizlonator 6y ago
      According to that, it skips level 1 and goes all the way to 3 in some cases. Again, not the same as what JSC does, and not nearly as aggressive. Most notably, there is no baseline jit. Also, C1 in any config compiles slower than DFG.
      - monocasa 6y ago
        Did you edit out where you had said "JSC > Java" in your initial reply? That really colors the conversation in a different way retroactively that I don't really appreciate. It now looks like I'm berating you out of nowhere, when really you originally made an assertion and I'm just trying to get you to back it up.
        pizlonator 6y ago
        You started by claiming that Azul is more advanced. You got snark. Maybe it’s more advanced at collecting garbage or supporting threads, but it is not comparable in the field of type inference, because Azul’s VM and other JVMs do not do any of the kind of type inference described in this post. And no, invokedynamic is nothing like inline caching for JS - not even close. Most of this post is about what type inference for dynamic languages really looks like when you invest HotSpot-like efforts to that specific problem. Saying that Azul is more advanced at type inference is far off from the truth at a very fundamental level. So I gave you snark. Being snarky is fun sometimes!
        saagarjha 6y ago
        Perhaps, but not for Hacker News: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- titzer 6y ago
  HotSpot does not need to infer object shapes, so it doesn't need inline caches for field accesses. HotSpot doesn't need to infer whether (and where) methods lie in the prototype chain of an object. HotSpot does not need to speculate that arithmetic fits in integer range. HotSpot does not need to speculate that fields are (not) deleted from objects. HotSpot does not need to speculate that a function has a .toString() called on it. HotSpot does not need to speculate that a local variable can be modified by a sloppy direct eval. HotSpot does not need to do scope analysis and closure conversion. HotSpot does not need to speculate that the arguments object does not escape. All of these things are extremely typical for a JS VM to profile and speculate on. I do not work on JSC, but I did work on V8 and it does all of these things.
  - monocasa 6y ago
    > HotSpot does not need to infer object shapes, so it doesn't need inline caches for field accesses. Those are just modeled as invokedynamic getters and setters for dynamically laid out objects. It's handled great. > HotSpot doesn't need to infer whether (and where) methods lie in the prototype chain of an object. How is that different than vtable lookups? > HotSpot does not need to speculate that arithmetic fits in integer range. Here's where they added that to the JVM. https://bugs.openjdk.java.net/browse/JDK-8042946 https://bugs.openjdk.java.net/browse/JDK-8042946 > HotSpot does not need to speculate that fields are (not) deleted from objects. Once again, handled as invokedynamiced getters and setters. > HotSpot does not need to do scope analysis and closure conversion. HotSpot does not need to speculate that the arguments object does not escape. They absolutely do since lambdas have been supported.
    - titzer 6y ago
      >> HotSpot doesn't need to infer whether (and where) methods lie in the prototype chain of an object. > How is that different than vtable lookups? sigh Maybe to you this seems fun, but from where I am sitting, you are starting to get annoying. It is really not necessary for you to try to dominate this whole post with some completely unnecessary over-the-top HotSpot-is-the-best-ever chest thumping. This wasn't an isolated comment, but you are all over the thread and in people's faces. It's odious when you want to make confident claims and yet don't know the difference between vtable lookup and JavaScript prototype access. It's exactly this kind of exchange that we need less of. I wish you would step back and appreciate more of the shared context here to recognize that you don't need to explain (and exaggerate) the inner workings of JVMs to people who have worked on them for quite some years in the past. We'd probably be friends and have fun if you'd drop the HotSpot schtick. I went through that phase too, about 10 years ago. At this point your comments here and elsewhere show a pattern of aggression that just makes people want to disengage, but I am forced to offer you some advice to try to salvage this. It's no fun for anyone to be part of a community with such an adversarial and hostile conversation ongoing. I hope I can resist the urge to be drawn into correcting the rest of your misunderstandings about JavaScript here in a way that doesn't make you feel slighted, because you're not receptive to it anyway and that's an obviously unproductive discussion. But listen, invokedynamic isn't a panacea, it's a nice addition to the JVM to accomplish some dynamism, but it's not mission accomplished by any means. Invokedynamic is a mechanism that requires the existence of dynamic optimization at a higher level, i.e. a higher-level language runtime. Your claims again overstate what it does. You didn't understand what I meant about scope analysis or the arguments object because those don't exist at the JVM level and you must have patterned matched them to something else completely different. And don't even get me started on HotSpot's startup time.

HotSpot has four tiers huh? That’s just one snarky example. There are lots of others. I’m sure you could identify them easily, if you are familiar with HotSpot and you read the post.

monocasa 6y ago

Last time I checked it had five tiers. Like, really one non snarky example is all I'm looking for. As someone who does know the internals of hotspot fairly well and read the post.

pizlonator 6y ago
JSC has four in the sense that hot enough functions go through LLInt, then Baseline, then DFG, and then FTL. They go through three lower optimization levels before the max one. HotSpot has three in the sense that you get interpreter, client, then server. Both VMs have additional execution engines available behind flags. JSC has a different interpreter (CLoop, based on LLInt but different) for some systems, so it’s like a “fifth tier” if you think of “tier” as just an available execution engine. I think of tier as a stage of optimization that you get adaptively, without having to specifically configure for it. I get that HotSpot can alternatively AOT or Graal, but those aren’t tiered with the rest to my knowledge (like there is no interpreter->client->server->graal config but if there was then that would be four tiers).
- monocasa 6y ago
  HotSpot definitely uses five tiers (including the interpreter, so same as JSC). https://github.com/openjdk/jdk/blob/0aefe6f20ae719c9793c790dbf5993a6edd9a746/src/hotspot/share/compiler/tieredThresholdPolicy.hpp#L37 https://github.com/openjdk/jdk/blob/0aefe6f20ae719c9793c790d... I'll give you that levels 1-3 use the same IR, but that says more about the generality of the C1 IR than JSC being more advanced for using different IRs IMO.
  - chrisseaton 6y ago
    I don't think it's reasonable to describe those as five independent tiers. Two of them just add (slower) code to collect profiling information.
  - pizlonator 6y ago
    According to that, it skips level 1 and goes all the way to 3 in some cases. Again, not the same as what JSC does, and not nearly as aggressive. Most notably, there is no baseline jit. Also, C1 in any config compiles slower than DFG.
    - monocasa 6y ago
      Did you edit out where you had said "JSC > Java" in your initial reply? That really colors the conversation in a different way retroactively that I don't really appreciate. It now looks like I'm berating you out of nowhere, when really you originally made an assertion and I'm just trying to get you to back it up.
      - pizlonator 6y ago
        You started by claiming that Azul is more advanced. You got snark. Maybe it’s more advanced at collecting garbage or supporting threads, but it is not comparable in the field of type inference, because Azul’s VM and other JVMs do not do any of the kind of type inference described in this post. And no, invokedynamic is nothing like inline caching for JS - not even close. Most of this post is about what type inference for dynamic languages really looks like when you invest HotSpot-like efforts to that specific problem. Saying that Azul is more advanced at type inference is far off from the truth at a very fundamental level. So I gave you snark. Being snarky is fun sometimes!
        saagarjha 6y ago
        Perhaps, but not for Hacker News: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
titzer 6y ago
HotSpot does not need to infer object shapes, so it doesn't need inline caches for field accesses. HotSpot doesn't need to infer whether (and where) methods lie in the prototype chain of an object. HotSpot does not need to speculate that arithmetic fits in integer range. HotSpot does not need to speculate that fields are (not) deleted from objects. HotSpot does not need to speculate that a function has a .toString() called on it. HotSpot does not need to speculate that a local variable can be modified by a sloppy direct eval. HotSpot does not need to do scope analysis and closure conversion. HotSpot does not need to speculate that the arguments object does not escape. All of these things are extremely typical for a JS VM to profile and speculate on. I do not work on JSC, but I did work on V8 and it does all of these things.
- monocasa 6y ago
  > HotSpot does not need to infer object shapes, so it doesn't need inline caches for field accesses. Those are just modeled as invokedynamic getters and setters for dynamically laid out objects. It's handled great. > HotSpot doesn't need to infer whether (and where) methods lie in the prototype chain of an object. How is that different than vtable lookups? > HotSpot does not need to speculate that arithmetic fits in integer range. Here's where they added that to the JVM. https://bugs.openjdk.java.net/browse/JDK-8042946 https://bugs.openjdk.java.net/browse/JDK-8042946 > HotSpot does not need to speculate that fields are (not) deleted from objects. Once again, handled as invokedynamiced getters and setters. > HotSpot does not need to do scope analysis and closure conversion. HotSpot does not need to speculate that the arguments object does not escape. They absolutely do since lambdas have been supported.
  - titzer 6y ago
    >> HotSpot doesn't need to infer whether (and where) methods lie in the prototype chain of an object. > How is that different than vtable lookups? sigh Maybe to you this seems fun, but from where I am sitting, you are starting to get annoying. It is really not necessary for you to try to dominate this whole post with some completely unnecessary over-the-top HotSpot-is-the-best-ever chest thumping. This wasn't an isolated comment, but you are all over the thread and in people's faces. It's odious when you want to make confident claims and yet don't know the difference between vtable lookup and JavaScript prototype access. It's exactly this kind of exchange that we need less of. I wish you would step back and appreciate more of the shared context here to recognize that you don't need to explain (and exaggerate) the inner workings of JVMs to people who have worked on them for quite some years in the past. We'd probably be friends and have fun if you'd drop the HotSpot schtick. I went through that phase too, about 10 years ago. At this point your comments here and elsewhere show a pattern of aggression that just makes people want to disengage, but I am forced to offer you some advice to try to salvage this. It's no fun for anyone to be part of a community with such an adversarial and hostile conversation ongoing. I hope I can resist the urge to be drawn into correcting the rest of your misunderstandings about JavaScript here in a way that doesn't make you feel slighted, because you're not receptive to it anyway and that's an obviously unproductive discussion. But listen, invokedynamic isn't a panacea, it's a nice addition to the JVM to accomplish some dynamism, but it's not mission accomplished by any means. Invokedynamic is a mechanism that requires the existence of dynamic optimization at a higher level, i.e. a higher-level language runtime. Your claims again overstate what it does. You didn't understand what I meant about scope analysis or the arguments object because those don't exist at the JVM level and you must have patterned matched them to something else completely different. And don't even get me started on HotSpot's startup time.