RFR(XL): 8185640: Thread-local handshakes

[Doerr, Martin]

Hi Andrew,

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 64 k bytecodes while every branch contains a safepoint check. (One might be kind of concerned about no poll in calls in the current implementation.)

Best regards,
Martin

 
-----Original Message-----
From: Andrew Haley [mailto:aph at redhat.com] 
Sent: Donnerstag, 26. Oktober 2017 10:59
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 25/10/17 23:05, Doerr, Martin wrote:

> after looking at the bytecodes again, I remembered that ret is olny
> for jsr. I think polling should also be done for the regular
> returns.
> A poll at the beginning of TemplateTable::_return should do the
> job. Unfortunately, it doesn't fit into your dispatch scheme.

I'm wondering if this is a good idea at all: it could increase the
latency of taking a safepoint in bytecode.  Granted, it does avoid
some significant code bloat in the interpreter.

BTW, I don't understand why interpreted code doesn't simply read the
polling page.  Or we could even simply read-protect the bytecode
dispatch tables themselves.

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