RFR (S) 8216302: StackTraceElement::fill_in can use cached Class.name
Mikael Vidstedt
mikael.vidstedt at oracle.com
Tue Jan 8 23:15:52 UTC 2019
Perhaps getName0 and JVM_GetClassName should be renamed to reflect that they actually are mutating state?
Cheers,
Mikael
> On Jan 8, 2019, at 2:40 PM, David Holmes <david.holmes at oracle.com> wrote:
>
> On 9/01/2019 5:54 am, coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com> wrote:
>> On 1/8/19 1:55 PM, Aleksey Shipilev wrote:
>>> On 1/8/19 5:48 PM, coleen.phillimore at oracle.com wrote:
>>>> I agree we shouldn't initialize the name field eagerly when creating a class. I also looked at this
>>>> code path:
>>>>
>>>> public String getName() {
>>>> String name = this.name;
>>>> if (name == null)
>>>> this.name = name = getName0();
>>>> return name;
>>>> }
>>>>
>>>> It looks like when we call JVM_GetClassName, we're initializing the Class.name field by the caller.
>>>>
>>>> Maybe could rewrite the java/lang/Class version to be:
>>>>
>>>> public String getName() {
>>>> String name = this.name;
>>>> if (name == null)
>>>> name = getName0(); // this initializes this.name yuck.
>>>> return name;
>>>> }
>>>>
>>>> and have JVM_GetClassName call java_lang_Class::name() to do the initialization. Seems not worth
>>>> it just to avoid duplicating these lines in both java_lang_Class::name() and JVM_GetClassName.
>>> Right. I also think it does not worth it. My reason is given in another reply in this thread:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-January/036152.html
>> Right, saw that. I agreed.
>
> I really don't like the fact the VM is now setting the name field and there's nothing in the Java code to give any indication that this is happening. At a minimum a comment should be added, as is done with other class members that get accessed directly by the VM.
>
> I also think core-libs folk should be having a say here.
>
> David
> -----
>
>> Coleen
>>>
>>> I'll handelize the oop and keep the rest as is.
>>>
>>> -Aleksey
More information about the hotspot-dev
mailing list