On Thu, 7 Mar 2024 01:44:22 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Dean's comments.
>
> src/hotspot/share/oops/instanceKlass.cpp line 1552:
>
>> 1550: RecursiveLocker rl(MultiArray_lock, THREAD);
>> 1551:
>> 1552: // This thread is the creator.
>
> This thread may not be the creator. The original comment was more apt - we
> typically say something like "Check if another thread beat us to it."
Fixed.
// Check if another thread created the array klass while we were waiting
for the lock.
> src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 121:
>
>> 119: {
>> 120: // To get a consistent list of classes we need MultiArray_lock to
>> ensure
>> 121: // array classes aren't created during this walk. This walks
>> through the
>
> Just curious but how can walking the set of classes trigger creation of array
> classes?
It can't. I'll reword that comment so it's clearer, with just a couple of
words.
// To get a consistent list of classes we need MultiArray_lock to ensure
// array classes aren't created by another thread this walk. This walks
through the
// InstanceKlass::_array_klasses links.
edit: added "during" to "by another thread during this walk"
> src/hotspot/share/runtime/mutexLocker.hpp line 335:
>
>> 333:
>> 334: // Instance of a RecursiveLock that may be held through Java heap
>> allocation, which may include calls to Java,
>> 335: // and JNI event notification for resource exhausted for metaspace or
>> heap.
>
> s/exhausted/exhaustion/
Fixed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1516126218
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1516128248
PR Review Comment: https://git.openjdk.org/jdk/pull/17739#discussion_r1516130552
