Review Request: Shark

[Gary Benson]

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
    needed.

> hotspot/src/share/vm/runtime/deoptimization.cpp:
> 
> +#ifndef SHARK
>    assert(CodeCache::find_blob_unsafe(frame_pcs[0]) != 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:
http://cr.openjdk.java.net/~gbenson/shark-hotspot-01/

Cheers,
Gary

-- 
http://gbenson.net/