RFR JDK-8194084: Obsolete FastTLABRefill and remove the related code

JC Beyler jcbeyler at google.com
Fri Feb 16 20:22:06 UTC 2018


Hi Coleen,

Done then I think correctly:
http://cr.openjdk.java.net/~jcbeyler/8194084/webrev.02/

Due diligence would require Derek White to potentially ack my latest webrev
change for aarch64 of removing r5 from the spill/fill as he had requested
it.

Other than that, let me know what else is needed/missing and thanks for
testing/sponsoring!
Jc


On Fri, Feb 16, 2018 at 10:30 AM, <coleen.phillimore at oracle.com> wrote:

>
>
> On 2/16/18 12:06 PM, JC Beyler wrote:
>
> Answering all in one go :)
>
> I updated the webrev to:
> http://cr.openjdk.java.net/~jcbeyler/8194084/webrev.01/
>
> I am guessing I need a tested ok from each architecture and not only a
> looks good. If I am wrong, I apologize! If I am right, the current status
> of each architecture is:
>
> - aarch64: I removed the use of r5 but left for now r19 to be
> stored/loaded back, let me know what you think, Derek.
> - ppc64 and s390 look good  from Martin, missing a tested ok
> - Sparc looks good from Coleen, missing a tested ok
>     - I removed the option from globals.h, let me know if that is correct,
> it seems to be what is said from the comment above but I thought maybe we
> had to wait until the version number got bumped and then move all flags out
> of globals.hpp.
>
> - arm: missing a looks good and test
> - x86: missing a looks good and test :)
>
> I'm happy to do as I did with https://bugs.openjdk.
> java.net/browse/JDK-8190862 and create subtasks if that will make it
> easier on everyone.
>
>
> Oh please, no.
>
> If you update your webrev with a commit message with the current reviewers
> (including myself).  I'll import and run final tests on the platforms
> missing and if it passes, I'll sponsor and push.
>
> thanks,
> Coleen
>
> Let me know,
> Jc
>
>
> On Fri, Feb 16, 2018 at 5:49 AM, <coleen.phillimore at oracle.com> wrote:
>
>>
>> I agree with this change, and will sponsor it and test on sparc (and on
>> oracle platforms).
>>
>> When you obsolete an option, I think you just remove it from globals.hpp
>> and the code in arguments.cpp should tell you it's obsolete.
>>
>> Thanks,
>> Coleen
>>
>> On 2/14/18 6:08 PM, JC Beyler wrote:
>>
>>> Hi all,
>>>
>>> Here is a webrev to do the work mentioned in JDK-8194084
>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>:
>>> http://cr.openjdk.java.net/~jcbeyler/8194084/webrev.01/
>>>
>>> It has the parts for each architecture and I can't test a lot of them so
>>> I
>>> would need a review and test for each :). I think first would be an
>>> agreement to the code change itself then test it once everyone agrees on
>>> the change ?
>>>
>>> Could I please get some initial reviews on this?
>>>
>>> Basically what this webrev does is follow what the interpreter is saying:
>>>    - No longer try to do a fast tlab refill
>>>    - Try eden allocation if contiguous inline allocation is true
>>>    - Otherwise slowpath
>>>
>>> This is true for all architectures except:
>>>     - ppc, which doesn't do eden allocations, I just cleaned up the code
>>> a
>>> bit there to be consistent
>>>     - s390 that does not do tlab_refill at all, I just removed the dead
>>> code
>>> there.
>>>
>>> Thanks a lot for your help,
>>> Jc
>>>
>>
>>
>
>


More information about the hotspot-dev mailing list