RFR: JDK-8152690: main thread does not have native thread name
Yasumasa Suenaga
yasuenag at gmail.com
Sun Apr 17 03:38:44 UTC 2016
Hi David,
> Need to hear from core-libs and/or launcher folk as this touches a number of pieces of code.
I'm waiting more reviewer(s) .
BTW, Should I make patches which are based on jdk9/dev repos?
My proposal includes hotspot changes.
So I want to know whether I can push all changes jdk9/dev/{jdk,hotspot} after reviewing.
I can update my webrev to adapt to jdk9/dev repos if need.
Thanks,
Yasumasa
On 2016/04/17 7:20, David Holmes wrote:
> Hi Yasumasa,
>
> On 16/04/2016 7:29 PM, Yasumasa Suenaga wrote:
>> Hi David,
>>
>> I uploaded new webrev:
>>
>> - hotspot:
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/
>>
>> - jdk:
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/
>
> Ah sneaky! :) Using JNI to by-pass access control so we can set up a private method to do the name setting, yet avoid any API change that would require a CCC request. I think I like it. :)
>
> Need to hear from core-libs and/or launcher folk as this touches a number of pieces of code.
>
> Thanks,
> David
> -----
>
>>
>>> it won't work unless you change the semantics of setName so I'm not
>>> sure what you were thinking here. To take advantage of an arg taking
>>> JVM_SetNativThreadName you would need to call it directly as no Java
>>> code will call it . ???
>>
>> I added a flag for setting native thread name to JNI-attached thread.
>> This change can set native thread name if main thread changes to
>> JNI-attached thread.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/04/16 16:11, David Holmes wrote:
>>> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote:
>>>> Hi David,
>>>>
>>>>> That change in behaviour may be a problem, it could be considered a
>>>>> regression that setName stops setting the native thread main, even
>>>>> though we never really intended it to work in the first place. :( Such
>>>>> a change needs to go through CCC.
>>>>
>>>> I understood.
>>>> Can I send CCC request?
>>>> (I'm jdk 9 commiter, but I'm not employee at Oracle.)
>>>
>>> Sorry you can't file a CCC request, you would need a sponsor for that.
>>> But at this stage I don't think I agree with the proposed change
>>> because of the change in behaviour - there's no way to restore the
>>> "broken" behaviour.
>>>
>>>> I want to continue to discuss about it on JDK-8154331 [1].
>>>
>>> Okay we can do that.
>>>
>>>>
>>>>> Further, we expect the launcher to use the supported JNI interface (as
>>>>> other processes would), not the internal JVM interface that exists for
>>>>> the JDK sources to communicate with the JVM.
>>>>
>>>> I think that we do not use JVM interface if we add new method in
>>>> LauncherHelper as below:
>>>> ----------------
>>>> diff -r f02139a1ac84
>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java
>>>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java
>>>> Wed Apr 13 14:19:30 2016 +0000
>>>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java
>>>> Sat Apr 16 11:25:53 2016 +0900
>>>> @@ -960,4 +960,8 @@
>>>> else
>>>> return md.toNameAndVersion() + " (" + loc + ")";
>>>> }
>>>> +
>>>> + static void setNativeThreadName(String name) {
>>>> + Thread.currentThread().setName(name);
>>>> + }
>>>
>>> You could also make that call via JNI directly, so not sure the helper
>>> adds much here. But it won't work unless you change the semantics of
>>> setName so I'm not sure what you were thinking here. To take advantage
>>> of an arg taking JVM_SetNativThreadName you would need to call it
>>> directly as no Java code will call it . ???
>>>
>>> David
>>> -----
>>>
>>>> }
>>>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c
>>>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30
>>>> 2016 +0000
>>>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53
>>>> 2016 +0900
>>>> @@ -125,6 +125,7 @@
>>>> static void PrintUsage(JNIEnv* env, jboolean doXUsage);
>>>> static void ShowSettings(JNIEnv* env, char *optString);
>>>> static void ListModules(JNIEnv* env, char *optString);
>>>> +static void SetNativeThreadName(JNIEnv* env, char *name);
>>>>
>>>> static void SetPaths(int argc, char **argv);
>>>>
>>>> @@ -325,6 +326,7 @@
>>>> * mainThread.isAlive() to work as expected.
>>>> */
>>>> #define LEAVE() \
>>>> + SetNativeThreadName(env, "DestroyJavaVM"); \
>>>> do { \
>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \
>>>> JLI_ReportErrorMessage(JVM_ERROR2); \
>>>> @@ -488,6 +490,9 @@
>>>> mainArgs = CreateApplicationArgs(env, argv, argc);
>>>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs);
>>>>
>>>> + /* Set native thread name. */
>>>> + SetNativeThreadName(env, "main");
>>>> +
>>>> /* Invoke main method. */
>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
>>>>
>>>> @@ -1686,6 +1691,22 @@
>>>> joptString);
>>>> }
>>>>
>>>> +/**
>>>> + * Set native thread name as possible.
>>>> + */
>>>> +static void
>>>> +SetNativeThreadName(JNIEnv *env, char *name)
>>>> +{
>>>> + jmethodID setNativeThreadNameID;
>>>> + jstring nameString;
>>>> + jclass cls = GetLauncherHelperClass(env);
>>>> + NULL_CHECK(cls);
>>>> + NULL_CHECK(setNativeThreadNameID =
>>>> (*env)->GetStaticMethodID(env, cls,
>>>> + "setNativeThreadName", "(Ljava/lang/String;)V"));
>>>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name));
>>>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID,
>>>> nameString);
>>>> +}
>>>> +
>>>> /*
>>>> * Prints default usage or the Xusage message, see
>>>> sun.launcher.LauncherHelper.java
>>>> */
>>>> ----------------
>>>>
>>>> So I want to add new arg to JVM_SetNativeThreadName().
>>>>
>>>>> However this is still a change to the exported JVM interface and so
>>>>> has to be approved.
>>>>
>>>> Do you mean that this change needs CCC?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html
>>>>
>>>>
>>>>
>>>>
>>>> On 2016/04/16 7:26, David Holmes wrote:
>>>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote:
>>>>>> Hi David,
>>>>>>
>>>>>>> I think it is a bug based on the comment here:
>>>>>>>
>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and
>>>>>>> JNI attached threads
>>>>>>
>>>>>> I filed it to JBS as JDK-8154331.
>>>>>> I will send review request to hotspot-runtime-dev.
>>>>>>
>>>>>>
>>>>>>> Though that will introduce a change in behaviour by itself as setName
>>>>>>> will no longer set the native name for the main thread.
>>>>>>
>>>>>> I know.
>>>>>
>>>>> That change in behaviour may be a problem, it could be considered a
>>>>> regression that setName stops setting the native thread main, even
>>>>> though we never really intended it to work in the first place. :( Such
>>>>> a change needs to go through CCC.
>>>>>
>>>>>> I checked changeset history.
>>>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is
>>>>>> backported JDK 8.
>>>>>
>>>>> Yes this all came in as part of the OSX port in 7u2.
>>>>>
>>>>>> However, this function seems to be called from Thread#setNativeName()
>>>>>> only.
>>>>>> In addition, Thread#setNativeName() is private method.
>>>>>>
>>>>>> Thus I think that we can add an argument to JVM_SetNativeThreadName()
>>>>>> for force setting.
>>>>>> (e.g. "bool forced")
>>>>>>
>>>>>> It makes a change of JVM API.
>>>>>> However, this function is NOT public, so I think we can add one more
>>>>>> argument.
>>>>>>
>>>>>> What do you think about this?
>>>>>> If it is accepted, we can set native thread name from Java launcher.
>>>>>
>>>>> The private/public aspect of the Java API is not really at issue. Yes
>>>>> we would add another arg to the JVM function to allow it to apply to
>>>>> JNI-attached threads as well (I'd prefer the arg reflect that not just
>>>>> "force"). However this is still a change to the exported JVM interface
>>>>> and so has to be approved. Further, we expect the launcher to use the
>>>>> supported JNI interface (as other processes would), not the internal
>>>>> JVM interface that exists for the JDK sources to communicate with the
>>>>> JVM.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>>
>>>>>> On 2016/04/15 19:16, David Holmes wrote:
>>>>>>> Hi Yasumasa,
>>>>>>>
>>>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>>> The fact that the "main" thread is not tagged as being a
>>>>>>>>> JNI-attached
>>>>>>>>> thread seems accidental to me
>>>>>>>>
>>>>>>>> Should I file it to JBS?
>>>>>>>
>>>>>>> I think it is a bug based on the comment here:
>>>>>>>
>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and
>>>>>>> JNI attached threads
>>>>>>>
>>>>>>> Though that will introduce a change in behaviour by itself as setName
>>>>>>> will no longer set the native name for the main thread.
>>>>>>>
>>>>>>>> I think that we can fix as below:
>>>>>>>> ---------------
>>>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp
>>>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016
>>>>>>>> +0200
>>>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016
>>>>>>>> +0900
>>>>>>>> @@ -3592,7 +3592,7 @@
>>>>>>>> #endif // INCLUDE_JVMCI
>>>>>>>>
>>>>>>>> // Attach the main thread to this os thread
>>>>>>>> - JavaThread* main_thread = new JavaThread();
>>>>>>>> + JavaThread* main_thread = new JavaThread(true);
>>>>>>>> main_thread->set_thread_state(_thread_in_vm);
>>>>>>>> main_thread->initialize_thread_current();
>>>>>>>> // must do this before set_active_handles
>>>>>>>> @@ -3776,6 +3776,9 @@
>>>>>>>> // Notify JVMTI agents that VM initialization is complete -
>>>>>>>> nop if
>>>>>>>> no agents.
>>>>>>>> JvmtiExport::post_vm_initialized();
>>>>>>>>
>>>>>>>> + // Change attach status to "attached"
>>>>>>>> + main_thread->set_done_attaching_via_jni();
>>>>>>>> +
>>>>>>>
>>>>>>> I think we can do this straight after the JavaThread constructor.
>>>>>>>
>>>>>>>> if (TRACE_START() != JNI_OK) {
>>>>>>>> vm_exit_during_initialization("Failed to start tracing
>>>>>>>> backend.");
>>>>>>>> }
>>>>>>>> ---------------
>>>>>>>>
>>>>>>>>
>>>>>>>>> If it wants to name its native threads then it is free to do so,
>>>>>>>>
>>>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread
>>>>>>>> name
>>>>>>>> when the caller thread is JNI-attached thread.
>>>>>>>> However, I think that it should be changed if Java developer calls
>>>>>>>> Thread#setName() explicitly.
>>>>>>>> It is not the same of changing native thread name at
>>>>>>>> Threads::create_vm().
>>>>>>>>
>>>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below.
>>>>>>>> What do you think about this?
>>>>>>>
>>>>>>> The decision to not change the name of JNI-attached threads was a
>>>>>>> deliberate one** - this functionality originated with the OSX port
>>>>>>> and
>>>>>>> it was reported that the initial feedback with this feature was to
>>>>>>> ensure it didn't mess with thread names that had been set by the host
>>>>>>> process. If we do as you propose then we will just have an
>>>>>>> inconsistency for people to complain about: "why does my native
>>>>>>> thread
>>>>>>> only have a name if I call cur.setName(cur.getName()) ?"
>>>>>>>
>>>>>>> ** If you follow the bugs and related discussions on this, the
>>>>>>> semantics and limitations (truncation, current thread only, non-JNI
>>>>>>> threads only) of setting the native thread name were supposed to be
>>>>>>> documented in the release notes - but as far as I can see that never
>>>>>>> happened. :(
>>>>>>>
>>>>>>> My position on this remains that if it is desirable for the main
>>>>>>> thread (and DestroyJavaVM thread) to have native names then the
>>>>>>> launcher needs to be setting them using the available platform APIs.
>>>>>>> Unfortunately this is complicated - as evidenced by the VM code for
>>>>>>> this - due to the need to verify API availability.
>>>>>>>
>>>>>>> Any change in behaviour in relation to Thread.setName would have
>>>>>>> to go
>>>>>>> through our CCC process I think. But a change in the launcher would
>>>>>>> not.
>>>>>>>
>>>>>>> Sorry.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> ---------------
>>>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016
>>>>>>>> +0200
>>>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016
>>>>>>>> +0900
>>>>>>>> @@ -3187,7 +3187,7 @@
>>>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread);
>>>>>>>> // Thread naming only supported for the current thread, doesn't
>>>>>>>> work
>>>>>>>> for
>>>>>>>> // target threads.
>>>>>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) {
>>>>>>>> + if (Thread::current() == thr) {
>>>>>>>> // we don't set the name of an attached thread to avoid
>>>>>>>> stepping
>>>>>>>> // on other programs
>>>>>>>> const char *thread_name =
>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name));
>>>>>>>>
>>>>>>>> ---------------
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Yasumasa
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2016/04/15 13:32, David Holmes wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote:
>>>>>>>>>> Roger,
>>>>>>>>>> Thanks for your comment!
>>>>>>>>>>
>>>>>>>>>> David,
>>>>>>>>>>
>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like
>>>>>>>>>>>>> exposing
>>>>>>>>>>>>> a new JVM function this way.
>>>>>>>>>>
>>>>>>>>>> I tried to call Thread#setName() after initializing VM (before
>>>>>>>>>> calling
>>>>>>>>>> main method),
>>>>>>>>>> I could set native thread name.
>>>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't
>>>>>>>>>> set
>>>>>>>>>> native thread name for DestroyJavaVM.
>>>>>>>>>
>>>>>>>>> Right - I came to the same realization earlier this morning. Which,
>>>>>>>>> unfortunately, takes me back to the basic premise here that we
>>>>>>>>> don't
>>>>>>>>> set the name of threads not created by the JVM. The fact that the
>>>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems
>>>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by
>>>>>>>>> accident for the initial attach, and can't be used for the
>>>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently
>>>>>>>>> named at
>>>>>>>>> the native level.
>>>>>>>>>
>>>>>>>>> I'm afraid my view here is that the launcher has to be treated like
>>>>>>>>> any other process that might host a JVM. If it wants to name its
>>>>>>>>> native threads then it is free to do so, but I would not be
>>>>>>>>> exporting
>>>>>>>>> a function from the JVM to do that - it would have to use the OS
>>>>>>>>> specific API's for that on a platform-by-platform basis.
>>>>>>>>>
>>>>>>>>> Sorry.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Yasumasa
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Comments:
>>>>>>>>>>>
>>>>>>>>>>> jvm.h: The function names are too similar but perform different
>>>>>>>>>>> functions:
>>>>>>>>>>>
>>>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName
>>>>>>>>>>>
>>>>>>>>>>> - The first function applies to the current thread, the second
>>>>>>>>>>> one a
>>>>>>>>>>> specific java thread.
>>>>>>>>>>> It would seem useful for there to be a comment somewhere about
>>>>>>>>>>> what
>>>>>>>>>>> the new function does.
>>>>>>>>>>>
>>>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*)
>>>>>>>>>>> instead of
>>>>>>>>>>> (SetNativeThreadName0_t)
>>>>>>>>>>> as is done on unix and mac.
>>>>>>>>>>>
>>>>>>>>>>> - macosx/native/libjli/java_md_macosx.c:
>>>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at
>>>>>>>>>>> line 730
>>>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the
>>>>>>>>>>> same
>>>>>>>>>>> line as dlsym...
>>>>>>>>>>>
>>>>>>>>>>> $.02, Roger
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>> That is an interesting question which I haven't had time to
>>>>>>>>>>>>> check -
>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread
>>>>>>>>>>>>> then
>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should
>>>>>>>>>>>>> work
>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of
>>>>>>>>>>>>> JNI-attached threads :( )
>>>>>>>>>>>>
>>>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native
>>>>>>>>>>>> thread name (test) was set.
>>>>>>>>>>>> ---------
>>>>>>>>>>>> public class Sleep{
>>>>>>>>>>>> public static void main(String[] args) throws Exception{
>>>>>>>>>>>> Thread.currentThread().setName("test");
>>>>>>>>>>>> Thread.sleep(3600000);
>>>>>>>>>>>> }
>>>>>>>>>>>> }
>>>>>>>>>>>> ---------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like
>>>>>>>>>>>>> exposing
>>>>>>>>>>>>> a new JVM function this way.
>>>>>>>>>>>>
>>>>>>>>>>>> I will update webrev after hearing Kumar's comment.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote:
>>>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for your comment.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I exported new JVM function to set native thread name,
>>>>>>>>>>>>>>>> and JLI
>>>>>>>>>>>>>>>> uses it
>>>>>>>>>>>>>>>> in new webrev.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First the launcher belongs to another team so core-libs will
>>>>>>>>>>>>>>> need to
>>>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>> I'm waiting to review :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName
>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes
>>>>>>>>>>>>>>> needed in
>>>>>>>>>>>>>>> that case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in
>>>>>>>>>>>>>> Thread#init(),
>>>>>>>>>>>>>> but I could not change native thread name.
>>>>>>>>>>>>>
>>>>>>>>>>>>> At Thread.init time the thread is not alive, which is why the
>>>>>>>>>>>>> native
>>>>>>>>>>>>> name is not set.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I guess that caller of main() is JNI attached thread.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is an interesting question which I haven't had time to
>>>>>>>>>>>>> check -
>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread
>>>>>>>>>>>>> then
>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should
>>>>>>>>>>>>> work
>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of
>>>>>>>>>>>>> JNI-attached threads :( )
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like
>>>>>>>>>>>>> exposing
>>>>>>>>>>>>> a new JVM function this way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus I think that we have to provide a function to set native
>>>>>>>>>>>>>> thread name.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could you review again?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - hotspot:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - jdk:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote:
>>>>>>>>>>>>>>>>> I'll answer on this original thread as well ...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Yasumasa,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on
>>>>>>>>>>>>>>>>> vacation).
>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not
>>>>>>>>>>>>>>>>> set the
>>>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the
>>>>>>>>>>>>>>>>> "main"
>>>>>>>>>>>>>>>>> thread.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>> Thanks Robbin,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" <robbin.ehn at oracle.com>:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Robbin
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks, looks good.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Robbin
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I uploaded new webrev.
>>>>>>>>>>>>>>>>>>>>> Could you review it?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Robbin,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" <robbin.ehn at oracle.com
>>>>>>>>>>>>>>>>>>>>>>> <mailto:robbin.ehn at oracle.com>>:
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa,
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin,
>>>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn"
>>>>>>>>>>>>>>>>>>>>>>> <robbin.ehn at oracle.com
>>>>>>>>>>>>>>>>>>>>>>> <mailto:robbin.ehn at oracle.com>
>>>>>>>>>>>>>>>>>>>>>>> >> <mailto:robbin.ehn at oracle.com
>>>>>>>>>>>>>>>>>>>>>>> <mailto:robbin.ehn at oracle.com>>>:
>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa,
>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it:
>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770
>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu
>>>>>>>>>>>>>>>>>>>>>>> Mar 24
>>>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016
>>>>>>>>>>>>>>>>>>>>>>> +0000
>>>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu
>>>>>>>>>>>>>>>>>>>>>>> Mar 24
>>>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016
>>>>>>>>>>>>>>>>>>>>>>> +0100
>>>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@
>>>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new
>>>>>>>>>>>>>>>>>>>>>>> JavaThread();
>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm);
>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current();
>>>>>>>>>>>>>>>>>>>>>>> >> > +
>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_native_thread_name("main");
>>>>>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles
>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size();
>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block());
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something?
>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in
>>>>>>>>>>>>>>>>>>>>>>> Thread
>>>>>>>>>>>>>>>>>>>>>>> class.
>>>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName().
>>>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native
>>>>>>>>>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>>>>>> set at
>>>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte
>>>>>>>>>>>>>>>>>>>>>>> in VM.
>>>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in
>>>>>>>>>>>>>>>>>>>>>>> create_initial_thread().
>>>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name
>>>>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>> be the
>>>>>>>>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like
>>>>>>>>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>>>>>>>> nicer, no?
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue
>>>>>>>>>>>>>>>>>>>>>>> Mar 29
>>>>>>>>>>>>>>>>>>>>>>> 09:43:05
>>>>>>>>>>>>>>>>>>>>>>> 2016
>>>>>>>>>>>>>>>>>>>>>>> +0200
>>>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed
>>>>>>>>>>>>>>>>>>>>>>> Mar 30
>>>>>>>>>>>>>>>>>>>>>>> 10:51:12
>>>>>>>>>>>>>>>>>>>>>>> 2016
>>>>>>>>>>>>>>>>>>>>>>> +0200
>>>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@
>>>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread
>>>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle
>>>>>>>>>>>>>>>>>>>>>>> thread_group,
>>>>>>>>>>>>>>>>>>>>>>> JavaThread*
>>>>>>>>>>>>>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>>>>>>>> > TRAPS) {
>>>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name =
>>>>>>>>>>>>>>>>>>>>>>> "main";
>>>>>>>>>>>>>>>>>>>>>>> > Klass* k =
>>>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(),
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> true,
>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL);
>>>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k);
>>>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop =
>>>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL);
>>>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@
>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(),
>>>>>>>>>>>>>>>>>>>>>>> thread);
>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(),
>>>>>>>>>>>>>>>>>>>>>>> NormPriority);
>>>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop());
>>>>>>>>>>>>>>>>>>>>>>> > -
>>>>>>>>>>>>>>>>>>>>>>> > - Handle string =
>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main",
>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL);
>>>>>>>>>>>>>>>>>>>>>>> > +
>>>>>>>>>>>>>>>>>>>>>>> > +
>>>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name);
>>>>>>>>>>>>>>>>>>>>>>> > +
>>>>>>>>>>>>>>>>>>>>>>> > + Handle string =
>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL);
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID);
>>>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and
>>>>>>>>>>>>>>>>>>>>>>> naming
>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me.
>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> process) is
>>>>>>>>>>>>>>>>>>>>>>> 'java' but
>>>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'.
>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not
>>>>>>>>>>>>>>>>>>>>>>> JavaThread.
>>>>>>>>>>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>>>>>>>>>>> waiting
>>>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with
>>>>>>>>>>>>>>>>>>>>>>> pthread_join().
>>>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I
>>>>>>>>>>>>>>>>>>>>>>> think that
>>>>>>>>>>>>>>>>>>>>>>> we do
>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread.
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we
>>>>>>>>>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>>>>>>>>> java and
>>>>>>>>>>>>>>>>>>>>>>> native
>>>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have
>>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>> dependents.
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc.
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4
>>>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND
>>>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java
>>>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main
>>>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main
>>>>>>>>>>>>>>>>>>>>>>> Thread'.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I do not think so.
>>>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher -
>>>>>>>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>>>>>>> Apache
>>>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I
>>>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>>>> that we
>>>>>>>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>>>>>>>> change Java launcher code.
>>>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks again!
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Robbin
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> > Thanks
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> > /Robbin
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>> >> Thanks,
>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>> >> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>> >> > Thanks!
>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>> >> > /Robbin
>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> >> > > Hi all,
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via
>>>>>>>>>>>>>>>>>>>>>>> pthread_setname_np().
>>>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it.
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main
>>>>>>>>>>>>>>>>>>>>>>> thread is
>>>>>>>>>>>>>>>>>>>>>>> JavaThread.
>>>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have
>>>>>>>>>>>>>>>>>>>>>>> native
>>>>>>>>>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>>>>>>> name.
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it?
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT.
>>>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor.
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >> > > Thanks,
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa
>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
More information about the core-libs-dev
mailing list