RFR(XL): 8185640: Thread-local handshakes
martin.doerr at sap.com
Thu Oct 26 09:44:01 UTC 2017
64k is the absolute worst case. I guess it won't take long until a branch gets reached in typical bytecode.
My point regarding the call is that it may be a tail recursion which fills up the stack.
From: Andrew Haley [mailto:aph at redhat.com]
Sent: Donnerstag, 26. Oktober 2017 11:40
To: Doerr, Martin <martin.doerr at sap.com>; Robbin Ehn <robbin.ehn at oracle.com>; Karen Kinnear <karen.kinnear at oracle.com>; Coleen Phillimore (coleen.phillimore at oracle.com) <coleen.phillimore at oracle.com>
Cc: hotspot-dev developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR(XL): 8185640: Thread-local handshakes
On 26/10/17 10:30, Doerr, Martin wrote:
> I don't think this will increase safepoint latency (if implemented
> appropriately). Methods compiled by C2 may contain counted loops
> (with int range) without safepoint. So this may be quite long in
> comparison to an interpreted method which can only contain up to 64k
> bytecodes while every branch contains a safepoint check.
This is to say, I think, that we already have one source of severe
safepoint delays, so why not have another one? 64k bytecodes is a
> (One might be kind of concerned about no poll in calls in the
> current implementation.)
I'm not sure why. For every call, there is a return.
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-dev