RFR: 8144083 [JVMCI] CompilationResult should be finalized by JVMCI compiler and made effectively final

Christian Thalinger christian.thalinger at oracle.com
Mon Nov 30 20:02:17 UTC 2015


> On Nov 30, 2015, at 8:01 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> 
>> On Nov 30, 2015, at 7:57 AM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> 
>>> On 30 Nov 2015, at 18:32, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>> Forgot one comment:
>>> 
>>>   /**
>>>    * Gets the assumptions made during compilation.
>>> +     *
>>> +     * The caller must not modify the contents of the returned array.
>>>    */
>> 
>> Good catch.
>> 
>>>   public Assumption[] getAssumptions() {
>>>       return assumptions;
>>>   }
>>> 
>>> Should we file an enhancement to somehow enforce this contract?  Or should we just clone the array?
>> 
>> We want to avoid copying/cloning to minimize code installation time.
> 
> I understand but are you sure this is a problem?  Installation time compared to compilation time should be small.

Anyway, I will integrate the change as is.

> 
>> 
>> This is a value that will assigned to HotSpotCompiledCode.assumptions which in turn will be read directly by the VM so we want a simple data type like an array. As far as I know, there’s no way to enforce array contents as being treated constant/final.
> 
> Not yet.
> 
>> 
>>> 
>>>> On Nov 30, 2015, at 7:30 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> 
>>>> Looks good.
>>>> 
>>>>> On Nov 26, 2015, at 3:33 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>> 
>>>>> The CompilationResult object is a mutable object built by a JVMCI compiler backend during code generation. Currently, clients of the compiler are required to finalize construction of a CompilationResult once the compilation has completed. Furthermore, the HotSpotCompiledCode constructor takes a partially-constructed CompilationResult and then completes its construction. This non-locality of mutation is not just bad software design but in this case means a single CompilationResult cannot be used to create multiple HotSpotCompiledCode objects. 
>>>>> 
>>>>> We propose to address this by requiring the JVMCI compiler to do all construction of a CompilationResult and then close it to further updating.
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8144083
>>>>> http://cr.openjdk.java.net/~dnsimon/8144083/
>>>>> 
>>>>> -Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151130/0f757f50/attachment-0001.html>


More information about the hotspot-compiler-dev mailing list