[9] RFR(L) 8166413: Integrate VM part of AOT changes

[Stefan Karlsson]

Thanks!

StefanK

On 03/11/16 07:54, Vladimir Kozlov wrote:
> Thank you, Stefan
>
> On 11/1/16 12:38 AM, Stefan Karlsson wrote:
>> (resending without formatting)
>>
>> Hi Vladimir,
>>
>> I just took a quick look at the GC code.
>>
>> 1) You need to go over the entire patch and fix all the include lines
>> that were added. They are are not sorted, as they should.
>
> Done.
>
>>
>> Some examples:
>>
>> http://cr.openjdk.java.net/~kvn/aot/hs.webrev/src/share/vm/memory/metaspace.cpp.udiff.html 
>>
>>
>>
>>   #include "utilities/debug.hpp"
>>   #include "utilities/macros.hpp"
>> + #include "aot/aotLoader.hpp"
>>
>>
>>
>> 2) I'd prefer if the the check if AOT is enabled was folded into
>> AOTLoader::oops_do, so that the additions to the GC code would be less
>> conspicuous.
>
> Done. But I don't remove UseAOT for complex checks to avoid executing 
> following checks, like next:
>
> +   if (UseAOT && 
> !_process_strong_tasks->is_task_claimed(GCH_PS_aot_oops_do)) {
> +     AOTLoader::oops_do(strong_roots);
> +   }
>
>>
>> For example:
>> http://cr.openjdk.java.net/~kvn/aot/hs.webrev/src/share/vm/gc/parallel/psMarkSweep.cpp.udiff.html 
>>
>>
>>
>>     CodeBlobToOopClosure adjust_from_blobs(adjust_pointer_closure(),
>> CodeBlobToOopClosure::FixRelocations);
>>     CodeCache::blobs_do(&adjust_from_blobs);
>> +   if (UseAOT) {
>> +     AOTLoader::oops_do(adjust_pointer_closure());
>> +   }
>>     StringTable::oops_do(adjust_pointer_closure());
>>     ref_processor()->weak_oops_do(adjust_pointer_closure());
>> PSScavenge::reference_processor()->weak_oops_do(adjust_pointer_closure()); 
>>
>>
>> Would be:
>>
>>     CodeBlobToOopClosure adjust_from_blobs(adjust_pointer_closure(),
>> CodeBlobToOopClosure::FixRelocations);
>>     CodeCache::blobs_do(&adjust_from_blobs);
>> +   AOTLoader::oops_do(adjust_pointer_closure());
>>     StringTable::oops_do(adjust_pointer_closure());
>>     ref_processor()->weak_oops_do(adjust_pointer_closure());
>> PSScavenge::reference_processor()->weak_oops_do(adjust_pointer_closure()); 
>>
>>
>> 3) aotLoader.hpp uses implements methods using GrowableArray. This will
>> expose the growable array functions to all includers of that file.
>> Please move all that code out to an aotLoader.inline.hpp file, and then
>> remove the unneeded includes from the aotLoader.hpp file.
>>
>
> Done.
>
>> 4) 
>> http://cr.openjdk.java.net/~kvn/aot/hs.webrev/src/share/vm/memory/virtualspace.hpp.udiff.html
>>
>>
>>     // Reserved area
>>     char* low_boundary()  const { return _low_boundary; }
>>     char* high_boundary() const { return _high_boundary; }
>>
>> +   void set_low_boundary(char *p)  { _low_boundary = p; }
>> +   void set_high_boundary(char *p) { _high_boundary = p; }
>> +   void set_low(char *p)           { _low = p; }
>> +   void set_high(char *p)          { _high = p; }
>> +
>>     bool special() const { return _special; }
>>
>> These seems unsafe to me, but that might be because I don't understand
>> how this is used. VirtualSpace has three sections, the lower, middle,
>> and the high. The middle section might have another alignment (large
>> pages) than the others. Is this property still maintained when these
>> functions are used?
>
> This is used only by AOT code because it does not call 
> VirtualSpace::initialize_with_granularity() when creates AOTCodeHeap 
> (inherited from CodeHeap). There is no actual memory heap reservation 
> for AOT code. We set those boundary values to code section addresses 
> in AOT library. AOT does not use alignment and middle section.
>
> I put #if INCLUDE_AOT around these methods to be clear where they are 
> used.
>
>>
>> 5)
>> http://cr.openjdk.java.net/~kvn/aot/hs.webrev/src/share/vm/logging/logTag.hpp.udiff.html 
>>
>>
>>
>> Did you discuss with the Runtime team about the naming of these tags?
>> The other class* tags where split up into multiple tags. For example,
>> classload was changed to class,load.
>
> Will reply to following Coleen's mail.
>
> Thanks,
> Vladimir
>
>>
>> Thanks,
>> StefanK
>>
>> On 27/10/16 03:15, Vladimir Kozlov wrote:
>>> AOT JEP:
>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>> Subtask:
>>> https://bugs.openjdk.java.net/browse/JDK-8166415
>>> Webrev:
>>> http://cr.openjdk.java.net/~kvn/aot/hs.webrev/
>>>
>>> Please, review Hotspot VM part of AOT changes.
>>>
>>> Only Linux/x64 platform is supported. 'jaotc' and AOT part of Hotspot
>>> will be build only on Linux/x64.
>>>
>>> AOT code is NOT linked during AOT libraries load as it happens with
>>> normal .so libraries. AOT code entry points are not exposed (not
>>> global) in AOT libraries. Only class data has global labels which we
>>> look for with dlsym(klass_name).
>>>
>>> AOT-compiled code in AOT libraries is treated by JVM as *extension* of
>>> existing CodeCache. When a java class is loaded JVM looks if
>>> corresponding AOT-compiled methods exist in loaded AOT libraries and
>>> add links to them from java methods descriptors (we have new field
>>> Method::_aot_code). AOT-compiled code follows the same
>>> invocation/deoptimization/unloading rules as normal JIT-compiled code.
>>>
>>> Calls in AOT code use the same methods resolution runtime code as
>>> calls in JITed code. The difference is call's destination address is
>>> loaded indirectly because we can't patch AOT code - it is immutable
>>> (to share between multiple JVM instances).
>>>
>>> Classes and Strings referenced in AOT code are resolved lazily by
>>> calling into runtime. All mutable pointers (oops (mostly strings),
>>> metadata) are stored and modified in a separate mutable memory (GOT
>>> cells) - they are not embedded into AOT code.
>>>
>>> Changes includes klass fingerprint generation since we need it to find
>>> correct klass data in loaded AOT libraries.
>>>
>>> Thanks,
>>> Vladimir
>>
>>