RFR(S): 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc
Volker Simonis
volker.simonis at gmail.com
Fri Jun 17 09:22:44 UTC 2016
Hi Goetz,
thanks for the review.
You're right, I've fixed the "else":
http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620.v1/
Regards,
Volker
On Fri, Jun 17, 2016 at 11:08 AM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> Hi Volker,
>
> thanks for doing this fix, I also have run into this issue before ...
> Looks good.
>
> Small nit: usually
> }
> else {
> are on one line.
>
> Best regards,
> Goetz.
>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of Volker Simonis
>> Sent: Donnerstag, 16. Juni 2016 16:54
>> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>> Subject: RFR(S): 8159620: -XX:-UseOnStackReplacement does not work
>> together with -XX:+TieredCompilation on ppc64 and sparc
>>
>> Hi,
>>
>> can I please have a review and sponsor for the following small change
>> which fixes -XX:-UseOnStackReplacement to work together with
>> -XX:+TieredCompilation:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8159620/
>> https://bugs.openjdk.java.net/browse/JDK-8159620
>>
>> This is a long standing bug on SPARC and as the ppc64 template
>> interpreter was initially forked from the SPARC implementation, it
>> also manifests there. The problem is that in the case of tiered
>> compilation the interpreter unconditionally calls
>> InterpreterRuntime::frequency_counter_overflow if the back edge
>> counter overflows. This triggers an OSR compilation, even if OSR was
>> switched off with -XX:-UseOnStackReplacement.
>>
>> The fix is simple - just don't call
>> InterpreterRuntime::frequency_counter_overflow if OSR has been
>> switched off.
>>
>> Thank you and best regards,
>> Volker
More information about the hotspot-dev
mailing list