RFR: 8171853: Remove Shark compiler

David Holmes david.holmes at oracle.com
Sun Oct 15 21:23:52 UTC 2017

Hi Roman,

I've looked at all the changes for the build and hotspot and everything 
appears okay to me. Still need someone from compiler team and build team 
to sign off on this though.

One observation in src/hotspot/cpu/zero/sharedRuntime_zero.cpp, these 
includes would seem to be impossible:

   38 #ifdef COMPILER1
   39 #include "c1/c1_Runtime1.hpp"
   40 #endif
   41 #ifdef COMPILER2
   42 #include "opto/runtime.hpp"
   43 #endif


In src/hotspot/share/ci/ciEnv.cpp you can just delete the comment 
entirely as it's obviously C2:

if (is_c2_compile(comp_level)) { // C2

Ditto in src/hotspot/share/compiler/compileBroker.cpp

!     // C2
       make_thread(name_buffer, _c2_compile_queue, counters, 
_compilers[1], compiler_thread, CHECK);


On 16/10/2017 6:48 AM, David Holmes wrote:
> Hi Roman,
> The build changes must be reviewed on build-dev - now cc'd.
> Thanks,
> David
> On 15/10/2017 8:41 AM, Roman Kennke wrote:
>> The JEP to remove the Shark compiler has received exclusively positive 
>> feedback (JDK-8189173) on zero-dev. So here comes the big patch to 
>> remove it.
>> What I have done:
>> grep -i -R shark src
>> grep -i -R shark make
>> grep -i -R shark doc
>> grep -i -R shark doc
>> and purged any reference to shark. Almost everything was straightforward.
>> The only things I wasn't really sure of:
>> - in globals.hpp, I re-arranged the KIND_* bits to account for the gap 
>> that removing KIND_SHARK left. I hope that's good?
>> - in relocInfo_zero.hpp I put a ShouldNotCallThis() in 
>> pd_address_in_code(), I am not sure it is the right thing to do. If 
>> not, what *would* be the right thing?
>> Then of course I did:
>> rm -rf src/hotspot/share/shark
>> I also went through the build machinery and removed stuff related to 
>> Shark and LLVM libs.
>> Now the only references in the whole JDK tree to shark is a 'Shark 
>> Bay' in a timezone file, and 'Wireshark' in some tests ;-)
>> I tested by building a regular x86 JVM and running JTREG tests. All 
>> looks fine.
>> - I could not build zero because it seems broken because of the recent 
>> Atomic::* changes
>> - I could not test any of the other arches that seemed to reference 
>> Shark (arm and sparc)
>> Here's the full webrev:
>> http://cr.openjdk.java.net/~rkennke/8171853/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Erkennke/8171853/webrev.00/>
>> Can I get a review on this?
>> Thanks, Roman

More information about the build-dev mailing list