Review Request: Shark
Christian.Thalinger at Sun.COM
Tue Jun 22 07:15:00 PDT 2010
On Tue, 2010-06-22 at 14:29 +0100, Gary Benson wrote:
> Christian Thalinger wrote:
> > hotspot/src/share/vm/compiler/disassembler.cpp:
> > +#ifdef SHARK
> > + SharkEntry* entry = (SharkEntry *) nm->instructions_begin();
> > + unsigned char* p = entry->code_start();
> > + unsigned char* end = entry->code_limit();
> > +#else
> > Why do you need to stuff a SharkEntry into the address?
> There's a few reasons for this:
> a) The server (and I think client) compilers generate code into a
> temporary CodeBuffer which the VM relocates into some "final"
> location when the nmethod is installed. Shark can't control
> where its code is generated, it happens in some LLVM-allocated
> buffer, so we can't generate into a CodeBuffer and we certainly
> can't relocate that code afterwards. So we generate a "dummy"
> CodeBuffer containing a pointer to the real native code.
> b) To free an LLVM-compiled method you need to keep track of the
> original IR it was compiled from. The CodeBuffer is a convenient
> place to store that.
> c) Shark has no access to the code it generates (other than knowing
> where it is in memory) so it can't, for example, inline an oop
> and the rewrite it later. Instead, Shark inlines oops into the
> method's CodeBuffer (with the appropriate relocations so they
> are rewritten as necessary) and loads them every time they're
I see. At least c) sounds familiar.
> > hotspot/src/share/vm/runtime/deoptimization.cpp:
> > +#ifndef SHARK
> > assert(CodeCache::find_blob_unsafe(frame_pcs) != NULL, "bad pc");
> > +#endif // SHARK
> > Why does this assert not hold?
> Neither interpreter frames nor call stub frames exist in the code
> cache in Zero.
> > hotspot/src/share/vm/includeDB_shark:
> > Still has the old Sun copyright header.
> Ah, good catch. I fixed this in:
I guess you mean: http://cr.openjdk.java.net/~gbenson/shark-hotspot-02/
More information about the hotspot-compiler-dev