From ioi.lam at oracle.com Tue May 8 00:29:01 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 7 May 2018 17:29:01 -0700 Subject: ResolvedMethodName::vmholder unused? Message-ID: I don't see anywhere in HotSpot that uses java_lang_invoke_ResolvedMethodName::_vmholder_offset, which is declared here: http://hg.openjdk.java.net/jdk/jdk/file/7444101401b2/src/hotspot/share/classfile/javaClasses.hpp#l1057 http://hg.openjdk.java.net/jdk/jdk/file/9608f7f41c4e/src/java.base/share/classes/java/lang/invoke/MemberName.java#l75 I tried commenting out the initialization of this field and was able to run a simple Lambda test. diff -r 9255cb73f048 src/hotspot/share/classfile/javaClasses.cpp --- a/src/hotspot/share/classfile/javaClasses.cpp??? Mon May 07 15:29:31 2018 -0700 +++ b/src/hotspot/share/classfile/javaClasses.cpp??? Mon May 07 17:27:27 2018 -0700 @@ -3808,7 +3808,7 @@ ???? // Add a reference to the loader (actually mirror because anonymous classes will not have ???? // distinct loaders) to ensure the metadata is kept alive. ???? // This mirror may be different than the one in clazz field. -??? new_resolved_method->obj_field_put(_vmholder_offset, m->method_holder()->java_mirror()); +??? //new_resolved_method->obj_field_put(_vmholder_offset, m->method_holder()->java_mirror()); ???? resolved_method = ResolvedMethodTable::add_method(Handle(THREAD, new_resolved_method)); ?? } Any plans to use vmholder in the future? Or, is this used by any non-HotSpot VM? If no one uses it, I'll file an RFE to remove it, so we can save a pointer per MemberName. Thanks - Ioi From vladimir.x.ivanov at oracle.com Tue May 8 00:45:39 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 May 2018 17:45:39 -0700 Subject: ResolvedMethodName::vmholder unused? In-Reply-To: References: Message-ID: <14655796-b874-606a-add4-5a93d52ccae6@oracle.com> Ioi, Though the field is never accessed directly, ResolvedMethodName::vmholder is still tracked by GC and keeps the metadata it accompanies (RMN::vmtarget) alive until RMN is reachable. Best regards, Vladimir Ivanov On 5/7/18 17:29, Ioi Lam wrote: > I don't see anywhere in HotSpot that uses > java_lang_invoke_ResolvedMethodName::_vmholder_offset, which is declared > here: > > http://hg.openjdk.java.net/jdk/jdk/file/7444101401b2/src/hotspot/share/classfile/javaClasses.hpp#l1057 > > http://hg.openjdk.java.net/jdk/jdk/file/9608f7f41c4e/src/java.base/share/classes/java/lang/invoke/MemberName.java#l75 > > > I tried commenting out the initialization of this field and was able to > run a simple Lambda test. > > diff -r 9255cb73f048 src/hotspot/share/classfile/javaClasses.cpp > --- a/src/hotspot/share/classfile/javaClasses.cpp??? Mon May 07 15:29:31 > 2018 -0700 > +++ b/src/hotspot/share/classfile/javaClasses.cpp??? Mon May 07 17:27:27 > 2018 -0700 > @@ -3808,7 +3808,7 @@ > ???? // Add a reference to the loader (actually mirror because > anonymous classes will not have > ???? // distinct loaders) to ensure the metadata is kept alive. > ???? // This mirror may be different than the one in clazz field. > -??? new_resolved_method->obj_field_put(_vmholder_offset, > m->method_holder()->java_mirror()); > +??? //new_resolved_method->obj_field_put(_vmholder_offset, > m->method_holder()->java_mirror()); > ???? resolved_method = ResolvedMethodTable::add_method(Handle(THREAD, > new_resolved_method)); > ?? } > > > Any plans to use vmholder in the future? Or, is this used by any > non-HotSpot VM? > > If no one uses it, I'll file an RFE to remove it, so we can save a > pointer per MemberName. > > Thanks > - Ioi > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From ioi.lam at oracle.com Tue May 8 01:55:11 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 7 May 2018 18:55:11 -0700 Subject: ResolvedMethodName::vmholder unused? In-Reply-To: <14655796-b874-606a-add4-5a93d52ccae6@oracle.com> References: <14655796-b874-606a-add4-5a93d52ccae6@oracle.com> Message-ID: <4b981eb0-ea78-8e60-76e1-a5160a312330@oracle.com> Hi Vladimir, Where does the GC tracks the vmholder? I did a grep of 'vmholder' in all the source code and I can't find anything. Thanks - Ioi On 5/7/18 5:45 PM, Vladimir Ivanov wrote: > Ioi, > > Though the field is never accessed directly, > ResolvedMethodName::vmholder is still tracked by GC and keeps the > metadata it accompanies (RMN::vmtarget) alive until RMN is reachable. > > Best regards, > Vladimir Ivanov > > On 5/7/18 17:29, Ioi Lam wrote: >> I don't see anywhere in HotSpot that uses >> java_lang_invoke_ResolvedMethodName::_vmholder_offset, which is >> declared here: >> >> http://hg.openjdk.java.net/jdk/jdk/file/7444101401b2/src/hotspot/share/classfile/javaClasses.hpp#l1057 >> >> http://hg.openjdk.java.net/jdk/jdk/file/9608f7f41c4e/src/java.base/share/classes/java/lang/invoke/MemberName.java#l75 >> >> >> I tried commenting out the initialization of this field and was able >> to run a simple Lambda test. >> >> diff -r 9255cb73f048 src/hotspot/share/classfile/javaClasses.cpp >> --- a/src/hotspot/share/classfile/javaClasses.cpp??? Mon May 07 >> 15:29:31 2018 -0700 >> +++ b/src/hotspot/share/classfile/javaClasses.cpp??? Mon May 07 >> 17:27:27 2018 -0700 >> @@ -3808,7 +3808,7 @@ >> ????? // Add a reference to the loader (actually mirror because >> anonymous classes will not have >> ????? // distinct loaders) to ensure the metadata is kept alive. >> ????? // This mirror may be different than the one in clazz field. >> -??? new_resolved_method->obj_field_put(_vmholder_offset, >> m->method_holder()->java_mirror()); >> +??? //new_resolved_method->obj_field_put(_vmholder_offset, >> m->method_holder()->java_mirror()); >> ????? resolved_method = >> ResolvedMethodTable::add_method(Handle(THREAD, new_resolved_method)); >> ??? } >> >> >> Any plans to use vmholder in the future? Or, is this used by any >> non-HotSpot VM? >> >> If no one uses it, I'll file an RFE to remove it, so we can save a >> pointer per MemberName. >> >> Thanks >> - Ioi >> >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.x.ivanov at oracle.com Tue May 8 02:13:40 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 May 2018 19:13:40 -0700 Subject: ResolvedMethodName::vmholder unused? In-Reply-To: <4b981eb0-ea78-8e60-76e1-a5160a312330@oracle.com> References: <14655796-b874-606a-add4-5a93d52ccae6@oracle.com> <4b981eb0-ea78-8e60-76e1-a5160a312330@oracle.com> Message-ID: > Where does the GC tracks the vmholder? I did a grep of 'vmholder' in all > the source code and I can't find anything. There's a notion of injected fields in HotSpot which aren't present in class declaration, but present in the class at runtime (for details see JavaClasses::get_injected() called from ClassFileParser::parse_fields()). vmholder is an object field injected into ResolvedMethodName class. It's an ordinary object field, so there's no additional GC support needed to support it. Best regards, Vladimir Ivanov > > Thanks > > - Ioi > > > On 5/7/18 5:45 PM, Vladimir Ivanov wrote: >> Ioi, >> >> Though the field is never accessed directly, >> ResolvedMethodName::vmholder is still tracked by GC and keeps the >> metadata it accompanies (RMN::vmtarget) alive until RMN is reachable. >> >> Best regards, >> Vladimir Ivanov >> >> On 5/7/18 17:29, Ioi Lam wrote: >>> I don't see anywhere in HotSpot that uses >>> java_lang_invoke_ResolvedMethodName::_vmholder_offset, which is >>> declared here: >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/7444101401b2/src/hotspot/share/classfile/javaClasses.hpp#l1057 >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/9608f7f41c4e/src/java.base/share/classes/java/lang/invoke/MemberName.java#l75 >>> >>> >>> I tried commenting out the initialization of this field and was able >>> to run a simple Lambda test. >>> >>> diff -r 9255cb73f048 src/hotspot/share/classfile/javaClasses.cpp >>> --- a/src/hotspot/share/classfile/javaClasses.cpp??? Mon May 07 >>> 15:29:31 2018 -0700 >>> +++ b/src/hotspot/share/classfile/javaClasses.cpp??? Mon May 07 >>> 17:27:27 2018 -0700 >>> @@ -3808,7 +3808,7 @@ >>> ????? // Add a reference to the loader (actually mirror because >>> anonymous classes will not have >>> ????? // distinct loaders) to ensure the metadata is kept alive. >>> ????? // This mirror may be different than the one in clazz field. >>> -??? new_resolved_method->obj_field_put(_vmholder_offset, >>> m->method_holder()->java_mirror()); >>> +??? //new_resolved_method->obj_field_put(_vmholder_offset, >>> m->method_holder()->java_mirror()); >>> ????? resolved_method = >>> ResolvedMethodTable::add_method(Handle(THREAD, new_resolved_method)); >>> ??? } >>> >>> >>> Any plans to use vmholder in the future? Or, is this used by any >>> non-HotSpot VM? >>> >>> If no one uses it, I'll file an RFE to remove it, so we can save a >>> pointer per MemberName. >>> >>> Thanks >>> - Ioi >>> >>> >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From daniel.smith at oracle.com Mon May 21 15:18:05 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 21 May 2018 09:18:05 -0600 Subject: General Registration -- 2018 JVM Language Summit Message-ID: <5A1E3A3C-16C7-4BFB-8026-C9B827FEECAF@oracle.com> GENERAL REGISTRATION -- JVM LANGUAGE SUMMIT, JULY 2018 General registration for the 2018 JVM Language Summit is now open. The event will be held at Oracle's Santa Clara campus on July 30-31, 2018. Speaker registration remains open through May 25. If you have an interesting topic to speak about, please submit an abstract! Many JVM Language Summit speakers and attendees are also deeply involved in the OpenJDK Community, where they do much of their technical work in their roles as OpenJDK Committers. This year, as an experiment, we're going to host the first OpenJDK Committers' Workshop right after the JVM Language Summit. To fit everything into the week, and allow time for travel, there will be two (rather than the usual three) days of the JVM Language Summit followed immediately by two days of the OpenJDK Committers' Workshop, at the same location. In short, OpenJDK Committers in attendance can look forward to four days of intense, inspiring collaboration around the JVM this year. Overview The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. The summit will be immediately followed by the OpenJDK Committers' Workshop, August 1-2. This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations interspersed with less-formal multitrack "workshop" discussion groups and, possibly, impromptu "lightning talks." Workshops are open discussions with only a small amount of prepared material. We ask each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2018 at jvmlangsummit.com