User: Password:
|
|
Subscribe / Log in / New account

GNU Java compiler

GNU Java compiler

Posted Aug 27, 2010 16:51 UTC (Fri) by Blaisorblade (guest, #25465)
In reply to: GNU Java compiler by linuxrocks123
Parent article: A very grumpy editor's thoughts on Oracle

That's not partial evaluation - my explanation was confusing. And partial evaluation (p.e.) is still unusable in practice in most cases (PyPy is the only known real-world exception I believe, and it's not really p.e.).

Sorry, I was very unclear - when I wrote "checking the exact class of the target object with a guard", I meant that the inlined code is executed only after checking, at runtime, the class of the receiver. So

  a.method(args);
becomes
  if (a.getClass() == expectedClass)
    call expectedClass_method(a, args);
  else
    //normal call dispatch
and you need profiling data to choose expectedClass. There are few cases in which they are not needed, mostly on final methods or on classes which currently have no subclasses (loading new classes might invalidate this assumption and cause the generated code to be thrown away).

This is a case of run-time algorithm specialisation, and IMHO it's related but different from p.e.

I was a bit sloppy, but the "impossibility" of C++ is actually more an effect of the lack of a virtual machine during C++ execution, in most cases (yes, I know Managed C++, that's the exception).

Profile-guided optimization could be applied to programs in non-VM-based languages - but I don't know of, say, mainstream Linux distributions doing this, even on specific cases.
This is not only due to convenience issues: a good reason is that the profile can be workload-dependent, and you don't necessarily have a gain when you use the wrong profile - I've read examples of this in some paper that I don't remember, but I hope the plausibility is clear enough.
Indeed, in VMs it's interesting the ability to adapt to changes in program behavior.

From my knowledge about p.e., derived from discussions with fellow PhD students and accounts on Wikipedia and PyPy docs (they used p.e., and stopped doing it), general p.e. techniques are well known as being difficult to use, because performance of programs using them is difficult to predict; that's cited as a reason for the invention of MetaML, an environment for staged compilation, where p.e. is explicitly controlled, and for the abandonment of the previous PyPy's JIT compiler [1]. Currently they have reimplemented a form of runtime specialization through tracing JIT compilation, which seems rather different from traditional techniques - in particular, it can't optimize an unmodified RPython program.
See here for a discussion about unpredictable optimizations in general.

The optimization I describe is well-known, except by, say, CPython implementors (and by Ruby implementors up to Ruby 1.8), together with a set of well-known results from the past 30 years (like "don't use reference counting" and other stuff - see these papers).

[1] "performance instability: change a seemingly unrelated bit in your source program, and the performance changes in unexpected ways, which is clearly not desirable". It's not clear whether it's related to p.e., until after reading the paper about MetaML.


(Log in to post comments)

GNU Java compiler

Posted Sep 21, 2010 0:02 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link]

I was using partial evaluation a little more broadly than you, and I understood you the first time :)

You're right that profiling isn't widely used on Linux yet, mostly, I believe, due to inertia. However, the Firefox build for Windows is compiled with the benefit of profiling data. It's not compiled with profiling on Linux only because Mozilla doesn't think it's worth the engineering effort to make it work with GCC. If you had profiling data, you could do algorithm specialization (which is really just a special case of partial evaluation IMHO) very easily.

Also, bear in mind that this is just one, small performance optimization. C++ beats Java with respect to many others.

---linuxrocks123


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds