C1 code installation and JNIHandle::deleted_handle() oop

[Vladimir Ivanov]

> The root of the evil is still that we're accessing the naked oop while 
> potentially at a safepoint (and oops moving around). You already 
> established that JVMCI doesn't have the problem because it's already 
> transitioned into VM. Why not make the other compilers consistent? I.e. 
> transition into VM (VM_ENTRY_MARK) before going into the same code path. 
> From the looks of it, code paths start to be shared between JVMCI and 
> others starting around 
> DebugInformationRecorder::create_scope_values(GrowableArray<ScopeValue*>*), 
> i.e. the VM_ENTRY_MARK could be placed around that in, e.g.,
> 
> void CodeEmitInfo::record_debug_info(DebugInformationRecorder* recorder, 
> int pc_offset) {
>    // record the safepoint before recording the debug info for enclosing 
> scopes
>    VM_ENTRY_MARK;
>    recorder->add_safepoint(pc_offset, _oop_map->deep_copy());
>    _scope_debug_info->record_debug_info(recorder, pc_offset, 
> true/*topmost*/, _is_method_handle_invoke);
>    recorder->end_safepoint(pc_offset);
> }
> 
> Although similarities between this code and related code in JVMCI would 
> suggest to place the VM_ENTRY_MARK even higher in the call stack.
> 
> WDYT?

(JVMCI is a different story, so leaving it aside for now.)

IMO the problem in ConstantOopWriteValue::write_on() doesn't justify 
such change. The problematic assert does something very unusual for 
existing compilers in the JVM and adjusting product code to fix that 
doesn't feel right.

Compiler threads were deliberately designed as JavaThreads running in 
native state to reduce interference with other parts of the JVM. 
Compiler interface (CI) encapsulates interactions with runtime and 
compilers code base is mostly free of handles & naked oops. In other 
words, compilers were written in a way to minimize the risk of accessing 
naked oops w/o proper coordination with the rest of runtime.

So, instead of precausiously putting VM_ENTRY_MARKs here and there, I'd 
prefer to see additional verification code to catch such problems in 
newly introduced code. IMO the lack of such functionality was the main 
reason why the bug slipped through testing.

Best regards,
Vladimir Ivanov