archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-09-18 18:14:38 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

8259713: Fix comments about ResetNoHandleMark in deoptimization

Browse source 
Reviewed-by: lfoltan, dcubed, dholmes
This commit is contained in:
Coleen Phillimore 2021-01-14 23:25:14 +00:00
parent 4f881ba54a
commit bf28f92555
1 changed files with 10 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

22
src/hotspot/share/runtime/deoptimization.cpp
View file

@ -150,15 +150,10 @@ void Deoptimization::UnrollBlock::print() {
// In order to make fetch_unroll_info work properly with escape // In order to make fetch_unroll_info work properly with escape
// analysis, The method was changed from JRT_LEAF to JRT_BLOCK_ENTRY and // analysis, the method was changed from JRT_LEAF to JRT_BLOCK_ENTRY.
// ResetNoHandleMark and HandleMark were removed from it. The actual reallocation // The actual reallocation of previously eliminated objects occurs in realloc_objects,
// of previously eliminated objects occurs in realloc_objects, which is // which is called from the method fetch_unroll_info_helper below.
// called from the method fetch_unroll_info_helper below.
JRT_BLOCK_ENTRY(Deoptimization::UnrollBlock*, Deoptimization::fetch_unroll_info(JavaThread* thread, int exec_mode)) JRT_BLOCK_ENTRY(Deoptimization::UnrollBlock*, Deoptimization::fetch_unroll_info(JavaThread* thread, int exec_mode))
// It is actually ok to allocate handles in a leaf method. It causes no safepoints,
// but makes the entry a little slower. There is however a little dance we have to
// do in debug mode to get around the NoHandleMark code in the JRT_LEAF macro
// fetch_unroll_info() is called at the beginning of the deoptimization // fetch_unroll_info() is called at the beginning of the deoptimization
// handler. Note this fact before we start generating temporary frames // handler. Note this fact before we start generating temporary frames
// that can confuse an asynchronous stack walker. This counter is // that can confuse an asynchronous stack walker. This counter is
@ -689,10 +684,13 @@ JRT_LEAF(BasicType, Deoptimization::unpack_frames(JavaThread* thread, int exec_m
// We are already active in the special DeoptResourceMark any ResourceObj's we // We are already active in the special DeoptResourceMark any ResourceObj's we
// allocate will be freed at the end of the routine. // allocate will be freed at the end of the routine.
// It is actually ok to allocate handles in a leaf method. It causes no safepoints, // JRT_LEAF methods don't normally allocate handles and there is a
// but makes the entry a little slower. There is however a little dance we have to // NoHandleMark to enforce that. It is actually safe to use Handles
// do in debug mode to get around the NoHandleMark code in the JRT_LEAF macro // in a JRT_LEAF method, and sometimes desirable, but to do so we
ResetNoHandleMark rnhm; // No-op in release/product versions // must use ResetNoHandleMark to bypass the NoHandleMark, and
// then use a HandleMark to ensure any Handles we do create are
// cleaned up in this scope.
ResetNoHandleMark rnhm;
HandleMark hm(thread); HandleMark hm(thread);
frame stub_frame = thread->last_frame(); frame stub_frame = thread->last_frame();