RFR: [XS]: 8236183: cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming - was : RE: running java with LD_DEBUG-tracing
David Holmes
david.holmes at oracle.com
Wed Dec 18 22:02:30 UTC 2019
Hi Matthias,
Looks good. Thanks for fixing and finding. :)
David
On 19/12/2019 12:33 am, Baesken, Matthias wrote:
> Hello David,
> Here is a change that adjusts the naming of Java_jdk_internal_reflect_Reflection_getCallerClass -
>
> With this change, I checked the output of LD_DEBUG=libs java Test , and the error I observed before is gone .
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8236183
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8236183.0/
>
>
> Thanks, Matthias
>
>
>>>>
>>>> By chance I noticed the following output when running a trivial Java
>>>> program :
>>>>
>>>> LD_DEBUG=libs /linuxx86_64/output-jdk-
>> test/images/jdk/bin/java Test
>>>> . . .
>>>> 12241:
>>>> 12241:
>>>> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol
>>>> lookup error: undefined symbol:
>>>> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal)
>>>> 12241:
>>>>
>>>> What is wrong with
>>>> "Java_jdk_internal_reflect_Reflection_getCallerClass" ?
>>>> Does the error message occur because of the naming
>>>> Java_jdk_internal_reflect_Reflection_getCallerClass__ with the added
>>>> "__" at the end of the method (Reflection.c) ?
>>>
>>> That definitely looks like an error in the C source to me. The ending
>>> "__" should not be there. How is this working ??
>>
>> Ah! It is a remnant of when there were overloads of getCallerClass. The
>> "__" should be followed by the signature - which is empty in this case.
>> So IIRC the lookup will first try to use the short name (without the
>> trailing "__") which will fail, then it will use the long name which
>> will succeed.
>>
>> It should be fixed so we don't waste time doing two lookups.
>>
>> David
>
More information about the core-libs-dev
mailing list