PIC is a way to speed up method dispatch. Normally, if you call a method foo in your program, but you don't know the class of the object you're calling foo on, you need to go look up the appropriate code to run in a virtual table or similar data structure. This is slow, because you might do this lookup very often. PIC means caching this lookup in the code that calls foo—basically adding an instruction like
if (obj.class == CACHED_CLASS) CACHED_CODE()
Now on to meta-programming. Suppose instead of calling a method on an object we are instead instantiating a class object which is dynamically determined. PIC isn't exactly applicable, because it's not like the type of the class object is in question (the class object's class is probably Class or something). Instead, this paper proposes caching the identity of the class object, and the caching the initialization code and optimizing around it. You could do the same for things that override method_missing and similar, to cache all the decisions those overrides are making and then allowing the JIT to inline the code.
Their evaluation suggests that this method works really well, almost eliminating all of the overhead from meta-programming. This isn't too surprising: we know that even dynamic features are usually used in very "static" ways, that JITs are really good at finding these ways, and that after warming up JITs can usually optimize away all that dynamism to get very fast code.
I am kicking myself for never having thought of this, despite having read several of the PIC papers. I am not a big believer in meta-programming, but this work is simple, extremely useful in practice, and also deepens our understanding of a technique both theoretically and practically.
In the case of this specific document, there’s all kinds of nasty gappy whitespace in the webpage version.
It’s made worse by the spaces in “et al. 19XX” getting turned into non-breaking spaces. You really want to fix that if you can. For example, look at the 3rd and 9th line in this screenshot.
But even disregarding that problem, many lines end up looking pretty bad.
[Note: don’t read this as personal criticism. The fault lies about 90% with the browser vendors who care more about saving a few microseconds of compute time than making legible documents.]
>and if so how
How is easy, they are many different programs, here are a few: https://enc.com.au/docs/latexhtml/. Which in particular is a bit harder, there is no
<meta name="generator" content="...
that some Latex->HTML converter leaves in, but I suspect you could turn that feature off. I think this page uses custom CSS too, as its using Google Fonts.
That's not the 'partial evaluation' per se. Instead, it is the difference between RPython and HotSpot that surfaces here. RPython does currently generated singled threaded VMs, and neither the GC nor the compilation are done in separate threads. The HotSpot JVM however can do those things in parallel and additionally has other infrastructure threads running. In the end, this increases the likelihood that the OS reschedules the application thread, which becomes visible as jitter.
BTW, would Graal really become available as a stock-HotSpot plugin in Java 9 thanks to JEP 243? I see things are ready on Graal's end, but are they on HotSpot's?