RFR: 8309663: test fails "assert(check_alignment(result)) failed: address not aligned: 0x00000008baadbabe"
Serguei Spitsyn
sspitsyn at openjdk.org
Fri Jun 16 05:53:02 UTC 2023
On Wed, 14 Jun 2023 19:28:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 2325:
>>
>>> 2323: // Need to apply load barriers for unmounted vthreads.
>>> 2324: nmethod* nm = jvf->cb()->as_nmethod();
>>> 2325: nm->run_nmethod_entry_barrier();
>>
>> This looks good in general.
>> However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):
>>
>> template <stackChunkOopDesc::BarrierType barrier, ChunkFrames frame_kind, typename RegisterMapT>
>> void stackChunkOopDesc::do_barriers0(const StackChunkFrameStream<frame_kind>& f, const RegisterMapT* map) {
>> // We need to invoke the write barriers so as not to miss oops in old chunks that haven't yet been concurrently scanned
>> assert (!f.is_done(), "");
>>
>> if (f.is_interpreted()) {
>> Method* m = f.to_frame().interpreter_frame_method();
>> // Class redefinition support
>> m->record_gc_epoch();
>> } else if (f.is_compiled()) {
>> nmethod* nm = f.cb()->as_nmethod();
>> // The entry barrier takes care of having the right synchronization
>> // when keeping the nmethod alive during concurrent execution.
>> nm->run_nmethod_entry_barrier();
>> // There is no need to mark the Method, as class redefinition will walk the
>> // CodeCache, noting their Methods
>> }
>> . . .
>
>> This looks good in general. However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):
>>
>
> This code collects references from thread stack, I don't see how class redefinition can affect them
Thanks. I agree with it.
The stackChunkOopDesc implementation needs it as it does some stack chunk updates.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14460#discussion_r1231803017
More information about the serviceability-dev
mailing list