RFR: 8171853: Remove Shark compiler

Roman Kennke rkennke at redhat.com
Mon Oct 16 05:49:26 UTC 2017


Hi David,

thanks for reviewing and testing!

The interaction between JEPs and patches going in is not really clear to 
me, nor is it well documented. For example, we're already pushing 
patches for JEP 304: Garbage Collection Interface, even though it's only 
in 'candidate' state...

In any case, I'll ping Mark Reinhold about moving the Shark JEP forward.

Thanks again,
Roman

> My internal JPRT run went fine. So this just needs a build team 
> signoff from the perspective of the patch.
>
> However, as this has had a JEP submitted for it, the code changes can 
> not be pushed until the JEP has been targeted.
>
> Thanks,
> David
>
> On 16/10/2017 8:08 AM, David Holmes wrote:
>> Looks good.
>>
>> Thanks,
>> David
>>
>> On 16/10/2017 8:00 AM, Roman Kennke wrote:
>>>
>>> Ok, I fixed all the comments you mentioned.
>>>
>>> Differential (against webrev.01):
>>> http://cr.openjdk.java.net/~rkennke/8171853/webrev.03.diff/ 
>>> <http://cr.openjdk.java.net/%7Erkennke/8171853/webrev.03.diff/>
>>> Full webrev:
>>> http://cr.openjdk.java.net/~rkennke/8171853/webrev.03/ 
>>> <http://cr.openjdk.java.net/%7Erkennke/8171853/webrev.03/>
>>>
>>> Roman
>>>
>>>> Just spotted this:
>>>>
>>>> ./hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java: /** 
>>>> {@code CompLevel::CompLevel_full_optimization} -- C2 or Shark */
>>>>
>>>> David
>>>>
>>>> On 16/10/2017 7:25 AM, David Holmes wrote:
>>>>> On 16/10/2017 7:01 AM, Roman Kennke wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> thanks!
>>>>>>
>>>>>> I'm uploading a 2nd revision of the patch that excludes the 
>>>>>> generated-configure.sh part, and adds a smallish Zero-related fix.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~rkennke/8171853/webrev.01/ 
>>>>>> <http://cr.openjdk.java.net/%7Erkennke/8171853/webrev.01/>
>>>>>
>>>>> Can you point me to the exact change please as I don't want to 
>>>>> re-examine it all. :)
>>>>>
>>>>> I'll pull this in and do a test build run internally.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks, Roman
>>>>>>
>>>>>>
>>>>>>> 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