The workaround requires a decoration to a JFR event that is fired from inside a non-recursive context, for example, like from inside non-reentrant load barriers.
JfrNonReentrant<EventZStatisticsCounter> e;
This issue should be resolved in a way that requires no additional JFR event decorations for sensitive non-reentrant JFR event sites.
Most oop accesses (that trigger reentry of load barriers) comes from fetching the vthread oop name, and involve the following sequence of operations:
Getting the thread name for a vthread:
oop vthread = jt->vthread();
oop name = java_lang_Thread::name(vthread);
typeArrayOop value = java_lang_String::value(name);
int length = java_lang_String::length(name, value);
bool is_latin1 = java_lang_String::is_latin1(name);
if (is_latin1) {
value->byte_at_addr(0);
} else {
value->char_at_addr(0)
}
// update epoch state
java_lang_Thread::set_jfr_epoch(vthread, epoch);
Virtual threads must be handled lazily from JFRs point of view, because, unlike regular threads, they are not reachable by other means.
We avoid reading the thread name on vthread mount because of the added overhead. Instead, JFR delays this operation until the very moment an event is committed.
- relates to
-
JDK-8348907 Stress times out when is executed with ZGC
-
- Resolved
-