Re: ResolvedMethodName::vmholder unused?

2018-05-07 Thread Vladimir Ivanov


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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Re: ResolvedMethodName::vmholder unused?

2018-05-07 Thread Ioi Lam

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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Re: ResolvedMethodName::vmholder unused?

2018-05-07 Thread Vladimir Ivanov

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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


ResolvedMethodName::vmholder unused?

2018-05-07 Thread Ioi Lam
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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev