RFR (S): 8022494: Make compilation IDs sequential

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Oct 28 11:59:32 PDT 2013


Albert,

The warning is not correct solution since we HAVE to generate method handle intrinsics if your comment is correct:

+       // must be generated for method handle intrinsics (8026407), print out a warning.
+       if (method->is_method_handle_intrinsic()) {
+         warning("Must generate wrapper for method handle intrinsic");
+         return;
+       }

I think assign_compile_id() should generate id in such case regardless CIStart and CIStop values. The warning above will 
be assert after that.

And, please, file RFE (starter task) to cleanup type of compile_id. In some places it declared as 'int' and in an other 
as 'uint'.

Thanks,
Vladimir

On 10/24/13 1:56 AM, Albert Noll wrote:
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ <http://cr.openjdk.java.net/%7Eanoll/8022494/webrev.04/>
>
> Best,
> Albert
>
> On 24.10.2013 10:21, Albert Noll wrote:
>> Hi Aleksey,
>>
>> thanks for looking at this.
>>
>> On 24.10.2013 10:15, Aleksey Shipilev wrote:
>>> On 10/24/2013 12:01 PM, Albert Noll wrote:
>>>> Here is the updated webrev:
>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/
>>> Nice to see the locking gone.
>>>
>>> compileBroker.cpp:
>>>    * Is that considered correct that OSR and normal compilations are
>>> marked differently when running in debug mode, but not in release? I
>>> understand the comment before assign_compile_id, so this is more of the
>>> philosophical question.
>> Compilation IDs are only different if -XX:CICountOSR is set, which is
>> defaulted to false.
>>> sharedRuntime.cpp:
>>>    * Why do you need "2653   return;" in the method tail?
>> Thanks for spotting this. I missed it during the cleanup.
>>
>> Best,
>> Albert
>>> Thanks,
>>> -Aleksey.
>>
>


More information about the hotspot-compiler-dev mailing list