Request Review: JDK-6479237 (cl) Add support for classloader names
coleen.phillimore at oracle.com
Thu Nov 3 01:10:39 UTC 2016
On 11/2/16 8:53 PM, Mandy Chung wrote:
>> On Nov 2, 2016, at 5:48 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> On 11/2/16 8:47 PM, Mandy Chung wrote:
>>>> On Nov 2, 2016, at 5:40 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>> I missed some of the iterations of this. To avoid making a large change larger, I think you should keep the original names of ToStackTraceElement and GetStackTraceElements.
>>> There is no change to the name of these JVM entry points.
>>> This patch changes the private native methods in the library. Is that what concerns you?
>> Yes, the names of the library methods don't match the JVM names anymore. I think changing the names are unnecessary and makes it not obvious the mapping.
> Is there such convention? I wasn’t aware of that. In addition, it would be impractical to synchronize the native methods to match JVM function names.
Yes, there's a convention of having very similar names. It's not 100%
but having completely different names here is really not helpful for
maintaining this code. This is from looking at the names in
src/java.base/share/native/libjava. Some of the names have additional
namespace-like strings like "Class" but basically they're close to the
same. I think it's a good convention to have. In this case, I think
the names toStackTraceElement and getStackTraceElements are pretty well
descriptive and don't see the reason to change them.
I'll read the thread. We've had a runtime offsite all week and haven't
been able to read this thread, and thought you'd checked in what I'd
More information about the hotspot-runtime-dev