Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HipHop Virtual Machine

research.facebook.com

Post reply on HN
Print view View original

1–10 of 31 posts

Re: The HipHop Virtual Machine

#4

Post by __Joker »

I assume latent type means simply the implicit typing. i.e. you declare a variable with the value, and the type is inferred through the value of the variable rather than the explicit type declared.

Re: The HipHop Virtual Machine

#5

Post by kmavm »

__Joker wrote: post #4

I assume latent type means simply the implicit typing. i.e. you declare a variable with the value, and the type is inferred through the value of the variable rather than the explicit type declared.

Hi, I'm one of the paper's co-authors.

As usual, the abstract really isn't enough to draw big conclusions from. The concept of a latent type applies to arbitrary expressions, not just variables. All the values flowing through a PHP program implicitly share the same union type; they can be floats, strings, arrays, etc. The latent types are the narrower types that can actually flow through the program in practice.

To be clear, it is more general than just things like:

  $a = 0; // $a is an int!
It includes learning that:

  g(foo() . bar());
foo() and bar() return strings. Since none of this information is marked syntactically in PHP, and since it might actually be undecidable because of dynamic control flow in the callees, dynamic binding, etc., you really need to see the program run to do this stuff.

Re: The HipHop Virtual Machine

#6

Post by zaptheimpaler »

This is awesome! I am not familiar with how compilers/VMs are generally implemented, but the tracelets and guards idea strikes me as very general - in particular, it looks like this approach could be applied to provide type inference to any dynamically typed language. Has this kind of thing been tried before?

In terms of optimization, is it possible to create tracelets that are not continuous regions in code? Roughly, if you identify two non contiguous tracelets, having the same inputs, and can guarantee the inputs havent changed in between, then you could merge them together. Because bigger tracelets would mean less guards and better performance.

Re: The HipHop Virtual Machine

#9

Post by kmavm »

zaptheimpaler wrote: post #6

This is awesome! I am not familiar with how compilers/VMs are generally implemented, but the tracelets and guards idea strikes me as very general - in particular, it looks like this approach could be applied to provide type inference to any dynamically typed language. Has this kind of thing been tried before? In terms of optimization, is it possible to create tracelets that are not continuous regions in code? Roughly…

As far as I know, you could try tracelets with any dynamic language.

And yes, you could try to share tracelets whose bodies are identical, but, unless their successor tracelets are also identical, you'd need to "dynamicise" the dispatch so you go down Path 1 when you're really tracelet 1 and Path 2 when you're really tracelet 2. We normally chain tracelets together by either falling through (if it's unconditional and the successor tracelet could be placed right next to it) or with jmp or branch instructions.

Re: The HipHop Virtual Machine

#10

Post by beagle3 »

So, a couple of questions:

a. Does the HHVM JIT do anything that LuaJIT doesn't? I assume you are familiar with LuaJIT, as it is mentioned in the paper - and from a quick scan, the only two things I didn't recognize from LuaJIT were the refcount optimizations (not required by Lua GC) and guard relaxation.

b. Is HHIR tied to Php, or is it usable as a general purpose JIT backend? LuaJIT's IR is, (unfortunately for other languages) tied very strongly to Lua semantics.

Thanks for an interesting read!

Post reply on HN