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

GNU Java compiler

GNU Java compiler

Posted Aug 17, 2010 18:45 UTC (Tue) by southey (subscriber, #9466)
In reply to: A very grumpy editor's thoughts on Oracle by pj
Parent article: A very grumpy editor's thoughts on Oracle

It is also has implications for the GNU Java compiler because the suit also appears to be also control of the Java language. Especially about writing an interpreter for the actual language and how create an executable program. It will make it hard to do that if Oracle America wins.


(Log in to post comments)

GNU Java compiler

Posted Aug 17, 2010 23:47 UTC (Tue) by ncm (subscriber, #165) [Link]

Amusingly, Oracle's patents don't cover a non-JIT compiler. Google could step around most of their troubles by including a Dalvik byte-code to machine-code compiler (based, perhaps, on Gcj) that runs when the bytecode objects are installed, rather then when they are executed. Android phones might need some more memory, then, but memory is still getting cheaper fast. It would be the more amusing if this resulted in better performance all around.

If Google were to abandon the JVM/Dalvik model and switch to a more optimizable intermediate representation, such as LLVM's, performance would be better still. That would, in turn, open up Android development to a much wider range of languages, and could make porting iPhone programs to Android much easier.

Dalvik and JIT

Posted Aug 18, 2010 9:34 UTC (Wed) by smurf (subscriber, #17840) [Link]

That's interesting, because last time I looked (see the presentation slides), Dalvik didn't have a JIT compiler.

Dalvik and JIT

Posted Aug 18, 2010 11:07 UTC (Wed) by dgm (subscriber, #49227) [Link]

Acording to Wikipedia, as of Android 2.2 it does.

Dalvik and JIT

Posted Aug 18, 2010 14:28 UTC (Wed) by smurf (subscriber, #17840) [Link]

Ah. Thanks. That's one patent which might be somewhat relevant, then, though I suspect there's a lot of prior art there. Forth systems, for instance, do something like this since the 1970s.

GNU Java compiler

Posted Aug 25, 2010 14:53 UTC (Wed) by Blaisorblade (guest, #25465) [Link]

> [About non-JIT performance] It would be the more amusing if this resulted in better performance all around.
Don't take it as an offense, but that's nonsense, and let a student of Virtual Machine implementation explain why.

The reason to use JIT compilation is that Java programs can't run fast without profile-guided optimizations - a JIT can inline virtual function calls easily (after checking the exact class of the target object with a guard, but that's a perfectly predictable branch). That's something C++ can't do.

Also, last time I tried Eclipse compiled with GCJ, it was IIRC 5 times slower in startup than the standard guy - enough to make me uninstall it. That doesn't mean anything per se, but I still wanted to point that out.

About LLVM, it has a great potential. But LLVM's JIT compiler was not _that_ good when Google's engineers working on Unladen Swallow tried using it.
So, yeah, in the long run basing a JVM on LLVM might be just the right move, for the sake of reuse, but you need to merge all HotSpot optimizations in LLVM, and then you would enjoy also a big-iron parallel GC even using Unladen Swallow, if those people ever manage removing the Global Interpreter Lock, their version of the Big Kernel Lock.

GNU Java compiler

Posted Aug 26, 2010 7:28 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]

There is no fundamental reason C++ could not do this. The optimization you are describing is partial evaluation and is well-known. Profiling data would be helpful to know when to perform the partial evaluation transformation, but static compilers can use profiling data generated from an instrumented executable.

---linuxrocks123

GNU Java compiler

Posted Aug 27, 2010 16:51 UTC (Fri) by Blaisorblade (guest, #25465) [Link]

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.

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

GNU Java compiler

Posted Aug 18, 2010 1:53 UTC (Wed) by coriordan (guest, #7544) [Link]

That's kinda mitigated by Oracle being a member of OIN and libgcj and GCC being on OIN's list of protected software packages. ...but the extent of OIN's protection is sometimes unclear.

I'm trying to untangle it here:
http://en.swpat.org/wiki/Java_and_patents


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