RFR(M) : 8059624 : Test task: WhiteBox API for testing segmented codecache feature

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Nov 7 01:25:52 UTC 2014


On 11/6/14 10:02 AM, Igor Ignatyev wrote:
> updated webrev: http://cr.openjdk.java.net/~iignatyev/8059624/webrev.01/
> 679 lines changed: 643 ins; 2 del; 34 mod;
>
> Hi Vladimir/Tobias,
>
> thanks for review. please see my answers inline.
>
> On 11/06/2014 02:55 AM, Vladimir Kozlov wrote:
>> Hi Igor,
>>
>> codeBlob.hpp
>>
>> Why you need?:
>>
>> +   // placement
>> +   inline void* operator new(size_t s, void* p) throw() { return p; }
> I need this to execute ctor in WhiteBox::allocateCodeHeap:
>> 887   new (blob) BufferBlob("WB::DummyBlob", full_size);
>
> it's impossible to use default placement new, since BufferBlob overloads
> operator new.

We do use ::new() in GrowableArray. Will it work in your case?

>
>> compileBroker.cpp
>>
>> I think MonitorLockerEx locker() should be before the loop. Then you may
>> not need to get lock in WB_UnlockCompilation.
> I moved MonitorLockerEx before the loop, but I still need a lock in
> UnlockCompilation to call notify_all();

Should it be like next? Otherwise it looks like deadlock.

+ WB_ENTRY(void, WB_UnlockCompilation(JNIEnv* env, jobject o))
+   WhiteBox::compilation_locked = false;
+   {
+     MonitorLockerEx mo(Compilation_lock, Mutex::_no_safepoint_check_flag);
+     mo.notify_all();
+   }
+ WB_END

>
>> whitebox.cpp
>>
>> allocateCodeHeap() - what if CodeCache::allocate() failed to allocate?
> it will return null, see AllocationCodeHeapTest.java:
>>   93         while ((addr = WHITE_BOX.allocateCodeHeap(size, type.id))
>> != 0) {
>>   94             blobs.add(addr);
>>   95         }

But in other cases you don't check:

  73         long addr = WHITE_BOX.allocateCodeHeap(SIZE, type.id);

  79         WHITE_BOX.freeCodeHeap(addr);

And BufferBlob::free() does not check for NULL:

void BufferBlob::free(BufferBlob *blob) {
   ThreadInVMfromUnknown __tiv;  // get to VM state in case we block on 
CodeCache_lock
   blob->flush();

>
>> In WB_GetCodeHeapEntries() checks that blobs array is not empty after
>> the loop which add entries.
> should I? I thought that blobs.length() will be 0 and blobs.begin() will
> equal blobs.end() in this case, won't it?

Yes, but I am asking to add short-cut to bailout early to avoid 
allocation of new array and other code which follows:

+   ThreadToNativeFromVM ttn(thread);
+   jobjectArray result = NULL;
+   jclass clazz = 
env->FindClass(vmSymbols::java_lang_Object()->as_C_string());
+   CHECK_JNI_EXCEPTION_(env, NULL);
+   result = env->NewObjectArray(blobs.length(), clazz, NULL);

>
>> You need to prevent sweeping when you processing codecache blobs
>> (getCodeHeapEntries). Otherwise pointers from getCodeBlobs() may point
>> to dead or overwritten space, consider -Xcomp -XX:+DeoptimizeALot
> sweeper does its work after acquiring CodeCache_lock and there is lock
> CodeCache before 1st loop, so I introduced struct CodeBlobStub and store
> it in GrowableArray instead of CodeBlob.

Yes, this works.

Thanks,
Vladimir

>>
>> Thanks,
>> Vladimir
>
> On 11/06/2014 12:11 PM, Tobias Hartmann wrote:
>> Hi Igor,
>>
>> looks good (not a reviewer). In addition to Vladimir's comments:
>>
>> 'WhiteBox::allocateCodeHeap' should be 'allocate_code_heap'. I think
>> the name is
>> a bit misleading since we don't allocate a CodeHeap but a CodeBlob in a
>> CodeHeap. Maybe use 'code_heap_allocate' or 'allocate_code_blob'. Same
>> for
>> 'WB_AllocateCodeHeap'.
> agree, changed it to AllocateCodeBlob/FreeCodeBlob
> // I just tried to mimic WB_AllocateMetaspace
>>
>> In 'BlobType::getAvailable' you always return the NonProfiledCodeHeap if
>> CodeCacheSegmentation is enabled. But if we only use the interpreter
>> (-Xint), we
>> don't have any method code heaps. Also with 'TieredStopAtLevel <=
>> CompLevel_simple' we don't need the ProfiledCodeHeap (see
>> 'CodeCache::heap_available'). The corresponding tests will hit the
>> "heap is
>> null" assert in 'CodeCache::allocate'.
> I updated 'BlobType::getAvailable' to handle such the situations.
>
>> On 11/5/14 8:25 AM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev/8059624/webrev.00/
>>> 660 lines changed: 624 ins; 2 del; 34 mod;
>>>
>>> Hi all,
>>>
>>> please review the patch which adds new WhiteBox methods needed for
>>> better testing SegmentedCodeCache:
>>>   - perform allocation in code cache
>>>   - force code cache sweep
>>>   - lock/unlock compilation
>>>   - get a segment id for nmethod.
>>> besides these methods, the patch also adds a method to get all entries
>>> in code heap.
>>>
>>> changes in product code:
>>>   - monitor 'Compilation_lock' was added to implement compilation
>>> locking/unlocking
>>>   - align_code_offset function was made a static member of CodeBlob
>>>   - WhiteBox was made a friend of several classes
>>>
>>> testing: jprt, new added tests
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8059624
>>>


More information about the hotspot-compiler-dev mailing list