RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint
igor.veresov at oracle.com
Fri May 23 22:35:28 UTC 2014
We don't flush OSRs, but you're right - a separate state should be a cleaner and more future proof (multiple code versions) solution. I'll make the change and add the state.
> On May 23, 2014, at 12:22 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> I remember someone (Vladimir Ivanov?) wanted to add additional state to nmethod to track installation phase. Because it could be other cases when nm != nm->method()->code(). What about OSR nmethods?
>> On 5/23/14 12:53 PM, Igor Veresov wrote:
>> So, I went back to this bug and here is the actual root cause of the problem... I was running stress tests with -XX:MinPassesBeforeFlush=0 and a very small code cache, which created a race between the method installation (in ciEnv::register_method()) and the flusher. Methods were flushed right after we released the CodeCache_lock in nmethod::new_nmethod(), and that’s the reason the verification thought that the installation has finished since the method wasn’t in use. It’s also btw pretty dangerous to do an nmethod state transition from in_use to not_entrant before the code pointer is installed - we don’t clean it up later when we transition from not_entrant to zombie (and we can’t).
>> Anyways, the solution is pretty straightforward, we must not flush an nmethod before it’s fully installed (that is until the code pointer is published).
>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.02/
More information about the hotspot-compiler-dev