hg: jdk8/tl/jdk: 8009558: linked_md.c::dll_build_name can get stuck in an infinite loop
Changeset: f1b89d4cce82 Author:sla Date: 2013-04-02 10:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1b89d4cce82 8009558: linked_md.c::dll_build_name can get stuck in an infinite loop Reviewed-by: alanb, sspitsyn ! src/share/back/export/sys.h ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof_md.h ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c
hg: hsx/hotspot-rt/hotspot: 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM
Changeset: e458120c6e1a Author:sla Date: 2013-03-28 15:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e458120c6e1a 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM Reviewed-by: sspitsyn, zgu Contributed-by: peter.all...@oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java
Re: RFR(XXS): 8008391: Incorrect metadata for event based tracing
Seems reasonable. StefanK On 03/25/2013 10:17 PM, Erik Gahlin wrote: Hi, Could you please review these small metadata changes for the event tracing framework: - Promotion Failed - objectCount has the datatype BYTES64, which implies that it is a size. It is not, and the type should be an unsigned long. - Thread Park, Java Monitor Enter and Java Monitor wait should have relational ids, so it's possible to see that the information is related (java/monitor/address) - The field caller in ExecuteVMOperation should not have a TO field but a FROM field, indicating from which thread the transition came from. The reason the review for 8007150 is handled seperately is because it modifies the structure of the data, while these changes are strictly cosmetical. http://cr.openjdk.java.net/~egahlin/8008391_1/ Thanks Erik
Re: RFR(XXS): 8007150 Event based tracing is missing truncated field in stack trace content type
Looks good. StefanK On 03/25/2013 09:13 PM, Erik Gahlin wrote: Hi, Could you please review this small change to the metadata for StackTrace content type, used by the event tracing framework. A boolean flag has been added so it's possible to see if a stack trace has been truncated (not all frames included). http://cr.openjdk.java.net/~egahlin/8007150_1/ The fix is targeted for hs24. Thanks Erik
hg: jdk8/tl/nashorn: 2 new changesets
Changeset: 3e4369fb810b
Author:hannesw
Date: 2013-04-02 13:55 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3e4369fb810b
8011219: Regression with recent PropertyMap history changes
Reviewed-by: jlaskey, lagergren
! src/jdk/nashorn/internal/runtime/PropertyMap.java
Changeset: 5362d96d5915
Author:sundar
Date: 2013-04-02 17:40 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5362d96d5915
8011209: Object.getOwnPropertyDescriptor(function(){use
strict},caller).get.length is not 0
Reviewed-by: lagergren, hannesw, jlaskey
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
+ test/script/basic/JDK-8011209.js
Re: hs25 review request: 8008511 JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition
On 4/1/13 3:51 PM, Coleen Phillimore wrote: On 04/01/2013 06:02 PM, serguei.spit...@oracle.com wrote: On 4/1/13 1:09 PM, Coleen Phillimore wrote: Hi Serguei, Sorry for the delay in reviewing this. In instanceKlass.cpp line 2730, can you make that mtClass since it's part of class metadata? Fixed. Thank you for the catch! In methodHandles.cpp, I think the whole member name table mechanism could be protected by #if INCLUDE_JVMTI since it's not needed unless you have jvmti built in the vm. And you don't need to call add_method_handle() or just have it do JVMTI_RETURN or something for the minimal vm. My understanding was that John is considering to use the MemberNameTable in the future for the compilation purposes. However, I can temporarily place it under #if INCLUDE_JVMTI until the compiler team decides what to do with it. Also, I think you should consider a global table rather than one per class. I think we discussed this and may have decided that speed of adding these is important, but depending on how many are actually used per class, there's one pointer per class. I thought we've reached a consensus and decided to add MNT pointer per class as it is performance sensitive for indy calls. Anyway, before changing it to a hashtable I'd want to hear from John and Christian first. Definitely would like to hear from John and Christian. We did discuss it but I wasn't totally convinced this field is more important than the others that were going to be moved out of Klass* to make it smaller. Some statistics for some sample applications like eclipse would be great. I'm not sure what statistics do you mean here. Do you mean a footprint or performance statistics? As I understand from our previous discussion there can be a more general solution for the footprint issue. As such we could attack the footprint problem separately. For instance, we could separate all JVMTI fields from InstanceKlass and initialize them lazily. But I'd not want to go deep into this discussion. You do not want me to get involved into the footprint work, do you? :) Also, the decision how to represent the MNT depends on its future usage by the compiler team. As we agreed, the compiler team is going to adjust the MNT to their needs at some point when it is more convenient for them. So that, could we make a final decision when the whole picture is ready? It would be better to approach it in some steps. Currently, this bug blocks other work on the JVMTI support of jsr-292. Thanks, Serguei Coleen Maybe they could be organized as a hashtable instead like the method handle intrinsics? The code itself looks good everywhere, except for the concern about footprint. I very appreciate you found a time to review it! There are not many people having an expertize in this area. Thanks, Serguei Thanks, Coleen Can you make this mtClass on line On 03/26/2013 04:37 AM, serguei.spit...@oracle.com wrote: Please, review the following fix. The fix was preliminarily reviewed by Coleen, Christian and John but still a final and open jdk review is needed. So that, everyone is welcome to review the fix! This is open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8008511-JVMTI-JSR292.1/ The CR is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008511 https://jbs.oracle.com/bugs/browse/JDK-8008511 The problem is that the old version of the bootstrap method is re-invoked after a popframe from the bootstrap method execution. It is because the MemberName keeps a stale reference to the old method version. The solution (suggested by John Rose) is to lazily create and keep up-to-date a MemberNameTable which plays a role of MemberName cache assosiated with the InstanceKlass. Then, at the Class redefinition, this cache is used to replace the old method references in the MemberName's with the new method references. The MemberNameTable is based on the GrowableArrayjweek. A C_HEAP array is allocated at the first call to InstanceKlass::add_member_name(). It is released in the InstanceKlass::release_C_heap_structures(). A global week reference to member name oop is stored in the MemberNameTable. It allowed to avoid having the oops_do() in the MemberNameTable. Also, the MemberNameTable won't hold member name oops in memory. The MemberNameTable_lock mutex is added to serialize MemberNameTable's updates. The following No_Safepoint_Verifier has been disabled: * src/share/vm/prims/methodHandles.cpp*: 799 int MethodHandles::find_MemberNames(Klass* k, . . . 803 DEBUG_ONLY(No_Safepoint_Verifier nsv); It is probably Ok, but, please, let me know if it is not. The assert related to locking is fired if it is not disabled. Test coverage: vm.mlvm, nsk.jvmti, nsk.jdi tests on multiple platforms (32 vs 64-bit too). The testing looks good so far. Thanks, Serguei
hg: jdk8/tl/jdk: 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding; ...
Changeset: e6c3b8e74e50 Author:sherman Date: 2013-04-02 10:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6c3b8e74e50 8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding 8008925: Base64.getMimeDecoder().decode() does not ignore padding chars Summary: updated implementation and spec for corner cases. Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java
hg: hsx/hotspot-rt/hotspot: 2 new changesets
Changeset: 8c03fc47511d Author:iklam Date: 2013-04-01 14:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8c03fc47511d 8011048: Possible reading from unmapped memory in UTF8::as_quoted_ascii() Summary: Pass utf_length parameter to UTF8::as_quoted_ascii() Reviewed-by: dcubed, minqi ! src/share/vm/oops/symbol.cpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp Changeset: a4e8dac9db8c Author:zgu Date: 2013-04-02 07:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a4e8dac9db8c Merge
hg: jdk8/tl/corba: 4 new changesets
Changeset: a45bb25a67c7 Author:katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a45bb25a67c7 Added tag jdk8-b82 for changeset 48e1bc77004d ! .hgtags Changeset: 14f1babaf548 Author:katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/14f1babaf548 Added tag jdk8-b83 for changeset a45bb25a67c7 ! .hgtags Changeset: 7d7a009d5fbd Author:lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7d7a009d5fbd Merge Changeset: 928f8b888deb Author:lana Date: 2013-04-01 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/928f8b888deb Merge
hg: jdk8/tl/langtools: 5 new changesets
Changeset: 22ba3f92d4ae Author:katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/22ba3f92d4ae Added tag jdk8-b82 for changeset 825da6847791 ! .hgtags Changeset: 35cef52b0023 Author:katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/35cef52b0023 Added tag jdk8-b83 for changeset 22ba3f92d4ae ! .hgtags Changeset: 28e466e9cd34 Author:lana Date: 2013-03-26 12:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/28e466e9cd34 Merge - src/share/classes/com/sun/tools/javac/Server.java - src/share/classes/com/sun/tools/jdeps/resources/jdk.properties - src/share/classes/javax/lang/model/type/AnnotatedType.java - test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java Changeset: cfb65ca92082 Author:lana Date: 2013-04-01 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cfb65ca92082 Merge - src/share/classes/com/sun/tools/javac/Server.java - src/share/classes/com/sun/tools/jdeps/resources/jdk.properties - src/share/classes/javax/lang/model/type/AnnotatedType.java - test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java Changeset: 46d2f144ebbd Author:lana Date: 2013-04-02 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/46d2f144ebbd Merge
hg: jdk8/tl/hotspot: 53 new changesets
Changeset: 4f7380dca47e Author:katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f7380dca47e Added tag jdk8-b82 for changeset 3db4ab0e12f4 ! .hgtags Changeset: 7ae04e71af90 Author:amurillo Date: 2013-03-15 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ae04e71af90 8010105: new hotspot build - hs25-b24 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 39432a1cefdd Author:minqi Date: 2013-03-14 00:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39432a1cefdd 8003348: SA can not read core file on OS Summary: Macosx uses Mach-O file format for binary files, not ELF format. Currently SA works on core files on other platforms, t his change enables SA work on core file generated on Darwin. Reviewed-by: sla, sspitsyn Contributed-by: yumin...@oracle.com ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/libproc.h ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_core.c ! agent/src/os/bsd/symtab.c ! agent/src/os/bsd/symtab.h ! agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! agent/src/share/native/sadis.c ! make/bsd/makefiles/saproc.make Changeset: 1fc4d4768b90 Author:coleenp Date: 2013-03-15 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1fc4d4768b90 8007725: NPG: Klass::restore_unshareable_info() triggers assert(k-java_mirror() == NULL) Summary: Check for exception during SystemDictionary::resolve_instance_class_or_null() and clean up. Reviewed-by: coleenp, acorn, hseigel, minqi Contributed-by: ioi@oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp Changeset: 82f49e8e2c28 Author:zgu Date: 2013-03-15 11:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/82f49e8e2c28 8009614: nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() Summary: Align up vm allocation size to os defined granularity Reviewed-by: dholmes, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: 919a5f9f36a9 Author:zgu Date: 2013-03-15 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/919a5f9f36a9 Merge Changeset: 82ab039b9680 Author:dcubed Date: 2013-03-17 08:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/82ab039b9680 Merge ! src/share/vm/memory/metaspace.cpp Changeset: 117bb0519114 Author:sla Date: 2013-03-19 13:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/117bb0519114 8009456: SA: typeToVtbl of BasicTypeDataBase should not be static Reviewed-by: coleenp, sla Contributed-by: yunda@taobao.com ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java Changeset: 686916dc0439 Author:sla Date: 2013-03-19 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/686916dc0439 8009457: SA: A small fix on scanoops command in CLHSDB Reviewed-by: sla, coleenp, kmo Contributed-by: yunda@taobao.com ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java Changeset: 9960dce2024f Author:kmo Date: 2013-03-14 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9960dce2024f 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 Summary: add cases for _MSC_VER == 1600 and 1700 Reviewed-by: zgu ! src/share/vm/runtime/vm_version.cpp Changeset: a40807924950 Author:kmo Date: 2013-03-14 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a40807924950 Merge Changeset: f3d486462d36 Author:morris Date: 2013-03-15 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3d486462d36 Merge Changeset: 96ef09c26978 Author:morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/96ef09c26978 8009166: [parfait] Null pointer deference in hotspot/src/share/vm/opto/type.cpp Summary: add guarantee() to as_instance_type() Reviewed-by: kvn, twisti ! src/share/vm/opto/type.cpp Changeset: 8b4ce9870fd6 Author:morris Date: 2013-03-16 07:39 -0700 URL:
hg: jdk8/tl/jdk: 18 new changesets
Changeset: 624bcb480006 Author:omajid Date: 2013-03-18 10:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/624bcb480006 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! makefiles/CompileNativeLibraries.gmk Changeset: cdcd4512c6f1 Author:katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdcd4512c6f1 Added tag jdk8-b82 for changeset 624bcb480006 ! .hgtags Changeset: 6782f2c46bca Author:wetmore Date: 2013-03-21 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6782f2c46bca 8009517: new code changes causing errors in old build (-Werror) environment Reviewed-by: mduigou ! make/com/sun/org/apache/xml/Makefile ! make/javax/others/Makefile Changeset: ac519af51769 Author:dcherepanov Date: 2013-03-27 08:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac519af51769 Merge Changeset: 8cc500af2454 Author:katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cc500af2454 Added tag jdk8-b83 for changeset ac519af51769 ! .hgtags Changeset: 07acfb90700b Author:malenkov Date: 2013-03-14 12:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07acfb90700b 8000183: 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK LFs Reviewed-by: alexsch, serb ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java + test/javax/swing/JScrollBar/7163696/Test7163696.java Changeset: d4e1c5803a59 Author:alexsch Date: 2013-03-15 17:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4e1c5803a59 8009221: [macosx] Two closed/javax/swing regression tests fail on MacOSX. Reviewed-by: serb, alexp + test/javax/swing/JMenu/4515762/bug4515762.java + test/javax/swing/JRootPane/4670486/bug4670486.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 2725b8a783e7 Author:lana Date: 2013-03-15 16:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2725b8a783e7 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - src/share/classes/sun/security/util/KeyLength.java - test/javax/script/RhinoExceptionTest.java Changeset: 4bf5a5a72664 Author:serb Date: 2013-03-18 22:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bf5a5a72664 8000435: [macosx] Button painting error under Java 7 on Mac Reviewed-by: denis, alexsch ! src/macosx/classes/com/apple/laf/AquaButtonBorder.java ! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java Changeset: af6049edac00 Author:kshefov Date: 2013-03-19 17:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af6049edac00 8009881: TEST_BUG: javax/swing/JTree/8004298/bug8004298.java should be modified Reviewed-by: serb, alexsch ! test/javax/swing/JTree/8004298/bug8004298.java Changeset: 4e15c3e56315 Author:kshefov Date: 2013-03-20 14:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e15c3e56315 8009880: TEST_BUG: Test java/beans/Introspector/TestTypeResolver.java should be modified again Reviewed-by: malenkov, alexsch ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 87001c7bb678 Author:alitvinov Date: 2013-03-20 20:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87001c7bb678 6550588: java.awt.Desktop cannot open file with Windows UNC filename Reviewed-by: art, uta ! src/windows/classes/sun/awt/windows/WDesktopPeer.java ! src/windows/native/sun/windows/awt_Desktop.cpp + test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java Changeset: ef948ef2b58f Author:alexsch Date: 2013-03-21 16:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef948ef2b58f 8007146: [macosx] Setting a display mode crashes JDK under VNC Reviewed-by: serb !
Re: hs25 review request: 8008511 JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition
On 04/02/2013 01:02 PM, serguei.spit...@oracle.com wrote: On 4/1/13 3:51 PM, Coleen Phillimore wrote: On 04/01/2013 06:02 PM, serguei.spit...@oracle.com wrote: On 4/1/13 1:09 PM, Coleen Phillimore wrote: Hi Serguei, Sorry for the delay in reviewing this. In instanceKlass.cpp line 2730, can you make that mtClass since it's part of class metadata? Fixed. Thank you for the catch! In methodHandles.cpp, I think the whole member name table mechanism could be protected by #if INCLUDE_JVMTI since it's not needed unless you have jvmti built in the vm. And you don't need to call add_method_handle() or just have it do JVMTI_RETURN or something for the minimal vm. My understanding was that John is considering to use the MemberNameTable in the future for the compilation purposes. However, I can temporarily place it under #if INCLUDE_JVMTI until the compiler team decides what to do with it. Also, I think you should consider a global table rather than one per class. I think we discussed this and may have decided that speed of adding these is important, but depending on how many are actually used per class, there's one pointer per class. I thought we've reached a consensus and decided to add MNT pointer per class as it is performance sensitive for indy calls. Anyway, before changing it to a hashtable I'd want to hear from John and Christian first. Definitely would like to hear from John and Christian. We did discuss it but I wasn't totally convinced this field is more important than the others that were going to be moved out of Klass* to make it smaller. Some statistics for some sample applications like eclipse would be great. I'm not sure what statistics do you mean here. Do you mean a footprint or performance statistics? As I understand from our previous discussion there can be a more general solution for the footprint issue. As such we could attack the footprint problem separately. Yes, there are more general solutions to the footprint issue. One would be moving these JVMTI fields and initializing them lazily and there are other footprint improvements. One additional improvement would be to remove this field which will be mostly zero and put this in a hashtable and not allocate it per class. For instance, we could separate all JVMTI fields from InstanceKlass and initialize them lazily. But I'd not want to go deep into this discussion. You do not want me to get involved into the footprint work, do you? :) Also, the decision how to represent the MNT depends on its future usage by the compiler team. As we agreed, the compiler team is going to adjust the MNT to their needs at some point when it is more convenient for them. So that, could we make a final decision when the whole picture is ready? It would be better to approach it in some steps. Currently, this bug blocks other work on the JVMTI support of jsr-292. I don't know what the jsr 292 team has in store for this field but it's still a footprint cost that's for only a special case. So this is okay if you file a bug so that we can remove it and reimplement this table to be global or a hashtable. Coleen Thanks, Serguei Coleen Maybe they could be organized as a hashtable instead like the method handle intrinsics? The code itself looks good everywhere, except for the concern about footprint. I very appreciate you found a time to review it! There are not many people having an expertize in this area. Thanks, Serguei Thanks, Coleen Can you make this mtClass on line On 03/26/2013 04:37 AM, serguei.spit...@oracle.com wrote: Please, review the following fix. The fix was preliminarily reviewed by Coleen, Christian and John but still a final and open jdk review is needed. So that, everyone is welcome to review the fix! This is open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8008511-JVMTI-JSR292.1/ The CR is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008511 https://jbs.oracle.com/bugs/browse/JDK-8008511 The problem is that the old version of the bootstrap method is re-invoked after a popframe from the bootstrap method execution. It is because the MemberName keeps a stale reference to the old method version. The solution (suggested by John Rose) is to lazily create and keep up-to-date a MemberNameTable which plays a role of MemberName cache assosiated with the InstanceKlass. Then, at the Class redefinition, this cache is used to replace the old method references in the MemberName's with the new method references. The MemberNameTable is based on the GrowableArrayjweek. A C_HEAP array is allocated at the first call to InstanceKlass::add_member_name(). It is released in the InstanceKlass::release_C_heap_structures(). A global week reference to member name oop is stored in the MemberNameTable. It allowed to avoid having the oops_do() in the MemberNameTable. Also, the MemberNameTable won't hold member name oops in memory. The
Re: hs25 review request: 8008511 JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition
On 4/2/13 2:09 PM, Coleen Phillimore wrote: On 04/02/2013 01:02 PM, serguei.spit...@oracle.com wrote: On 4/1/13 3:51 PM, Coleen Phillimore wrote: On 04/01/2013 06:02 PM, serguei.spit...@oracle.com wrote: On 4/1/13 1:09 PM, Coleen Phillimore wrote: Hi Serguei, Sorry for the delay in reviewing this. In instanceKlass.cpp line 2730, can you make that mtClass since it's part of class metadata? Fixed. Thank you for the catch! In methodHandles.cpp, I think the whole member name table mechanism could be protected by #if INCLUDE_JVMTI since it's not needed unless you have jvmti built in the vm. And you don't need to call add_method_handle() or just have it do JVMTI_RETURN or something for the minimal vm. My understanding was that John is considering to use the MemberNameTable in the future for the compilation purposes. However, I can temporarily place it under #if INCLUDE_JVMTI until the compiler team decides what to do with it. Also, I think you should consider a global table rather than one per class. I think we discussed this and may have decided that speed of adding these is important, but depending on how many are actually used per class, there's one pointer per class. I thought we've reached a consensus and decided to add MNT pointer per class as it is performance sensitive for indy calls. Anyway, before changing it to a hashtable I'd want to hear from John and Christian first. Definitely would like to hear from John and Christian. We did discuss it but I wasn't totally convinced this field is more important than the others that were going to be moved out of Klass* to make it smaller. Some statistics for some sample applications like eclipse would be great. I'm not sure what statistics do you mean here. Do you mean a footprint or performance statistics? As I understand from our previous discussion there can be a more general solution for the footprint issue. As such we could attack the footprint problem separately. Yes, there are more general solutions to the footprint issue. One would be moving these JVMTI fields and initializing them lazily and there are other footprint improvements. One additional improvement would be to remove this field which will be mostly zero and put this in a hashtable and not allocate it per class. For instance, we could separate all JVMTI fields from InstanceKlass and initialize them lazily. But I'd not want to go deep into this discussion. You do not want me to get involved into the footprint work, do you? :) Also, the decision how to represent the MNT depends on its future usage by the compiler team. As we agreed, the compiler team is going to adjust the MNT to their needs at some point when it is more convenient for them. So that, could we make a final decision when the whole picture is ready? It would be better to approach it in some steps. Currently, this bug blocks other work on the JVMTI support of jsr-292. I don't know what the jsr 292 team has in store for this field but it's still a footprint cost that's for only a special case. So this is okay if you file a bug so that we can remove it and reimplement this table to be global or a hashtable. Ok, I'll file a bug on the footprint issue and attach it to the next round of review. Thanks, Coleen! Serguei Coleen Thanks, Serguei Coleen Maybe they could be organized as a hashtable instead like the method handle intrinsics? The code itself looks good everywhere, except for the concern about footprint. I very appreciate you found a time to review it! There are not many people having an expertize in this area. Thanks, Serguei Thanks, Coleen Can you make this mtClass on line On 03/26/2013 04:37 AM, serguei.spit...@oracle.com wrote: Please, review the following fix. The fix was preliminarily reviewed by Coleen, Christian and John but still a final and open jdk review is needed. So that, everyone is welcome to review the fix! This is open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8008511-JVMTI-JSR292.1/ The CR is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008511 https://jbs.oracle.com/bugs/browse/JDK-8008511 The problem is that the old version of the bootstrap method is re-invoked after a popframe from the bootstrap method execution. It is because the MemberName keeps a stale reference to the old method version. The solution (suggested by John Rose) is to lazily create and keep up-to-date a MemberNameTable which plays a role of MemberName cache assosiated with the InstanceKlass. Then, at the Class redefinition, this cache is used to replace the old method references in the MemberName's with the new method references. The MemberNameTable is based on the GrowableArrayjweek. A C_HEAP array is allocated at the first call to InstanceKlass::add_member_name(). It is released in the InstanceKlass::release_C_heap_structures(). A global week reference to member name oop is stored in the
hg: jdk8/tl: 8011342: hgforest.sh : 'python --version' not supported on older python
Changeset: 7320922b694e Author:mduigou Date: 2013-04-02 14:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7320922b694e 8011342: hgforest.sh : 'python --version' not supported on older python Reviewed-by: wetmore ! common/bin/hgforest.sh
Re: hs25 review request: 8007037 JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands
Hi Serguei, This looks good from how much I understand of these two things. There is one problem that I found though. In ConstantPool::extend_operands() and shrink_operands() when you allocate a new Arrayu2* and assign it to the from_cp, you have to explicitly deallocate the operands that were there with MetadataFactory::free_arrayu2() or they will leak. This isn't true if you backport this code to 7u. Thanks, Coleen On 03/27/2013 07:45 PM, serguei.spit...@oracle.com wrote: Please, review the hs25 fix below. Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8007037-JVMTI-JSR292.1/ CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007037 https://jbs.oracle.com/bugs/browse/JDK-8007037 References from INDY bootstrap method specifier operands to CP entries and back must be correctly merged at class redefinition. Some background. An invokedynamic bytecode spec: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.invokedynamic A invokedynamic instruction has an argument which is an index to the *Constant Pool* item. That index must be a symbolic reference to a *call-site specifier*: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4.10 A CP item of the type *CONSTANT_InvokeDynamic_inf* has an index into the *bootstrap method attribute* of the class file: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.21 The *|BootstrapMethods|* attribute elements normally have references to other *Constant Pool* items. In VM the *bootstrap method attribute* is represented by the *operands* array of the *ConstantPool*. The problem is is that all the force and back cross links between *ConstantPool* elements and *operands* array elements must be correctly merged at class redefinition. Test coverage: vm.mlvm, nsk.jvmti, nsk.jdi tests on multiple platforms (32 vs 64-bit too). The testing looks good so far. One difficulty is that new vm.mlvm tests are currently failed because of multiple reasons. Thanks, Serguei
hg: jdk8/tl/jdk: 8004979: java.lang.reflect.Modifier.toString should include default
Changeset: b4f68aca1000 Author:darcy Date: 2013-04-02 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4f68aca1000 8004979: java.lang.reflect.Modifier.toString should include default Reviewed-by: mduigou ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java ! test/java/lang/reflect/Method/GenericStringTest.java
Re: hs25 review request: 8007037 JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands
Hi Coleen, Again, thank you a lot for reviewing this code! This is a good catch too, thank you for pointing to it. BTW, I was thinking that this probably must be explicitly deallocated but at some point lost my focus. :) Thanks! Serguei On 4/2/13 3:45 PM, Coleen Phillimore wrote: Hi Serguei, This looks good from how much I understand of these two things. There is one problem that I found though. In ConstantPool::extend_operands() and shrink_operands() when you allocate a new Arrayu2* and assign it to the from_cp, you have to explicitly deallocate the operands that were there with MetadataFactory::free_arrayu2() or they will leak. This isn't true if you backport this code to 7u. Thanks, Coleen On 03/27/2013 07:45 PM, serguei.spit...@oracle.com wrote: Please, review the hs25 fix below. Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8007037-JVMTI-JSR292.1/ CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007037 https://jbs.oracle.com/bugs/browse/JDK-8007037 References from INDY bootstrap method specifier operands to CP entries and back must be correctly merged at class redefinition. Some background. An invokedynamic bytecode spec: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.invokedynamic A invokedynamic instruction has an argument which is an index to the *Constant Pool* item. That index must be a symbolic reference to a *call-site specifier*: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4.10 A CP item of the type *CONSTANT_InvokeDynamic_inf* has an index into the *bootstrap method attribute* of the class file: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.21 The *|BootstrapMethods|* attribute elements normally have references to other *Constant Pool* items. In VM the *bootstrap method attribute* is represented by the *operands* array of the *ConstantPool*. The problem is is that all the force and back cross links between *ConstantPool* elements and *operands* array elements must be correctly merged at class redefinition. Test coverage: vm.mlvm, nsk.jvmti, nsk.jdi tests on multiple platforms (32 vs 64-bit too). The testing looks good so far. One difficulty is that new vm.mlvm tests are currently failed because of multiple reasons. Thanks, Serguei
