RFR(XL): 8185640: Thread-local handshakes

[Doerr, Martin]

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.

Best regards,
Martin


-----Original Message-----
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
lot.

> (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.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671