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