From igor.ignatyev at oracle.com Sat Jan 2 11:59:26 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 2 Jan 2016 16:59:26 +0500 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform In-Reply-To: References: Message-ID: <4CE12B2E-FDEF-48E0-AA84-E410DC09CE53@oracle.com> Hi Filipp, there is no options to make ?@library /test/lib? works. there is ?external.lib.roots? property in TEST.ROOT files, which adds additional root for @library. I noticed that there is no /test/lib-test isn?t a part of any test-suites, hence moving test to test/lib-test implies extra work in infra. given that I think it?ll be better to do it lately and separately from 8066599. please file an RFE for that. on 2nd question, I think it makes sense to move ClassFileInstaller to jdk.test.lib and annotate ClassFileInstaller in both jdk/test/lib/testlibrary/ and hotspot/test/testlibrary/ w/ @Deprectate. and I also think it?d be better to do it separately. Thanks, Igor > On Dec 25, 2015, at 12:41 PM, Filipp Zhinkin wrote: > > Hi Igor, > > thanks for looking at this change. > > On Thu, Dec 24, 2015 at 9:24 PM, Igor Ignatyev wrote: >> Hi Filipp, >> >> could you please move TestMutuallyExclusivePlatformPredicates and TestPlatformIsTieredSupported from hotspot/testlibrary_tests/ to test/lib-test and update it according to your changes? please note that we started to use packages in our tests. > > Sure, I'll move it. > > Do I need to pass any specific options to jtreg to make '@library > /test/lib' work? > At the moment jtreg can't locate it unless I specify > '/../../test/lib/share/classes'. > > Does it make sense to also move ClassFileInstaller to jdk.test.lib? > > > Thanks, > Filipp. > >> >> otherwise looks good to me. >> >> Thanks, >> ? Igor >> >>> On Dec 22, 2015, at 10:36 AM, Filipp Zhinkin wrote: >>> >>> Hi all, >>> >>> please review a small change that adds VM mode checking methods to >>> jdk.test.lib.Platform. >>> I didn't touch Platform class from hotspot/test/testlibrary, because >>> it is already deprecated and at some point of time all hs tests will >>> be updated to use j.t.l.Platform instead. >>> Update of hs tests that use own logic to check VM mode is tracked by >>> JDK-8145848 [1]. >>> >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 >>> Testing: on local machine with different VM modes. >>> >>> Regards, >>> Filipp. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8145848 >> From jeremymanson at google.com Sun Jan 3 03:33:00 2016 From: jeremymanson at google.com (Jeremy Manson) Date: Sat, 2 Jan 2016 19:33:00 -0800 Subject: Class preloading In-Reply-To: References: Message-ID: Is this different from application class data sharing? http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#app_class_data_sharing You will still have to run class initializers - anything that, for example, reads the time of day or does something based on an IP address won't work otherwise. Jeremy On Thu, Dec 31, 2015 at 5:26 AM, Gustav ?kesson wrote: > Hi, > > I hope this is the appropriate mailing list, if not please advise. > > I'm working in a telco system and in one of our R&D projects we experienced > significant problems when the system processed its' first request. The > first request took 1600ms and the second 50ms, and the latency of the first > request was unacceptable especially in case an unexpected restart is > performed during peak hours. > > Quite obviously, classloading was to blame. The problem we saw was not > classloading itself, but the static initializers and initialization of > static fields. Both our own code and 3PPs make use of static, heavy and > reusable objects in order to improve performance - which of course are > initialized by the classloader. And to my experience, this idiom is quite > frequent. One common example is the thread-safe Holder idiom for singleton > instantiation. > > Even though this issue is well-known, we had to come up with a remedy. What > I did is hatching the idea that before JVM shutdown, we store the currently > loaded classes on disk. At next start, before the JVM accepts any requests, > these classes are loaded again. The main idea is that classes which have > been loaded by a previous JVM lifecycle is likely to be loaded in the > subsequent. This trick resulted in the first request taking 50ms, i.e. as > short/long as the second one. We had no choice but to move forward with > this solution, which I think is sort of sad since this is somewhat of an > inherited issue with the dynamic classloading of Java. > > Reason for sharing this scenario here is that I'd like to explore the > opportunity of bringing this as an optional JVM feature (-XX flag), but > obviously as a more builtin and refined construct. I reckon more folks have > similar kind of issues, but before proceeding with a JEP I'd like to get > some input and views on the matter. > > In case the above proposal as such is not the way forward for the JVM as a > product, I think we need to figure out something else because we Java > server folks are really suffering because of classloading. > > > Happy new year & cheers, > Gustav ?kesson > From ioi.lam at oracle.com Sun Jan 3 07:36:03 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Sat, 02 Jan 2016 23:36:03 -0800 Subject: Class preloading In-Reply-To: References: Message-ID: <5688CF63.4010305@oracle.com> Do you have statistics regarding how much time is spent in class loading vs the static initializers? How many classes are loaded during the 1600ms? One quick thing to try is to run with -verify:none. This typically would reduce the class loading time by about half. If you don't see a significant reduction, then I would suspect that the bottleneck is not in class loading itself, but rather the amount of work done inside the static initializers. - Ioi On 12/31/15 5:26 AM, Gustav ?kesson wrote: > Hi, > > I hope this is the appropriate mailing list, if not please advise. > > I'm working in a telco system and in one of our R&D projects we experienced > significant problems when the system processed its' first request. The > first request took 1600ms and the second 50ms, and the latency of the first > request was unacceptable especially in case an unexpected restart is > performed during peak hours. > > Quite obviously, classloading was to blame. The problem we saw was not > classloading itself, but the static initializers and initialization of > static fields. Both our own code and 3PPs make use of static, heavy and > reusable objects in order to improve performance - which of course are > initialized by the classloader. And to my experience, this idiom is quite > frequent. One common example is the thread-safe Holder idiom for singleton > instantiation. > > Even though this issue is well-known, we had to come up with a remedy. What > I did is hatching the idea that before JVM shutdown, we store the currently > loaded classes on disk. At next start, before the JVM accepts any requests, > these classes are loaded again. The main idea is that classes which have > been loaded by a previous JVM lifecycle is likely to be loaded in the > subsequent. This trick resulted in the first request taking 50ms, i.e. as > short/long as the second one. We had no choice but to move forward with > this solution, which I think is sort of sad since this is somewhat of an > inherited issue with the dynamic classloading of Java. > > Reason for sharing this scenario here is that I'd like to explore the > opportunity of bringing this as an optional JVM feature (-XX flag), but > obviously as a more builtin and refined construct. I reckon more folks have > similar kind of issues, but before proceeding with a JEP I'd like to get > some input and views on the matter. > > In case the above proposal as such is not the way forward for the JVM as a > product, I think we need to figure out something else because we Java > server folks are really suffering because of classloading. > > > Happy new year & cheers, > Gustav ?kesson From gustav.r.akesson at gmail.com Mon Jan 4 14:36:02 2016 From: gustav.r.akesson at gmail.com (=?UTF-8?Q?Gustav_=C3=85kesson?=) Date: Mon, 4 Jan 2016 15:36:02 +0100 Subject: Class preloading In-Reply-To: <5688CF63.4010305@oracle.com> References: <5688CF63.4010305@oracle.com> Message-ID: Hi all, Since we suffer from static initializers/fields, I can't see that AppCDS would benefit. Also, as I interpret CDS is that it more or less "loads" all the classes in the specified jar-files (specifying the jars is another maintenance problem, whenever we introduce new modules/components). Our system consists of multiple JVMs using different classes from shared modules/components, and CDS would load classes which are not used which would affect JIT, memory consumption etc. These are also the reason for the topic of discussion here - having a preloading of classes and static initializers/fields which bases its' decision on previous JVM lifecycle. - - - - Fresh statistics for the first request after JVM start. *No changes* Client timeout (= more than 2.1sec) *Preloading using Class.forName(className, false, classLoader)* 2045ms *Preloading using Class.forName(className, true, classLoader)* 462ms Please not that the statistics above is a bit different than reported in the original mail since we have expanded the request's content. Best Regards, Gustav ?kesson On Sun, Jan 3, 2016 at 8:36 AM, Ioi Lam wrote: > Do you have statistics regarding how much time is spent in class loading > vs the static initializers? How many classes are loaded during the 1600ms? > > One quick thing to try is to run with -verify:none. This typically would > reduce the class loading time by about half. If you don't see a significant > reduction, then I would suspect that the bottleneck is not in class loading > itself, but rather the amount of work done inside the static initializers. > > - Ioi > > > > On 12/31/15 5:26 AM, Gustav ?kesson wrote: > >> Hi, >> >> I hope this is the appropriate mailing list, if not please advise. >> >> I'm working in a telco system and in one of our R&D projects we >> experienced >> significant problems when the system processed its' first request. The >> first request took 1600ms and the second 50ms, and the latency of the >> first >> request was unacceptable especially in case an unexpected restart is >> performed during peak hours. >> >> Quite obviously, classloading was to blame. The problem we saw was not >> classloading itself, but the static initializers and initialization of >> static fields. Both our own code and 3PPs make use of static, heavy and >> reusable objects in order to improve performance - which of course are >> initialized by the classloader. And to my experience, this idiom is quite >> frequent. One common example is the thread-safe Holder idiom for singleton >> instantiation. >> >> Even though this issue is well-known, we had to come up with a remedy. >> What >> I did is hatching the idea that before JVM shutdown, we store the >> currently >> loaded classes on disk. At next start, before the JVM accepts any >> requests, >> these classes are loaded again. The main idea is that classes which have >> been loaded by a previous JVM lifecycle is likely to be loaded in the >> subsequent. This trick resulted in the first request taking 50ms, i.e. as >> short/long as the second one. We had no choice but to move forward with >> this solution, which I think is sort of sad since this is somewhat of an >> inherited issue with the dynamic classloading of Java. >> >> Reason for sharing this scenario here is that I'd like to explore the >> opportunity of bringing this as an optional JVM feature (-XX flag), but >> obviously as a more builtin and refined construct. I reckon more folks >> have >> similar kind of issues, but before proceeding with a JEP I'd like to get >> some input and views on the matter. >> >> In case the above proposal as such is not the way forward for the JVM as a >> product, I think we need to figure out something else because we Java >> server folks are really suffering because of classloading. >> >> >> Happy new year & cheers, >> Gustav ?kesson >> > > From jiangli.zhou at oracle.com Mon Jan 4 19:29:32 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 4 Jan 2016 11:29:32 -0800 Subject: Class preloading In-Reply-To: References: <5688CF63.4010305@oracle.com> Message-ID: <7F2E3E32-7745-475C-A65F-5B85388F3BBD@oracle.com> Hi Gustav, Thanks for sharing the data. In the old Java ME days, we had similar support in the VM (CVM). The server VM can pre-load and pre-initializae a set of classes. The pre-loaded and initialized classes reside in shared memory, so client/child VM spawned by the server VM can access those classes. However not all classes can be pre-initialized. For example, classes that creates Thread should not be pre-initialized. CDS does not archive all classes in a specified jar file. It archives a set of classes, which can be adjusted based on the usage requirement. As of today, CDS does not support pre-initializing archived classes. So you are right on that part. Thanks, Jiangli > On Jan 4, 2016, at 6:36 AM, Gustav ?kesson wrote: > > Hi all, > > Since we suffer from static initializers/fields, I can't see that AppCDS > would benefit. Also, as I interpret CDS is that it more or less "loads" all > the classes in the specified jar-files (specifying the jars is another > maintenance problem, whenever we introduce new modules/components). Our > system consists of multiple JVMs using different classes from shared > modules/components, and CDS would load classes which are not used which > would affect JIT, memory consumption etc. > > These are also the reason for the topic of discussion here - having a > preloading of classes and static initializers/fields which bases its' > decision on previous JVM lifecycle. > > - - - - > > Fresh statistics for the first request after JVM start. > > *No changes* > Client timeout (= more than 2.1sec) > > *Preloading using Class.forName(className, false, classLoader)* > 2045ms > > *Preloading using Class.forName(className, true, classLoader)* > 462ms > > > Please not that the statistics above is a bit different than reported in > the original mail since we have expanded the request's content. > > > Best Regards, > Gustav ?kesson > > > On Sun, Jan 3, 2016 at 8:36 AM, Ioi Lam wrote: > >> Do you have statistics regarding how much time is spent in class loading >> vs the static initializers? How many classes are loaded during the 1600ms? >> >> One quick thing to try is to run with -verify:none. This typically would >> reduce the class loading time by about half. If you don't see a significant >> reduction, then I would suspect that the bottleneck is not in class loading >> itself, but rather the amount of work done inside the static initializers. >> >> - Ioi >> >> >> >> On 12/31/15 5:26 AM, Gustav ?kesson wrote: >> >>> Hi, >>> >>> I hope this is the appropriate mailing list, if not please advise. >>> >>> I'm working in a telco system and in one of our R&D projects we >>> experienced >>> significant problems when the system processed its' first request. The >>> first request took 1600ms and the second 50ms, and the latency of the >>> first >>> request was unacceptable especially in case an unexpected restart is >>> performed during peak hours. >>> >>> Quite obviously, classloading was to blame. The problem we saw was not >>> classloading itself, but the static initializers and initialization of >>> static fields. Both our own code and 3PPs make use of static, heavy and >>> reusable objects in order to improve performance - which of course are >>> initialized by the classloader. And to my experience, this idiom is quite >>> frequent. One common example is the thread-safe Holder idiom for singleton >>> instantiation. >>> >>> Even though this issue is well-known, we had to come up with a remedy. >>> What >>> I did is hatching the idea that before JVM shutdown, we store the >>> currently >>> loaded classes on disk. At next start, before the JVM accepts any >>> requests, >>> these classes are loaded again. The main idea is that classes which have >>> been loaded by a previous JVM lifecycle is likely to be loaded in the >>> subsequent. This trick resulted in the first request taking 50ms, i.e. as >>> short/long as the second one. We had no choice but to move forward with >>> this solution, which I think is sort of sad since this is somewhat of an >>> inherited issue with the dynamic classloading of Java. >>> >>> Reason for sharing this scenario here is that I'd like to explore the >>> opportunity of bringing this as an optional JVM feature (-XX flag), but >>> obviously as a more builtin and refined construct. I reckon more folks >>> have >>> similar kind of issues, but before proceeding with a JEP I'd like to get >>> some input and views on the matter. >>> >>> In case the above proposal as such is not the way forward for the JVM as a >>> product, I think we need to figure out something else because we Java >>> server folks are really suffering because of classloading. >>> >>> >>> Happy new year & cheers, >>> Gustav ?kesson >>> >> >> From coleen.phillimore at oracle.com Mon Jan 4 22:42:37 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 4 Jan 2016 17:42:37 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files Message-ID: <568AF55D.9000706@oracle.com> Summary: Moved functions to the correct files. See bug for more details. I basically did an hg mv templateInterpreter_.cpp abstractInterpreter_.cpp and moved the interpreter_.cpp functions there. Also moved generate_slow_signature_handler to TemplateInterpreterGenerator/CppInterpreterGenerator because it's not shared. open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ bug link https://bugs.openjdk.java.net/browse/JDK-8146410 Tested with JPRT on Oracle supported platforms and built zero on linux x86. Also fixed change that broke zero in stack_zero.inline.hpp. I think this should work on PPC and AARCH64, but please let me know. One question for AARCH64 platform in file: http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp.udiff.html thanks, Coleen From coleen.phillimore at oracle.com Mon Jan 4 22:57:30 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 4 Jan 2016 17:57:30 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568AF55D.9000706@oracle.com> References: <568AF55D.9000706@oracle.com> Message-ID: <568AF8DA.1050800@oracle.com> I forgot to add that I have a script that updates copyrights when I commit. Thanks, Coleen On 1/4/16 5:42 PM, Coleen Phillimore wrote: > Summary: Moved functions to the correct files. > > See bug for more details. > > I basically did an hg mv templateInterpreter_.cpp > abstractInterpreter_.cpp and moved the interpreter_.cpp > functions there. > > Also moved generate_slow_signature_handler to > TemplateInterpreterGenerator/CppInterpreterGenerator because it's not > shared. > > open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ > bug link https://bugs.openjdk.java.net/browse/JDK-8146410 > > Tested with JPRT on Oracle supported platforms and built zero on linux > x86. Also fixed change that broke zero in stack_zero.inline.hpp. I > think this should work on PPC and AARCH64, but please let me know. > > One question for AARCH64 platform in file: > > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp.udiff.html > > > thanks, > Coleen From kim.barrett at oracle.com Tue Jan 5 02:25:28 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 4 Jan 2016 21:25:28 -0500 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> Message-ID: <98B07F13-1D90-4DEC-AAED-D791F4666BF7@oracle.com> On Dec 18, 2015, at 7:41 PM, Kim Barrett wrote: > > On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 >> >> /Magnus > > I only looked at hotspot files. > > [?] > There are a couple of "TBD"s below that I need to spend more time on. > Back from holiday, and here?s my comments on those two TBDs ------------------------------------------------------------------------------ hotspot/agent/src/share/native/sadis.c 96 return (int)strlen(buf); The only call to the (file-scoped) getLastErrorString function is Java_sun_jvm_hotspot_asm_Disassembler_load_1library, which ignores the result. It would be better to change the return type of getLastErrorString to void and update the return statements accordingly. ------------------------------------------------------------------------------ hotspot/src/share/vm/adlc/arena.hpp 74 // Usual (non-placement) deallocation function to allow placement delete use size_t 75 // See 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2. 76 void operator delete(void* p); and associated code in the .cpp file. I think this is another C++11 change: http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#429 I think the proposed code change is OK, although the comment is problematic: [basic.stc.dynamic.deallocation] is C++03 3.7.3.2 and C++11 3.7.4.2. Also, the standard change that leads to this code change is in C++11 5.3.4 [expr.new] paragraph 20 (C++02 p 19). Also, I *think* with the addition of the one-arg operator delete we don't actually use the two-arg form. If so, then I suggest removing it and the proposed new comment for the one-arg form. ------------------------------------------------------------------------------ From ioi.lam at oracle.com Tue Jan 5 02:47:33 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 04 Jan 2016 18:47:33 -0800 Subject: Class preloading In-Reply-To: References: <5688CF63.4010305@oracle.com> Message-ID: <568B2EC5.309@oracle.com> Gustav, I think what you are doing (forcing classes to be initialized during server start-up) is a common practice. Doing this in the user code would be the right thing to do. It will be difficult for the JVM to do this automatically for you. Imagine you have a custom class loader like this: ClassLoader myLoader = new MyLoader(....); myLoader.loadClass("Foo"); myLoader.loadClass("Bar"); Even if the JVM knows (from past executions) that a class named "Foo" should be loaded and initialized at program start-up, it would not know how to find the myLoader to load such a class. Yes, we could specialize something for the application class loader, but in general, the user program would be the right entity to be doing such things. Thanks - Ioi On 1/4/16 6:36 AM, Gustav ?kesson wrote: > Hi all, > > Since we suffer from static initializers/fields, I can't see that > AppCDS would benefit. Also, as I interpret CDS is that it more or less > "loads" all the classes in the specified jar-files (specifying the > jars is another maintenance problem, whenever we introduce new > modules/components). Our system consists of multiple JVMs using > different classes from shared modules/components, and CDS would load > classes which are not used which would affect JIT, memory consumption > etc. > > These are also the reason for the topic of discussion here - having a > preloading of classes and static initializers/fields which bases its' > decision on previous JVM lifecycle. > > - - - - > > Fresh statistics for the first request after JVM start. > > *No changes* > Client timeout (= more than 2.1sec) > > *Preloading using Class.forName(className, _false_, classLoader)* > 2045ms > > *Preloading using Class.forName(className, _true_, classLoader)* > 462ms > > > Please not that the statistics above is a bit different than reported > in the original mail since we have expanded the request's content. > > > Best Regards, > Gustav ?kesson > > > On Sun, Jan 3, 2016 at 8:36 AM, Ioi Lam > wrote: > > Do you have statistics regarding how much time is spent in class > loading vs the static initializers? How many classes are loaded > during the 1600ms? > > One quick thing to try is to run with -verify:none. This typically > would reduce the class loading time by about half. If you don't > see a significant reduction, then I would suspect that the > bottleneck is not in class loading itself, but rather the amount > of work done inside the static initializers. > > - Ioi > > > > On 12/31/15 5:26 AM, Gustav ?kesson wrote: > > Hi, > > I hope this is the appropriate mailing list, if not please advise. > > I'm working in a telco system and in one of our R&D projects > we experienced > significant problems when the system processed its' first > request. The > first request took 1600ms and the second 50ms, and the latency > of the first > request was unacceptable especially in case an unexpected > restart is > performed during peak hours. > > Quite obviously, classloading was to blame. The problem we saw > was not > classloading itself, but the static initializers and > initialization of > static fields. Both our own code and 3PPs make use of static, > heavy and > reusable objects in order to improve performance - which of > course are > initialized by the classloader. And to my experience, this > idiom is quite > frequent. One common example is the thread-safe Holder idiom > for singleton > instantiation. > > Even though this issue is well-known, we had to come up with a > remedy. What > I did is hatching the idea that before JVM shutdown, we store > the currently > loaded classes on disk. At next start, before the JVM accepts > any requests, > these classes are loaded again. The main idea is that classes > which have > been loaded by a previous JVM lifecycle is likely to be loaded > in the > subsequent. This trick resulted in the first request taking > 50ms, i.e. as > short/long as the second one. We had no choice but to move > forward with > this solution, which I think is sort of sad since this is > somewhat of an > inherited issue with the dynamic classloading of Java. > > Reason for sharing this scenario here is that I'd like to > explore the > opportunity of bringing this as an optional JVM feature (-XX > flag), but > obviously as a more builtin and refined construct. I reckon > more folks have > similar kind of issues, but before proceeding with a JEP I'd > like to get > some input and views on the matter. > > In case the above proposal as such is not the way forward for > the JVM as a > product, I think we need to figure out something else because > we Java > server folks are really suffering because of classloading. > > > Happy new year & cheers, > Gustav ?kesson > > > From goetz.lindenmaier at sap.com Tue Jan 5 07:19:45 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Jan 2016 07:19:45 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568AF55D.9000706@oracle.com> References: <568AF55D.9000706@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> Hi Coleen, Could you please also move AbstractInterpreter::can_be_compiled(methodHandle m) to above TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter::MethodKind kind)? I think these belong together. We seem to have different BIND macros on ppc. The '__' is also in the macro. Could you please fix this small issue? It breaks the ppc build. diff -r 743aa331fc90 src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue Jan 05 07:47:21 2016 +0100 +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue Jan 05 08:06:12 2016 +0100 @@ -416,7 +416,7 @@ default: ShouldNotReachHere(); } - __ BIND(done); + BIND(done); __ blr(); return entry; Besides this, the change looks good. Thanks and best regards, Goetz. PS: is it possible to share your Copyright script? > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Coleen Phillimore > Sent: Monday, January 04, 2016 11:43 PM > To: hotspot-dev developers > Subject: RFR (M) 8146410: Interpreter functions are declared and defined in > the wrong files > > Summary: Moved functions to the correct files. > > See bug for more details. > > I basically did an hg mv templateInterpreter_.cpp > abstractInterpreter_.cpp and moved the interpreter_.cpp > functions there. > > Also moved generate_slow_signature_handler to > TemplateInterpreterGenerator/CppInterpreterGenerator because it's not > shared. > > open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ > bug link https://bugs.openjdk.java.net/browse/JDK-8146410 > > Tested with JPRT on Oracle supported platforms and built zero on linux > x86. Also fixed change that broke zero in stack_zero.inline.hpp. I > think this should work on PPC and AARCH64, but please let me know. > > One question for AARCH64 platform in file: > > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat > eInterpreterGenerator_aarch64.cpp.udiff.html > > thanks, > Coleen From adinn at redhat.com Tue Jan 5 10:28:41 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 5 Jan 2016 10:28:41 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568AF55D.9000706@oracle.com> References: <568AF55D.9000706@oracle.com> Message-ID: <568B9AD9.4040504@redhat.com> Hi Coleen, On 04/01/16 22:42, Coleen Phillimore wrote: > One question for AARCH64 platform in file: > > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp.udiff.html Hmm. That's a good question. The generic code manages relies on the MacroAssembler auxiliary bang_stack_with_offset(int offset) called with the relevant offsets. On AArch64, that auxiliary method does a store using a register with register offset mov(rscratch2, -offset); str(zr, Address(sp, rscratch2)); The overriding definition that you have commented out bypasses this auxiliary, computing the address in a scratch register then using a register direct store for (int pages = start_page; pages <= n_shadow_pages ; pages++) { __ sub(rscratch2, sp, pages*page_size); __ str(zr, Address(rscratch2)); I cannot be certain but I recall we found that there was a significant performance difference between these two variants -- which means we want to retain the definition you have commented out. Andrew Haley (in cc) may be able to provide more info here as I believe he added this overriding implementation. I guess a comment on our overriding definition would be in order should we ascertain that this was indeed the rationale. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From coleen.phillimore at oracle.com Tue Jan 5 15:00:47 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Jan 2016 10:00:47 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568B9AD9.4040504@redhat.com> References: <568AF55D.9000706@oracle.com> <568B9AD9.4040504@redhat.com> Message-ID: <568BDA9F.3080706@oracle.com> On 1/5/16 5:28 AM, Andrew Dinn wrote: > Hi Coleen, > > On 04/01/16 22:42, Coleen Phillimore wrote: > >> One question for AARCH64 platform in file: >> >> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp.udiff.html > Hmm. That's a good question. > > The generic code manages relies on the MacroAssembler auxiliary > bang_stack_with_offset(int offset) called with the relevant offsets. On > AArch64, that auxiliary method does a store using a register with > register offset > > mov(rscratch2, -offset); > str(zr, Address(sp, rscratch2)); > > The overriding definition that you have commented out bypasses this > auxiliary, computing the address in a scratch register then using a > register direct store > > for (int pages = start_page; pages <= n_shadow_pages ; pages++) { > __ sub(rscratch2, sp, pages*page_size); > __ str(zr, Address(rscratch2)); > > I cannot be certain but I recall we found that there was a significant > performance difference between these two variants -- which means we want > to retain the definition you have commented out. Andrew Haley (in cc) > may be able to provide more info here as I believe he added this > overriding implementation. > > I guess a comment on our overriding definition would be in order should > we ascertain that this was indeed the rationale. Thank you for the quick answer. The reason I had trouble with the overriding definition in AARCH64 is that I moved bang_stack_shadow_pages() to TemplateInterpreterGenerator so the AARCH64 version would no longer override. I didn't want to copy the code to the other platforms. The four lines above are something that can easily get out of sync and cause hard to find bugs. const int page_size = os::vm_page_size(); const int n_shadow_pages = ((int)JavaThread::stack_shadow_zone_size()) / page_size; const int start_page = native_call ? n_shadow_pages : 1; for (int pages = start_page; pages <= n_shadow_pages; pages++) { Can bang_stack_with_offset on AARCH64 be changed to: // Stack overflow checking void bang_stack_with_offset(int offset) { // stack grows down, caller passes positive offset assert(offset > 0, "must bang with positive offset"); + sub(rscratch2, sp, offset); + str(zr, Address(rscratch2)); - mov(rscratch2, -offset); - str(zr, Address(sp, rscratch2)); } thanks, Coleen > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul > Argiry (US) From aph at redhat.com Tue Jan 5 15:45:08 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jan 2016 15:45:08 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568B9AD9.4040504@redhat.com> References: <568AF55D.9000706@oracle.com> <568B9AD9.4040504@redhat.com> Message-ID: <568BE504.6000802@redhat.com> Hi, On 01/05/2016 10:28 AM, Andrew Dinn wrote: > > The generic code manages relies on the MacroAssembler auxiliary > bang_stack_with_offset(int offset) called with the relevant offsets. On > AArch64, that auxiliary method does a store using a register with > register offset > > mov(rscratch2, -offset); > str(zr, Address(sp, rscratch2)); > > The overriding definition that you have commented out bypasses this > auxiliary, computing the address in a scratch register then using a > register direct store > > for (int pages = start_page; pages <= n_shadow_pages ; pages++) { > __ sub(rscratch2, sp, pages*page_size); > __ str(zr, Address(rscratch2)); > > I cannot be certain but I recall we found that there was a significant > performance difference between these two variants -- which means we want > to retain the definition you have commented out. Andrew Haley (in cc) > may be able to provide more info here as I believe he added this > overriding implementation. > > I guess a comment on our overriding definition would be in order should > we ascertain that this was indeed the rationale. I don't think that it matters any more. It used to be that we were not very good at generating all the possible versions of move immediate instructions, so with the "old" code before Coleen's patch we generated 0x0000007fa808e394: sub xscratch2, sp, #0x1, lsl #12 0x0000007fa808e398: str xzr, [xscratch2] 0x0000007fa808e39c: sub xscratch2, sp, #0x2, lsl #12 0x0000007fa808e3a0: str xzr, [xscratch2] 0x0000007fa808e3a4: sub xscratch2, sp, #0x3, lsl #12 0x0000007fa808e3a8: str xzr, [xscratch2] 0x0000007fa808e3ac: sub xscratch2, sp, #0x4, lsl #12 0x0000007fa808e3b0: str xzr, [xscratch2] 0x0000007fa808e3b4: sub xscratch2, sp, #0x5, lsl #12 0x0000007fa808e3b8: str xzr, [xscratch2] 0x0000007fa808e3bc: sub xscratch2, sp, #0x6, lsl #12 0x0000007fa808e3c0: str xzr, [xscratch2] 0x0000007fa808e3c4: sub xscratch2, sp, #0x7, lsl #12 0x0000007fa808e3c8: str xzr, [xscratch2] 0x0000007fa808e3cc: sub xscratch2, sp, #0x8, lsl #12 0x0000007fa808e3d0: str xzr, [xscratch2] 0x0000007fa808e3d4: sub xscratch2, sp, #0x9, lsl #12 0x0000007fa808e3d8: str xzr, [xscratch2] and with the generic code after this patch 0x0000007fa808e394: orr xscratch2, xzr, #0xfffffffffffff000 0x0000007fa808e398: str xzr, [sp,x9] 0x0000007fa808e39c: orr xscratch2, xzr, #0xffffffffffffe000 0x0000007fa808e3a0: str xzr, [sp,x9] 0x0000007fa808e3a4: mov xscratch2, #0xffffffffffffd000 // #-12288 0x0000007fa808e3a8: str xzr, [sp,x9] 0x0000007fa808e3ac: orr xscratch2, xzr, #0xffffffffffffc000 0x0000007fa808e3b0: str xzr, [sp,x9] 0x0000007fa808e3b4: mov xscratch2, #0xffffffffffffb000 // #-20480 0x0000007fa808e3b8: str xzr, [sp,x9] 0x0000007fa808e3bc: mov xscratch2, #0xffffffffffffa000 // #-24576 0x0000007fa808e3c0: str xzr, [sp,x9] 0x0000007fa808e3c4: mov xscratch2, #0xffffffffffff9000 // #-28672 0x0000007fa808e3c8: str xzr, [sp,x9] 0x0000007fa808e3cc: orr xscratch2, xzr, #0xffffffffffff8000 0x0000007fa808e3d0: str xzr, [sp,x9] 0x0000007fa808e3d4: mov xscratch2, #0xffffffffffff7000 // #-36864 0x0000007fa808e3d8: str xzr, [sp,x9] in the case of 64k pages, that's before 0x000003ffa808e398: sub xscratch2, sp, #0x10, lsl #12 0x000003ffa808e39c: str xzr, [xscratch2] 0x000003ffa808e3a0: sub xscratch2, sp, #0x20, lsl #12 0x000003ffa808e3a4: str xzr, [xscratch2] and after 0x000003ffa808e398: orr xscratch2, xzr, #0xffffffffffff0000 0x000003ffa808e39c: str xzr, [sp,x9] 0x000003ffa808e3a0: mov xscratch2, #0xfffffffffffe0000 // #-131072 0x000003ffa808e3a4: str xzr, [sp,x9] So, it turns out we can generate all the offsets in a single instruction: it really doesn't matter, and I think Coleen's patch is just fine. In terms of efficiency the cost of a few instructions is dwarfed by the fact that we dirty 9 (out of only maybe 48) TLB entries. That's a huge performance effect. Andrew. From goetz.lindenmaier at sap.com Tue Jan 5 16:33:42 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Jan 2016 16:33:42 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568BE504.6000802@redhat.com> References: <568AF55D.9000706@oracle.com> <568B9AD9.4040504@redhat.com> <568BE504.6000802@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EFC265@DEWDFEMB12A.global.corp.sap> Hi Andrew, If you are concerned about the TLB pollution, you can load thread->_stack_overflow_limit and compare against that. If you are past that limit, you just touch a yellow page to get the SIGSEGV for the stack overflow. You touch the thread nearby anyways, so that page should be in the TLB. (There is Thread::stack_overflow_limit_offset()). Best regards, Goetz. (I guess this is out-of-scope of the original RFR.) > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Andrew Haley > Sent: Tuesday, January 05, 2016 4:45 PM > To: Andrew Dinn ; Coleen Phillimore > ; hotspot-dev developers dev at openjdk.java.net> > Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined > in the wrong files > > Hi, > > On 01/05/2016 10:28 AM, Andrew Dinn wrote: > > > > The generic code manages relies on the MacroAssembler auxiliary > > bang_stack_with_offset(int offset) called with the relevant offsets. On > > AArch64, that auxiliary method does a store using a register with > > register offset > > > > mov(rscratch2, -offset); > > str(zr, Address(sp, rscratch2)); > > > > The overriding definition that you have commented out bypasses this > > auxiliary, computing the address in a scratch register then using a > > register direct store > > > > for (int pages = start_page; pages <= n_shadow_pages ; pages++) { > > __ sub(rscratch2, sp, pages*page_size); > > __ str(zr, Address(rscratch2)); > > > > I cannot be certain but I recall we found that there was a significant > > performance difference between these two variants -- which means we > want > > to retain the definition you have commented out. Andrew Haley (in cc) > > may be able to provide more info here as I believe he added this > > overriding implementation. > > > > I guess a comment on our overriding definition would be in order should > > we ascertain that this was indeed the rationale. > > I don't think that it matters any more. It used to be that we were > not very good at generating all the possible versions of move > immediate instructions, so with the "old" code before Coleen's patch > we generated > > 0x0000007fa808e394: sub xscratch2, sp, #0x1, lsl #12 > 0x0000007fa808e398: str xzr, [xscratch2] > 0x0000007fa808e39c: sub xscratch2, sp, #0x2, lsl #12 > 0x0000007fa808e3a0: str xzr, [xscratch2] > 0x0000007fa808e3a4: sub xscratch2, sp, #0x3, lsl #12 > 0x0000007fa808e3a8: str xzr, [xscratch2] > 0x0000007fa808e3ac: sub xscratch2, sp, #0x4, lsl #12 > 0x0000007fa808e3b0: str xzr, [xscratch2] > 0x0000007fa808e3b4: sub xscratch2, sp, #0x5, lsl #12 > 0x0000007fa808e3b8: str xzr, [xscratch2] > 0x0000007fa808e3bc: sub xscratch2, sp, #0x6, lsl #12 > 0x0000007fa808e3c0: str xzr, [xscratch2] > 0x0000007fa808e3c4: sub xscratch2, sp, #0x7, lsl #12 > 0x0000007fa808e3c8: str xzr, [xscratch2] > 0x0000007fa808e3cc: sub xscratch2, sp, #0x8, lsl #12 > 0x0000007fa808e3d0: str xzr, [xscratch2] > 0x0000007fa808e3d4: sub xscratch2, sp, #0x9, lsl #12 > 0x0000007fa808e3d8: str xzr, [xscratch2] > > and with the generic code after this patch > > 0x0000007fa808e394: orr xscratch2, xzr, #0xfffffffffffff000 > 0x0000007fa808e398: str xzr, [sp,x9] > 0x0000007fa808e39c: orr xscratch2, xzr, #0xffffffffffffe000 > 0x0000007fa808e3a0: str xzr, [sp,x9] > 0x0000007fa808e3a4: mov xscratch2, #0xffffffffffffd000 // #-12288 > 0x0000007fa808e3a8: str xzr, [sp,x9] > 0x0000007fa808e3ac: orr xscratch2, xzr, #0xffffffffffffc000 > 0x0000007fa808e3b0: str xzr, [sp,x9] > 0x0000007fa808e3b4: mov xscratch2, #0xffffffffffffb000 // #-20480 > 0x0000007fa808e3b8: str xzr, [sp,x9] > 0x0000007fa808e3bc: mov xscratch2, #0xffffffffffffa000 // #-24576 > 0x0000007fa808e3c0: str xzr, [sp,x9] > 0x0000007fa808e3c4: mov xscratch2, #0xffffffffffff9000 // #-28672 > 0x0000007fa808e3c8: str xzr, [sp,x9] > 0x0000007fa808e3cc: orr xscratch2, xzr, #0xffffffffffff8000 > 0x0000007fa808e3d0: str xzr, [sp,x9] > 0x0000007fa808e3d4: mov xscratch2, #0xffffffffffff7000 // #-36864 > 0x0000007fa808e3d8: str xzr, [sp,x9] > > in the case of 64k pages, that's before > > 0x000003ffa808e398: sub xscratch2, sp, #0x10, lsl #12 > 0x000003ffa808e39c: str xzr, [xscratch2] > 0x000003ffa808e3a0: sub xscratch2, sp, #0x20, lsl #12 > 0x000003ffa808e3a4: str xzr, [xscratch2] > > and after > > 0x000003ffa808e398: orr xscratch2, xzr, #0xffffffffffff0000 > 0x000003ffa808e39c: str xzr, [sp,x9] > 0x000003ffa808e3a0: mov xscratch2, #0xfffffffffffe0000 // #-131072 > 0x000003ffa808e3a4: str xzr, [sp,x9] > > So, it turns out we can generate all the offsets in a single > instruction: it really doesn't matter, and I think Coleen's patch is > just fine. > > In terms of efficiency the cost of a few instructions is dwarfed by > the fact that we dirty 9 (out of only maybe 48) TLB entries. That's a > huge performance effect. > > Andrew. From rachel.protacio at oracle.com Tue Jan 5 17:42:22 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 5 Jan 2016 12:42:22 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code Message-ID: <568C007E.6060807@oracle.com> Hi, Please review this fix allowing TraceExceptionTest.java to pass with compiled code. c1_Runtime1.cpp had been missing the necessary long-form message, which has been added, and at the same time I discovered bytecodeInterpreter.cpp was similarly lacking, though no test had turned it up. Passes JPRT and RBT tests. Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 Thanks, Rachel From aph at redhat.com Tue Jan 5 18:01:11 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jan 2016 18:01:11 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EFC265@DEWDFEMB12A.global.corp.sap> References: <568AF55D.9000706@oracle.com> <568B9AD9.4040504@redhat.com> <568BE504.6000802@redhat.com> <4295855A5C1DE049A61835A1887419CC41EFC265@DEWDFEMB12A.global.corp.sap> Message-ID: <568C04E7.3030403@redhat.com> On 01/05/2016 04:33 PM, Lindenmaier, Goetz wrote: > If you are concerned about the TLB pollution, you can > load thread->_stack_overflow_limit and compare against that. > If you are past that limit, you just touch a yellow page to get the > SIGSEGV for the stack overflow. Very nice! > You touch the thread nearby anyways, so that page should be > in the TLB. > > (There is Thread::stack_overflow_limit_offset()). That has to be far better than what we do today. Unfortunately, the patch we're discussing removes the locally-defined override in which such a change could be made. Coleen, is it actually necessary to remove a cpu-specific override for this code? Banging all these pages blows away 20% of the L1 TLB entries on a Cortex-A57 and 90% (!) of them on a Cortex-A53. (At least, this is true for 4kbyte pages; with 64k pages it's less of an issue.) Andrew. From coleen.phillimore at oracle.com Tue Jan 5 18:09:30 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Jan 2016 13:09:30 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568C04E7.3030403@redhat.com> References: <568AF55D.9000706@oracle.com> <568B9AD9.4040504@redhat.com> <568BE504.6000802@redhat.com> <4295855A5C1DE049A61835A1887419CC41EFC265@DEWDFEMB12A.global.corp.sap> <568C04E7.3030403@redhat.com> Message-ID: <568C06DA.7080903@oracle.com> On 1/5/16 1:01 PM, Andrew Haley wrote: > On 01/05/2016 04:33 PM, Lindenmaier, Goetz wrote: > >> If you are concerned about the TLB pollution, you can >> load thread->_stack_overflow_limit and compare against that. >> If you are past that limit, you just touch a yellow page to get the >> SIGSEGV for the stack overflow. > Very nice! yes, that is nice and would be less instructions overall. > >> You touch the thread nearby anyways, so that page should be >> in the TLB. >> >> (There is Thread::stack_overflow_limit_offset()). > That has to be far better than what we do today. > > Unfortunately, the patch we're discussing removes the locally-defined > override in which such a change could be made. > > Coleen, is it actually necessary to remove a cpu-specific override > for this code? Banging all these pages blows away 20% of the L1 TLB > entries on a Cortex-A57 and 90% (!) of them on a Cortex-A53. (At > least, this is true for 4kbyte pages; with 64k pages it's less of an > issue.) Okay, I'll have to copy the function into other CPU implementations but it does leave room for changing them so that we don't have to bang all of the pages in the stack (the reason was so that we didn't know where the top/bottom was to compare against so had to do incremental stack banging by page). Thanks! Coleen > > Andrew. From aph at redhat.com Tue Jan 5 18:13:17 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Jan 2016 18:13:17 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568C06DA.7080903@oracle.com> References: <568AF55D.9000706@oracle.com> <568B9AD9.4040504@redhat.com> <568BE504.6000802@redhat.com> <4295855A5C1DE049A61835A1887419CC41EFC265@DEWDFEMB12A.global.corp.sap> <568C04E7.3030403@redhat.com> <568C06DA.7080903@oracle.com> Message-ID: <568C07BD.7060609@redhat.com> On 01/05/2016 06:09 PM, Coleen Phillimore wrote: > Okay, I'll have to copy the function into other CPU implementations but > it does leave room for changing them so that we don't have to bang all > of the pages in the stack (the reason was so that we didn't know where > the top/bottom was to compare against so had to do incremental stack > banging by page). Right. I think this is probably an improvement for all targets. Thanks, Andrew. From coleen.phillimore at oracle.com Tue Jan 5 18:17:07 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Jan 2016 13:17:07 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> Message-ID: <568C08A3.2060405@oracle.com> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > Could you please also move > AbstractInterpreter::can_be_compiled(methodHandle m) > to above > TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter::MethodKind kind)? > I think these belong together. Really? They're in different classes (hence the motivation for the change) and generate_math_entry doesn't call can_be_compiled. CompilationPolicy does but it calls it from AbstractInterpreter::can_be_compiled() so I really can't move this function into TemplateInterpreterGenerator. It doesn't make sense to me. > > We seem to have different BIND macros on ppc. The '__' is also in the > macro. Could you please fix this small issue? It breaks the ppc build. > > diff -r 743aa331fc90 src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue Jan 05 07:47:21 2016 +0100 > +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue Jan 05 08:06:12 2016 +0100 > @@ -416,7 +416,7 @@ > default: ShouldNotReachHere(); > } > > - __ BIND(done); > + BIND(done); > __ blr(); > Fixed. Thanks!! > return entry; > > Besides this, the change looks good. Thanks, Coleen > Thanks and best regards, > Goetz. > > PS: is it possible to share your Copyright script? > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Coleen Phillimore >> Sent: Monday, January 04, 2016 11:43 PM >> To: hotspot-dev developers >> Subject: RFR (M) 8146410: Interpreter functions are declared and defined in >> the wrong files >> >> Summary: Moved functions to the correct files. >> >> See bug for more details. >> >> I basically did an hg mv templateInterpreter_.cpp >> abstractInterpreter_.cpp and moved the interpreter_.cpp >> functions there. >> >> Also moved generate_slow_signature_handler to >> TemplateInterpreterGenerator/CppInterpreterGenerator because it's not >> shared. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >> >> Tested with JPRT on Oracle supported platforms and built zero on linux >> x86. Also fixed change that broke zero in stack_zero.inline.hpp. I >> think this should work on PPC and AARCH64, but please let me know. >> >> One question for AARCH64 platform in file: >> >> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >> eInterpreterGenerator_aarch64.cpp.udiff.html >> >> thanks, >> Coleen From coleen.phillimore at oracle.com Tue Jan 5 18:49:26 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Jan 2016 13:49:26 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> Message-ID: <568C1036.3040809@oracle.com> commit script that updates copyrights for modified files below: On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > Could you please also move > AbstractInterpreter::can_be_compiled(methodHandle m) > to above > TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter::MethodKind kind)? > I think these belong together. > > We seem to have different BIND macros on ppc. The '__' is also in the > macro. Could you please fix this small issue? It breaks the ppc build. > > diff -r 743aa331fc90 src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue Jan 05 07:47:21 2016 +0100 > +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue Jan 05 08:06:12 2016 +0100 > @@ -416,7 +416,7 @@ > default: ShouldNotReachHere(); > } > > - __ BIND(done); > + BIND(done); > __ blr(); > > return entry; > > Besides this, the change looks good. > > Thanks and best regards, > Goetz. > > PS: is it possible to share your Copyright script? hg status -mar | grep "^M" | sed -e "s/M//" >file.list foreach f (`cat file.list`) echo $f sed -e "s/Copyright (c) \([0-9][0-9][0-9][0-9]\), [0-9][0-9][0-9][0-9], Oracle/Copyright (c) \1, 2016, Oracle/" \ -e "s/Copyright (c) \([0-9][0-9][0-9][012346789]\), Oracle/Copyright (c) \1, 2016, Oracle/" <$f >$f.new diff $f $f.new mv $f.new $f end hg commit > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Coleen Phillimore >> Sent: Monday, January 04, 2016 11:43 PM >> To: hotspot-dev developers >> Subject: RFR (M) 8146410: Interpreter functions are declared and defined in >> the wrong files >> >> Summary: Moved functions to the correct files. >> >> See bug for more details. >> >> I basically did an hg mv templateInterpreter_.cpp >> abstractInterpreter_.cpp and moved the interpreter_.cpp >> functions there. >> >> Also moved generate_slow_signature_handler to >> TemplateInterpreterGenerator/CppInterpreterGenerator because it's not >> shared. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >> >> Tested with JPRT on Oracle supported platforms and built zero on linux >> x86. Also fixed change that broke zero in stack_zero.inline.hpp. I >> think this should work on PPC and AARCH64, but please let me know. >> >> One question for AARCH64 platform in file: >> >> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >> eInterpreterGenerator_aarch64.cpp.udiff.html >> >> thanks, >> Coleen From goetz.lindenmaier at sap.com Tue Jan 5 19:51:05 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Jan 2016 19:51:05 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568C08A3.2060405@oracle.com> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> Hi Coleen, I think they belong together because can_be_compiled() just returns false for functions that have a math entry which is generated by generate_math_entry(). So if you add a new math_entry, you also have to fix can_be_compiled. We wired this dependency into math_entry_available(kind), so that both functions are guaranteed to behave similar. The name of the function is kind of misleading to me. But I won't insist... Best regards, Goetz. > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Tuesday, January 05, 2016 7:17 PM > To: Lindenmaier, Goetz ; hotspot-dev > developers > Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined > in the wrong files > > > > On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > > > Could you please also move > > AbstractInterpreter::can_be_compiled(methodHandle m) > > to above > > > TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: > MethodKind kind)? > > I think these belong together. > > Really? They're in different classes (hence the motivation for the > change) and generate_math_entry doesn't call can_be_compiled. > CompilationPolicy does but it calls it from > AbstractInterpreter::can_be_compiled() so I really can't move this > function into TemplateInterpreterGenerator. It doesn't make sense to me. > > > > > We seem to have different BIND macros on ppc. The '__' is also in the > > macro. Could you please fix this small issue? It breaks the ppc build. > > > > diff -r 743aa331fc90 > src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > > --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue > Jan 05 07:47:21 2016 +0100 > > +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue > Jan 05 08:06:12 2016 +0100 > > @@ -416,7 +416,7 @@ > > default: ShouldNotReachHere(); > > } > > > > - __ BIND(done); > > + BIND(done); > > __ blr(); > > > > Fixed. Thanks!! > > return entry; > > > > Besides this, the change looks good. > > Thanks, > Coleen > > > Thanks and best regards, > > Goetz. > > > > PS: is it possible to share your Copyright script? > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of Coleen Phillimore > >> Sent: Monday, January 04, 2016 11:43 PM > >> To: hotspot-dev developers > >> Subject: RFR (M) 8146410: Interpreter functions are declared and defined > in > >> the wrong files > >> > >> Summary: Moved functions to the correct files. > >> > >> See bug for more details. > >> > >> I basically did an hg mv templateInterpreter_.cpp > >> abstractInterpreter_.cpp and moved the interpreter_.cpp > >> functions there. > >> > >> Also moved generate_slow_signature_handler to > >> TemplateInterpreterGenerator/CppInterpreterGenerator because it's > not > >> shared. > >> > >> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ > >> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 > >> > >> Tested with JPRT on Oracle supported platforms and built zero on linux > >> x86. Also fixed change that broke zero in stack_zero.inline.hpp. I > >> think this should work on PPC and AARCH64, but please let me know. > >> > >> One question for AARCH64 platform in file: > >> > >> > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat > >> eInterpreterGenerator_aarch64.cpp.udiff.html > >> > >> thanks, > >> Coleen From goetz.lindenmaier at sap.com Tue Jan 5 19:53:06 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Jan 2016 19:53:06 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568C1036.3040809@oracle.com> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C1036.3040809@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EFC365@DEWDFEMB12A.global.corp.sap> That's great, thanks! > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Tuesday, January 05, 2016 7:49 PM > To: Lindenmaier, Goetz ; hotspot-dev > developers > Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined > in the wrong files > > > commit script that updates copyrights for modified files below: > > On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > > > Could you please also move > > AbstractInterpreter::can_be_compiled(methodHandle m) > > to above > > > TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: > MethodKind kind)? > > I think these belong together. > > > > We seem to have different BIND macros on ppc. The '__' is also in the > > macro. Could you please fix this small issue? It breaks the ppc build. > > > > diff -r 743aa331fc90 > src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > > --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue > Jan 05 07:47:21 2016 +0100 > > +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue > Jan 05 08:06:12 2016 +0100 > > @@ -416,7 +416,7 @@ > > default: ShouldNotReachHere(); > > } > > > > - __ BIND(done); > > + BIND(done); > > __ blr(); > > > > return entry; > > > > Besides this, the change looks good. > > > > Thanks and best regards, > > Goetz. > > > > PS: is it possible to share your Copyright script? > > hg status -mar | grep "^M" | sed -e "s/M//" >file.list > foreach f (`cat file.list`) > echo $f > sed -e "s/Copyright (c) \([0-9][0-9][0-9][0-9]\), > [0-9][0-9][0-9][0-9], Oracle/Copyright (c) \1, 2016, Oracle/" \ > -e "s/Copyright (c) \([0-9][0-9][0-9][012346789]\), > Oracle/Copyright (c) \1, 2016, Oracle/" <$f >$f.new > diff $f $f.new > mv $f.new $f > end > hg commit > > > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of Coleen Phillimore > >> Sent: Monday, January 04, 2016 11:43 PM > >> To: hotspot-dev developers > >> Subject: RFR (M) 8146410: Interpreter functions are declared and defined > in > >> the wrong files > >> > >> Summary: Moved functions to the correct files. > >> > >> See bug for more details. > >> > >> I basically did an hg mv templateInterpreter_.cpp > >> abstractInterpreter_.cpp and moved the interpreter_.cpp > >> functions there. > >> > >> Also moved generate_slow_signature_handler to > >> TemplateInterpreterGenerator/CppInterpreterGenerator because it's > not > >> shared. > >> > >> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ > >> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 > >> > >> Tested with JPRT on Oracle supported platforms and built zero on linux > >> x86. Also fixed change that broke zero in stack_zero.inline.hpp. I > >> think this should work on PPC and AARCH64, but please let me know. > >> > >> One question for AARCH64 platform in file: > >> > >> > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat > >> eInterpreterGenerator_aarch64.cpp.udiff.html > >> > >> thanks, > >> Coleen From coleen.phillimore at oracle.com Tue Jan 5 20:01:10 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Jan 2016 15:01:10 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> Message-ID: <568C2106.8010608@oracle.com> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: > Hi Coleen, > > I think they belong together because can_be_compiled() just returns > false for functions that have a math entry which is generated by > generate_math_entry(). So if you add a new math_entry, you > also have to fix can_be_compiled. We wired this dependency into > math_entry_available(kind), so that both functions are guaranteed > to behave similar. I'm getting confused by this. It seems like math_entry_available should be in templateInterpreterGenerator near generate_math_entry. The reason I don't want can_be_compiled (which is misleading) is because all the other platforms have it too and I don't want them in the wrong files. what do you think? Coleen > > The name of the function is kind of misleading to me. > > But I won't insist... > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Tuesday, January 05, 2016 7:17 PM >> To: Lindenmaier, Goetz ; hotspot-dev >> developers >> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined >> in the wrong files >> >> >> >> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> Could you please also move >>> AbstractInterpreter::can_be_compiled(methodHandle m) >>> to above >>> >> TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: >> MethodKind kind)? >>> I think these belong together. >> Really? They're in different classes (hence the motivation for the >> change) and generate_math_entry doesn't call can_be_compiled. >> CompilationPolicy does but it calls it from >> AbstractInterpreter::can_be_compiled() so I really can't move this >> function into TemplateInterpreterGenerator. It doesn't make sense to me. >> >>> We seem to have different BIND macros on ppc. The '__' is also in the >>> macro. Could you please fix this small issue? It breaks the ppc build. >>> >>> diff -r 743aa331fc90 >> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >> Jan 05 07:47:21 2016 +0100 >>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >> Jan 05 08:06:12 2016 +0100 >>> @@ -416,7 +416,7 @@ >>> default: ShouldNotReachHere(); >>> } >>> >>> - __ BIND(done); >>> + BIND(done); >>> __ blr(); >>> >> Fixed. Thanks!! >>> return entry; >>> >>> Besides this, the change looks good. >> Thanks, >> Coleen >> >>> Thanks and best regards, >>> Goetz. >>> >>> PS: is it possible to share your Copyright script? >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Coleen Phillimore >>>> Sent: Monday, January 04, 2016 11:43 PM >>>> To: hotspot-dev developers >>>> Subject: RFR (M) 8146410: Interpreter functions are declared and defined >> in >>>> the wrong files >>>> >>>> Summary: Moved functions to the correct files. >>>> >>>> See bug for more details. >>>> >>>> I basically did an hg mv templateInterpreter_.cpp >>>> abstractInterpreter_.cpp and moved the interpreter_.cpp >>>> functions there. >>>> >>>> Also moved generate_slow_signature_handler to >>>> TemplateInterpreterGenerator/CppInterpreterGenerator because it's >> not >>>> shared. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >>>> >>>> Tested with JPRT on Oracle supported platforms and built zero on linux >>>> x86. Also fixed change that broke zero in stack_zero.inline.hpp. I >>>> think this should work on PPC and AARCH64, but please let me know. >>>> >>>> One question for AARCH64 platform in file: >>>> >>>> >> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >>>> eInterpreterGenerator_aarch64.cpp.udiff.html >>>> >>>> thanks, >>>> Coleen From goetz.lindenmaier at sap.com Tue Jan 5 20:49:46 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Jan 2016 20:49:46 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568C2106.8010608@oracle.com> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Dienstag, 5. Januar 2016 21:01 > To: Lindenmaier, Goetz ; hotspot-dev > developers > Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined > in the wrong files > > > > On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > > > I think they belong together because can_be_compiled() just returns > > false for functions that have a math entry which is generated by > > generate_math_entry(). So if you add a new math_entry, you > > also have to fix can_be_compiled. We wired this dependency into > > math_entry_available(kind), so that both functions are guaranteed > > to behave similar. > > I'm getting confused by this. It seems like math_entry_available should > be in templateInterpreterGenerator near generate_math_entry. > > The reason I don't want can_be_compiled (which is misleading) is because > all the other platforms have it too and I don't want them in the wrong > files. > > what do you think? What I mean is can_be_compiled() should be moved to class templateInterpreterGenerator and placed near generate_math_entry() on all platforms. The similarity is the same on all of them. But I must admit in compilationPolicy.cpp it reads better if the AbstractInterpreter is asked. Also, method_kind is member of AbstractInterpreter. But method_kind is also completely over-engeneered, as it's only used in can_be_compiled, and there it's only used for math entries... Maybe a change of it's own is needed... Best regards, Goetz. > > Coleen > > > > The name of the function is kind of misleading to me. > > > > But I won't insist... > > > > Best regards, > > Goetz. > > > > > > > >> -----Original Message----- > >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > >> Sent: Tuesday, January 05, 2016 7:17 PM > >> To: Lindenmaier, Goetz ; hotspot-dev > >> developers > >> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and > defined > >> in the wrong files > >> > >> > >> > >> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: > >>> Hi Coleen, > >>> > >>> Could you please also move > >>> AbstractInterpreter::can_be_compiled(methodHandle m) > >>> to above > >>> > >> > TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: > >> MethodKind kind)? > >>> I think these belong together. > >> Really? They're in different classes (hence the motivation for the > >> change) and generate_math_entry doesn't call can_be_compiled. > >> CompilationPolicy does but it calls it from > >> AbstractInterpreter::can_be_compiled() so I really can't move this > >> function into TemplateInterpreterGenerator. It doesn't make sense to > me. > >> > >>> We seem to have different BIND macros on ppc. The '__' is also in the > >>> macro. Could you please fix this small issue? It breaks the ppc build. > >>> > >>> diff -r 743aa331fc90 > >> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > >>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue > >> Jan 05 07:47:21 2016 +0100 > >>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue > >> Jan 05 08:06:12 2016 +0100 > >>> @@ -416,7 +416,7 @@ > >>> default: ShouldNotReachHere(); > >>> } > >>> > >>> - __ BIND(done); > >>> + BIND(done); > >>> __ blr(); > >>> > >> Fixed. Thanks!! > >>> return entry; > >>> > >>> Besides this, the change looks good. > >> Thanks, > >> Coleen > >> > >>> Thanks and best regards, > >>> Goetz. > >>> > >>> PS: is it possible to share your Copyright script? > >>> > >>>> -----Original Message----- > >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] > On > >>>> Behalf Of Coleen Phillimore > >>>> Sent: Monday, January 04, 2016 11:43 PM > >>>> To: hotspot-dev developers > >>>> Subject: RFR (M) 8146410: Interpreter functions are declared and > defined > >> in > >>>> the wrong files > >>>> > >>>> Summary: Moved functions to the correct files. > >>>> > >>>> See bug for more details. > >>>> > >>>> I basically did an hg mv templateInterpreter_.cpp > >>>> abstractInterpreter_.cpp and moved the interpreter_.cpp > >>>> functions there. > >>>> > >>>> Also moved generate_slow_signature_handler to > >>>> TemplateInterpreterGenerator/CppInterpreterGenerator because it's > >> not > >>>> shared. > >>>> > >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ > >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 > >>>> > >>>> Tested with JPRT on Oracle supported platforms and built zero on linux > >>>> x86. Also fixed change that broke zero in stack_zero.inline.hpp. I > >>>> think this should work on PPC and AARCH64, but please let me know. > >>>> > >>>> One question for AARCH64 platform in file: > >>>> > >>>> > >> > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat > >>>> eInterpreterGenerator_aarch64.cpp.udiff.html > >>>> > >>>> thanks, > >>>> Coleen From coleen.phillimore at oracle.com Tue Jan 5 21:00:52 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Jan 2016 16:00:52 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> Message-ID: <568C2F04.8020802@oracle.com> On 1/5/16 3:49 PM, Lindenmaier, Goetz wrote: > >> -----Original Message----- >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Dienstag, 5. Januar 2016 21:01 >> To: Lindenmaier, Goetz ; hotspot-dev >> developers >> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined >> in the wrong files >> >> >> >> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> I think they belong together because can_be_compiled() just returns >>> false for functions that have a math entry which is generated by >>> generate_math_entry(). So if you add a new math_entry, you >>> also have to fix can_be_compiled. We wired this dependency into >>> math_entry_available(kind), so that both functions are guaranteed >>> to behave similar. >> I'm getting confused by this. It seems like math_entry_available should >> be in templateInterpreterGenerator near generate_math_entry. >> >> The reason I don't want can_be_compiled (which is misleading) is because >> all the other platforms have it too and I don't want them in the wrong >> files. >> >> what do you think? > What I mean is can_be_compiled() should be moved to class > templateInterpreterGenerator and placed near generate_math_entry() > on all platforms. > The similarity is the same on all of them. > > But I must admit in compilationPolicy.cpp it reads better if the > AbstractInterpreter is asked. Also, method_kind is member > of AbstractInterpreter. Yes, that's what I thought. It's more of an Interpreter:: method. And it's a static function and the functions in TemplateInterpreterGenerator are not generally static functions. I didn't want to move the others there. > > But method_kind is also completely over-engeneered, as it's > only used in can_be_compiled, and there it's only used > for math entries... > > Maybe a change of it's own is needed... I'm holding my head in pain, and my change is too big already to add this. I did move math_entry_available because to templateInterpreterGenerator_ppc.cpp because there is no templateInterpreter_ppc.cpp anymore (there would only be this one function and the sizing). I think this looks good and better than having TemplateInterpreter::math_entry_available() in abstractInterpreter_ppc.cpp. See: http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp.udiff.html I think moving can_be_compiled and cleaning up the method_kind vs. intrinsics is a bigger problem to solve, and should be attempted in a further RFE. Thanks, Coleen > > Best regards, > Goetz. > > > > > > > >> Coleen >>> The name of the function is kind of misleading to me. >>> >>> But I won't insist... >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>>> -----Original Message----- >>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>> Sent: Tuesday, January 05, 2016 7:17 PM >>>> To: Lindenmaier, Goetz ; hotspot-dev >>>> developers >>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >> defined >>>> in the wrong files >>>> >>>> >>>> >>>> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: >>>>> Hi Coleen, >>>>> >>>>> Could you please also move >>>>> AbstractInterpreter::can_be_compiled(methodHandle m) >>>>> to above >>>>> >> TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: >>>> MethodKind kind)? >>>>> I think these belong together. >>>> Really? They're in different classes (hence the motivation for the >>>> change) and generate_math_entry doesn't call can_be_compiled. >>>> CompilationPolicy does but it calls it from >>>> AbstractInterpreter::can_be_compiled() so I really can't move this >>>> function into TemplateInterpreterGenerator. It doesn't make sense to >> me. >>>>> We seem to have different BIND macros on ppc. The '__' is also in the >>>>> macro. Could you please fix this small issue? It breaks the ppc build. >>>>> >>>>> diff -r 743aa331fc90 >>>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >>>>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>> Jan 05 07:47:21 2016 +0100 >>>>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>> Jan 05 08:06:12 2016 +0100 >>>>> @@ -416,7 +416,7 @@ >>>>> default: ShouldNotReachHere(); >>>>> } >>>>> >>>>> - __ BIND(done); >>>>> + BIND(done); >>>>> __ blr(); >>>>> >>>> Fixed. Thanks!! >>>>> return entry; >>>>> >>>>> Besides this, the change looks good. >>>> Thanks, >>>> Coleen >>>> >>>>> Thanks and best regards, >>>>> Goetz. >>>>> >>>>> PS: is it possible to share your Copyright script? >>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] >> On >>>>>> Behalf Of Coleen Phillimore >>>>>> Sent: Monday, January 04, 2016 11:43 PM >>>>>> To: hotspot-dev developers >>>>>> Subject: RFR (M) 8146410: Interpreter functions are declared and >> defined >>>> in >>>>>> the wrong files >>>>>> >>>>>> Summary: Moved functions to the correct files. >>>>>> >>>>>> See bug for more details. >>>>>> >>>>>> I basically did an hg mv templateInterpreter_.cpp >>>>>> abstractInterpreter_.cpp and moved the interpreter_.cpp >>>>>> functions there. >>>>>> >>>>>> Also moved generate_slow_signature_handler to >>>>>> TemplateInterpreterGenerator/CppInterpreterGenerator because it's >>>> not >>>>>> shared. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >>>>>> >>>>>> Tested with JPRT on Oracle supported platforms and built zero on linux >>>>>> x86. Also fixed change that broke zero in stack_zero.inline.hpp. I >>>>>> think this should work on PPC and AARCH64, but please let me know. >>>>>> >>>>>> One question for AARCH64 platform in file: >>>>>> >>>>>> >> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >>>>>> eInterpreterGenerator_aarch64.cpp.udiff.html >>>>>> >>>>>> thanks, >>>>>> Coleen From coleen.phillimore at oracle.com Tue Jan 5 21:19:33 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Jan 2016 16:19:33 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568C2F04.8020802@oracle.com> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> <568C2F04.8020802@oracle.com> Message-ID: <568C3365.5000502@oracle.com> Hi, Please see updated webrev for comments so far: http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/ Tested again with JPRT (on all Oracle supported platforms). thanks, Coleen On 1/5/16 4:00 PM, Coleen Phillimore wrote: > > > On 1/5/16 3:49 PM, Lindenmaier, Goetz wrote: >> >>> -----Original Message----- >>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>> Sent: Dienstag, 5. Januar 2016 21:01 >>> To: Lindenmaier, Goetz ; hotspot-dev >>> developers >>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>> defined >>> in the wrong files >>> >>> >>> >>> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: >>>> Hi Coleen, >>>> >>>> I think they belong together because can_be_compiled() just returns >>>> false for functions that have a math entry which is generated by >>>> generate_math_entry(). So if you add a new math_entry, you >>>> also have to fix can_be_compiled. We wired this dependency into >>>> math_entry_available(kind), so that both functions are guaranteed >>>> to behave similar. >>> I'm getting confused by this. It seems like math_entry_available >>> should >>> be in templateInterpreterGenerator near generate_math_entry. >>> >>> The reason I don't want can_be_compiled (which is misleading) is >>> because >>> all the other platforms have it too and I don't want them in the wrong >>> files. >>> >>> what do you think? >> What I mean is can_be_compiled() should be moved to class >> templateInterpreterGenerator and placed near generate_math_entry() >> on all platforms. >> The similarity is the same on all of them. >> >> But I must admit in compilationPolicy.cpp it reads better if the >> AbstractInterpreter is asked. Also, method_kind is member >> of AbstractInterpreter. > > Yes, that's what I thought. It's more of an Interpreter:: method. And > it's a static function and the functions in > TemplateInterpreterGenerator are not generally static functions. I > didn't want to move the others there. > >> >> But method_kind is also completely over-engeneered, as it's >> only used in can_be_compiled, and there it's only used >> for math entries... >> >> Maybe a change of it's own is needed... > > I'm holding my head in pain, and my change is too big already to add > this. I did move math_entry_available because to > templateInterpreterGenerator_ppc.cpp because there is no > templateInterpreter_ppc.cpp anymore (there would only be this one > function and the sizing). I think this looks good and better than > having TemplateInterpreter::math_entry_available() in > abstractInterpreter_ppc.cpp. See: > > http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp.udiff.html > > > I think moving can_be_compiled and cleaning up the method_kind vs. > intrinsics is a bigger problem to solve, and should be attempted in a > further RFE. > > Thanks, > Coleen > >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >>> Coleen >>>> The name of the function is kind of misleading to me. >>>> >>>> But I won't insist... >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>> Sent: Tuesday, January 05, 2016 7:17 PM >>>>> To: Lindenmaier, Goetz ; hotspot-dev >>>>> developers >>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>> defined >>>>> in the wrong files >>>>> >>>>> >>>>> >>>>> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> Could you please also move >>>>>> AbstractInterpreter::can_be_compiled(methodHandle m) >>>>>> to above >>>>>> >>> TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: >>>>> MethodKind kind)? >>>>>> I think these belong together. >>>>> Really? They're in different classes (hence the motivation for the >>>>> change) and generate_math_entry doesn't call can_be_compiled. >>>>> CompilationPolicy does but it calls it from >>>>> AbstractInterpreter::can_be_compiled() so I really can't move this >>>>> function into TemplateInterpreterGenerator. It doesn't make sense to >>> me. >>>>>> We seem to have different BIND macros on ppc. The '__' is also in >>>>>> the >>>>>> macro. Could you please fix this small issue? It breaks the ppc >>>>>> build. >>>>>> >>>>>> diff -r 743aa331fc90 >>>>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >>>>>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>>> Jan 05 07:47:21 2016 +0100 >>>>>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>>> Jan 05 08:06:12 2016 +0100 >>>>>> @@ -416,7 +416,7 @@ >>>>>> default: ShouldNotReachHere(); >>>>>> } >>>>>> >>>>>> - __ BIND(done); >>>>>> + BIND(done); >>>>>> __ blr(); >>>>>> >>>>> Fixed. Thanks!! >>>>>> return entry; >>>>>> >>>>>> Besides this, the change looks good. >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> Thanks and best regards, >>>>>> Goetz. >>>>>> >>>>>> PS: is it possible to share your Copyright script? >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] >>> On >>>>>>> Behalf Of Coleen Phillimore >>>>>>> Sent: Monday, January 04, 2016 11:43 PM >>>>>>> To: hotspot-dev developers >>>>>>> Subject: RFR (M) 8146410: Interpreter functions are declared and >>> defined >>>>> in >>>>>>> the wrong files >>>>>>> >>>>>>> Summary: Moved functions to the correct files. >>>>>>> >>>>>>> See bug for more details. >>>>>>> >>>>>>> I basically did an hg mv templateInterpreter_.cpp >>>>>>> abstractInterpreter_.cpp and moved the interpreter_.cpp >>>>>>> functions there. >>>>>>> >>>>>>> Also moved generate_slow_signature_handler to >>>>>>> TemplateInterpreterGenerator/CppInterpreterGenerator because it's >>>>> not >>>>>>> shared. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >>>>>>> >>>>>>> Tested with JPRT on Oracle supported platforms and built zero on >>>>>>> linux >>>>>>> x86. Also fixed change that broke zero in >>>>>>> stack_zero.inline.hpp. I >>>>>>> think this should work on PPC and AARCH64, but please let me know. >>>>>>> >>>>>>> One question for AARCH64 platform in file: >>>>>>> >>>>>>> >>> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >>>>>>> eInterpreterGenerator_aarch64.cpp.udiff.html >>>>>>> >>>>>>> thanks, >>>>>>> Coleen > From david.holmes at oracle.com Wed Jan 6 04:05:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Jan 2016 14:05:33 +1000 Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT In-Reply-To: <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> References: <04c701d13d7b$01b388f0$051a9ad0$@oracle.com> <8A31C5F6-4DED-475E-975E-F664784FB364@oracle.com> Message-ID: <568C928D.4040403@oracle.com> On 24/12/2015 8:15 AM, Christian Thalinger wrote: > David Holmes said he wanted a JPRT run to see the impact. Did you look at the times I put in the bug? Thanks for that info. David >> On Dec 23, 2015, at 2:11 AM, Christian Tornqvist wrote: >> >> Hi Chris, >> >> This looks good. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of >> Christian Thalinger >> Sent: Tuesday, December 22, 2015 6:07 PM >> To: hotspot-dev developers >> Subject: RFR (XXS): 8146043: run JVMCI tests in JPRT >> >> https://bugs.openjdk.java.net/browse/JDK-8146043 >> >> Running all JVMCI tests on my MacBook takes about 2 minutes: >> >> Test results: passed: 63; error: 3 >> Results written to /private/tmp/twisti >> Error: Some tests failed or other problems occurred. >> >> real 2m6.236s >> user 4m7.922s >> sys 0m14.363s >> >> Looking at a few JPRT jobs it seems hotspot_compiler_2 takes the least >> amount of time currently. >> >> diff -r 46122d93612d test/TEST.groups >> --- a/test/TEST.groups Mon Dec 21 22:17:23 2015 +0100 >> +++ b/test/TEST.groups Tue Dec 22 13:02:47 2015 -1000 >> @@ -279,6 +279,7 @@ hotspot_compiler_2 = \ >> compiler/inlining/ \ >> compiler/integerArithmetic/ \ >> compiler/interpreter/ \ >> + compiler/jvmci/ \ >> -compiler/codegen/7184394 \ >> -compiler/codecache/stress >> >> >> > From david.holmes at oracle.com Wed Jan 6 05:42:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Jan 2016 15:42:56 +1000 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568C007E.6060807@oracle.com> References: <568C007E.6060807@oracle.com> Message-ID: <568CA960.40202@oracle.com> Hi Rachel, On 6/01/2016 3:42 AM, Rachel Protacio wrote: > Hi, > > Please review this fix allowing TraceExceptionTest.java to pass with > compiled code. c1_Runtime1.cpp had been missing the necessary long-form > message, which has been added, and at the same time I discovered > bytecodeInterpreter.cpp was similarly lacking, though no test had turned > it up. So really this is extending the change introduced by: https://bugs.openjdk.java.net/browse/JDK-8048933 which begs the question as to why that change was only made for interpreted code in the first place? Changes look okay but I can't vouch for the validity of those calls in that particular context. Thanks, David > Passes JPRT and RBT tests. > > Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 > > Thanks, > Rachel From filipp.zhinkin at gmail.com Wed Jan 6 13:00:14 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Wed, 6 Jan 2016 16:00:14 +0300 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform In-Reply-To: <4CE12B2E-FDEF-48E0-AA84-E410DC09CE53@oracle.com> References: <4CE12B2E-FDEF-48E0-AA84-E410DC09CE53@oracle.com> Message-ID: Hi Igor, here are RFEs for tests relocation and ClassFileInstaller relocation: https://bugs.openjdk.java.net/browse/JDK-8146549 https://bugs.openjdk.java.net/browse/JDK-8146550 Thanks, Filipp. On Sat, Jan 2, 2016 at 2:59 PM, Igor Ignatyev wrote: > Hi Filipp, > > there is no options to make ?@library /test/lib? works. there is ?external.lib.roots? property in TEST.ROOT files, which adds additional root for @library. I noticed that there is no /test/lib-test isn?t a part of any test-suites, hence moving test to test/lib-test implies extra work in infra. given that I think it?ll be better to do it lately and separately from 8066599. please file an RFE for that. > > on 2nd question, I think it makes sense to move ClassFileInstaller to jdk.test.lib and annotate ClassFileInstaller in both jdk/test/lib/testlibrary/ and hotspot/test/testlibrary/ w/ @Deprectate. and I also think it?d be better to do it separately. > > Thanks, > Igor > >> On Dec 25, 2015, at 12:41 PM, Filipp Zhinkin wrote: >> >> Hi Igor, >> >> thanks for looking at this change. >> >> On Thu, Dec 24, 2015 at 9:24 PM, Igor Ignatyev wrote: >>> Hi Filipp, >>> >>> could you please move TestMutuallyExclusivePlatformPredicates and TestPlatformIsTieredSupported from hotspot/testlibrary_tests/ to test/lib-test and update it according to your changes? please note that we started to use packages in our tests. >> >> Sure, I'll move it. >> >> Do I need to pass any specific options to jtreg to make '@library >> /test/lib' work? >> At the moment jtreg can't locate it unless I specify >> '/../../test/lib/share/classes'. >> >> Does it make sense to also move ClassFileInstaller to jdk.test.lib? >> >> >> Thanks, >> Filipp. >> >>> >>> otherwise looks good to me. >>> >>> Thanks, >>> ? Igor >>> >>>> On Dec 22, 2015, at 10:36 AM, Filipp Zhinkin wrote: >>>> >>>> Hi all, >>>> >>>> please review a small change that adds VM mode checking methods to >>>> jdk.test.lib.Platform. >>>> I didn't touch Platform class from hotspot/test/testlibrary, because >>>> it is already deprecated and at some point of time all hs tests will >>>> be updated to use j.t.l.Platform instead. >>>> Update of hs tests that use own logic to check VM mode is tracked by >>>> JDK-8145848 [1]. >>>> >>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 >>>> Testing: on local machine with different VM modes. >>>> >>>> Regards, >>>> Filipp. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8145848 >>> > From rachel.protacio at oracle.com Wed Jan 6 19:47:12 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 6 Jan 2016 14:47:12 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568CA960.40202@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> Message-ID: <568D6F40.90806@oracle.com> Thanks for the review, David. My impression was that no one had realized that the detailed message was needed anywhere else in that original 8048933, so this is just a matter of thoroughness, but maybe Coleen can speak to that? Rachel On 1/6/2016 12:42 AM, David Holmes wrote: > Hi Rachel, > > On 6/01/2016 3:42 AM, Rachel Protacio wrote: >> Hi, >> >> Please review this fix allowing TraceExceptionTest.java to pass with >> compiled code. c1_Runtime1.cpp had been missing the necessary long-form >> message, which has been added, and at the same time I discovered >> bytecodeInterpreter.cpp was similarly lacking, though no test had turned >> it up. > > So really this is extending the change introduced by: > > https://bugs.openjdk.java.net/browse/JDK-8048933 > > which begs the question as to why that change was only made for > interpreted code in the first place? > > Changes look okay but I can't vouch for the validity of those calls in > that particular context. > > Thanks, > David > >> Passes JPRT and RBT tests. >> >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >> >> Thanks, >> Rachel From coleen.phillimore at oracle.com Wed Jan 6 20:30:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Jan 2016 15:30:17 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568D6F40.90806@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> Message-ID: <568D7959.7090003@oracle.com> Yes, I missed the one in the compiler file. I would really like if there was only one function for this logging though, but am trying to think of the best place for it. Coleen On 1/6/16 2:47 PM, Rachel Protacio wrote: > Thanks for the review, David. My impression was that no one had > realized that the detailed message was needed anywhere else in that > original 8048933, so this is just a matter of thoroughness, but maybe > Coleen can speak to that? > > Rachel > > On 1/6/2016 12:42 AM, David Holmes wrote: >> Hi Rachel, >> >> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>> Hi, >>> >>> Please review this fix allowing TraceExceptionTest.java to pass with >>> compiled code. c1_Runtime1.cpp had been missing the necessary long-form >>> message, which has been added, and at the same time I discovered >>> bytecodeInterpreter.cpp was similarly lacking, though no test had >>> turned >>> it up. >> >> So really this is extending the change introduced by: >> >> https://bugs.openjdk.java.net/browse/JDK-8048933 >> >> which begs the question as to why that change was only made for >> interpreted code in the first place? >> >> Changes look okay but I can't vouch for the validity of those calls >> in that particular context. >> >> Thanks, >> David >> >>> Passes JPRT and RBT tests. >>> >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>> >>> Thanks, >>> Rachel > From coleen.phillimore at oracle.com Wed Jan 6 20:35:42 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Jan 2016 15:35:42 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568D7959.7090003@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> <568D7959.7090003@oracle.com> Message-ID: <568D7A9E.20700@oracle.com> On 1/6/16 3:30 PM, Coleen Phillimore wrote: > > Yes, I missed the one in the compiler file. I would really like if > there was only one function for this logging though, but am trying to > think of the best place for it. So can this be consolidated into Exceptions::log_exception() in src/share/vm/utilities/exceptions.hpp/cpp ? Thanks, Coleen > > Coleen > > > On 1/6/16 2:47 PM, Rachel Protacio wrote: >> Thanks for the review, David. My impression was that no one had >> realized that the detailed message was needed anywhere else in that >> original 8048933, so this is just a matter of thoroughness, but maybe >> Coleen can speak to that? >> >> Rachel >> >> On 1/6/2016 12:42 AM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> Please review this fix allowing TraceExceptionTest.java to pass with >>>> compiled code. c1_Runtime1.cpp had been missing the necessary >>>> long-form >>>> message, which has been added, and at the same time I discovered >>>> bytecodeInterpreter.cpp was similarly lacking, though no test had >>>> turned >>>> it up. >>> >>> So really this is extending the change introduced by: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8048933 >>> >>> which begs the question as to why that change was only made for >>> interpreted code in the first place? >>> >>> Changes look okay but I can't vouch for the validity of those calls >>> in that particular context. >>> >>> Thanks, >>> David >>> >>>> Passes JPRT and RBT tests. >>>> >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>>> >>>> Thanks, >>>> Rachel >> > From coleen.phillimore at oracle.com Wed Jan 6 21:11:57 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Jan 2016 16:11:57 -0500 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> <56730A4E.3020204@oracle.com> Message-ID: <568D831D.5050104@oracle.com> On 12/29/15 1:58 PM, Christian Thalinger wrote: > >> On Dec 17, 2015, at 9:17 AM, Coleen Phillimore >> > >> wrote: >> >> >> >> On 12/17/15 2:08 PM, Christian Thalinger wrote: >>>> On Dec 17, 2015, at 9:03 AM, Tom Rodriguez >>>> > wrote: >>>> >>>> >>>>> On Dec 17, 2015, at 10:53 AM, Christian Thalinger >>>>> >>>> > wrote: >>>>> >>>>> >>>>>> On Dec 17, 2015, at 8:28 AM, Tom Rodriguez >>>>>> > wrote: >>>>>> >>>>>> I think the ttyLocker should be in print_stack_trace. >>>>> Well, the problem is that ttyLocker only locks >>>>> defaultStream::instance (whatever that is) but print_stack_trace >>>>> can take any outputStream. >>>> Well maybe it shouldn?t. No one uses that flexibility but having a >>>> ttyLocker would be practically useful. >>> True. I?m tempted to make that change but I see more bike-shedding >>> coming up. Maybe if Coleen is okay with that? ;-) >> >> No, just leave it where it was.... With logging the ttyLocker >> doesn't work anyway. > > Well, turns out that we can?t hold the tty lock when calling out to Java: > > https://bugs.openjdk.java.net/browse/JDK-8146246 > > Either we give up the lock completely or we call out to Java code to > do the printing for us (which was there in the first place). Since we > are already calling out to Java (to Throwable.getCause) calling Java > code at that point must work. I finally had some time to look at this. I was surprised that I never noticed that we call out to Java to get the cause. If you call out to Java to print the stack trace, I see a lock on the stream so at least the stack and cause are together. Just not the exception line. Can you add a function to java_lang_Throwable to print the exception name and stack trace or is that not allowed? I don't know. I wonder if we can remove the jvm's java_lang_Throwable::print_stack_trace altogether. It doesn't have to be fast at all so could call java (which calls back into the jvm for each stack trace element). Maybe it's needed for bootstrapping (but there it's already created an exception object) or for OutOfMemoryError? Or remove the ttyLocker in your calls. I don't have the entire context for the motivation for this change. Coleen > >> >> Coleen >>> >>>> Anyway, it?s ok as is too. >>>> >>>> tom >>>> >>>>>> A short comment on print_stack_trace explaining that it prints >>>>>> the exception message along with the exception chain wouldn?t >>>>>> hurt. Otherwise looks good. >>>>> Sure. >>>>> >>>>>> tom >>>>>> >>>>>>> On Dec 17, 2015, at 9:46 AM, Christian Thalinger >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> On Dec 17, 2015, at 3:56 AM, Doug Simon >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 17 Dec 2015, at 08:20, Tom Rodriguez >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>>>> I feel like there was a reason we weren?t using >>>>>>>>>>>> java_lang_Throwable::print_stack_trace but it looks like it >>>>>>>>>>>> handles the causes properly which is the only reason I >>>>>>>>>>>> could think of. Maybe Doug knows? >>>>>>>>>>> >>>>>>>>>>> There are two issues with >>>>>>>>>>> java_lang_Throwable::print_stack_trace: >>>>>>>>>>> >>>>>>>>>>> 1. It doesn?t print the exception message, just the stack. >>>>>>>>>> I?m printing the message separately: >>>>>>>>>> >>>>>>>>>> java_lang_Throwable::print(exception, tty); >>>>>>>>>> tty->cr(); >>>>>>>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>>>>>>> There are already 3 other copies of this idiom. Throwable >>>>>>>>> should probably have a single method for this. Or maybe >>>>>>>>> print_stack_trace itself should do this? >>>>>>>> +1 >>>>>>>> >>>>>>>>> That would better parallel Throwable.printStackTrace(). >>>>>>>> Makes sense to me! >>>>>>> It does. Here it goes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ >>>>>>> >>>>>>> >>>>>> > >>>>>>> >>>>>>> I?ve made java_lang_Throwable::print_stack_trace to take a >>>>>>> Handle instead of an oop and removed the unneeded copy of >>>>>>> java_lang_Throwable::print. >>>>>>> >>>>>>>> -Doug > From christian.thalinger at oracle.com Wed Jan 6 22:55:56 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 6 Jan 2016 12:55:56 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <568D831D.5050104@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> <56730A4E.3020204@oracle.com> <568D831D.5050104@oracle.com> Message-ID: <0300CB25-EDB1-473C-A001-5E16F2951E8C@oracle.com> > On Jan 6, 2016, at 11:11 AM, Coleen Phillimore wrote: > > > > On 12/29/15 1:58 PM, Christian Thalinger wrote: >> >>> On Dec 17, 2015, at 9:17 AM, Coleen Phillimore > wrote: >>> >>> >>> >>> On 12/17/15 2:08 PM, Christian Thalinger wrote: >>>>> On Dec 17, 2015, at 9:03 AM, Tom Rodriguez > wrote: >>>>> >>>>> >>>>>> On Dec 17, 2015, at 10:53 AM, Christian Thalinger < christian.thalinger at oracle.com > wrote: >>>>>> >>>>>> >>>>>>> On Dec 17, 2015, at 8:28 AM, Tom Rodriguez > wrote: >>>>>>> >>>>>>> I think the ttyLocker should be in print_stack_trace. >>>>>> Well, the problem is that ttyLocker only locks defaultStream::instance (whatever that is) but print_stack_trace can take any outputStream. >>>>> Well maybe it shouldn?t. No one uses that flexibility but having a ttyLocker would be practically useful. >>>> True. I?m tempted to make that change but I see more bike-shedding coming up. Maybe if Coleen is okay with that? ;-) >>> >>> No, just leave it where it was.... With logging the ttyLocker doesn't work anyway. >> >> Well, turns out that we can?t hold the tty lock when calling out to Java: >> >> https://bugs.openjdk.java.net/browse/JDK-8146246 >> >> Either we give up the lock completely or we call out to Java code to do the printing for us (which was there in the first place). Since we are already calling out to Java (to Throwable.getCause) calling Java code at that point must work. > > I finally had some time to look at this. I was surprised that I never noticed that we call out to Java to get the cause. If you call out to Java to print the stack trace, I see a lock on the stream so at least the stack and cause are together. Just not the exception line. Can you add a function to java_lang_Throwable to print the exception name and stack trace or is that not allowed? > > I don't know. I wonder if we can remove the jvm's java_lang_Throwable::print_stack_trace altogether. It doesn't have to be fast at all so could call java (which calls back into the jvm for each stack trace element). Maybe it's needed for bootstrapping (but there it's already created an exception object) or for OutOfMemoryError? I think it?s needed for bootstrapping in: void vm_exit_during_initialization(Handle exception) { Although that?s the only place that seems to really need it. The other usages in ciReplay should be able to handle calls out to Java. > > Or remove the ttyLocker in your calls. I don't have the entire context for the motivation for this change. Did you see my other review for 8146246? I sent it to the wrong list. > > Coleen > >> >>> >>> Coleen >>>> >>>>> Anyway, it?s ok as is too. >>>>> >>>>> tom >>>>> >>>>>>> A short comment on print_stack_trace explaining that it prints the exception message along with the exception chain wouldn?t hurt. Otherwise looks good. >>>>>> Sure. >>>>>> >>>>>>> tom >>>>>>> >>>>>>>> On Dec 17, 2015, at 9:46 AM, Christian Thalinger < christian.thalinger at oracle.com > wrote: >>>>>>>> >>>>>>>>> On Dec 17, 2015, at 3:56 AM, Doug Simon < doug.simon at oracle.com >> wrote: >>>>>>>>> >>>>>>>>>> On 17 Dec 2015, at 08:20, Tom Rodriguez < tom.rodriguez at oracle.com > wrote: >>>>>>>>>> >>>>>>>>>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>>>>>>>>> >>>>>>>>>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>>>>>>>>> >>>>>>>>>>>> 1. It doesn?t print the exception message, just the stack. >>>>>>>>>>> I?m printing the message separately: >>>>>>>>>>> >>>>>>>>>>> java_lang_Throwable::print(exception, tty); >>>>>>>>>>> tty->cr(); >>>>>>>>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>>>>>>>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >>>>>>>>> +1 >>>>>>>>> >>>>>>>>>> That would better parallel Throwable.printStackTrace(). >>>>>>>>> Makes sense to me! >>>>>>>> It does. Here it goes: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ > >>>>>>>> >>>>>>>> I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. >>>>>>>> >>>>>>>>> -Doug >> > From coleen.phillimore at oracle.com Wed Jan 6 23:06:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Jan 2016 18:06:32 -0500 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <0300CB25-EDB1-473C-A001-5E16F2951E8C@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> <56730A4E.3020204@oracle.com> <568D831D.5050104@oracle.com> <0300CB25-EDB1-473C-A001-5E16F2951E8C@oracle.com> Message-ID: <568D9DF8.50203@oracle.com> On 1/6/16 5:55 PM, Christian Thalinger wrote: > >> On Jan 6, 2016, at 11:11 AM, Coleen Phillimore >> > >> wrote: >> >> >> >> On 12/29/15 1:58 PM, Christian Thalinger wrote: >>> >>>> On Dec 17, 2015, at 9:17 AM, Coleen Phillimore >>>> >>> > wrote: >>>> >>>> >>>> >>>> On 12/17/15 2:08 PM, Christian Thalinger wrote: >>>>>> On Dec 17, 2015, at 9:03 AM, Tom Rodriguez >>>>>> > wrote: >>>>>> >>>>>> >>>>>>> On Dec 17, 2015, at 10:53 AM, Christian Thalinger >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> On Dec 17, 2015, at 8:28 AM, Tom Rodriguez >>>>>>>> > wrote: >>>>>>>> >>>>>>>> I think the ttyLocker should be in print_stack_trace. >>>>>>> Well, the problem is that ttyLocker only locks >>>>>>> defaultStream::instance (whatever that is) but print_stack_trace >>>>>>> can take any outputStream. >>>>>> Well maybe it shouldn?t. No one uses that flexibility but having >>>>>> a ttyLocker would be practically useful. >>>>> True. I?m tempted to make that change but I see more >>>>> bike-shedding coming up. Maybe if Coleen is okay with that? ;-) >>>> >>>> No, just leave it where it was.... With logging the ttyLocker >>>> doesn't work anyway. >>> >>> Well, turns out that we can?t hold the tty lock when calling out to >>> Java: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8146246 >>> >>> Either we give up the lock completely or we call out to Java code to >>> do the printing for us (which was there in the first place). Since >>> we are already calling out to Java (to Throwable.getCause) calling >>> Java code at that point must work. >> >> I finally had some time to look at this. I was surprised that I >> never noticed that we call out to Java to get the cause. If you call >> out to Java to print the stack trace, I see a lock on the stream so >> at least the stack and cause are together. Just not the exception >> line. Can you add a function to java_lang_Throwable to print the >> exception name and stack trace or is that not allowed? >> >> I don't know. I wonder if we can remove the jvm's >> java_lang_Throwable::print_stack_trace altogether. It doesn't have >> to be fast at all so could call java (which calls back into the jvm >> for each stack trace element). Maybe it's needed for bootstrapping >> (but there it's already created an exception object) or for >> OutOfMemoryError? > > I think it?s needed for bootstrapping in: > > void vm_exit_during_initialization(Handle exception) { > > Although that?s the only place that seems to really need it. The > other usages in ciReplay should be able to handle calls out to Java. In the initialization case, you can only get there if java_lang_Throwable is already initialized (an exception has been created), so I think it's probably fine to call up to Java. Love to get rid of more code that uses BacktraceBuilder and the weird arrays. > >> >> Or remove the ttyLocker in your calls. I don't have the entire >> context for the motivation for this change. > > Did you see my other review for 8146246? I sent it to the wrong list. > No, I didn't. Coleen >> >> Coleen >> >>> >>>> >>>> Coleen >>>>> >>>>>> Anyway, it?s ok as is too. >>>>>> >>>>>> tom >>>>>> >>>>>>>> A short comment on print_stack_trace explaining that it prints >>>>>>>> the exception message along with the exception chain wouldn?t >>>>>>>> hurt. Otherwise looks good. >>>>>>> Sure. >>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>> On Dec 17, 2015, at 9:46 AM, Christian Thalinger >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Dec 17, 2015, at 3:56 AM, Doug Simon >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> On 17 Dec 2015, at 08:20, Tom Rodriguez >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>>>> I feel like there was a reason we weren?t using >>>>>>>>>>>>>> java_lang_Throwable::print_stack_trace but it looks like >>>>>>>>>>>>>> it handles the causes properly which is the only reason I >>>>>>>>>>>>>> could think of. Maybe Doug knows? >>>>>>>>>>>>> >>>>>>>>>>>>> There are two issues with >>>>>>>>>>>>> java_lang_Throwable::print_stack_trace: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. It doesn?t print the exception message, just the stack. >>>>>>>>>>>> I?m printing the message separately: >>>>>>>>>>>> >>>>>>>>>>>> java_lang_Throwable::print(exception, tty); >>>>>>>>>>>> tty->cr(); >>>>>>>>>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>>>>>>>>> There are already 3 other copies of this idiom. Throwable >>>>>>>>>>> should probably have a single method for this. Or maybe >>>>>>>>>>> print_stack_trace itself should do this? >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>>> That would better parallel Throwable.printStackTrace(). >>>>>>>>>> Makes sense to me! >>>>>>>>> It does. Here it goes: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ >>>>>>>>> >>>>>>>>> >>>>>>>> > >>>>>>>>> >>>>>>>>> I?ve made java_lang_Throwable::print_stack_trace to take a >>>>>>>>> Handle instead of an oop and removed the unneeded copy of >>>>>>>>> java_lang_Throwable::print. >>>>>>>>> >>>>>>>>>> -Doug >>> >> > From goetz.lindenmaier at sap.com Thu Jan 7 08:08:11 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Jan 2016 08:08:11 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568C3365.5000502@oracle.com> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> <568C2F04.8020802@oracle.com> <568C3365.5000502@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41EFC943@DEWDFEMB12A.global.corp.sap> Hi Coleen, sorry I didn't answer yesterday, we had another holiday. You moved PPCs math_entry_available() in your new change. I think it makes no difference where it's located, as long as it's called from both, interpreter and interpreterGenerator classes. But if you want to move it, you need to fix all the other occurances of the method, too: http://cr.openjdk.java.net/~goetz/wr16/8146410-interpCleanup/move_math_entry_available.patch Elsewise good. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Coleen Phillimore > Sent: Dienstag, 5. Januar 2016 22:20 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined > in the wrong files > > > Hi, Please see updated webrev for comments so far: > > http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/ > > Tested again with JPRT (on all Oracle supported platforms). > > thanks, > Coleen > > On 1/5/16 4:00 PM, Coleen Phillimore wrote: > > > > > > On 1/5/16 3:49 PM, Lindenmaier, Goetz wrote: > >> > >>> -----Original Message----- > >>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > >>> Sent: Dienstag, 5. Januar 2016 21:01 > >>> To: Lindenmaier, Goetz ; hotspot-dev > >>> developers > >>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and > >>> defined > >>> in the wrong files > >>> > >>> > >>> > >>> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: > >>>> Hi Coleen, > >>>> > >>>> I think they belong together because can_be_compiled() just returns > >>>> false for functions that have a math entry which is generated by > >>>> generate_math_entry(). So if you add a new math_entry, you > >>>> also have to fix can_be_compiled. We wired this dependency into > >>>> math_entry_available(kind), so that both functions are guaranteed > >>>> to behave similar. > >>> I'm getting confused by this. It seems like math_entry_available > >>> should > >>> be in templateInterpreterGenerator near generate_math_entry. > >>> > >>> The reason I don't want can_be_compiled (which is misleading) is > >>> because > >>> all the other platforms have it too and I don't want them in the wrong > >>> files. > >>> > >>> what do you think? > >> What I mean is can_be_compiled() should be moved to class > >> templateInterpreterGenerator and placed near generate_math_entry() > >> on all platforms. > >> The similarity is the same on all of them. > >> > >> But I must admit in compilationPolicy.cpp it reads better if the > >> AbstractInterpreter is asked. Also, method_kind is member > >> of AbstractInterpreter. > > > > Yes, that's what I thought. It's more of an Interpreter:: method. And > > it's a static function and the functions in > > TemplateInterpreterGenerator are not generally static functions. I > > didn't want to move the others there. > > > >> > >> But method_kind is also completely over-engeneered, as it's > >> only used in can_be_compiled, and there it's only used > >> for math entries... > >> > >> Maybe a change of it's own is needed... > > > > I'm holding my head in pain, and my change is too big already to add > > this. I did move math_entry_available because to > > templateInterpreterGenerator_ppc.cpp because there is no > > templateInterpreter_ppc.cpp anymore (there would only be this one > > function and the sizing). I think this looks good and better than > > having TemplateInterpreter::math_entry_available() in > > abstractInterpreter_ppc.cpp. See: > > > > > http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/src/cpu/ppc/vm/t > emplateInterpreterGenerator_ppc.cpp.udiff.html > > > > > > I think moving can_be_compiled and cleaning up the method_kind vs. > > intrinsics is a bigger problem to solve, and should be attempted in a > > further RFE. > > > > Thanks, > > Coleen > > > >> > >> Best regards, > >> Goetz. > >> > >> > >> > >> > >> > >> > >> > >>> Coleen > >>>> The name of the function is kind of misleading to me. > >>>> > >>>> But I won't insist... > >>>> > >>>> Best regards, > >>>> Goetz. > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > >>>>> Sent: Tuesday, January 05, 2016 7:17 PM > >>>>> To: Lindenmaier, Goetz ; hotspot-dev > >>>>> developers > >>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and > >>> defined > >>>>> in the wrong files > >>>>> > >>>>> > >>>>> > >>>>> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: > >>>>>> Hi Coleen, > >>>>>> > >>>>>> Could you please also move > >>>>>> AbstractInterpreter::can_be_compiled(methodHandle m) > >>>>>> to above > >>>>>> > >>> > TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: > >>>>> MethodKind kind)? > >>>>>> I think these belong together. > >>>>> Really? They're in different classes (hence the motivation for the > >>>>> change) and generate_math_entry doesn't call can_be_compiled. > >>>>> CompilationPolicy does but it calls it from > >>>>> AbstractInterpreter::can_be_compiled() so I really can't move this > >>>>> function into TemplateInterpreterGenerator. It doesn't make sense > to > >>> me. > >>>>>> We seem to have different BIND macros on ppc. The '__' is also in > >>>>>> the > >>>>>> macro. Could you please fix this small issue? It breaks the ppc > >>>>>> build. > >>>>>> > >>>>>> diff -r 743aa331fc90 > >>>>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > >>>>>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue > >>>>> Jan 05 07:47:21 2016 +0100 > >>>>>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue > >>>>> Jan 05 08:06:12 2016 +0100 > >>>>>> @@ -416,7 +416,7 @@ > >>>>>> default: ShouldNotReachHere(); > >>>>>> } > >>>>>> > >>>>>> - __ BIND(done); > >>>>>> + BIND(done); > >>>>>> __ blr(); > >>>>>> > >>>>> Fixed. Thanks!! > >>>>>> return entry; > >>>>>> > >>>>>> Besides this, the change looks good. > >>>>> Thanks, > >>>>> Coleen > >>>>> > >>>>>> Thanks and best regards, > >>>>>> Goetz. > >>>>>> > >>>>>> PS: is it possible to share your Copyright script? > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: hotspot-dev [mailto:hotspot-dev- > bounces at openjdk.java.net] > >>> On > >>>>>>> Behalf Of Coleen Phillimore > >>>>>>> Sent: Monday, January 04, 2016 11:43 PM > >>>>>>> To: hotspot-dev developers > >>>>>>> Subject: RFR (M) 8146410: Interpreter functions are declared and > >>> defined > >>>>> in > >>>>>>> the wrong files > >>>>>>> > >>>>>>> Summary: Moved functions to the correct files. > >>>>>>> > >>>>>>> See bug for more details. > >>>>>>> > >>>>>>> I basically did an hg mv templateInterpreter_.cpp > >>>>>>> abstractInterpreter_.cpp and moved the > interpreter_.cpp > >>>>>>> functions there. > >>>>>>> > >>>>>>> Also moved generate_slow_signature_handler to > >>>>>>> TemplateInterpreterGenerator/CppInterpreterGenerator because > it's > >>>>> not > >>>>>>> shared. > >>>>>>> > >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ > >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 > >>>>>>> > >>>>>>> Tested with JPRT on Oracle supported platforms and built zero on > >>>>>>> linux > >>>>>>> x86. Also fixed change that broke zero in > >>>>>>> stack_zero.inline.hpp. I > >>>>>>> think this should work on PPC and AARCH64, but please let me > know. > >>>>>>> > >>>>>>> One question for AARCH64 platform in file: > >>>>>>> > >>>>>>> > >>> > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat > >>>>>>> eInterpreterGenerator_aarch64.cpp.udiff.html > >>>>>>> > >>>>>>> thanks, > >>>>>>> Coleen > > From christian.thalinger at oracle.com Thu Jan 7 16:43:28 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 7 Jan 2016 06:43:28 -1000 Subject: RFR (M): 8145435: [JVMCI] some tests on Windows fail with: assert(!thread->is_Java_thread()) failed: must not be java thread In-Reply-To: <568D9DF8.50203@oracle.com> References: <2C308C21-C604-4357-9758-6C5D9E3AA09C@oracle.com> <5EC5DB8B-205F-40B0-85D2-3C009EFDA33B@oracle.com> <045BD056-2A36-4DBF-BFD2-4313750D2D74@oracle.com> <34273F9F-95C4-43A8-81F2-38F206738D9C@oracle.com> <4874A4F8-BB49-4DD9-87E7-8719D7851AD8@oracle.com> <02C27630-DD02-4D4B-8D3D-99F715C996D7@oracle.com> <04A84761-382F-42BA-B143-BF52B182B636@oracle.com> <2AE2D2D0-87ED-4794-A50F-818C1B05A373@oracle.com> <393F4221-839F-4BBE-8FBE-2BEF8E974BCB@oracle.com> <2E250702-A55C-43C0-B549-6E5D39A9DB4D@oracle.com> <56730A4E.3020204@oracle.com> <568D831D.5050104@oracle.com> <0300CB25-EDB1-473C-A001-5E16F2951E8C@oracle.com> <568D9DF8.50203@oracle.com> Message-ID: <780696A7-30B3-4005-A912-DA98FC5296EA@oracle.com> > On Jan 6, 2016, at 1:06 PM, Coleen Phillimore wrote: > > > > On 1/6/16 5:55 PM, Christian Thalinger wrote: >> >>> On Jan 6, 2016, at 11:11 AM, Coleen Phillimore > wrote: >>> >>> >>> >>> On 12/29/15 1:58 PM, Christian Thalinger wrote: >>>> >>>>> On Dec 17, 2015, at 9:17 AM, Coleen Phillimore > wrote: >>>>> >>>>> >>>>> >>>>> On 12/17/15 2:08 PM, Christian Thalinger wrote: >>>>>>> On Dec 17, 2015, at 9:03 AM, Tom Rodriguez > wrote: >>>>>>> >>>>>>> >>>>>>>> On Dec 17, 2015, at 10:53 AM, Christian Thalinger wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Dec 17, 2015, at 8:28 AM, Tom Rodriguez > wrote: >>>>>>>>> >>>>>>>>> I think the ttyLocker should be in print_stack_trace. >>>>>>>> Well, the problem is that ttyLocker only locks defaultStream::instance (whatever that is) but print_stack_trace can take any outputStream. >>>>>>> Well maybe it shouldn?t. No one uses that flexibility but having a ttyLocker would be practically useful. >>>>>> True. I?m tempted to make that change but I see more bike-shedding coming up. Maybe if Coleen is okay with that? ;-) >>>>> >>>>> No, just leave it where it was.... With logging the ttyLocker doesn't work anyway. >>>> >>>> Well, turns out that we can?t hold the tty lock when calling out to Java: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8146246 >>>> >>>> Either we give up the lock completely or we call out to Java code to do the printing for us (which was there in the first place). Since we are already calling out to Java (to Throwable.getCause) calling Java code at that point must work. >>> >>> I finally had some time to look at this. I was surprised that I never noticed that we call out to Java to get the cause. If you call out to Java to print the stack trace, I see a lock on the stream so at least the stack and cause are together. Just not the exception line. Can you add a function to java_lang_Throwable to print the exception name and stack trace or is that not allowed? >>> >>> I don't know. I wonder if we can remove the jvm's java_lang_Throwable::print_stack_trace altogether. It doesn't have to be fast at all so could call java (which calls back into the jvm for each stack trace element). Maybe it's needed for bootstrapping (but there it's already created an exception object) or for OutOfMemoryError? >> >> I think it?s needed for bootstrapping in: >> >> void vm_exit_during_initialization(Handle exception) { >> >> Although that?s the only place that seems to really need it. The other usages in ciReplay should be able to handle calls out to Java. > > In the initialization case, you can only get there if java_lang_Throwable is already initialized (an exception has been created), so I think it's probably fine to call up to Java. Love to get rid of more code that uses BacktraceBuilder and the weird arrays. If you think it?s fine I?m more than happy to make that change. > >> >>> >>> Or remove the ttyLocker in your calls. I don't have the entire context for the motivation for this change. >> >> Did you see my other review for 8146246? I sent it to the wrong list. >> > No, I didn?t. Let me change mailing lists for that one. > Coleen >>> >>> Coleen >>> >>>> >>>>> >>>>> Coleen >>>>>> >>>>>>> Anyway, it?s ok as is too. >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>>> A short comment on print_stack_trace explaining that it prints the exception message along with the exception chain wouldn?t hurt. Otherwise looks good. >>>>>>>> Sure. >>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>>> On Dec 17, 2015, at 9:46 AM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>>> On Dec 17, 2015, at 3:56 AM, Doug Simon > wrote: >>>>>>>>>>> >>>>>>>>>>>> On 17 Dec 2015, at 08:20, Tom Rodriguez wrote: >>>>>>>>>>>> >>>>>>>>>>>>>>> I feel like there was a reason we weren?t using java_lang_Throwable::print_stack_trace but it looks like it handles the causes properly which is the only reason I could think of. Maybe Doug knows? >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are two issues with java_lang_Throwable::print_stack_trace: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. It doesn?t print the exception message, just the stack. >>>>>>>>>>>>> I?m printing the message separately: >>>>>>>>>>>>> >>>>>>>>>>>>> java_lang_Throwable::print(exception, tty); >>>>>>>>>>>>> tty->cr(); >>>>>>>>>>>>> java_lang_Throwable::print_stack_trace(exception(), tty); >>>>>>>>>>>> There are already 3 other copies of this idiom. Throwable should probably have a single method for this. Or maybe print_stack_trace itself should do this? >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>>> That would better parallel Throwable.printStackTrace(). >>>>>>>>>>> Makes sense to me! >>>>>>>>>> It does. Here it goes: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~twisti/8145435/webrev.02/ > >>>>>>>>>> >>>>>>>>>> I?ve made java_lang_Throwable::print_stack_trace to take a Handle instead of an oop and removed the unneeded copy of java_lang_Throwable::print. >>>>>>>>>> >>>>>>>>>>> -Doug >>>> >>> >> > From christian.thalinger at oracle.com Thu Jan 7 16:45:43 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 7 Jan 2016 06:45:43 -1000 Subject: RFR (S): 8146246: JVMCICompiler::abort_on_pending_exception: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: <0C62FED5-F3F8-44CE-B1DB-095F9170370B@oracle.com> References: <568D6C63.5000403@oracle.com> <0C62FED5-F3F8-44CE-B1DB-095F9170370B@oracle.com> Message-ID: <80FAECCD-94BA-479C-B042-0A50D9121C8F@oracle.com> [Changing lists because it should have been on hotspot-dev.] Coleen, in case 2) below I could replace java_lang_Throwable::print_stack_trace with java_lang_Throwable::java_printStackTrace. > On Jan 6, 2016, at 12:57 PM, Christian Thalinger wrote: > > >> On Jan 6, 2016, at 9:34 AM, Vladimir Kozlov wrote: >> >> I would go with "Java code do the printing?. > > Yeah, it might be better. > >> You left ttyLocker in case 2) in src/share/vm/runtime/java.cpp > > Right. Thanks for pointing that out. > >> >> Thanks, >> Vladimir >> >> On 1/6/16 11:19 AM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8146246 >>> >>> The problem is that https://bugs.openjdk.java.net/browse/JDK-8145435 introduced ttyLocker to synchronize the exception output but java_lang_Throwable::print_stack_trace can call out to Java to get the cause. >>> >>> There are two solutions: >>> >>> 1) Remove ttyLocker and deal with some possible scrambling in the rare case of an exception: >>> >>> diff -r df8d635f2296 -r e87e187552fb src/share/vm/jvmci/jvmciCompiler.cpp >>> --- a/src/share/vm/jvmci/jvmciCompiler.cpp Tue Dec 29 11:24:01 2015 -0800 >>> +++ b/src/share/vm/jvmci/jvmciCompiler.cpp Thu Dec 31 09:20:16 2015 -0800 >>> @@ -162,10 +162,7 @@ void JVMCICompiler::compile_method(const >>> Handle exception(THREAD, PENDING_EXCEPTION); >>> CLEAR_PENDING_EXCEPTION; >>> >>> - { >>> - ttyLocker ttyl; >>> - java_lang_Throwable::print_stack_trace(exception, tty); >>> - } >>> + java_lang_Throwable::print_stack_trace(exception, tty); >>> >>> // Something went wrong so disable compilation at this level >>> method->set_not_compilable(CompLevel_full_optimization); >>> @@ -181,11 +178,8 @@ void JVMCICompiler::abort_on_pending_exc >>> Thread* THREAD = Thread::current(); >>> CLEAR_PENDING_EXCEPTION; >>> >>> - { >>> - ttyLocker ttyl; >>> - tty->print_raw_cr(message); >>> - java_lang_Throwable::print_stack_trace(exception, tty); >>> - } >>> + tty->print_raw_cr(message); >>> + java_lang_Throwable::print_stack_trace(exception, tty); >>> >>> // Give other aborting threads to also print their stack traces. >>> // This can be very useful when debugging class initialization >>> diff -r df8d635f2296 -r e87e187552fb src/share/vm/runtime/java.cpp >>> --- a/src/share/vm/runtime/java.cpp Tue Dec 29 11:24:01 2015 -0800 >>> +++ b/src/share/vm/runtime/java.cpp Thu Dec 31 09:20:16 2015 -0800 >>> @@ -432,7 +432,6 @@ void before_exit(JavaThread* thread) { >>> if (HAS_PENDING_EXCEPTION) { >>> Handle exception(THREAD, PENDING_EXCEPTION); >>> CLEAR_PENDING_EXCEPTION; >>> - ttyLocker ttyl; >>> java_lang_Throwable::print_stack_trace(exception, tty); >>> } >>> #endif >>> >>> or >>> >>> 2) Call out to Java and let the Java code do the printing: >>> >>> diff -r 0fcfe4b07f7e src/share/vm/classfile/javaClasses.cpp >>> --- a/src/share/vm/classfile/javaClasses.cpp Tue Dec 29 18:30:51 2015 +0100 >>> +++ b/src/share/vm/classfile/javaClasses.cpp Wed Jan 06 09:12:00 2016 -1000 >>> @@ -1784,6 +1784,20 @@ void java_lang_Throwable::print_stack_tr >>> } >>> } >>> >>> +/** >>> + * Print the throwable stack trace by calling the Java method java.lang.Throwable.printStackTrace(). >>> + */ >>> +void java_lang_Throwable::java_printStackTrace(Handle throwable, TRAPS) { >>> + assert(throwable->is_a(SystemDictionary::Throwable_klass()), "Throwable instance expected"); >>> + JavaValue result(T_VOID); >>> + JavaCalls::call_virtual(&result, >>> + throwable, >>> + KlassHandle(THREAD, SystemDictionary::Throwable_klass()), >>> + vmSymbols::printStackTrace_name(), >>> + vmSymbols::void_method_signature(), >>> + THREAD); >>> +} >>> + >>> void java_lang_Throwable::fill_in_stack_trace(Handle throwable, const methodHandle& method, TRAPS) { >>> if (!StackTraceInThrowable) return; >>> ResourceMark rm(THREAD); >>> diff -r 0fcfe4b07f7e src/share/vm/classfile/javaClasses.hpp >>> --- a/src/share/vm/classfile/javaClasses.hpp Tue Dec 29 18:30:51 2015 +0100 >>> +++ b/src/share/vm/classfile/javaClasses.hpp Wed Jan 06 09:12:00 2016 -1000 >>> @@ -554,6 +554,7 @@ class java_lang_Throwable: AllStatic { >>> // Printing >>> static void print(Handle throwable, outputStream* st); >>> static void print_stack_trace(Handle throwable, outputStream* st); >>> + static void java_printStackTrace(Handle throwable, TRAPS); >>> // Debugging >>> friend class JavaClasses; >>> }; >>> diff -r 0fcfe4b07f7e src/share/vm/jvmci/jvmciCompiler.cpp >>> --- a/src/share/vm/jvmci/jvmciCompiler.cpp Tue Dec 29 18:30:51 2015 +0100 >>> +++ b/src/share/vm/jvmci/jvmciCompiler.cpp Wed Jan 06 09:12:00 2016 -1000 >>> @@ -162,10 +162,7 @@ void JVMCICompiler::compile_method(const >>> Handle exception(THREAD, PENDING_EXCEPTION); >>> CLEAR_PENDING_EXCEPTION; >>> >>> - { >>> - ttyLocker ttyl; >>> - java_lang_Throwable::print_stack_trace(exception, tty); >>> - } >>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>> >>> // Something went wrong so disable compilation at this level >>> method->set_not_compilable(CompLevel_full_optimization); >>> @@ -181,11 +178,7 @@ void JVMCICompiler::abort_on_pending_exc >>> Thread* THREAD = Thread::current(); >>> CLEAR_PENDING_EXCEPTION; >>> >>> - { >>> - ttyLocker ttyl; >>> - tty->print_raw_cr(message); >>> - java_lang_Throwable::print_stack_trace(exception, tty); >>> - } >>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>> >>> // Give other aborting threads to also print their stack traces. >>> // This can be very useful when debugging class initialization >>> diff -r 0fcfe4b07f7e src/share/vm/runtime/java.cpp >>> --- a/src/share/vm/runtime/java.cpp Tue Dec 29 18:30:51 2015 +0100 >>> +++ b/src/share/vm/runtime/java.cpp Wed Jan 06 09:12:00 2016 -1000 >>> @@ -433,7 +433,7 @@ void before_exit(JavaThread* thread) { >>> Handle exception(THREAD, PENDING_EXCEPTION); >>> CLEAR_PENDING_EXCEPTION; >>> ttyLocker ttyl; >>> - java_lang_Throwable::print_stack_trace(exception, tty); >>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>> } >>> #endif >>> > From coleen.phillimore at oracle.com Thu Jan 7 17:53:37 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 7 Jan 2016 12:53:37 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <4295855A5C1DE049A61835A1887419CC41EFC943@DEWDFEMB12A.global.corp.sap> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> <568C2F04.8020802@oracle.com> <568C3365.5000502@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC943@DEWDFEMB12A.global.corp.sap> Message-ID: <568EA621.4040407@oracle.com> Hi Goetz, I messed up when I moved math_entry_available. I meant to leave it in class TemplateInterpreter but move it to templateInterpreterGenerator_ppc.cpp file. But that would defeat some of the purpose of this change to make sure that functions were in the right files. I didn't like TemplateInterpreter::math_entry_available() in abstractInterpreter_ppc.cpp either though. So, I moved the function math_entry_available into class AbstractInterpreter which is called by AbstractInterpreter::can_be_compiled(), hence avoiding a call to a derived class which didn't seem good. This makes the most sense to me. Can you check out: http://cr.openjdk.java.net/~coleenp/8146410.02/webrev/index.html thanks, Coleen On 1/7/16 3:08 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > sorry I didn't answer yesterday, we had another holiday. > > You moved PPCs math_entry_available() in your new change. > I think it makes no difference where it's located, as long as it's > called from both, interpreter and interpreterGenerator classes. > > But if you want to move it, you need to fix all the other occurances > of the method, too: > http://cr.openjdk.java.net/~goetz/wr16/8146410-interpCleanup/move_math_entry_available.patch > > Elsewise good. > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of Coleen Phillimore >> Sent: Dienstag, 5. Januar 2016 22:20 >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined >> in the wrong files >> >> >> Hi, Please see updated webrev for comments so far: >> >> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/ >> >> Tested again with JPRT (on all Oracle supported platforms). >> >> thanks, >> Coleen >> >> On 1/5/16 4:00 PM, Coleen Phillimore wrote: >>> >>> On 1/5/16 3:49 PM, Lindenmaier, Goetz wrote: >>>>> -----Original Message----- >>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>> Sent: Dienstag, 5. Januar 2016 21:01 >>>>> To: Lindenmaier, Goetz ; hotspot-dev >>>>> developers >>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>>>> defined >>>>> in the wrong files >>>>> >>>>> >>>>> >>>>> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> I think they belong together because can_be_compiled() just returns >>>>>> false for functions that have a math entry which is generated by >>>>>> generate_math_entry(). So if you add a new math_entry, you >>>>>> also have to fix can_be_compiled. We wired this dependency into >>>>>> math_entry_available(kind), so that both functions are guaranteed >>>>>> to behave similar. >>>>> I'm getting confused by this. It seems like math_entry_available >>>>> should >>>>> be in templateInterpreterGenerator near generate_math_entry. >>>>> >>>>> The reason I don't want can_be_compiled (which is misleading) is >>>>> because >>>>> all the other platforms have it too and I don't want them in the wrong >>>>> files. >>>>> >>>>> what do you think? >>>> What I mean is can_be_compiled() should be moved to class >>>> templateInterpreterGenerator and placed near generate_math_entry() >>>> on all platforms. >>>> The similarity is the same on all of them. >>>> >>>> But I must admit in compilationPolicy.cpp it reads better if the >>>> AbstractInterpreter is asked. Also, method_kind is member >>>> of AbstractInterpreter. >>> Yes, that's what I thought. It's more of an Interpreter:: method. And >>> it's a static function and the functions in >>> TemplateInterpreterGenerator are not generally static functions. I >>> didn't want to move the others there. >>> >>>> But method_kind is also completely over-engeneered, as it's >>>> only used in can_be_compiled, and there it's only used >>>> for math entries... >>>> >>>> Maybe a change of it's own is needed... >>> I'm holding my head in pain, and my change is too big already to add >>> this. I did move math_entry_available because to >>> templateInterpreterGenerator_ppc.cpp because there is no >>> templateInterpreter_ppc.cpp anymore (there would only be this one >>> function and the sizing). I think this looks good and better than >>> having TemplateInterpreter::math_entry_available() in >>> abstractInterpreter_ppc.cpp. See: >>> >>> >> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/src/cpu/ppc/vm/t >> emplateInterpreterGenerator_ppc.cpp.udiff.html >>> >>> I think moving can_be_compiled and cleaning up the method_kind vs. >>> intrinsics is a bigger problem to solve, and should be attempted in a >>> further RFE. >>> >>> Thanks, >>> Coleen >>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Coleen >>>>>> The name of the function is kind of misleading to me. >>>>>> >>>>>> But I won't insist... >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>>>> Sent: Tuesday, January 05, 2016 7:17 PM >>>>>>> To: Lindenmaier, Goetz ; hotspot-dev >>>>>>> developers >>>>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>>>> defined >>>>>>> in the wrong files >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> Could you please also move >>>>>>>> AbstractInterpreter::can_be_compiled(methodHandle m) >>>>>>>> to above >>>>>>>> >> TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: >>>>>>> MethodKind kind)? >>>>>>>> I think these belong together. >>>>>>> Really? They're in different classes (hence the motivation for the >>>>>>> change) and generate_math_entry doesn't call can_be_compiled. >>>>>>> CompilationPolicy does but it calls it from >>>>>>> AbstractInterpreter::can_be_compiled() so I really can't move this >>>>>>> function into TemplateInterpreterGenerator. It doesn't make sense >> to >>>>> me. >>>>>>>> We seem to have different BIND macros on ppc. The '__' is also in >>>>>>>> the >>>>>>>> macro. Could you please fix this small issue? It breaks the ppc >>>>>>>> build. >>>>>>>> >>>>>>>> diff -r 743aa331fc90 >>>>>>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >>>>>>>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>>>>> Jan 05 07:47:21 2016 +0100 >>>>>>>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>>>>> Jan 05 08:06:12 2016 +0100 >>>>>>>> @@ -416,7 +416,7 @@ >>>>>>>> default: ShouldNotReachHere(); >>>>>>>> } >>>>>>>> >>>>>>>> - __ BIND(done); >>>>>>>> + BIND(done); >>>>>>>> __ blr(); >>>>>>>> >>>>>>> Fixed. Thanks!! >>>>>>>> return entry; >>>>>>>> >>>>>>>> Besides this, the change looks good. >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>>> Thanks and best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> PS: is it possible to share your Copyright script? >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: hotspot-dev [mailto:hotspot-dev- >> bounces at openjdk.java.net] >>>>> On >>>>>>>>> Behalf Of Coleen Phillimore >>>>>>>>> Sent: Monday, January 04, 2016 11:43 PM >>>>>>>>> To: hotspot-dev developers >>>>>>>>> Subject: RFR (M) 8146410: Interpreter functions are declared and >>>>> defined >>>>>>> in >>>>>>>>> the wrong files >>>>>>>>> >>>>>>>>> Summary: Moved functions to the correct files. >>>>>>>>> >>>>>>>>> See bug for more details. >>>>>>>>> >>>>>>>>> I basically did an hg mv templateInterpreter_.cpp >>>>>>>>> abstractInterpreter_.cpp and moved the >> interpreter_.cpp >>>>>>>>> functions there. >>>>>>>>> >>>>>>>>> Also moved generate_slow_signature_handler to >>>>>>>>> TemplateInterpreterGenerator/CppInterpreterGenerator because >> it's >>>>>>> not >>>>>>>>> shared. >>>>>>>>> >>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >>>>>>>>> >>>>>>>>> Tested with JPRT on Oracle supported platforms and built zero on >>>>>>>>> linux >>>>>>>>> x86. Also fixed change that broke zero in >>>>>>>>> stack_zero.inline.hpp. I >>>>>>>>> think this should work on PPC and AARCH64, but please let me >> know. >>>>>>>>> One question for AARCH64 platform in file: >>>>>>>>> >>>>>>>>> >> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >>>>>>>>> eInterpreterGenerator_aarch64.cpp.udiff.html >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Coleen From coleen.phillimore at oracle.com Thu Jan 7 19:36:49 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 7 Jan 2016 14:36:49 -0500 Subject: RFR (S): 8146246: JVMCICompiler::abort_on_pending_exception: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: <80FAECCD-94BA-479C-B042-0A50D9121C8F@oracle.com> References: <568D6C63.5000403@oracle.com> <0C62FED5-F3F8-44CE-B1DB-095F9170370B@oracle.com> <80FAECCD-94BA-479C-B042-0A50D9121C8F@oracle.com> Message-ID: <568EBE51.3030904@oracle.com> Hi, What testing did you run with the change to java.cpp ? Besides the calls in ci/ciReplay.cpp, this is the only call to java_lang_Throwable::print_stack_trace. Can the ciReplay.cpp calls be converted to the Java call to printStackTrace? If you didn't run full tests on the java.cpp change to make sure it doesn't break anything, I think you should revert that part and file another RFE to remove the function and the remaining calls so it can be tested separately. The JVMCI changes seem fine to me. Coleen On 1/7/16 11:45 AM, Christian Thalinger wrote: > [Changing lists because it should have been on hotspot-dev.] > > Coleen, in case 2) below I could replace java_lang_Throwable::print_stack_trace with java_lang_Throwable::java_printStackTrace. > >> On Jan 6, 2016, at 12:57 PM, Christian Thalinger wrote: >> >> >>> On Jan 6, 2016, at 9:34 AM, Vladimir Kozlov wrote: >>> >>> I would go with "Java code do the printing?. >> Yeah, it might be better. >> >>> You left ttyLocker in case 2) in src/share/vm/runtime/java.cpp >> Right. Thanks for pointing that out. >> >>> Thanks, >>> Vladimir >>> >>> On 1/6/16 11:19 AM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8146246 >>>> >>>> The problem is that https://bugs.openjdk.java.net/browse/JDK-8145435 introduced ttyLocker to synchronize the exception output but java_lang_Throwable::print_stack_trace can call out to Java to get the cause. >>>> >>>> There are two solutions: >>>> >>>> 1) Remove ttyLocker and deal with some possible scrambling in the rare case of an exception: >>>> >>>> diff -r df8d635f2296 -r e87e187552fb src/share/vm/jvmci/jvmciCompiler.cpp >>>> --- a/src/share/vm/jvmci/jvmciCompiler.cpp Tue Dec 29 11:24:01 2015 -0800 >>>> +++ b/src/share/vm/jvmci/jvmciCompiler.cpp Thu Dec 31 09:20:16 2015 -0800 >>>> @@ -162,10 +162,7 @@ void JVMCICompiler::compile_method(const >>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>> CLEAR_PENDING_EXCEPTION; >>>> >>>> - { >>>> - ttyLocker ttyl; >>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>> - } >>>> + java_lang_Throwable::print_stack_trace(exception, tty); >>>> >>>> // Something went wrong so disable compilation at this level >>>> method->set_not_compilable(CompLevel_full_optimization); >>>> @@ -181,11 +178,8 @@ void JVMCICompiler::abort_on_pending_exc >>>> Thread* THREAD = Thread::current(); >>>> CLEAR_PENDING_EXCEPTION; >>>> >>>> - { >>>> - ttyLocker ttyl; >>>> - tty->print_raw_cr(message); >>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>> - } >>>> + tty->print_raw_cr(message); >>>> + java_lang_Throwable::print_stack_trace(exception, tty); >>>> >>>> // Give other aborting threads to also print their stack traces. >>>> // This can be very useful when debugging class initialization >>>> diff -r df8d635f2296 -r e87e187552fb src/share/vm/runtime/java.cpp >>>> --- a/src/share/vm/runtime/java.cpp Tue Dec 29 11:24:01 2015 -0800 >>>> +++ b/src/share/vm/runtime/java.cpp Thu Dec 31 09:20:16 2015 -0800 >>>> @@ -432,7 +432,6 @@ void before_exit(JavaThread* thread) { >>>> if (HAS_PENDING_EXCEPTION) { >>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>> CLEAR_PENDING_EXCEPTION; >>>> - ttyLocker ttyl; >>>> java_lang_Throwable::print_stack_trace(exception, tty); >>>> } >>>> #endif >>>> >>>> or >>>> >>>> 2) Call out to Java and let the Java code do the printing: >>>> >>>> diff -r 0fcfe4b07f7e src/share/vm/classfile/javaClasses.cpp >>>> --- a/src/share/vm/classfile/javaClasses.cpp Tue Dec 29 18:30:51 2015 +0100 >>>> +++ b/src/share/vm/classfile/javaClasses.cpp Wed Jan 06 09:12:00 2016 -1000 >>>> @@ -1784,6 +1784,20 @@ void java_lang_Throwable::print_stack_tr >>>> } >>>> } >>>> >>>> +/** >>>> + * Print the throwable stack trace by calling the Java method java.lang.Throwable.printStackTrace(). >>>> + */ >>>> +void java_lang_Throwable::java_printStackTrace(Handle throwable, TRAPS) { >>>> + assert(throwable->is_a(SystemDictionary::Throwable_klass()), "Throwable instance expected"); >>>> + JavaValue result(T_VOID); >>>> + JavaCalls::call_virtual(&result, >>>> + throwable, >>>> + KlassHandle(THREAD, SystemDictionary::Throwable_klass()), >>>> + vmSymbols::printStackTrace_name(), >>>> + vmSymbols::void_method_signature(), >>>> + THREAD); >>>> +} >>>> + >>>> void java_lang_Throwable::fill_in_stack_trace(Handle throwable, const methodHandle& method, TRAPS) { >>>> if (!StackTraceInThrowable) return; >>>> ResourceMark rm(THREAD); >>>> diff -r 0fcfe4b07f7e src/share/vm/classfile/javaClasses.hpp >>>> --- a/src/share/vm/classfile/javaClasses.hpp Tue Dec 29 18:30:51 2015 +0100 >>>> +++ b/src/share/vm/classfile/javaClasses.hpp Wed Jan 06 09:12:00 2016 -1000 >>>> @@ -554,6 +554,7 @@ class java_lang_Throwable: AllStatic { >>>> // Printing >>>> static void print(Handle throwable, outputStream* st); >>>> static void print_stack_trace(Handle throwable, outputStream* st); >>>> + static void java_printStackTrace(Handle throwable, TRAPS); >>>> // Debugging >>>> friend class JavaClasses; >>>> }; >>>> diff -r 0fcfe4b07f7e src/share/vm/jvmci/jvmciCompiler.cpp >>>> --- a/src/share/vm/jvmci/jvmciCompiler.cpp Tue Dec 29 18:30:51 2015 +0100 >>>> +++ b/src/share/vm/jvmci/jvmciCompiler.cpp Wed Jan 06 09:12:00 2016 -1000 >>>> @@ -162,10 +162,7 @@ void JVMCICompiler::compile_method(const >>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>> CLEAR_PENDING_EXCEPTION; >>>> >>>> - { >>>> - ttyLocker ttyl; >>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>> - } >>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>> >>>> // Something went wrong so disable compilation at this level >>>> method->set_not_compilable(CompLevel_full_optimization); >>>> @@ -181,11 +178,7 @@ void JVMCICompiler::abort_on_pending_exc >>>> Thread* THREAD = Thread::current(); >>>> CLEAR_PENDING_EXCEPTION; >>>> >>>> - { >>>> - ttyLocker ttyl; >>>> - tty->print_raw_cr(message); >>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>> - } >>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>> >>>> // Give other aborting threads to also print their stack traces. >>>> // This can be very useful when debugging class initialization >>>> diff -r 0fcfe4b07f7e src/share/vm/runtime/java.cpp >>>> --- a/src/share/vm/runtime/java.cpp Tue Dec 29 18:30:51 2015 +0100 >>>> +++ b/src/share/vm/runtime/java.cpp Wed Jan 06 09:12:00 2016 -1000 >>>> @@ -433,7 +433,7 @@ void before_exit(JavaThread* thread) { >>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>> CLEAR_PENDING_EXCEPTION; >>>> ttyLocker ttyl; >>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>> } >>>> #endif >>>> From rachel.protacio at oracle.com Thu Jan 7 20:55:14 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 7 Jan 2016 15:55:14 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568D7A9E.20700@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> <568D7959.7090003@oracle.com> <568D7A9E.20700@oracle.com> Message-ID: <568ED0B2.6040200@oracle.com> Hi, I've refactored as suggested: http://cr.openjdk.java.net/~rprotacio/8144953.01/ TraceExceptionsTest.java still passes, both when run regularly and when run with compiled code. Thanks, Rachel On 1/6/2016 3:35 PM, Coleen Phillimore wrote: > > > On 1/6/16 3:30 PM, Coleen Phillimore wrote: >> >> Yes, I missed the one in the compiler file. I would really like if >> there was only one function for this logging though, but am trying to >> think of the best place for it. > > So can this be consolidated into Exceptions::log_exception() in > src/share/vm/utilities/exceptions.hpp/cpp ? > > Thanks, > Coleen > >> >> Coleen >> >> >> On 1/6/16 2:47 PM, Rachel Protacio wrote: >>> Thanks for the review, David. My impression was that no one had >>> realized that the detailed message was needed anywhere else in that >>> original 8048933, so this is just a matter of thoroughness, but >>> maybe Coleen can speak to that? >>> >>> Rachel >>> >>> On 1/6/2016 12:42 AM, David Holmes wrote: >>>> Hi Rachel, >>>> >>>> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>>>> Hi, >>>>> >>>>> Please review this fix allowing TraceExceptionTest.java to pass with >>>>> compiled code. c1_Runtime1.cpp had been missing the necessary >>>>> long-form >>>>> message, which has been added, and at the same time I discovered >>>>> bytecodeInterpreter.cpp was similarly lacking, though no test had >>>>> turned >>>>> it up. >>>> >>>> So really this is extending the change introduced by: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8048933 >>>> >>>> which begs the question as to why that change was only made for >>>> interpreted code in the first place? >>>> >>>> Changes look okay but I can't vouch for the validity of those calls >>>> in that particular context. >>>> >>>> Thanks, >>>> David >>>> >>>>> Passes JPRT and RBT tests. >>>>> >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>>>> >>>>> Thanks, >>>>> Rachel >>> >> > From christian.thalinger at oracle.com Thu Jan 7 21:10:46 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 7 Jan 2016 11:10:46 -1000 Subject: RFR (S): 8146246: JVMCICompiler::abort_on_pending_exception: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: <568EBE51.3030904@oracle.com> References: <568D6C63.5000403@oracle.com> <0C62FED5-F3F8-44CE-B1DB-095F9170370B@oracle.com> <80FAECCD-94BA-479C-B042-0A50D9121C8F@oracle.com> <568EBE51.3030904@oracle.com> Message-ID: > On Jan 7, 2016, at 9:36 AM, Coleen Phillimore wrote: > > > Hi, > > What testing did you run with the change to java.cpp ? Besides the calls in ci/ciReplay.cpp, this is the only call to java_lang_Throwable::print_stack_trace. Can the ciReplay.cpp calls be converted to the Java call to printStackTrace? Not enough. > > If you didn't run full tests on the java.cpp change to make sure it doesn't break anything, I think you should revert that part and file another RFE to remove the function and the remaining calls so it can be tested separately. Yes, I?ll file another RFE. > The JVMCI changes seem fine to me. Thanks. > > Coleen > > On 1/7/16 11:45 AM, Christian Thalinger wrote: >> [Changing lists because it should have been on hotspot-dev.] >> >> Coleen, in case 2) below I could replace java_lang_Throwable::print_stack_trace with java_lang_Throwable::java_printStackTrace. >> >>> On Jan 6, 2016, at 12:57 PM, Christian Thalinger wrote: >>> >>> >>>> On Jan 6, 2016, at 9:34 AM, Vladimir Kozlov wrote: >>>> >>>> I would go with "Java code do the printing?. >>> Yeah, it might be better. >>> >>>> You left ttyLocker in case 2) in src/share/vm/runtime/java.cpp >>> Right. Thanks for pointing that out. >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/6/16 11:19 AM, Christian Thalinger wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146246 >>>>> >>>>> The problem is that https://bugs.openjdk.java.net/browse/JDK-8145435 introduced ttyLocker to synchronize the exception output but java_lang_Throwable::print_stack_trace can call out to Java to get the cause. >>>>> >>>>> There are two solutions: >>>>> >>>>> 1) Remove ttyLocker and deal with some possible scrambling in the rare case of an exception: >>>>> >>>>> diff -r df8d635f2296 -r e87e187552fb src/share/vm/jvmci/jvmciCompiler.cpp >>>>> --- a/src/share/vm/jvmci/jvmciCompiler.cpp Tue Dec 29 11:24:01 2015 -0800 >>>>> +++ b/src/share/vm/jvmci/jvmciCompiler.cpp Thu Dec 31 09:20:16 2015 -0800 >>>>> @@ -162,10 +162,7 @@ void JVMCICompiler::compile_method(const >>>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> >>>>> - { >>>>> - ttyLocker ttyl; >>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>> - } >>>>> + java_lang_Throwable::print_stack_trace(exception, tty); >>>>> >>>>> // Something went wrong so disable compilation at this level >>>>> method->set_not_compilable(CompLevel_full_optimization); >>>>> @@ -181,11 +178,8 @@ void JVMCICompiler::abort_on_pending_exc >>>>> Thread* THREAD = Thread::current(); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> >>>>> - { >>>>> - ttyLocker ttyl; >>>>> - tty->print_raw_cr(message); >>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>> - } >>>>> + tty->print_raw_cr(message); >>>>> + java_lang_Throwable::print_stack_trace(exception, tty); >>>>> >>>>> // Give other aborting threads to also print their stack traces. >>>>> // This can be very useful when debugging class initialization >>>>> diff -r df8d635f2296 -r e87e187552fb src/share/vm/runtime/java.cpp >>>>> --- a/src/share/vm/runtime/java.cpp Tue Dec 29 11:24:01 2015 -0800 >>>>> +++ b/src/share/vm/runtime/java.cpp Thu Dec 31 09:20:16 2015 -0800 >>>>> @@ -432,7 +432,6 @@ void before_exit(JavaThread* thread) { >>>>> if (HAS_PENDING_EXCEPTION) { >>>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> - ttyLocker ttyl; >>>>> java_lang_Throwable::print_stack_trace(exception, tty); >>>>> } >>>>> #endif >>>>> >>>>> or >>>>> >>>>> 2) Call out to Java and let the Java code do the printing: >>>>> >>>>> diff -r 0fcfe4b07f7e src/share/vm/classfile/javaClasses.cpp >>>>> --- a/src/share/vm/classfile/javaClasses.cpp Tue Dec 29 18:30:51 2015 +0100 >>>>> +++ b/src/share/vm/classfile/javaClasses.cpp Wed Jan 06 09:12:00 2016 -1000 >>>>> @@ -1784,6 +1784,20 @@ void java_lang_Throwable::print_stack_tr >>>>> } >>>>> } >>>>> >>>>> +/** >>>>> + * Print the throwable stack trace by calling the Java method java.lang.Throwable.printStackTrace(). >>>>> + */ >>>>> +void java_lang_Throwable::java_printStackTrace(Handle throwable, TRAPS) { >>>>> + assert(throwable->is_a(SystemDictionary::Throwable_klass()), "Throwable instance expected"); >>>>> + JavaValue result(T_VOID); >>>>> + JavaCalls::call_virtual(&result, >>>>> + throwable, >>>>> + KlassHandle(THREAD, SystemDictionary::Throwable_klass()), >>>>> + vmSymbols::printStackTrace_name(), >>>>> + vmSymbols::void_method_signature(), >>>>> + THREAD); >>>>> +} >>>>> + >>>>> void java_lang_Throwable::fill_in_stack_trace(Handle throwable, const methodHandle& method, TRAPS) { >>>>> if (!StackTraceInThrowable) return; >>>>> ResourceMark rm(THREAD); >>>>> diff -r 0fcfe4b07f7e src/share/vm/classfile/javaClasses.hpp >>>>> --- a/src/share/vm/classfile/javaClasses.hpp Tue Dec 29 18:30:51 2015 +0100 >>>>> +++ b/src/share/vm/classfile/javaClasses.hpp Wed Jan 06 09:12:00 2016 -1000 >>>>> @@ -554,6 +554,7 @@ class java_lang_Throwable: AllStatic { >>>>> // Printing >>>>> static void print(Handle throwable, outputStream* st); >>>>> static void print_stack_trace(Handle throwable, outputStream* st); >>>>> + static void java_printStackTrace(Handle throwable, TRAPS); >>>>> // Debugging >>>>> friend class JavaClasses; >>>>> }; >>>>> diff -r 0fcfe4b07f7e src/share/vm/jvmci/jvmciCompiler.cpp >>>>> --- a/src/share/vm/jvmci/jvmciCompiler.cpp Tue Dec 29 18:30:51 2015 +0100 >>>>> +++ b/src/share/vm/jvmci/jvmciCompiler.cpp Wed Jan 06 09:12:00 2016 -1000 >>>>> @@ -162,10 +162,7 @@ void JVMCICompiler::compile_method(const >>>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> >>>>> - { >>>>> - ttyLocker ttyl; >>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>> - } >>>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>>> >>>>> // Something went wrong so disable compilation at this level >>>>> method->set_not_compilable(CompLevel_full_optimization); >>>>> @@ -181,11 +178,7 @@ void JVMCICompiler::abort_on_pending_exc >>>>> Thread* THREAD = Thread::current(); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> >>>>> - { >>>>> - ttyLocker ttyl; >>>>> - tty->print_raw_cr(message); >>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>> - } >>>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>>> >>>>> // Give other aborting threads to also print their stack traces. >>>>> // This can be very useful when debugging class initialization >>>>> diff -r 0fcfe4b07f7e src/share/vm/runtime/java.cpp >>>>> --- a/src/share/vm/runtime/java.cpp Tue Dec 29 18:30:51 2015 +0100 >>>>> +++ b/src/share/vm/runtime/java.cpp Wed Jan 06 09:12:00 2016 -1000 >>>>> @@ -433,7 +433,7 @@ void before_exit(JavaThread* thread) { >>>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> ttyLocker ttyl; >>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>>> } >>>>> #endif >>>>> > From coleen.phillimore at oracle.com Thu Jan 7 22:27:03 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 7 Jan 2016 17:27:03 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568ED0B2.6040200@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> <568D7959.7090003@oracle.com> <568D7A9E.20700@oracle.com> <568ED0B2.6040200@oracle.com> Message-ID: <568EE637.8000909@oracle.com> Hi, I really like this except the second argument to log_exception isn't needed. It's just oop fmt = exception(); Or you can pass *+ message->as_C_string(), p2i(exception()), tempst.as_string());* See src/share/vm/runtime/handles.hpp for Handle - operator() turns into an oop. But this looks really good. If it was like this, I wouldn't have introduced the bug in the first place. Thanks, Coleen On 1/7/16 3:55 PM, Rachel Protacio wrote: > Hi, > > I've refactored as suggested: > http://cr.openjdk.java.net/~rprotacio/8144953.01/ > > TraceExceptionsTest.java still passes, both when run regularly and > when run with compiled code. > > Thanks, > Rachel > > On 1/6/2016 3:35 PM, Coleen Phillimore wrote: >> >> >> On 1/6/16 3:30 PM, Coleen Phillimore wrote: >>> >>> Yes, I missed the one in the compiler file. I would really like if >>> there was only one function for this logging though, but am trying >>> to think of the best place for it. >> >> So can this be consolidated into Exceptions::log_exception() in >> src/share/vm/utilities/exceptions.hpp/cpp ? >> >> Thanks, >> Coleen >> >>> >>> Coleen >>> >>> >>> On 1/6/16 2:47 PM, Rachel Protacio wrote: >>>> Thanks for the review, David. My impression was that no one had >>>> realized that the detailed message was needed anywhere else in that >>>> original 8048933, so this is just a matter of thoroughness, but >>>> maybe Coleen can speak to that? >>>> >>>> Rachel >>>> >>>> On 1/6/2016 12:42 AM, David Holmes wrote: >>>>> Hi Rachel, >>>>> >>>>> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this fix allowing TraceExceptionTest.java to pass with >>>>>> compiled code. c1_Runtime1.cpp had been missing the necessary >>>>>> long-form >>>>>> message, which has been added, and at the same time I discovered >>>>>> bytecodeInterpreter.cpp was similarly lacking, though no test had >>>>>> turned >>>>>> it up. >>>>> >>>>> So really this is extending the change introduced by: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8048933 >>>>> >>>>> which begs the question as to why that change was only made for >>>>> interpreted code in the first place? >>>>> >>>>> Changes look okay but I can't vouch for the validity of those >>>>> calls in that particular context. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Passes JPRT and RBT tests. >>>>>> >>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>>>>> >>>>>> Thanks, >>>>>> Rachel >>>> >>> >> > From goetz.lindenmaier at sap.com Fri Jan 8 09:57:35 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Jan 2016 09:57:35 +0000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568EA621.4040407@oracle.com> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> <568C2F04.8020802@oracle.com> <568C3365.5000502@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC943@DEWDFEMB12A.global.corp.sap> <568EA621.4040407@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC41F0F683@DEWDFEMB12A.global.corp.sap> Hi Coleen, this change works fine, thanks! Best regards, Goetz. > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Donnerstag, 7. Januar 2016 18:54 > To: Lindenmaier, Goetz ; hotspot- > dev at openjdk.java.net > Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined > in the wrong files > > > Hi Goetz, > > I messed up when I moved math_entry_available. I meant to leave it in > class TemplateInterpreter but move it to > templateInterpreterGenerator_ppc.cpp file. > > But that would defeat some of the purpose of this change to make sure > that functions were in the right files. I didn't like > TemplateInterpreter::math_entry_available() in > abstractInterpreter_ppc.cpp either though. > > So, I moved the function math_entry_available into class > AbstractInterpreter which is called by > AbstractInterpreter::can_be_compiled(), hence avoiding a call to a > derived class which didn't seem good. This makes the most sense to me. > > Can you check out: > > http://cr.openjdk.java.net/~coleenp/8146410.02/webrev/index.html > > thanks, > Coleen > > On 1/7/16 3:08 AM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > > > sorry I didn't answer yesterday, we had another holiday. > > > > You moved PPCs math_entry_available() in your new change. > > I think it makes no difference where it's located, as long as it's > > called from both, interpreter and interpreterGenerator classes. > > > > But if you want to move it, you need to fix all the other occurances > > of the method, too: > > http://cr.openjdk.java.net/~goetz/wr16/8146410- > interpCleanup/move_math_entry_available.patch > > > > Elsewise good. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >> Behalf Of Coleen Phillimore > >> Sent: Dienstag, 5. Januar 2016 22:20 > >> To: hotspot-dev at openjdk.java.net > >> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and > defined > >> in the wrong files > >> > >> > >> Hi, Please see updated webrev for comments so far: > >> > >> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/ > >> > >> Tested again with JPRT (on all Oracle supported platforms). > >> > >> thanks, > >> Coleen > >> > >> On 1/5/16 4:00 PM, Coleen Phillimore wrote: > >>> > >>> On 1/5/16 3:49 PM, Lindenmaier, Goetz wrote: > >>>>> -----Original Message----- > >>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > >>>>> Sent: Dienstag, 5. Januar 2016 21:01 > >>>>> To: Lindenmaier, Goetz ; hotspot-dev > >>>>> developers > >>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and > >>>>> defined > >>>>> in the wrong files > >>>>> > >>>>> > >>>>> > >>>>> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: > >>>>>> Hi Coleen, > >>>>>> > >>>>>> I think they belong together because can_be_compiled() just > returns > >>>>>> false for functions that have a math entry which is generated by > >>>>>> generate_math_entry(). So if you add a new math_entry, you > >>>>>> also have to fix can_be_compiled. We wired this dependency into > >>>>>> math_entry_available(kind), so that both functions are guaranteed > >>>>>> to behave similar. > >>>>> I'm getting confused by this. It seems like math_entry_available > >>>>> should > >>>>> be in templateInterpreterGenerator near generate_math_entry. > >>>>> > >>>>> The reason I don't want can_be_compiled (which is misleading) is > >>>>> because > >>>>> all the other platforms have it too and I don't want them in the wrong > >>>>> files. > >>>>> > >>>>> what do you think? > >>>> What I mean is can_be_compiled() should be moved to class > >>>> templateInterpreterGenerator and placed near > generate_math_entry() > >>>> on all platforms. > >>>> The similarity is the same on all of them. > >>>> > >>>> But I must admit in compilationPolicy.cpp it reads better if the > >>>> AbstractInterpreter is asked. Also, method_kind is member > >>>> of AbstractInterpreter. > >>> Yes, that's what I thought. It's more of an Interpreter:: method. And > >>> it's a static function and the functions in > >>> TemplateInterpreterGenerator are not generally static functions. I > >>> didn't want to move the others there. > >>> > >>>> But method_kind is also completely over-engeneered, as it's > >>>> only used in can_be_compiled, and there it's only used > >>>> for math entries... > >>>> > >>>> Maybe a change of it's own is needed... > >>> I'm holding my head in pain, and my change is too big already to add > >>> this. I did move math_entry_available because to > >>> templateInterpreterGenerator_ppc.cpp because there is no > >>> templateInterpreter_ppc.cpp anymore (there would only be this one > >>> function and the sizing). I think this looks good and better than > >>> having TemplateInterpreter::math_entry_available() in > >>> abstractInterpreter_ppc.cpp. See: > >>> > >>> > >> > http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/src/cpu/ppc/vm/t > >> emplateInterpreterGenerator_ppc.cpp.udiff.html > >>> > >>> I think moving can_be_compiled and cleaning up the method_kind vs. > >>> intrinsics is a bigger problem to solve, and should be attempted in a > >>> further RFE. > >>> > >>> Thanks, > >>> Coleen > >>> > >>>> Best regards, > >>>> Goetz. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Coleen > >>>>>> The name of the function is kind of misleading to me. > >>>>>> > >>>>>> But I won't insist... > >>>>>> > >>>>>> Best regards, > >>>>>> Goetz. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > >>>>>>> Sent: Tuesday, January 05, 2016 7:17 PM > >>>>>>> To: Lindenmaier, Goetz ; hotspot- > dev > >>>>>>> developers > >>>>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared > and > >>>>> defined > >>>>>>> in the wrong files > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: > >>>>>>>> Hi Coleen, > >>>>>>>> > >>>>>>>> Could you please also move > >>>>>>>> AbstractInterpreter::can_be_compiled(methodHandle m) > >>>>>>>> to above > >>>>>>>> > >> > TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: > >>>>>>> MethodKind kind)? > >>>>>>>> I think these belong together. > >>>>>>> Really? They're in different classes (hence the motivation for the > >>>>>>> change) and generate_math_entry doesn't call can_be_compiled. > >>>>>>> CompilationPolicy does but it calls it from > >>>>>>> AbstractInterpreter::can_be_compiled() so I really can't move this > >>>>>>> function into TemplateInterpreterGenerator. It doesn't make > sense > >> to > >>>>> me. > >>>>>>>> We seem to have different BIND macros on ppc. The '__' is also in > >>>>>>>> the > >>>>>>>> macro. Could you please fix this small issue? It breaks the ppc > >>>>>>>> build. > >>>>>>>> > >>>>>>>> diff -r 743aa331fc90 > >>>>>>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > >>>>>>>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > Tue > >>>>>>> Jan 05 07:47:21 2016 +0100 > >>>>>>>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > Tue > >>>>>>> Jan 05 08:06:12 2016 +0100 > >>>>>>>> @@ -416,7 +416,7 @@ > >>>>>>>> default: ShouldNotReachHere(); > >>>>>>>> } > >>>>>>>> > >>>>>>>> - __ BIND(done); > >>>>>>>> + BIND(done); > >>>>>>>> __ blr(); > >>>>>>>> > >>>>>>> Fixed. Thanks!! > >>>>>>>> return entry; > >>>>>>>> > >>>>>>>> Besides this, the change looks good. > >>>>>>> Thanks, > >>>>>>> Coleen > >>>>>>> > >>>>>>>> Thanks and best regards, > >>>>>>>> Goetz. > >>>>>>>> > >>>>>>>> PS: is it possible to share your Copyright script? > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: hotspot-dev [mailto:hotspot-dev- > >> bounces at openjdk.java.net] > >>>>> On > >>>>>>>>> Behalf Of Coleen Phillimore > >>>>>>>>> Sent: Monday, January 04, 2016 11:43 PM > >>>>>>>>> To: hotspot-dev developers > >>>>>>>>> Subject: RFR (M) 8146410: Interpreter functions are declared and > >>>>> defined > >>>>>>> in > >>>>>>>>> the wrong files > >>>>>>>>> > >>>>>>>>> Summary: Moved functions to the correct files. > >>>>>>>>> > >>>>>>>>> See bug for more details. > >>>>>>>>> > >>>>>>>>> I basically did an hg mv templateInterpreter_.cpp > >>>>>>>>> abstractInterpreter_.cpp and moved the > >> interpreter_.cpp > >>>>>>>>> functions there. > >>>>>>>>> > >>>>>>>>> Also moved generate_slow_signature_handler to > >>>>>>>>> TemplateInterpreterGenerator/CppInterpreterGenerator > because > >> it's > >>>>>>> not > >>>>>>>>> shared. > >>>>>>>>> > >>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ > >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 > >>>>>>>>> > >>>>>>>>> Tested with JPRT on Oracle supported platforms and built zero > on > >>>>>>>>> linux > >>>>>>>>> x86. Also fixed change that broke zero in > >>>>>>>>> stack_zero.inline.hpp. I > >>>>>>>>> think this should work on PPC and AARCH64, but please let me > >> know. > >>>>>>>>> One question for AARCH64 platform in file: > >>>>>>>>> > >>>>>>>>> > >> > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat > >>>>>>>>> eInterpreterGenerator_aarch64.cpp.udiff.html > >>>>>>>>> > >>>>>>>>> thanks, > >>>>>>>>> Coleen From coleen.phillimore at oracle.com Fri Jan 8 13:31:58 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 8 Jan 2016 08:31:58 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F0F683@DEWDFEMB12A.global.corp.sap> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> <568C2F04.8020802@oracle.com> <568C3365.5000502@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC943@DEWDFEMB12A.global.corp.sap> <568EA621.4040407@oracle.com> <4295855A5C1DE049A61835A1887419CC41F0F683@DEWDFEMB12A.global.corp.sap> Message-ID: <568FBA4E.9010102@oracle.com> Thank you, Goetz! Coleen On 1/8/16 4:57 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > this change works fine, thanks! > > Best regards, > Goetz. > >> -----Original Message----- >> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> Sent: Donnerstag, 7. Januar 2016 18:54 >> To: Lindenmaier, Goetz ; hotspot- >> dev at openjdk.java.net >> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined >> in the wrong files >> >> >> Hi Goetz, >> >> I messed up when I moved math_entry_available. I meant to leave it in >> class TemplateInterpreter but move it to >> templateInterpreterGenerator_ppc.cpp file. >> >> But that would defeat some of the purpose of this change to make sure >> that functions were in the right files. I didn't like >> TemplateInterpreter::math_entry_available() in >> abstractInterpreter_ppc.cpp either though. >> >> So, I moved the function math_entry_available into class >> AbstractInterpreter which is called by >> AbstractInterpreter::can_be_compiled(), hence avoiding a call to a >> derived class which didn't seem good. This makes the most sense to me. >> >> Can you check out: >> >> http://cr.openjdk.java.net/~coleenp/8146410.02/webrev/index.html >> >> thanks, >> Coleen >> >> On 1/7/16 3:08 AM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> sorry I didn't answer yesterday, we had another holiday. >>> >>> You moved PPCs math_entry_available() in your new change. >>> I think it makes no difference where it's located, as long as it's >>> called from both, interpreter and interpreterGenerator classes. >>> >>> But if you want to move it, you need to fix all the other occurances >>> of the method, too: >>> http://cr.openjdk.java.net/~goetz/wr16/8146410- >> interpCleanup/move_math_entry_available.patch >>> Elsewise good. >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Coleen Phillimore >>>> Sent: Dienstag, 5. Januar 2016 22:20 >>>> To: hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >> defined >>>> in the wrong files >>>> >>>> >>>> Hi, Please see updated webrev for comments so far: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/ >>>> >>>> Tested again with JPRT (on all Oracle supported platforms). >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 1/5/16 4:00 PM, Coleen Phillimore wrote: >>>>> On 1/5/16 3:49 PM, Lindenmaier, Goetz wrote: >>>>>>> -----Original Message----- >>>>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>>>> Sent: Dienstag, 5. Januar 2016 21:01 >>>>>>> To: Lindenmaier, Goetz ; hotspot-dev >>>>>>> developers >>>>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>>>>>> defined >>>>>>> in the wrong files >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> I think they belong together because can_be_compiled() just >> returns >>>>>>>> false for functions that have a math entry which is generated by >>>>>>>> generate_math_entry(). So if you add a new math_entry, you >>>>>>>> also have to fix can_be_compiled. We wired this dependency into >>>>>>>> math_entry_available(kind), so that both functions are guaranteed >>>>>>>> to behave similar. >>>>>>> I'm getting confused by this. It seems like math_entry_available >>>>>>> should >>>>>>> be in templateInterpreterGenerator near generate_math_entry. >>>>>>> >>>>>>> The reason I don't want can_be_compiled (which is misleading) is >>>>>>> because >>>>>>> all the other platforms have it too and I don't want them in the wrong >>>>>>> files. >>>>>>> >>>>>>> what do you think? >>>>>> What I mean is can_be_compiled() should be moved to class >>>>>> templateInterpreterGenerator and placed near >> generate_math_entry() >>>>>> on all platforms. >>>>>> The similarity is the same on all of them. >>>>>> >>>>>> But I must admit in compilationPolicy.cpp it reads better if the >>>>>> AbstractInterpreter is asked. Also, method_kind is member >>>>>> of AbstractInterpreter. >>>>> Yes, that's what I thought. It's more of an Interpreter:: method. And >>>>> it's a static function and the functions in >>>>> TemplateInterpreterGenerator are not generally static functions. I >>>>> didn't want to move the others there. >>>>> >>>>>> But method_kind is also completely over-engeneered, as it's >>>>>> only used in can_be_compiled, and there it's only used >>>>>> for math entries... >>>>>> >>>>>> Maybe a change of it's own is needed... >>>>> I'm holding my head in pain, and my change is too big already to add >>>>> this. I did move math_entry_available because to >>>>> templateInterpreterGenerator_ppc.cpp because there is no >>>>> templateInterpreter_ppc.cpp anymore (there would only be this one >>>>> function and the sizing). I think this looks good and better than >>>>> having TemplateInterpreter::math_entry_available() in >>>>> abstractInterpreter_ppc.cpp. See: >>>>> >>>>> >> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/src/cpu/ppc/vm/t >>>> emplateInterpreterGenerator_ppc.cpp.udiff.html >>>>> I think moving can_be_compiled and cleaning up the method_kind vs. >>>>> intrinsics is a bigger problem to solve, and should be attempted in a >>>>> further RFE. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Coleen >>>>>>>> The name of the function is kind of misleading to me. >>>>>>>> >>>>>>>> But I won't insist... >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>>>>>> Sent: Tuesday, January 05, 2016 7:17 PM >>>>>>>>> To: Lindenmaier, Goetz ; hotspot- >> dev >>>>>>>>> developers >>>>>>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared >> and >>>>>>> defined >>>>>>>>> in the wrong files >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> Could you please also move >>>>>>>>>> AbstractInterpreter::can_be_compiled(methodHandle m) >>>>>>>>>> to above >>>>>>>>>> >> TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: >>>>>>>>> MethodKind kind)? >>>>>>>>>> I think these belong together. >>>>>>>>> Really? They're in different classes (hence the motivation for the >>>>>>>>> change) and generate_math_entry doesn't call can_be_compiled. >>>>>>>>> CompilationPolicy does but it calls it from >>>>>>>>> AbstractInterpreter::can_be_compiled() so I really can't move this >>>>>>>>> function into TemplateInterpreterGenerator. It doesn't make >> sense >>>> to >>>>>>> me. >>>>>>>>>> We seem to have different BIND macros on ppc. The '__' is also in >>>>>>>>>> the >>>>>>>>>> macro. Could you please fix this small issue? It breaks the ppc >>>>>>>>>> build. >>>>>>>>>> >>>>>>>>>> diff -r 743aa331fc90 >>>>>>>>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >>>>>>>>>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >> Tue >>>>>>>>> Jan 05 07:47:21 2016 +0100 >>>>>>>>>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >> Tue >>>>>>>>> Jan 05 08:06:12 2016 +0100 >>>>>>>>>> @@ -416,7 +416,7 @@ >>>>>>>>>> default: ShouldNotReachHere(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> - __ BIND(done); >>>>>>>>>> + BIND(done); >>>>>>>>>> __ blr(); >>>>>>>>>> >>>>>>>>> Fixed. Thanks!! >>>>>>>>>> return entry; >>>>>>>>>> >>>>>>>>>> Besides this, the change looks good. >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>>> Thanks and best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> PS: is it possible to share your Copyright script? >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: hotspot-dev [mailto:hotspot-dev- >>>> bounces at openjdk.java.net] >>>>>>> On >>>>>>>>>>> Behalf Of Coleen Phillimore >>>>>>>>>>> Sent: Monday, January 04, 2016 11:43 PM >>>>>>>>>>> To: hotspot-dev developers >>>>>>>>>>> Subject: RFR (M) 8146410: Interpreter functions are declared and >>>>>>> defined >>>>>>>>> in >>>>>>>>>>> the wrong files >>>>>>>>>>> >>>>>>>>>>> Summary: Moved functions to the correct files. >>>>>>>>>>> >>>>>>>>>>> See bug for more details. >>>>>>>>>>> >>>>>>>>>>> I basically did an hg mv templateInterpreter_.cpp >>>>>>>>>>> abstractInterpreter_.cpp and moved the >>>> interpreter_.cpp >>>>>>>>>>> functions there. >>>>>>>>>>> >>>>>>>>>>> Also moved generate_slow_signature_handler to >>>>>>>>>>> TemplateInterpreterGenerator/CppInterpreterGenerator >> because >>>> it's >>>>>>>>> not >>>>>>>>>>> shared. >>>>>>>>>>> >>>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >>>>>>>>>>> >>>>>>>>>>> Tested with JPRT on Oracle supported platforms and built zero >> on >>>>>>>>>>> linux >>>>>>>>>>> x86. Also fixed change that broke zero in >>>>>>>>>>> stack_zero.inline.hpp. I >>>>>>>>>>> think this should work on PPC and AARCH64, but please let me >>>> know. >>>>>>>>>>> One question for AARCH64 platform in file: >>>>>>>>>>> >>>>>>>>>>> >> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >>>>>>>>>>> eInterpreterGenerator_aarch64.cpp.udiff.html >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> Coleen From rachel.protacio at oracle.com Fri Jan 8 16:50:42 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 8 Jan 2016 11:50:42 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568EE637.8000909@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> <568D7959.7090003@oracle.com> <568D7A9E.20700@oracle.com> <568ED0B2.6040200@oracle.com> <568EE637.8000909@oracle.com> Message-ID: <568FE8E2.6020403@oracle.com> Cool. I've fixed the issue: http://cr.openjdk.java.net/~rprotacio/8144953.02/ Thanks! Rachel On 1/7/2016 5:27 PM, Coleen Phillimore wrote: > > Hi, I really like this except the second argument to log_exception > isn't needed. It's just > > oop fmt = exception(); Or you can pass > > *+ message->as_C_string(), p2i(exception()), tempst.as_string());* > > > See src/share/vm/runtime/handles.hpp for Handle - operator() turns > into an oop. > > But this looks really good. If it was like this, I wouldn't have > introduced the bug in the first place. > > Thanks, > Coleen > > On 1/7/16 3:55 PM, Rachel Protacio wrote: >> Hi, >> >> I've refactored as suggested: >> http://cr.openjdk.java.net/~rprotacio/8144953.01/ >> >> TraceExceptionsTest.java still passes, both when run regularly and >> when run with compiled code. >> >> Thanks, >> Rachel >> >> On 1/6/2016 3:35 PM, Coleen Phillimore wrote: >>> >>> >>> On 1/6/16 3:30 PM, Coleen Phillimore wrote: >>>> >>>> Yes, I missed the one in the compiler file. I would really like if >>>> there was only one function for this logging though, but am trying >>>> to think of the best place for it. >>> >>> So can this be consolidated into Exceptions::log_exception() in >>> src/share/vm/utilities/exceptions.hpp/cpp ? >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Coleen >>>> >>>> >>>> On 1/6/16 2:47 PM, Rachel Protacio wrote: >>>>> Thanks for the review, David. My impression was that no one had >>>>> realized that the detailed message was needed anywhere else in >>>>> that original 8048933, so this is just a matter of thoroughness, >>>>> but maybe Coleen can speak to that? >>>>> >>>>> Rachel >>>>> >>>>> On 1/6/2016 12:42 AM, David Holmes wrote: >>>>>> Hi Rachel, >>>>>> >>>>>> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this fix allowing TraceExceptionTest.java to pass >>>>>>> with >>>>>>> compiled code. c1_Runtime1.cpp had been missing the necessary >>>>>>> long-form >>>>>>> message, which has been added, and at the same time I discovered >>>>>>> bytecodeInterpreter.cpp was similarly lacking, though no test >>>>>>> had turned >>>>>>> it up. >>>>>> >>>>>> So really this is extending the change introduced by: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8048933 >>>>>> >>>>>> which begs the question as to why that change was only made for >>>>>> interpreted code in the first place? >>>>>> >>>>>> Changes look okay but I can't vouch for the validity of those >>>>>> calls in that particular context. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Passes JPRT and RBT tests. >>>>>>> >>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>>>>>> >>>>>>> Thanks, >>>>>>> Rachel >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Fri Jan 8 17:30:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 8 Jan 2016 12:30:32 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568FE8E2.6020403@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> <568D7959.7090003@oracle.com> <568D7A9E.20700@oracle.com> <568ED0B2.6040200@oracle.com> <568EE637.8000909@oracle.com> <568FE8E2.6020403@oracle.com> Message-ID: <568FF238.6060806@oracle.com> It looks great! thanks, Coleen On 1/8/16 11:50 AM, Rachel Protacio wrote: > Cool. I've fixed the issue: > http://cr.openjdk.java.net/~rprotacio/8144953.02/ > > Thanks! > Rachel > > On 1/7/2016 5:27 PM, Coleen Phillimore wrote: >> >> Hi, I really like this except the second argument to log_exception >> isn't needed. It's just >> >> oop fmt = exception(); Or you can pass >> >> *+ message->as_C_string(), p2i(exception()), tempst.as_string());* >> >> >> See src/share/vm/runtime/handles.hpp for Handle - operator() turns >> into an oop. >> >> But this looks really good. If it was like this, I wouldn't have >> introduced the bug in the first place. >> >> Thanks, >> Coleen >> >> On 1/7/16 3:55 PM, Rachel Protacio wrote: >>> Hi, >>> >>> I've refactored as suggested: >>> http://cr.openjdk.java.net/~rprotacio/8144953.01/ >>> >>> TraceExceptionsTest.java still passes, both when run regularly and >>> when run with compiled code. >>> >>> Thanks, >>> Rachel >>> >>> On 1/6/2016 3:35 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 1/6/16 3:30 PM, Coleen Phillimore wrote: >>>>> >>>>> Yes, I missed the one in the compiler file. I would really like >>>>> if there was only one function for this logging though, but am >>>>> trying to think of the best place for it. >>>> >>>> So can this be consolidated into Exceptions::log_exception() in >>>> src/share/vm/utilities/exceptions.hpp/cpp ? >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 1/6/16 2:47 PM, Rachel Protacio wrote: >>>>>> Thanks for the review, David. My impression was that no one had >>>>>> realized that the detailed message was needed anywhere else in >>>>>> that original 8048933, so this is just a matter of thoroughness, >>>>>> but maybe Coleen can speak to that? >>>>>> >>>>>> Rachel >>>>>> >>>>>> On 1/6/2016 12:42 AM, David Holmes wrote: >>>>>>> Hi Rachel, >>>>>>> >>>>>>> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this fix allowing TraceExceptionTest.java to pass >>>>>>>> with >>>>>>>> compiled code. c1_Runtime1.cpp had been missing the necessary >>>>>>>> long-form >>>>>>>> message, which has been added, and at the same time I discovered >>>>>>>> bytecodeInterpreter.cpp was similarly lacking, though no test >>>>>>>> had turned >>>>>>>> it up. >>>>>>> >>>>>>> So really this is extending the change introduced by: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8048933 >>>>>>> >>>>>>> which begs the question as to why that change was only made for >>>>>>> interpreted code in the first place? >>>>>>> >>>>>>> Changes look okay but I can't vouch for the validity of those >>>>>>> calls in that particular context. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Passes JPRT and RBT tests. >>>>>>>> >>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Rachel >>>>>> >>>>> >>>> >>> >> > From rachel.protacio at oracle.com Fri Jan 8 17:33:09 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 8 Jan 2016 12:33:09 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568FF238.6060806@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> <568D7959.7090003@oracle.com> <568D7A9E.20700@oracle.com> <568ED0B2.6040200@oracle.com> <568EE637.8000909@oracle.com> <568FE8E2.6020403@oracle.com> <568FF238.6060806@oracle.com> Message-ID: <568FF2D5.6060101@oracle.com> Thanks for the review, Coleen! Rachel On 1/8/2016 12:30 PM, Coleen Phillimore wrote: > > It looks great! > thanks, > Coleen > > On 1/8/16 11:50 AM, Rachel Protacio wrote: >> Cool. I've fixed the issue: >> http://cr.openjdk.java.net/~rprotacio/8144953.02/ >> >> Thanks! >> Rachel >> >> On 1/7/2016 5:27 PM, Coleen Phillimore wrote: >>> >>> Hi, I really like this except the second argument to log_exception >>> isn't needed. It's just >>> >>> oop fmt = exception(); Or you can pass >>> >>> *+ message->as_C_string(), p2i(exception()), tempst.as_string());* >>> >>> >>> See src/share/vm/runtime/handles.hpp for Handle - operator() turns >>> into an oop. >>> >>> But this looks really good. If it was like this, I wouldn't have >>> introduced the bug in the first place. >>> >>> Thanks, >>> Coleen >>> >>> On 1/7/16 3:55 PM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> I've refactored as suggested: >>>> http://cr.openjdk.java.net/~rprotacio/8144953.01/ >>>> >>>> TraceExceptionsTest.java still passes, both when run regularly and >>>> when run with compiled code. >>>> >>>> Thanks, >>>> Rachel >>>> >>>> On 1/6/2016 3:35 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 1/6/16 3:30 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Yes, I missed the one in the compiler file. I would really like >>>>>> if there was only one function for this logging though, but am >>>>>> trying to think of the best place for it. >>>>> >>>>> So can this be consolidated into Exceptions::log_exception() in >>>>> src/share/vm/utilities/exceptions.hpp/cpp ? >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 1/6/16 2:47 PM, Rachel Protacio wrote: >>>>>>> Thanks for the review, David. My impression was that no one had >>>>>>> realized that the detailed message was needed anywhere else in >>>>>>> that original 8048933, so this is just a matter of thoroughness, >>>>>>> but maybe Coleen can speak to that? >>>>>>> >>>>>>> Rachel >>>>>>> >>>>>>> On 1/6/2016 12:42 AM, David Holmes wrote: >>>>>>>> Hi Rachel, >>>>>>>> >>>>>>>> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this fix allowing TraceExceptionTest.java to >>>>>>>>> pass with >>>>>>>>> compiled code. c1_Runtime1.cpp had been missing the necessary >>>>>>>>> long-form >>>>>>>>> message, which has been added, and at the same time I discovered >>>>>>>>> bytecodeInterpreter.cpp was similarly lacking, though no test >>>>>>>>> had turned >>>>>>>>> it up. >>>>>>>> >>>>>>>> So really this is extending the change introduced by: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8048933 >>>>>>>> >>>>>>>> which begs the question as to why that change was only made for >>>>>>>> interpreted code in the first place? >>>>>>>> >>>>>>>> Changes look okay but I can't vouch for the validity of those >>>>>>>> calls in that particular context. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Passes JPRT and RBT tests. >>>>>>>>> >>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Rachel >>>>>>> >>>>>> >>>>> >>>> >>> >> > From filipp.zhinkin at gmail.com Mon Jan 11 11:07:46 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Mon, 11 Jan 2016 14:07:46 +0300 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform In-Reply-To: References: <4CE12B2E-FDEF-48E0-AA84-E410DC09CE53@oracle.com> Message-ID: Igor, So, do you want me to include any other changes for this CR? Regards, Filipp. On Wed, Jan 6, 2016 at 4:00 PM, Filipp Zhinkin wrote: > Hi Igor, > > here are RFEs for tests relocation and ClassFileInstaller relocation: > https://bugs.openjdk.java.net/browse/JDK-8146549 > https://bugs.openjdk.java.net/browse/JDK-8146550 > > Thanks, > Filipp. > > On Sat, Jan 2, 2016 at 2:59 PM, Igor Ignatyev wrote: >> Hi Filipp, >> >> there is no options to make ?@library /test/lib? works. there is ?external.lib.roots? property in TEST.ROOT files, which adds additional root for @library. I noticed that there is no /test/lib-test isn?t a part of any test-suites, hence moving test to test/lib-test implies extra work in infra. given that I think it?ll be better to do it lately and separately from 8066599. please file an RFE for that. >> >> on 2nd question, I think it makes sense to move ClassFileInstaller to jdk.test.lib and annotate ClassFileInstaller in both jdk/test/lib/testlibrary/ and hotspot/test/testlibrary/ w/ @Deprectate. and I also think it?d be better to do it separately. >> >> Thanks, >> Igor >> >>> On Dec 25, 2015, at 12:41 PM, Filipp Zhinkin wrote: >>> >>> Hi Igor, >>> >>> thanks for looking at this change. >>> >>> On Thu, Dec 24, 2015 at 9:24 PM, Igor Ignatyev wrote: >>>> Hi Filipp, >>>> >>>> could you please move TestMutuallyExclusivePlatformPredicates and TestPlatformIsTieredSupported from hotspot/testlibrary_tests/ to test/lib-test and update it according to your changes? please note that we started to use packages in our tests. >>> >>> Sure, I'll move it. >>> >>> Do I need to pass any specific options to jtreg to make '@library >>> /test/lib' work? >>> At the moment jtreg can't locate it unless I specify >>> '/../../test/lib/share/classes'. >>> >>> Does it make sense to also move ClassFileInstaller to jdk.test.lib? >>> >>> >>> Thanks, >>> Filipp. >>> >>>> >>>> otherwise looks good to me. >>>> >>>> Thanks, >>>> ? Igor >>>> >>>>> On Dec 22, 2015, at 10:36 AM, Filipp Zhinkin wrote: >>>>> >>>>> Hi all, >>>>> >>>>> please review a small change that adds VM mode checking methods to >>>>> jdk.test.lib.Platform. >>>>> I didn't touch Platform class from hotspot/test/testlibrary, because >>>>> it is already deprecated and at some point of time all hs tests will >>>>> be updated to use j.t.l.Platform instead. >>>>> Update of hs tests that use own logic to check VM mode is tracked by >>>>> JDK-8145848 [1]. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 >>>>> Testing: on local machine with different VM modes. >>>>> >>>>> Regards, >>>>> Filipp. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8145848 >>>> >> From konstantin.shefov at oracle.com Mon Jan 11 13:34:10 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 11 Jan 2016 16:34:10 +0300 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <567271CE.3080604@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> <56714765.5010009@oracle.com> <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> <567271CE.3080604@oracle.com> Message-ID: <5693AF52.6090109@oracle.com> Kindly reminder. Already approved by C. Thalinger and I. Ignatyev. Thanks -Konstantin On 12/17/2015 11:26 AM, Konstantin Shefov wrote: > Hi Coleen > > You have previously reviewed this enhancement and made a few comments > I have resolved them, so could you look at the webrevs again, please? > > I have added tests, removed cp tags that are not in JVM spec (100 - > 105) and made some other changes. > > JDK: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04 > HOTSPOT: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 > > Thanks > -Konstantin > > > On 12/16/2015 07:42 PM, Christian Thalinger wrote: >> Looks good. Thanks. >> >>> On Dec 16, 2015, at 1:13 AM, Konstantin Shefov >>> wrote: >>> >>> Christian >>> >>> I have fixed the enum so it uses "ENUMENTRY(int)" format now and >>> does linear search. >>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ >>> >>> -Konstantin >>> >>> On 12/15/2015 08:36 PM, Christian Thalinger wrote: >>>>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov >>>>> >>>> > wrote: >>>>> >>>>> Hi Christian >>>>> >>>>> Thanks for reviewing, I have changed indents as you asked: >>>>> >>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 >>>>> >>>> Thanks. I?m still not comfortable with the enum. It would be >>>> great if we could get the values from the VM like in JVMCI: >>>> >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 >>>> >>>> >>>> but that would be overkill here. But I would like to see the enum >>>> entries take the integer values as arguments, like here: >>>> >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 >>>> >>>> >>>> and either do a simple linear search to find the entry or build up >>>> a table like the HotSpotConstantPool example above. >>>> >>>>> -Konstantin >>>>> >>>>> On 12/15/2015 06:23 AM, Christian Thalinger wrote: >>>>>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hello >>>>>>> >>>>>>> Please review the new version on the patch. >>>>>>> >>>>>>> New webrev: >>>>>>> Webrev hotspot: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>>>>>> >>>>>>> Webrev jdk: >>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >>>>>>> >>>>>> These newlines look ridiculous especially when it?s not even needed: >>>>>> >>>>>> + // Returns a class reference index for a method or a field. >>>>>> + public int getClassRefIndexAt >>>>>> + (int index) { return >>>>>> getClassRefIndexAt0 (constantPoolOop, index); } >>>>>> >>>>>> Either fix the indent or just add them like regular methods >>>>>> should look like. >>>>>> >>>>>>> What has been changed: >>>>>>> 1. Added tests for the new added methods. >>>>>>> 2. Removed CP tag codes 100 - 105 from being passed to java and >>>>>>> left only codes from the open JVM spec >>>>>>> (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >>>>>>> >>>>>>> Thanks >>>>>>> -Konstantin >>>>>>> >>>>>>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>>>>>> Coleen, >>>>>>>> Thanks for review >>>>>>>> >>>>>>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>>>>>> I have a couple preliminary comments. First, there are no >>>>>>>>> tests added with all this new functionality. Tests should be >>>>>>>>> added with the functionality changeset, not promised afterward. >>>>>>>> I will add tests. >>>>>>>>> Secondly, I do not like that JDK code knows the implementation >>>>>>>>> details of the JVM's constant pool tags. These should be only >>>>>>>>> for internal use. >>>>>>>> The package "sun.reflect" is for internal use only, so it >>>>>>>> shouldn?t be a problem. >>>>>>>>> My third comment is that I haven't looked carefully at this >>>>>>>>> constant pool implementation but it seems very unsafe if the >>>>>>>>> class is redefined and relies on an implementation detail in >>>>>>>>> the JVM that can change. I will have more comments once I >>>>>>>>> look more at the jvmti specification. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>>>>>> Hello >>>>>>>>>> >>>>>>>>>> Please, review modified webrev. >>>>>>>>>> >>>>>>>>>> I have added methods >>>>>>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type >>>>>>>>>> entry index from a method, field or indy entry index; >>>>>>>>>> getClassRefIndexAt(int index) - to get class entry index from >>>>>>>>>> a method or field entry index; >>>>>>>>>> >>>>>>>>>> I removed previously added method >>>>>>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more >>>>>>>>>> needed now. >>>>>>>>>> >>>>>>>>>> New webrev: >>>>>>>>>> Webrev hotspot: >>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Webrev jdk: >>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Konstantin >>>>>>>>>> >>>>>>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>>>>>> Remi, >>>>>>>>>>> >>>>>>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>>>>>> May be it also has sense to make a method >>>>>>>>>>> "getMethodRefNameAndTypeIndex(int index)" to acquire >>>>>>>>>>> name-and-type entry index for methods also. >>>>>>>>>>> >>>>>>>>>>> -Konstantin >>>>>>>>>>> >>>>>>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>>>>>> Hi Konstantin, >>>>>>>>>>>> Technically, getInvokedynamicRefInfoAt should be >>>>>>>>>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only >>>>>>>>>>>> extract the nameAndType value of the InvokeDynamicRef. >>>>>>>>>>>> >>>>>>>>>>>> In term of API, I think it's better to decompose the API, >>>>>>>>>>>> i.e. to have a method >>>>>>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>>>>>> that returns the nameAndType index and to reuse >>>>>>>>>>>> getNameAndTypeRefInfoAt(index) to get the corresponding >>>>>>>>>>>> array of Strings. >>>>>>>>>>>> >>>>>>>>>>>> cheers, >>>>>>>>>>>> R?mi >>>>>>>>>>>> >>>>>>>>>>>> ----- Mail original ----- >>>>>>>>>>>>> De: "Christian Thalinger" >>>>>>>>>>>> > >>>>>>>>>>>>> ?: "Konstantin Shefov" >>>>>>>>>>>>> Cc: "hotspot-dev developers" >>>>>>>>>>>>> , >>>>>>>>>>>>> core-libs-dev at openjdk.java.net >>>>>>>>>>>>> >>>>>>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to >>>>>>>>>>>>> sun.reflect.ConstantPool >>>>>>>>>>>>> >>>>>>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>>>>>> >>>>>>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>>>>>> The following methods are suggested: >>>>>>>>>>>>>> >>>>>>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - >>>>>>>>>>>>>> returns string >>>>>>>>>>>>>> representation of name and type from a NameAndType >>>>>>>>>>>>>> constant pool entry >>>>>>>>>>>>>> with the specified index >>>>>>>>>>>>>> >>>>>>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - >>>>>>>>>>>>>> returns string >>>>>>>>>>>>>> representation of name and type from an InvokeDynamic >>>>>>>>>>>>>> constant pool entry >>>>>>>>>>>>>> with the specified index >>>>>>>>>>>>>> >>>>>>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum >>>>>>>>>>>>>> instance of a constant >>>>>>>>>>>>>> pool entry with the specified index >>>>>>>>>>>>>> >>>>>>>>>>>>>> These three methods could be used for testing API working >>>>>>>>>>>>>> with constant >>>>>>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>>>>>> >>>>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>>>>>> Webrev hotspot: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev jdk: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> -Konstantin > From paul.sandoz at oracle.com Mon Jan 11 13:45:52 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 11 Jan 2016 14:45:52 +0100 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <5693AF52.6090109@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> <56714765.5010009@oracle.com> <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> <567271CE.3080604@oracle.com> <5693AF52.6090109@oracle.com> Message-ID: <339358FB-A0EF-4475-A9D9-E5C2182B5F6B@oracle.com> > On 11 Jan 2016, at 14:34, Konstantin Shefov wrote: > > Kindly reminder. > > Already approved by C. Thalinger and I. Ignatyev. > JDK changes look ok to me. I would prefer if the JDK test ConstantPoolTest.java could be converted to TestNG using data providers, rather than rolling your own specific pattern with enums. Paul. From aph at redhat.com Mon Jan 11 15:18:03 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Jan 2016 15:18:03 +0000 Subject: RFR: 8146709: AArch64: Incorrect use of ADRP for byte_map_base Message-ID: <5693C7AB.90103@redhat.com> The adrp() (address of page) assembler macro can reach anywhere in the 48-bit AArch64 address space. However, byte_map_base is not necessarily an address: it might even wrap around the address space so that it is a negative 64-bit constant. in that case, we should not use ADRP to form its address. While investigating this bug we discovered that the code stubs for C1's G1 pre- and post-barriers push the incorrect set of registers. We must include the call-clobbered vector registers too; they probably won't be used by the native runtime, but the ABI says that they may be so we must save them. http://cr.openjdk.java.net/~aph/8146709-2/ Andrew. From adinn at redhat.com Mon Jan 11 16:23:32 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 Jan 2016 16:23:32 +0000 Subject: RFR: 8146709: AArch64: Incorrect use of ADRP for byte_map_base In-Reply-To: <5693C7AB.90103@redhat.com> References: <5693C7AB.90103@redhat.com> Message-ID: <5693D704.1000803@redhat.com> On 11/01/16 15:18, Andrew Haley wrote: > The adrp() (address of page) assembler macro can reach anywhere in the > 48-bit AArch64 address space. However, byte_map_base is not > necessarily an address: it might even wrap around the address space so > that it is a negative 64-bit constant. in that case, we should not use > ADRP to form its address. > > While investigating this bug we discovered that the code stubs for > C1's G1 pre- and post-barriers push the incorrect set of registers. We > must include the call-clobbered vector registers too; they probably > won't be used by the native runtime, but the ABI says that they may be > so we must save them. > > http://cr.openjdk.java.net/~aph/8146709-2/ The patch looks good. However, I am not clear how we arrive at the circumstance it is meant to fix. How do we end up with a negative byte_map_base -- is that when we have a zero-based heap? How do we get a circumstance where it is 'not [necessarily] an address'? If we do have a negative value with a zero-based heap then load_byte_map_base calls mov_immediate64. Would it plant a single movz and single movk in this case or will it require more than one movk? regards, Andrew Dinn ----------- From aph at redhat.com Mon Jan 11 16:34:48 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Jan 2016 16:34:48 +0000 Subject: RFR: 8146709: AArch64: Incorrect use of ADRP for byte_map_base In-Reply-To: <5693D704.1000803@redhat.com> References: <5693C7AB.90103@redhat.com> <5693D704.1000803@redhat.com> Message-ID: <5693D9A8.1010608@redhat.com> On 01/11/2016 04:23 PM, Andrew Dinn wrote: > However, I am not clear how we arrive at the circumstance it is meant to > fix. How do we end up with a negative byte_map_base -- is that when we > have a zero-based heap? How do we get a circumstance where it is 'not > [necessarily] an address'? Imagine that we have a large heap, and it is mapped fairly high in memory. Imagine also that our byte map is mapped low in memory. An index into the byte map is byte_map_base[addr >> 9]. So, byte_map_base = _byte_map - (uintptr_t(low_bound) >> 9) There's nothing which will prevent (low_bound >> 9) from being greater than _byte_map. I don't think it's happened, but there are warnings about this in the source code. Think of it as future proofing. > If we do have a negative value with a zero-based heap then > load_byte_map_base calls mov_immediate64. Would it plant a single > movz and single movk in this case or will it require more than one > movk? If it ever happens, that depends on the exact value of byte_map_base. mov_immediate64, as you know, tries very hard to do the right thing. Andrew. From ktruong.nguyen at gmail.com Sat Jan 9 04:50:57 2016 From: ktruong.nguyen at gmail.com (Khanh Nguyen) Date: Fri, 8 Jan 2016 20:50:57 -0800 Subject: Output debug with printf? Message-ID: Hi everyone, I am modifying OpenJDK7 to implement an algorithm. In the process of doing this, I need to output debug information to the stdout. As I can see in the code base, all printings are done by using outputStream*->print_cr(). I wonder why printf() was not used at all? The reason I'm asking this because I in fact used a lot of printf() calls. And I have been seeing weird bugs such as random memory corruption and random JVM crashing. Is there any chance that my printf() is the root cause? (Assume that the logic is my code is bug-free of course) Thank you, Khanh Nguyen From rachel.protacio at oracle.com Mon Jan 11 18:38:35 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 11 Jan 2016 13:38:35 -0500 Subject: Output debug with printf? In-Reply-To: References: Message-ID: <5693F6AB.1030306@oracle.com> Hi, I can't speak to your bugs, but at least one of the purposes of the outputStream*->print_cr() calls are that you can tty->print() multiple times, buffering the output, until a tty->cr() (or print_cr()) is called, which flushes the buffer. Rachel On 1/8/2016 11:50 PM, Khanh Nguyen wrote: > Hi everyone, > > I am modifying OpenJDK7 to implement an algorithm. In the process of doing > this, I need to output debug information to the stdout. As I can see in the > code base, all printings are done by using outputStream*->print_cr(). I > wonder why printf() was not used at all? > > The reason I'm asking this because I in fact used a lot of printf() calls. > And I have been seeing weird bugs such as random memory corruption and > random JVM crashing. Is there any chance that my printf() is the root > cause? (Assume that the logic is my code is bug-free of course) > > Thank you, > > Khanh Nguyen From lois.foltan at oracle.com Mon Jan 11 19:37:31 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 11 Jan 2016 14:37:31 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <568FE8E2.6020403@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> <568D7959.7090003@oracle.com> <568D7A9E.20700@oracle.com> <568ED0B2.6040200@oracle.com> <568EE637.8000909@oracle.com> <568FE8E2.6020403@oracle.com> Message-ID: <5694047B.7040402@oracle.com> Looks good Rachel! Lois On 1/8/2016 11:50 AM, Rachel Protacio wrote: > Cool. I've fixed the issue: > http://cr.openjdk.java.net/~rprotacio/8144953.02/ > > Thanks! > Rachel > > On 1/7/2016 5:27 PM, Coleen Phillimore wrote: >> >> Hi, I really like this except the second argument to log_exception >> isn't needed. It's just >> >> oop fmt = exception(); Or you can pass >> >> *+ message->as_C_string(), p2i(exception()), tempst.as_string());* >> >> >> See src/share/vm/runtime/handles.hpp for Handle - operator() turns >> into an oop. >> >> But this looks really good. If it was like this, I wouldn't have >> introduced the bug in the first place. >> >> Thanks, >> Coleen >> >> On 1/7/16 3:55 PM, Rachel Protacio wrote: >>> Hi, >>> >>> I've refactored as suggested: >>> http://cr.openjdk.java.net/~rprotacio/8144953.01/ >>> >>> TraceExceptionsTest.java still passes, both when run regularly and >>> when run with compiled code. >>> >>> Thanks, >>> Rachel >>> >>> On 1/6/2016 3:35 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 1/6/16 3:30 PM, Coleen Phillimore wrote: >>>>> >>>>> Yes, I missed the one in the compiler file. I would really like >>>>> if there was only one function for this logging though, but am >>>>> trying to think of the best place for it. >>>> >>>> So can this be consolidated into Exceptions::log_exception() in >>>> src/share/vm/utilities/exceptions.hpp/cpp ? >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 1/6/16 2:47 PM, Rachel Protacio wrote: >>>>>> Thanks for the review, David. My impression was that no one had >>>>>> realized that the detailed message was needed anywhere else in >>>>>> that original 8048933, so this is just a matter of thoroughness, >>>>>> but maybe Coleen can speak to that? >>>>>> >>>>>> Rachel >>>>>> >>>>>> On 1/6/2016 12:42 AM, David Holmes wrote: >>>>>>> Hi Rachel, >>>>>>> >>>>>>> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this fix allowing TraceExceptionTest.java to pass >>>>>>>> with >>>>>>>> compiled code. c1_Runtime1.cpp had been missing the necessary >>>>>>>> long-form >>>>>>>> message, which has been added, and at the same time I discovered >>>>>>>> bytecodeInterpreter.cpp was similarly lacking, though no test >>>>>>>> had turned >>>>>>>> it up. >>>>>>> >>>>>>> So really this is extending the change introduced by: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8048933 >>>>>>> >>>>>>> which begs the question as to why that change was only made for >>>>>>> interpreted code in the first place? >>>>>>> >>>>>>> Changes look okay but I can't vouch for the validity of those >>>>>>> calls in that particular context. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Passes JPRT and RBT tests. >>>>>>>> >>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Rachel >>>>>> >>>>> >>>> >>> >> > From rachel.protacio at oracle.com Mon Jan 11 19:46:02 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 11 Jan 2016 14:46:02 -0500 Subject: RFR: 8144953: runtime/CommandLine/TraceExceptionsTest.java fails when exception is thrown in compiled code In-Reply-To: <5694047B.7040402@oracle.com> References: <568C007E.6060807@oracle.com> <568CA960.40202@oracle.com> <568D6F40.90806@oracle.com> <568D7959.7090003@oracle.com> <568D7A9E.20700@oracle.com> <568ED0B2.6040200@oracle.com> <568EE637.8000909@oracle.com> <568FE8E2.6020403@oracle.com> <5694047B.7040402@oracle.com> Message-ID: <5694067A.6010503@oracle.com> Thank you, Lois! I'll commit. Rachel On 1/11/2016 2:37 PM, Lois Foltan wrote: > Looks good Rachel! > Lois > > On 1/8/2016 11:50 AM, Rachel Protacio wrote: >> Cool. I've fixed the issue: >> http://cr.openjdk.java.net/~rprotacio/8144953.02/ >> >> Thanks! >> Rachel >> >> On 1/7/2016 5:27 PM, Coleen Phillimore wrote: >>> >>> Hi, I really like this except the second argument to log_exception >>> isn't needed. It's just >>> >>> oop fmt = exception(); Or you can pass >>> >>> *+ message->as_C_string(), p2i(exception()), tempst.as_string());* >>> >>> >>> See src/share/vm/runtime/handles.hpp for Handle - operator() turns >>> into an oop. >>> >>> But this looks really good. If it was like this, I wouldn't have >>> introduced the bug in the first place. >>> >>> Thanks, >>> Coleen >>> >>> On 1/7/16 3:55 PM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> I've refactored as suggested: >>>> http://cr.openjdk.java.net/~rprotacio/8144953.01/ >>>> >>>> TraceExceptionsTest.java still passes, both when run regularly and >>>> when run with compiled code. >>>> >>>> Thanks, >>>> Rachel >>>> >>>> On 1/6/2016 3:35 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 1/6/16 3:30 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Yes, I missed the one in the compiler file. I would really like >>>>>> if there was only one function for this logging though, but am >>>>>> trying to think of the best place for it. >>>>> >>>>> So can this be consolidated into Exceptions::log_exception() in >>>>> src/share/vm/utilities/exceptions.hpp/cpp ? >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 1/6/16 2:47 PM, Rachel Protacio wrote: >>>>>>> Thanks for the review, David. My impression was that no one had >>>>>>> realized that the detailed message was needed anywhere else in >>>>>>> that original 8048933, so this is just a matter of thoroughness, >>>>>>> but maybe Coleen can speak to that? >>>>>>> >>>>>>> Rachel >>>>>>> >>>>>>> On 1/6/2016 12:42 AM, David Holmes wrote: >>>>>>>> Hi Rachel, >>>>>>>> >>>>>>>> On 6/01/2016 3:42 AM, Rachel Protacio wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this fix allowing TraceExceptionTest.java to >>>>>>>>> pass with >>>>>>>>> compiled code. c1_Runtime1.cpp had been missing the necessary >>>>>>>>> long-form >>>>>>>>> message, which has been added, and at the same time I discovered >>>>>>>>> bytecodeInterpreter.cpp was similarly lacking, though no test >>>>>>>>> had turned >>>>>>>>> it up. >>>>>>>> >>>>>>>> So really this is extending the change introduced by: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8048933 >>>>>>>> >>>>>>>> which begs the question as to why that change was only made for >>>>>>>> interpreted code in the first place? >>>>>>>> >>>>>>>> Changes look okay but I can't vouch for the validity of those >>>>>>>> calls in that particular context. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Passes JPRT and RBT tests. >>>>>>>>> >>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8144953/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144953 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Rachel >>>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Mon Jan 11 23:38:09 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 11 Jan 2016 18:38:09 -0500 Subject: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool In-Reply-To: <5693AF52.6090109@oracle.com> References: <5645F9C6.2070802@oracle.com> <186AB3D9-5DAE-4558-AF8F-5043E22E5668@oracle.com> <1180432413.1310829.1447794240035.JavaMail.zimbra@u-pem.fr> <564C5CC4.5070003@oracle.com> <565478CB.2030005@oracle.com> <5654914E.1090603@oracle.com> <56588950.7050101@oracle.com> <566AB958.8010901@oracle.com> <9C46F7FF-BE6A-4E8C-99D0-54A71168455A@oracle.com> <566FD940.4090608@oracle.com> <61833FD9-418C-4B6E-9D31-05B43E770422@oracle.com> <56714765.5010009@oracle.com> <38C93A32-85EF-4B51-BADE-730A1C1CD656@oracle.com> <567271CE.3080604@oracle.com> <5693AF52.6090109@oracle.com> Message-ID: <56943CE1.3000207@oracle.com> This seems fine. Only one minor comment (where I don't need to see another webrev) + constantPoolHandle cp = constantPoolHandle(THREAD, sun_reflect_ConstantPool::get_cp(JNIHandles::resolve_non_null(obj))); would be shorter as + constantPoolHandle cp(THREAD, sun_reflect_ConstantPool::get_cp(JNIHandles::resolve_non_null(obj))); and avoid implicit copy construction. Thanks for adding tests. Coleen On 1/11/16 8:34 AM, Konstantin Shefov wrote: > Kindly reminder. > > Already approved by C. Thalinger and I. Ignatyev. > > Thanks > -Konstantin > > On 12/17/2015 11:26 AM, Konstantin Shefov wrote: >> Hi Coleen >> >> You have previously reviewed this enhancement and made a few comments >> I have resolved them, so could you look at the webrevs again, please? >> >> I have added tests, removed cp tags that are not in JVM spec (100 - >> 105) and made some other changes. >> >> JDK: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04 >> HOTSPOT: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >> >> Thanks >> -Konstantin >> >> >> On 12/16/2015 07:42 PM, Christian Thalinger wrote: >>> Looks good. Thanks. >>> >>>> On Dec 16, 2015, at 1:13 AM, Konstantin Shefov >>>> wrote: >>>> >>>> Christian >>>> >>>> I have fixed the enum so it uses "ENUMENTRY(int)" format now and >>>> does linear search. >>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.04/ >>>> >>>> -Konstantin >>>> >>>> On 12/15/2015 08:36 PM, Christian Thalinger wrote: >>>>>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi Christian >>>>>> >>>>>> Thanks for reviewing, I have changed indents as you asked: >>>>>> >>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.03 >>>>>> >>>>> Thanks. I?m still not comfortable with the enum. It would be >>>>> great if we could get the values from the VM like in JVMCI: >>>>> >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#l101 >>>>> >>>>> >>>>> but that would be overkill here. But I would like to see the enum >>>>> entries take the integer values as arguments, like here: >>>>> >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/c036c7f17e09/src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARCKind.java#l27 >>>>> >>>>> >>>>> and either do a simple linear search to find the entry or build up >>>>> a table like the HotSpotConstantPool example above. >>>>> >>>>>> -Konstantin >>>>>> >>>>>> On 12/15/2015 06:23 AM, Christian Thalinger wrote: >>>>>>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review the new version on the patch. >>>>>>>> >>>>>>>> New webrev: >>>>>>>> Webrev hotspot: >>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 >>>>>>>> >>>>>>>> Webrev jdk: >>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 >>>>>>>> >>>>>>> These newlines look ridiculous especially when it?s not even >>>>>>> needed: >>>>>>> >>>>>>> + // Returns a class reference index for a method or a field. >>>>>>> + public int getClassRefIndexAt >>>>>>> + (int index) { return >>>>>>> getClassRefIndexAt0 (constantPoolOop, index); } >>>>>>> >>>>>>> Either fix the indent or just add them like regular methods >>>>>>> should look like. >>>>>>> >>>>>>>> What has been changed: >>>>>>>> 1. Added tests for the new added methods. >>>>>>>> 2. Removed CP tag codes 100 - 105 from being passed to java and >>>>>>>> left only codes from the open JVM spec >>>>>>>> (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140). >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Konstantin >>>>>>>> >>>>>>>> On 11/27/2015 07:48 PM, Konstantin Shefov wrote: >>>>>>>>> Coleen, >>>>>>>>> Thanks for review >>>>>>>>> >>>>>>>>> On 11/24/2015 07:33 PM, Coleen Phillimore wrote: >>>>>>>>>> I have a couple preliminary comments. First, there are no >>>>>>>>>> tests added with all this new functionality. Tests should be >>>>>>>>>> added with the functionality changeset, not promised afterward. >>>>>>>>> I will add tests. >>>>>>>>>> Secondly, I do not like that JDK code knows the >>>>>>>>>> implementation details of the JVM's constant pool tags. >>>>>>>>>> These should be only for internal use. >>>>>>>>> The package "sun.reflect" is for internal use only, so it >>>>>>>>> shouldn?t be a problem. >>>>>>>>>> My third comment is that I haven't looked carefully at this >>>>>>>>>> constant pool implementation but it seems very unsafe if the >>>>>>>>>> class is redefined and relies on an implementation detail in >>>>>>>>>> the JVM that can change. I will have more comments once I >>>>>>>>>> look more at the jvmti specification. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> On 11/24/15 9:48 AM, Konstantin Shefov wrote: >>>>>>>>>>> Hello >>>>>>>>>>> >>>>>>>>>>> Please, review modified webrev. >>>>>>>>>>> >>>>>>>>>>> I have added methods >>>>>>>>>>> getNameAndTypeRefIndexAt(int index) - to get name and type >>>>>>>>>>> entry index from a method, field or indy entry index; >>>>>>>>>>> getClassRefIndexAt(int index) - to get class entry index >>>>>>>>>>> from a method or field entry index; >>>>>>>>>>> >>>>>>>>>>> I removed previously added method >>>>>>>>>>> getInvokedynamicRefInfoAt(int index) - as it is no more >>>>>>>>>>> needed now. >>>>>>>>>>> >>>>>>>>>>> New webrev: >>>>>>>>>>> Webrev hotspot: >>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.01 >>>>>>>>>>> >>>>>>>>>>> Webrev jdk: >>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.01 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Konstantin >>>>>>>>>>> >>>>>>>>>>> On 11/18/2015 02:11 PM, Konstantin Shefov wrote: >>>>>>>>>>>> Remi, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for reviewing. Your suggestion sounds sensibly. >>>>>>>>>>>> May be it also has sense to make a method >>>>>>>>>>>> "getMethodRefNameAndTypeIndex(int index)" to acquire >>>>>>>>>>>> name-and-type entry index for methods also. >>>>>>>>>>>> >>>>>>>>>>>> -Konstantin >>>>>>>>>>>> >>>>>>>>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>>>>>>>>> Hi Konstantin, >>>>>>>>>>>>> Technically, getInvokedynamicRefInfoAt should be >>>>>>>>>>>>> getNameAndTypeOfInvokedynamicRefInfoAt because it only >>>>>>>>>>>>> extract the nameAndType value of the InvokeDynamicRef. >>>>>>>>>>>>> >>>>>>>>>>>>> In term of API, I think it's better to decompose the API, >>>>>>>>>>>>> i.e. to have a method >>>>>>>>>>>>> int getInvokedynamicRefNameAndTypeIndex(int index) >>>>>>>>>>>>> that returns the nameAndType index and to reuse >>>>>>>>>>>>> getNameAndTypeRefInfoAt(index) to get the corresponding >>>>>>>>>>>>> array of Strings. >>>>>>>>>>>>> >>>>>>>>>>>>> cheers, >>>>>>>>>>>>> R?mi >>>>>>>>>>>>> >>>>>>>>>>>>> ----- Mail original ----- >>>>>>>>>>>>>> De: "Christian Thalinger" >>>>>>>>>>>>> > >>>>>>>>>>>>>> ?: "Konstantin Shefov" >>>>>>>>>>>>>> Cc: "hotspot-dev developers" >>>>>>>>>>>>>> , >>>>>>>>>>>>>> core-libs-dev at openjdk.java.net >>>>>>>>>>>>>> >>>>>>>>>>>>>> Envoy?: Lundi 16 Novembre 2015 23:41:45 >>>>>>>>>>>>>> Objet: Re: RFR [9] 8141615: Add new public methods to >>>>>>>>>>>>>> sun.reflect.ConstantPool >>>>>>>>>>>>>> >>>>>>>>>>>>>> [CC'ing core-libs-dev] >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review an enhancement to add three new methods to >>>>>>>>>>>>>>> sun.reflect.ConstantPool class. >>>>>>>>>>>>>>> The following methods are suggested: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> public String[] getNameAndTypeRefInfoAt(int index) - >>>>>>>>>>>>>>> returns string >>>>>>>>>>>>>>> representation of name and type from a NameAndType >>>>>>>>>>>>>>> constant pool entry >>>>>>>>>>>>>>> with the specified index >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> public String[] getInvokedynamicRefInfoAt(int index) - >>>>>>>>>>>>>>> returns string >>>>>>>>>>>>>>> representation of name and type from an InvokeDynamic >>>>>>>>>>>>>>> constant pool entry >>>>>>>>>>>>>>> with the specified index >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> public Tag getTagAt(int index) - returns a Tag enum >>>>>>>>>>>>>>> instance of a constant >>>>>>>>>>>>>>> pool entry with the specified index >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> These three methods could be used for testing API >>>>>>>>>>>>>>> working with constant >>>>>>>>>>>>>>> pool, e.g. JVMCI. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8141615 >>>>>>>>>>>>>>> Webrev hotspot: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev jdk: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> -Konstantin >> > From christian.thalinger at oracle.com Tue Jan 12 01:50:20 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Jan 2016 15:50:20 -1000 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568EA621.4040407@oracle.com> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> <568C2F04.8020802@oracle.com> <568C3365.5000502@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC943@DEWDFEMB12A.global.corp.sap> <568EA621.4040407@oracle.com> Message-ID: <80F6500E-8321-4DFD-9796-93DFD9232B26@oracle.com> Assuming you copied the functions verbatim this looks good. Good improvement. > On Jan 7, 2016, at 7:53 AM, Coleen Phillimore wrote: > > > Hi Goetz, > > I messed up when I moved math_entry_available. I meant to leave it in class TemplateInterpreter but move it to templateInterpreterGenerator_ppc.cpp file. > > But that would defeat some of the purpose of this change to make sure that functions were in the right files. I didn't like TemplateInterpreter::math_entry_available() in abstractInterpreter_ppc.cpp either though. > > So, I moved the function math_entry_available into class AbstractInterpreter which is called by AbstractInterpreter::can_be_compiled(), hence avoiding a call to a derived class which didn't seem good. This makes the most sense to me. > > Can you check out: > > http://cr.openjdk.java.net/~coleenp/8146410.02/webrev/index.html > > thanks, > Coleen > > On 1/7/16 3:08 AM, Lindenmaier, Goetz wrote: >> Hi Coleen, >> >> sorry I didn't answer yesterday, we had another holiday. >> >> You moved PPCs math_entry_available() in your new change. >> I think it makes no difference where it's located, as long as it's >> called from both, interpreter and interpreterGenerator classes. >> >> But if you want to move it, you need to fix all the other occurances >> of the method, too: >> http://cr.openjdk.java.net/~goetz/wr16/8146410-interpCleanup/move_math_entry_available.patch >> >> Elsewise good. >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Coleen Phillimore >>> Sent: Dienstag, 5. Januar 2016 22:20 >>> To: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined >>> in the wrong files >>> >>> >>> Hi, Please see updated webrev for comments so far: >>> >>> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/ >>> >>> Tested again with JPRT (on all Oracle supported platforms). >>> >>> thanks, >>> Coleen >>> >>> On 1/5/16 4:00 PM, Coleen Phillimore wrote: >>>> >>>> On 1/5/16 3:49 PM, Lindenmaier, Goetz wrote: >>>>>> -----Original Message----- >>>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>>> Sent: Dienstag, 5. Januar 2016 21:01 >>>>>> To: Lindenmaier, Goetz ; hotspot-dev >>>>>> developers >>>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>>>>> defined >>>>>> in the wrong files >>>>>> >>>>>> >>>>>> >>>>>> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> I think they belong together because can_be_compiled() just returns >>>>>>> false for functions that have a math entry which is generated by >>>>>>> generate_math_entry(). So if you add a new math_entry, you >>>>>>> also have to fix can_be_compiled. We wired this dependency into >>>>>>> math_entry_available(kind), so that both functions are guaranteed >>>>>>> to behave similar. >>>>>> I'm getting confused by this. It seems like math_entry_available >>>>>> should >>>>>> be in templateInterpreterGenerator near generate_math_entry. >>>>>> >>>>>> The reason I don't want can_be_compiled (which is misleading) is >>>>>> because >>>>>> all the other platforms have it too and I don't want them in the wrong >>>>>> files. >>>>>> >>>>>> what do you think? >>>>> What I mean is can_be_compiled() should be moved to class >>>>> templateInterpreterGenerator and placed near generate_math_entry() >>>>> on all platforms. >>>>> The similarity is the same on all of them. >>>>> >>>>> But I must admit in compilationPolicy.cpp it reads better if the >>>>> AbstractInterpreter is asked. Also, method_kind is member >>>>> of AbstractInterpreter. >>>> Yes, that's what I thought. It's more of an Interpreter:: method. And >>>> it's a static function and the functions in >>>> TemplateInterpreterGenerator are not generally static functions. I >>>> didn't want to move the others there. >>>> >>>>> But method_kind is also completely over-engeneered, as it's >>>>> only used in can_be_compiled, and there it's only used >>>>> for math entries... >>>>> >>>>> Maybe a change of it's own is needed... >>>> I'm holding my head in pain, and my change is too big already to add >>>> this. I did move math_entry_available because to >>>> templateInterpreterGenerator_ppc.cpp because there is no >>>> templateInterpreter_ppc.cpp anymore (there would only be this one >>>> function and the sizing). I think this looks good and better than >>>> having TemplateInterpreter::math_entry_available() in >>>> abstractInterpreter_ppc.cpp. See: >>>> >>>> >>> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/src/cpu/ppc/vm/t >>> emplateInterpreterGenerator_ppc.cpp.udiff.html >>>> >>>> I think moving can_be_compiled and cleaning up the method_kind vs. >>>> intrinsics is a bigger problem to solve, and should be attempted in a >>>> further RFE. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Coleen >>>>>>> The name of the function is kind of misleading to me. >>>>>>> >>>>>>> But I won't insist... >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>>>>> Sent: Tuesday, January 05, 2016 7:17 PM >>>>>>>> To: Lindenmaier, Goetz ; hotspot-dev >>>>>>>> developers >>>>>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>>>>> defined >>>>>>>> in the wrong files >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> Could you please also move >>>>>>>>> AbstractInterpreter::can_be_compiled(methodHandle m) >>>>>>>>> to above >>>>>>>>> >>> TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: >>>>>>>> MethodKind kind)? >>>>>>>>> I think these belong together. >>>>>>>> Really? They're in different classes (hence the motivation for the >>>>>>>> change) and generate_math_entry doesn't call can_be_compiled. >>>>>>>> CompilationPolicy does but it calls it from >>>>>>>> AbstractInterpreter::can_be_compiled() so I really can't move this >>>>>>>> function into TemplateInterpreterGenerator. It doesn't make sense >>> to >>>>>> me. >>>>>>>>> We seem to have different BIND macros on ppc. The '__' is also in >>>>>>>>> the >>>>>>>>> macro. Could you please fix this small issue? It breaks the ppc >>>>>>>>> build. >>>>>>>>> >>>>>>>>> diff -r 743aa331fc90 >>>>>>>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >>>>>>>>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>>>>>> Jan 05 07:47:21 2016 +0100 >>>>>>>>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>>>>>> Jan 05 08:06:12 2016 +0100 >>>>>>>>> @@ -416,7 +416,7 @@ >>>>>>>>> default: ShouldNotReachHere(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> - __ BIND(done); >>>>>>>>> + BIND(done); >>>>>>>>> __ blr(); >>>>>>>>> >>>>>>>> Fixed. Thanks!! >>>>>>>>> return entry; >>>>>>>>> >>>>>>>>> Besides this, the change looks good. >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>>> Thanks and best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> PS: is it possible to share your Copyright script? >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: hotspot-dev [mailto:hotspot-dev- >>> bounces at openjdk.java.net] >>>>>> On >>>>>>>>>> Behalf Of Coleen Phillimore >>>>>>>>>> Sent: Monday, January 04, 2016 11:43 PM >>>>>>>>>> To: hotspot-dev developers >>>>>>>>>> Subject: RFR (M) 8146410: Interpreter functions are declared and >>>>>> defined >>>>>>>> in >>>>>>>>>> the wrong files >>>>>>>>>> >>>>>>>>>> Summary: Moved functions to the correct files. >>>>>>>>>> >>>>>>>>>> See bug for more details. >>>>>>>>>> >>>>>>>>>> I basically did an hg mv templateInterpreter_.cpp >>>>>>>>>> abstractInterpreter_.cpp and moved the >>> interpreter_.cpp >>>>>>>>>> functions there. >>>>>>>>>> >>>>>>>>>> Also moved generate_slow_signature_handler to >>>>>>>>>> TemplateInterpreterGenerator/CppInterpreterGenerator because >>> it's >>>>>>>> not >>>>>>>>>> shared. >>>>>>>>>> >>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >>>>>>>>>> >>>>>>>>>> Tested with JPRT on Oracle supported platforms and built zero on >>>>>>>>>> linux >>>>>>>>>> x86. Also fixed change that broke zero in >>>>>>>>>> stack_zero.inline.hpp. I >>>>>>>>>> think this should work on PPC and AARCH64, but please let me >>> know. >>>>>>>>>> One question for AARCH64 platform in file: >>>>>>>>>> >>>>>>>>>> >>> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >>>>>>>>>> eInterpreterGenerator_aarch64.cpp.udiff.html >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Coleen > From edward.nevill at gmail.com Tue Jan 12 09:31:12 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 12 Jan 2016 09:31:12 +0000 Subject: RFR: 8146709: AArch64: Incorrect use of ADRP for byte_map_base In-Reply-To: <5693C7AB.90103@redhat.com> References: <5693C7AB.90103@redhat.com> Message-ID: <1452591072.28862.1.camel@mylittlepony.linaroharston> Looks fine to me. Ed. On Mon, 2016-01-11 at 15:18 +0000, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8146709-2/ > > Andrew. > From max.ockner at oracle.com Tue Jan 12 15:06:28 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 12 Jan 2016 10:06:28 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568AF55D.9000706@oracle.com> References: <568AF55D.9000706@oracle.com> Message-ID: <56951674.3060207@oracle.com> Looks fine to me. -Max On 1/4/2016 5:42 PM, Coleen Phillimore wrote: > Summary: Moved functions to the correct files. > > See bug for more details. > > I basically did an hg mv templateInterpreter_.cpp > abstractInterpreter_.cpp and moved the interpreter_.cpp > functions there. > > Also moved generate_slow_signature_handler to > TemplateInterpreterGenerator/CppInterpreterGenerator because it's not > shared. > > open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ > bug link https://bugs.openjdk.java.net/browse/JDK-8146410 > > Tested with JPRT on Oracle supported platforms and built zero on linux > x86. Also fixed change that broke zero in stack_zero.inline.hpp. I > think this should work on PPC and AARCH64, but please let me know. > > One question for AARCH64 platform in file: > > http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp.udiff.html > > > thanks, > Coleen From aph at redhat.com Tue Jan 12 15:08:51 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Jan 2016 15:08:51 +0000 Subject: RFR: 8146891: AArch64 needs patch for 8032463 Message-ID: <56951703.70605@redhat.com> The fix for 8032463 contains some CPU-specific code which was never applied to the AArch64 tree. Fixed thusly. http://cr.openjdk.java.net/~aph/8146891/ Andrew. From kim.barrett at oracle.com Tue Jan 12 15:25:07 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 12 Jan 2016 10:25:07 -0500 Subject: RFR: 8146793: logStream::write re-formats string Message-ID: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> Please review this fix to some problems in logStream::write and the facilities used to implement it. 1. logStream::write no longer attempt to reformat the already formatted accumulated output. [Fixing this led to the discovery of the issues below.] 2. Fixed Log<>::vwrite test for overflow of the initial buffer, which didn't allow for the trailing NUL. 3. Fixed Log<>::vwrite to copy the va_list arguments before first format attempt and use that copy if a second format attempt is needed, rather than incorrectly reusing the original (now possibly modified) va_list. CR: https://bugs.openjdk.java.net/browse/JDK-8146793 Webrev: http://cr.openjdk.java.net/~kbarrett/8146793/webrev.00/ Testing: JPRT Locally verified printing a "%" to a log stream works, by running TestPrintGCDetailsVerbose (after fixing it for JDK-8146728). From marcus.larsson at oracle.com Tue Jan 12 15:51:33 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 12 Jan 2016 16:51:33 +0100 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> Message-ID: <56952105.4090406@oracle.com> Hi Kim, On 01/12/2016 04:25 PM, Kim Barrett wrote: > Please review this fix to some problems in logStream::write and the > facilities used to implement it. > > 1. logStream::write no longer attempt to reformat the already > formatted accumulated output. [Fixing this led to the discovery of > the issues below.] > > 2. Fixed Log<>::vwrite test for overflow of the initial buffer, which > didn't allow for the trailing NUL. > > 3. Fixed Log<>::vwrite to copy the va_list arguments before first > format attempt and use that copy if a second format attempt is > needed, rather than incorrectly reusing the original (now possibly > modified) va_list. All good catches. > CR: > https://bugs.openjdk.java.net/browse/JDK-8146793 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8146793/webrev.00/ Looks good, thanks for finding and fixing this! Marcus > > Testing: > JPRT > Locally verified printing a "%" to a log stream works, by running > TestPrintGCDetailsVerbose (after fixing it for JDK-8146728). > From coleen.phillimore at oracle.com Tue Jan 12 18:09:13 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Jan 2016 13:09:13 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <80F6500E-8321-4DFD-9796-93DFD9232B26@oracle.com> References: <568AF55D.9000706@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC0A6@DEWDFEMB12A.global.corp.sap> <568C08A3.2060405@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC33E@DEWDFEMB12A.global.corp.sap> <568C2106.8010608@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC3AD@DEWDFEMB12A.global.corp.sap> <568C2F04.8020802@oracle.com> <568C3365.5000502@oracle.com> <4295855A5C1DE049A61835A1887419CC41EFC943@DEWDFEMB12A.global.corp.sap> <568EA621.4040407@oracle.com> <80F6500E-8321-4DFD-9796-93DFD9232B26@oracle.com> Message-ID: <56954149.2030401@oracle.com> On 1/11/16 8:50 PM, Christian Thalinger wrote: > Assuming you copied the functions verbatim this looks good. Good improvement. Yes, they are only copied. Thanks, Christian! Coleen > >> On Jan 7, 2016, at 7:53 AM, Coleen Phillimore wrote: >> >> >> Hi Goetz, >> >> I messed up when I moved math_entry_available. I meant to leave it in class TemplateInterpreter but move it to templateInterpreterGenerator_ppc.cpp file. >> >> But that would defeat some of the purpose of this change to make sure that functions were in the right files. I didn't like TemplateInterpreter::math_entry_available() in abstractInterpreter_ppc.cpp either though. >> >> So, I moved the function math_entry_available into class AbstractInterpreter which is called by AbstractInterpreter::can_be_compiled(), hence avoiding a call to a derived class which didn't seem good. This makes the most sense to me. >> >> Can you check out: >> >> http://cr.openjdk.java.net/~coleenp/8146410.02/webrev/index.html >> >> thanks, >> Coleen >> >> On 1/7/16 3:08 AM, Lindenmaier, Goetz wrote: >>> Hi Coleen, >>> >>> sorry I didn't answer yesterday, we had another holiday. >>> >>> You moved PPCs math_entry_available() in your new change. >>> I think it makes no difference where it's located, as long as it's >>> called from both, interpreter and interpreterGenerator classes. >>> >>> But if you want to move it, you need to fix all the other occurances >>> of the method, too: >>> http://cr.openjdk.java.net/~goetz/wr16/8146410-interpCleanup/move_math_entry_available.patch >>> >>> Elsewise good. >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf Of Coleen Phillimore >>>> Sent: Dienstag, 5. Januar 2016 22:20 >>>> To: hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and defined >>>> in the wrong files >>>> >>>> >>>> Hi, Please see updated webrev for comments so far: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/ >>>> >>>> Tested again with JPRT (on all Oracle supported platforms). >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 1/5/16 4:00 PM, Coleen Phillimore wrote: >>>>> On 1/5/16 3:49 PM, Lindenmaier, Goetz wrote: >>>>>>> -----Original Message----- >>>>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>>>> Sent: Dienstag, 5. Januar 2016 21:01 >>>>>>> To: Lindenmaier, Goetz ; hotspot-dev >>>>>>> developers >>>>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>>>>>> defined >>>>>>> in the wrong files >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 1/5/16 2:51 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> I think they belong together because can_be_compiled() just returns >>>>>>>> false for functions that have a math entry which is generated by >>>>>>>> generate_math_entry(). So if you add a new math_entry, you >>>>>>>> also have to fix can_be_compiled. We wired this dependency into >>>>>>>> math_entry_available(kind), so that both functions are guaranteed >>>>>>>> to behave similar. >>>>>>> I'm getting confused by this. It seems like math_entry_available >>>>>>> should >>>>>>> be in templateInterpreterGenerator near generate_math_entry. >>>>>>> >>>>>>> The reason I don't want can_be_compiled (which is misleading) is >>>>>>> because >>>>>>> all the other platforms have it too and I don't want them in the wrong >>>>>>> files. >>>>>>> >>>>>>> what do you think? >>>>>> What I mean is can_be_compiled() should be moved to class >>>>>> templateInterpreterGenerator and placed near generate_math_entry() >>>>>> on all platforms. >>>>>> The similarity is the same on all of them. >>>>>> >>>>>> But I must admit in compilationPolicy.cpp it reads better if the >>>>>> AbstractInterpreter is asked. Also, method_kind is member >>>>>> of AbstractInterpreter. >>>>> Yes, that's what I thought. It's more of an Interpreter:: method. And >>>>> it's a static function and the functions in >>>>> TemplateInterpreterGenerator are not generally static functions. I >>>>> didn't want to move the others there. >>>>> >>>>>> But method_kind is also completely over-engeneered, as it's >>>>>> only used in can_be_compiled, and there it's only used >>>>>> for math entries... >>>>>> >>>>>> Maybe a change of it's own is needed... >>>>> I'm holding my head in pain, and my change is too big already to add >>>>> this. I did move math_entry_available because to >>>>> templateInterpreterGenerator_ppc.cpp because there is no >>>>> templateInterpreter_ppc.cpp anymore (there would only be this one >>>>> function and the sizing). I think this looks good and better than >>>>> having TemplateInterpreter::math_entry_available() in >>>>> abstractInterpreter_ppc.cpp. See: >>>>> >>>>> >>>> http://cr.openjdk.java.net/~coleenp/8146410.01/webrev/src/cpu/ppc/vm/t >>>> emplateInterpreterGenerator_ppc.cpp.udiff.html >>>>> I think moving can_be_compiled and cleaning up the method_kind vs. >>>>> intrinsics is a bigger problem to solve, and should be attempted in a >>>>> further RFE. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Coleen >>>>>>>> The name of the function is kind of misleading to me. >>>>>>>> >>>>>>>> But I won't insist... >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>>>>>>> Sent: Tuesday, January 05, 2016 7:17 PM >>>>>>>>> To: Lindenmaier, Goetz ; hotspot-dev >>>>>>>>> developers >>>>>>>>> Subject: Re: RFR (M) 8146410: Interpreter functions are declared and >>>>>>> defined >>>>>>>>> in the wrong files >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/5/16 2:19 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> Could you please also move >>>>>>>>>> AbstractInterpreter::can_be_compiled(methodHandle m) >>>>>>>>>> to above >>>>>>>>>> >>>> TemplateInterpreterGenerator::generate_math_entry(AbstractInterpreter:: >>>>>>>>> MethodKind kind)? >>>>>>>>>> I think these belong together. >>>>>>>>> Really? They're in different classes (hence the motivation for the >>>>>>>>> change) and generate_math_entry doesn't call can_be_compiled. >>>>>>>>> CompilationPolicy does but it calls it from >>>>>>>>> AbstractInterpreter::can_be_compiled() so I really can't move this >>>>>>>>> function into TemplateInterpreterGenerator. It doesn't make sense >>>> to >>>>>>> me. >>>>>>>>>> We seem to have different BIND macros on ppc. The '__' is also in >>>>>>>>>> the >>>>>>>>>> macro. Could you please fix this small issue? It breaks the ppc >>>>>>>>>> build. >>>>>>>>>> >>>>>>>>>> diff -r 743aa331fc90 >>>>>>>>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >>>>>>>>>> --- a/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>>>>>>> Jan 05 07:47:21 2016 +0100 >>>>>>>>>> +++ b/src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Tue >>>>>>>>> Jan 05 08:06:12 2016 +0100 >>>>>>>>>> @@ -416,7 +416,7 @@ >>>>>>>>>> default: ShouldNotReachHere(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> - __ BIND(done); >>>>>>>>>> + BIND(done); >>>>>>>>>> __ blr(); >>>>>>>>>> >>>>>>>>> Fixed. Thanks!! >>>>>>>>>> return entry; >>>>>>>>>> >>>>>>>>>> Besides this, the change looks good. >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>>> Thanks and best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> PS: is it possible to share your Copyright script? >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: hotspot-dev [mailto:hotspot-dev- >>>> bounces at openjdk.java.net] >>>>>>> On >>>>>>>>>>> Behalf Of Coleen Phillimore >>>>>>>>>>> Sent: Monday, January 04, 2016 11:43 PM >>>>>>>>>>> To: hotspot-dev developers >>>>>>>>>>> Subject: RFR (M) 8146410: Interpreter functions are declared and >>>>>>> defined >>>>>>>>> in >>>>>>>>>>> the wrong files >>>>>>>>>>> >>>>>>>>>>> Summary: Moved functions to the correct files. >>>>>>>>>>> >>>>>>>>>>> See bug for more details. >>>>>>>>>>> >>>>>>>>>>> I basically did an hg mv templateInterpreter_.cpp >>>>>>>>>>> abstractInterpreter_.cpp and moved the >>>> interpreter_.cpp >>>>>>>>>>> functions there. >>>>>>>>>>> >>>>>>>>>>> Also moved generate_slow_signature_handler to >>>>>>>>>>> TemplateInterpreterGenerator/CppInterpreterGenerator because >>>> it's >>>>>>>>> not >>>>>>>>>>> shared. >>>>>>>>>>> >>>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >>>>>>>>>>> >>>>>>>>>>> Tested with JPRT on Oracle supported platforms and built zero on >>>>>>>>>>> linux >>>>>>>>>>> x86. Also fixed change that broke zero in >>>>>>>>>>> stack_zero.inline.hpp. I >>>>>>>>>>> think this should work on PPC and AARCH64, but please let me >>>> know. >>>>>>>>>>> One question for AARCH64 platform in file: >>>>>>>>>>> >>>>>>>>>>> >>>> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templat >>>>>>>>>>> eInterpreterGenerator_aarch64.cpp.udiff.html >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> Coleen From coleen.phillimore at oracle.com Tue Jan 12 18:09:24 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Jan 2016 13:09:24 -0500 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <56951674.3060207@oracle.com> References: <568AF55D.9000706@oracle.com> <56951674.3060207@oracle.com> Message-ID: <56954154.5060500@oracle.com> Thanks Max! Coleen On 1/12/16 10:06 AM, Max Ockner wrote: > Looks fine to me. > -Max > > On 1/4/2016 5:42 PM, Coleen Phillimore wrote: >> Summary: Moved functions to the correct files. >> >> See bug for more details. >> >> I basically did an hg mv templateInterpreter_.cpp >> abstractInterpreter_.cpp and moved the interpreter_.cpp >> functions there. >> >> Also moved generate_slow_signature_handler to >> TemplateInterpreterGenerator/CppInterpreterGenerator because it's not >> shared. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8146410/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8146410 >> >> Tested with JPRT on Oracle supported platforms and built zero on >> linux x86. Also fixed change that broke zero in >> stack_zero.inline.hpp. I think this should work on PPC and AARCH64, >> but please let me know. >> >> One question for AARCH64 platform in file: >> >> http://cr.openjdk.java.net/~coleenp/8146410/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp.udiff.html >> >> >> thanks, >> Coleen > From kim.barrett at oracle.com Tue Jan 12 18:11:37 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 12 Jan 2016 13:11:37 -0500 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <56952105.4090406@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> <56952105.4090406@oracle.com> Message-ID: <854720D4-9658-4559-8A0A-DFC02272F050@oracle.com> On Jan 12, 2016, at 10:51 AM, Marcus Larsson wrote: > > On 01/12/2016 04:25 PM, Kim Barrett wrote: >> Please review this fix to some problems in logStream::write and the >> facilities used to implement it. >> >> 1. logStream::write no longer attempt to reformat the already >> formatted accumulated output. [Fixing this led to the discovery of >> the issues below.] >> >> 2. Fixed Log<>::vwrite test for overflow of the initial buffer, which >> didn't allow for the trailing NUL. >> >> 3. Fixed Log<>::vwrite to copy the va_list arguments before first >> format attempt and use that copy if a second format attempt is >> needed, rather than incorrectly reusing the original (now possibly >> modified) va_list. > > All good catches. > >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8146793 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8146793/webrev.00/ > > Looks good, thanks for finding and fixing this! > > Marcus Thanks for reviewing. From rachel.protacio at oracle.com Tue Jan 12 18:39:37 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 12 Jan 2016 13:39:37 -0500 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> Message-ID: <56954869.8030809@oracle.com> Looks good to me, Kim! Thank you for fixing this. One note: I think you accidentally overwrote the original log.hpp copyright instead of adding to it. Rachel On 1/12/2016 10:25 AM, Kim Barrett wrote: > Please review this fix to some problems in logStream::write and the > facilities used to implement it. > > 1. logStream::write no longer attempt to reformat the already > formatted accumulated output. [Fixing this led to the discovery of > the issues below.] > > 2. Fixed Log<>::vwrite test for overflow of the initial buffer, which > didn't allow for the trailing NUL. > > 3. Fixed Log<>::vwrite to copy the va_list arguments before first > format attempt and use that copy if a second format attempt is > needed, rather than incorrectly reusing the original (now possibly > modified) va_list. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8146793 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8146793/webrev.00/ > > Testing: > JPRT > Locally verified printing a "%" to a log stream works, by running > TestPrintGCDetailsVerbose (after fixing it for JDK-8146728). > From vladimir.kozlov at oracle.com Tue Jan 12 19:19:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Jan 2016 11:19:56 -0800 Subject: RFR: 8146891: AArch64 needs patch for 8032463 In-Reply-To: <56951703.70605@redhat.com> References: <56951703.70605@redhat.com> Message-ID: <569551DC.8000000@oracle.com> Looks good assuming 0 means stack slot offset. Thanks, Vladimir On 1/12/16 7:08 AM, Andrew Haley wrote: > The fix for 8032463 contains some CPU-specific code which was never applied to the AArch64 tree. > > Fixed thusly. > > http://cr.openjdk.java.net/~aph/8146891/ > > Andrew. > From kim.barrett at oracle.com Tue Jan 12 19:55:14 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 12 Jan 2016 14:55:14 -0500 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <56954869.8030809@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> <56954869.8030809@oracle.com> Message-ID: <76EAE52C-B59E-4EE0-92A8-94005E358B60@oracle.com> On Jan 12, 2016, at 1:39 PM, Rachel Protacio wrote: > > Looks good to me, Kim! Thank you for fixing this. One note: I think you accidentally overwrote the original log.hpp copyright instead of adding to it. Thanks for reviewing, and thanks for spotting that. From christian.thalinger at oracle.com Tue Jan 12 20:13:30 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 12 Jan 2016 10:13:30 -1000 Subject: RFR (S): 8146246: JVMCICompiler::abort_on_pending_exception: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: <568D6C63.5000403@oracle.com> <0C62FED5-F3F8-44CE-B1DB-095F9170370B@oracle.com> <80FAECCD-94BA-479C-B042-0A50D9121C8F@oracle.com> <568EBE51.3030904@oracle.com> Message-ID: > On Jan 7, 2016, at 11:10 AM, Christian Thalinger wrote: > > >> On Jan 7, 2016, at 9:36 AM, Coleen Phillimore wrote: >> >> >> Hi, >> >> What testing did you run with the change to java.cpp ? Besides the calls in ci/ciReplay.cpp, this is the only call to java_lang_Throwable::print_stack_trace. Can the ciReplay.cpp calls be converted to the Java call to printStackTrace? > > Not enough. > >> >> If you didn't run full tests on the java.cpp change to make sure it doesn't break anything, I think you should revert that part and file another RFE to remove the function and the remaining calls so it can be tested separately. > > Yes, I?ll file another RFE. FTR: https://bugs.openjdk.java.net/browse/JDK-8146933 > >> The JVMCI changes seem fine to me. > > Thanks. > >> >> Coleen >> >> On 1/7/16 11:45 AM, Christian Thalinger wrote: >>> [Changing lists because it should have been on hotspot-dev.] >>> >>> Coleen, in case 2) below I could replace java_lang_Throwable::print_stack_trace with java_lang_Throwable::java_printStackTrace. >>> >>>> On Jan 6, 2016, at 12:57 PM, Christian Thalinger wrote: >>>> >>>> >>>>> On Jan 6, 2016, at 9:34 AM, Vladimir Kozlov wrote: >>>>> >>>>> I would go with "Java code do the printing?. >>>> Yeah, it might be better. >>>> >>>>> You left ttyLocker in case 2) in src/share/vm/runtime/java.cpp >>>> Right. Thanks for pointing that out. >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/6/16 11:19 AM, Christian Thalinger wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146246 >>>>>> >>>>>> The problem is that https://bugs.openjdk.java.net/browse/JDK-8145435 introduced ttyLocker to synchronize the exception output but java_lang_Throwable::print_stack_trace can call out to Java to get the cause. >>>>>> >>>>>> There are two solutions: >>>>>> >>>>>> 1) Remove ttyLocker and deal with some possible scrambling in the rare case of an exception: >>>>>> >>>>>> diff -r df8d635f2296 -r e87e187552fb src/share/vm/jvmci/jvmciCompiler.cpp >>>>>> --- a/src/share/vm/jvmci/jvmciCompiler.cpp Tue Dec 29 11:24:01 2015 -0800 >>>>>> +++ b/src/share/vm/jvmci/jvmciCompiler.cpp Thu Dec 31 09:20:16 2015 -0800 >>>>>> @@ -162,10 +162,7 @@ void JVMCICompiler::compile_method(const >>>>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> >>>>>> - { >>>>>> - ttyLocker ttyl; >>>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>>> - } >>>>>> + java_lang_Throwable::print_stack_trace(exception, tty); >>>>>> >>>>>> // Something went wrong so disable compilation at this level >>>>>> method->set_not_compilable(CompLevel_full_optimization); >>>>>> @@ -181,11 +178,8 @@ void JVMCICompiler::abort_on_pending_exc >>>>>> Thread* THREAD = Thread::current(); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> >>>>>> - { >>>>>> - ttyLocker ttyl; >>>>>> - tty->print_raw_cr(message); >>>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>>> - } >>>>>> + tty->print_raw_cr(message); >>>>>> + java_lang_Throwable::print_stack_trace(exception, tty); >>>>>> >>>>>> // Give other aborting threads to also print their stack traces. >>>>>> // This can be very useful when debugging class initialization >>>>>> diff -r df8d635f2296 -r e87e187552fb src/share/vm/runtime/java.cpp >>>>>> --- a/src/share/vm/runtime/java.cpp Tue Dec 29 11:24:01 2015 -0800 >>>>>> +++ b/src/share/vm/runtime/java.cpp Thu Dec 31 09:20:16 2015 -0800 >>>>>> @@ -432,7 +432,6 @@ void before_exit(JavaThread* thread) { >>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> - ttyLocker ttyl; >>>>>> java_lang_Throwable::print_stack_trace(exception, tty); >>>>>> } >>>>>> #endif >>>>>> >>>>>> or >>>>>> >>>>>> 2) Call out to Java and let the Java code do the printing: >>>>>> >>>>>> diff -r 0fcfe4b07f7e src/share/vm/classfile/javaClasses.cpp >>>>>> --- a/src/share/vm/classfile/javaClasses.cpp Tue Dec 29 18:30:51 2015 +0100 >>>>>> +++ b/src/share/vm/classfile/javaClasses.cpp Wed Jan 06 09:12:00 2016 -1000 >>>>>> @@ -1784,6 +1784,20 @@ void java_lang_Throwable::print_stack_tr >>>>>> } >>>>>> } >>>>>> >>>>>> +/** >>>>>> + * Print the throwable stack trace by calling the Java method java.lang.Throwable.printStackTrace(). >>>>>> + */ >>>>>> +void java_lang_Throwable::java_printStackTrace(Handle throwable, TRAPS) { >>>>>> + assert(throwable->is_a(SystemDictionary::Throwable_klass()), "Throwable instance expected"); >>>>>> + JavaValue result(T_VOID); >>>>>> + JavaCalls::call_virtual(&result, >>>>>> + throwable, >>>>>> + KlassHandle(THREAD, SystemDictionary::Throwable_klass()), >>>>>> + vmSymbols::printStackTrace_name(), >>>>>> + vmSymbols::void_method_signature(), >>>>>> + THREAD); >>>>>> +} >>>>>> + >>>>>> void java_lang_Throwable::fill_in_stack_trace(Handle throwable, const methodHandle& method, TRAPS) { >>>>>> if (!StackTraceInThrowable) return; >>>>>> ResourceMark rm(THREAD); >>>>>> diff -r 0fcfe4b07f7e src/share/vm/classfile/javaClasses.hpp >>>>>> --- a/src/share/vm/classfile/javaClasses.hpp Tue Dec 29 18:30:51 2015 +0100 >>>>>> +++ b/src/share/vm/classfile/javaClasses.hpp Wed Jan 06 09:12:00 2016 -1000 >>>>>> @@ -554,6 +554,7 @@ class java_lang_Throwable: AllStatic { >>>>>> // Printing >>>>>> static void print(Handle throwable, outputStream* st); >>>>>> static void print_stack_trace(Handle throwable, outputStream* st); >>>>>> + static void java_printStackTrace(Handle throwable, TRAPS); >>>>>> // Debugging >>>>>> friend class JavaClasses; >>>>>> }; >>>>>> diff -r 0fcfe4b07f7e src/share/vm/jvmci/jvmciCompiler.cpp >>>>>> --- a/src/share/vm/jvmci/jvmciCompiler.cpp Tue Dec 29 18:30:51 2015 +0100 >>>>>> +++ b/src/share/vm/jvmci/jvmciCompiler.cpp Wed Jan 06 09:12:00 2016 -1000 >>>>>> @@ -162,10 +162,7 @@ void JVMCICompiler::compile_method(const >>>>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> >>>>>> - { >>>>>> - ttyLocker ttyl; >>>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>>> - } >>>>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>>>> >>>>>> // Something went wrong so disable compilation at this level >>>>>> method->set_not_compilable(CompLevel_full_optimization); >>>>>> @@ -181,11 +178,7 @@ void JVMCICompiler::abort_on_pending_exc >>>>>> Thread* THREAD = Thread::current(); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> >>>>>> - { >>>>>> - ttyLocker ttyl; >>>>>> - tty->print_raw_cr(message); >>>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>>> - } >>>>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>>>> >>>>>> // Give other aborting threads to also print their stack traces. >>>>>> // This can be very useful when debugging class initialization >>>>>> diff -r 0fcfe4b07f7e src/share/vm/runtime/java.cpp >>>>>> --- a/src/share/vm/runtime/java.cpp Tue Dec 29 18:30:51 2015 +0100 >>>>>> +++ b/src/share/vm/runtime/java.cpp Wed Jan 06 09:12:00 2016 -1000 >>>>>> @@ -433,7 +433,7 @@ void before_exit(JavaThread* thread) { >>>>>> Handle exception(THREAD, PENDING_EXCEPTION); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> ttyLocker ttyl; >>>>>> - java_lang_Throwable::print_stack_trace(exception, tty); >>>>>> + java_lang_Throwable::java_printStackTrace(exception, THREAD); >>>>>> } >>>>>> #endif >>>>>> >> > From aleksey.shipilev at oracle.com Tue Jan 12 21:30:22 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 13 Jan 2016 00:30:22 +0300 Subject: RFR (M) 8146410: Interpreter functions are declared and defined in the wrong files In-Reply-To: <568C07BD.7060609@redhat.com> References: <568AF55D.9000706@oracle.com> <568B9AD9.4040504@redhat.com> <568BE504.6000802@redhat.com> <4295855A5C1DE049A61835A1887419CC41EFC265@DEWDFEMB12A.global.corp.sap> <568C04E7.3030403@redhat.com> <568C06DA.7080903@oracle.com> <568C07BD.7060609@redhat.com> Message-ID: <5695706E.8020705@oracle.com> On 01/05/2016 09:13 PM, Andrew Haley wrote: > On 01/05/2016 06:09 PM, Coleen Phillimore wrote: >> Okay, I'll have to copy the function into other CPU implementations but >> it does leave room for changing them so that we don't have to bang all >> of the pages in the stack (the reason was so that we didn't know where >> the top/bottom was to compare against so had to do incremental stack >> banging by page). > > Right. I think this is probably an improvement for all targets. Aha, this was observed before in: https://bugs.openjdk.java.net/browse/JDK-8072070 Coleen linked this discussion in comments there. Thanks, -Aleksey From ioi.lam at oracle.com Wed Jan 13 01:51:29 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 12 Jan 2016 17:51:29 -0800 Subject: Adding help information to log tags In-Reply-To: <567B07EE.3050500@oracle.com> References: <567A2EC7.6070801@oracle.com> <567B07EE.3050500@oracle.com> Message-ID: <5695ADA1.7040503@oracle.com> I have filed JDK-8146948: Add help information to log tags https://bugs.openjdk.java.net/browse/JDK-8146948 - Ioi On 12/23/15 12:45 PM, Rachel Protacio wrote: > That seems like a good idea to me! It'd be helpful for the user and > also anyone looking at the actual code in logTag.hpp > Rachel > > On 12/23/2015 12:19 AM, Ioi Lam wrote: >> Now there are a lot of log tags [1], and it looks like many more will >> be added. I start to wonder what 'ihop' or 'rt' would do ... >> >> Would it make sense to add help information that can be printed to >> the user, like >> >> #define LOG_TAG_LIST \ >> LOG_TAG(alloc, "this prints something about alloc") \ >> LOG_TAG(age, "blah blah") \ >> >> $ java -Xlog:help=alloc >> alloc - this prints something about alloc >> >> $ java -Xlog:help=all >> alloc - this prints something about alloc >> age - blah blah >> >> >> ----------------- >> >> [1] The list of log tags as of today in jdk9/hs-rt/hotspot >> >> #define LOG_TAG_LIST \ >> LOG_TAG(alloc) \ >> LOG_TAG(age) \ >> LOG_TAG(barrier) \ >> LOG_TAG(bot) \ >> LOG_TAG(census) \ >> LOG_TAG(classhisto) \ >> LOG_TAG(classinit) \ >> LOG_TAG(comp) \ >> LOG_TAG(compaction) \ >> LOG_TAG(cpu) \ >> LOG_TAG(cset) \ >> LOG_TAG(defaultmethods) \ >> LOG_TAG(ergo) \ >> LOG_TAG(exceptions) \ >> LOG_TAG(exit) \ >> LOG_TAG(freelist) \ >> LOG_TAG(gc) \ >> LOG_TAG(heap) \ >> LOG_TAG(humongous) \ >> LOG_TAG(ihop) \ >> LOG_TAG(jni) \ >> LOG_TAG(liveness) \ >> LOG_TAG(logging) \ >> LOG_TAG(marking) \ >> LOG_TAG(metaspace) \ >> LOG_TAG(monitorinflation) \ >> LOG_TAG(phases) \ >> LOG_TAG(plab) \ >> LOG_TAG(promotion) \ >> LOG_TAG(ref) \ >> LOG_TAG(refine) \ >> LOG_TAG(region) \ >> LOG_TAG(remset) \ >> LOG_TAG(rt) \ >> LOG_TAG(safepoint) \ >> LOG_TAG(scavenge) \ >> LOG_TAG(scrub) \ >> LOG_TAG(start) \ >> LOG_TAG(state) \ >> LOG_TAG(stats) \ >> LOG_TAG(stringdedup) \ >> LOG_TAG(survivor) \ >> LOG_TAG(svc) \ >> LOG_TAG(sweep) \ >> LOG_TAG(task) \ >> LOG_TAG(tlab) \ >> LOG_TAG(time) \ >> LOG_TAG(verify) \ >> LOG_TAG(vmoperation) >> >> > From david.lindholm at oracle.com Wed Jan 13 08:55:51 2016 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 13 Jan 2016 09:55:51 +0100 Subject: RFR: 8146690: Make all classes in GC follow the naming convention. Message-ID: <56961117.2030908@oracle.com> Hi, My latest cleanup effort has been to make sure that all class names in GC follow the CamelCase naming convention. Almost all classes does this already, but there are a few that doesn't. For a list of these classes, see https://bugs.openjdk.java.net/browse/JDK-8146690 Please review this patch that renames these classes to follow the naming convention. I have not changed names of the gc vm operations, since all vm operations throughout hotspot follow the same naming convention (VM_Operation). Bug: https://bugs.openjdk.java.net/browse/JDK-8146690 Webrev: http://cr.openjdk.java.net/~david/JDK-8146690/webrev.00/ Testing: JPRT. Thanks, David L From david.holmes at oracle.com Wed Jan 13 09:29:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Jan 2016 19:29:35 +1000 Subject: RFR: 8146690: Make all classes in GC follow the naming convention. In-Reply-To: <56961117.2030908@oracle.com> References: <56961117.2030908@oracle.com> Message-ID: <569618FF.2090406@oracle.com> Hi David, On 13/01/2016 6:55 PM, David Lindholm wrote: > Hi, > > My latest cleanup effort has been to make sure that all class names in > GC follow the CamelCase naming convention. Almost all classes does this > already, but there are a few that doesn't. For a list of these classes, > see https://bugs.openjdk.java.net/browse/JDK-8146690 > > Please review this patch that renames these classes to follow the naming > convention. > > I have not changed names of the gc vm operations, since all vm > operations throughout hotspot follow the same naming convention > (VM_Operation). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146690 > Webrev: http://cr.openjdk.java.net/~david/JDK-8146690/webrev.00/ Generally looks fine. An indention fix needed here: -Par_PushAndMarkClosure::Par_PushAndMarkClosure(CMSCollector* collector, +ParPushAndMarkClosure::ParPushAndMarkClosure(CMSCollector* collector, MemRegion span, ReferenceProcessor* rp, CMSBitMap* bit_map, Are there any SA changes needed to match the vmStructs changes? Thanks, David H. -------- > Testing: JPRT. > > > Thanks, > David L From david.lindholm at oracle.com Wed Jan 13 09:45:48 2016 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 13 Jan 2016 10:45:48 +0100 Subject: RFR: 8146690: Make all classes in GC follow the naming convention. In-Reply-To: <569618FF.2090406@oracle.com> References: <56961117.2030908@oracle.com> <569618FF.2090406@oracle.com> Message-ID: <56961CCC.8040601@oracle.com> Hi David, Thanks for looking at this! On 2016-01-13 10:29, David Holmes wrote: > Hi David, > > On 13/01/2016 6:55 PM, David Lindholm wrote: >> Hi, >> >> My latest cleanup effort has been to make sure that all class names in >> GC follow the CamelCase naming convention. Almost all classes does this >> already, but there are a few that doesn't. For a list of these classes, >> see https://bugs.openjdk.java.net/browse/JDK-8146690 >> >> Please review this patch that renames these classes to follow the naming >> convention. >> >> I have not changed names of the gc vm operations, since all vm >> operations throughout hotspot follow the same naming convention >> (VM_Operation). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146690 >> Webrev: http://cr.openjdk.java.net/~david/JDK-8146690/webrev.00/ > > Generally looks fine. > > An indention fix needed here: > > -Par_PushAndMarkClosure::Par_PushAndMarkClosure(CMSCollector* collector, > +ParPushAndMarkClosure::ParPushAndMarkClosure(CMSCollector* collector, > MemRegion span, > ReferenceProcessor* rp, > CMSBitMap* bit_map, Good catch, fixed that. > Are there any SA changes needed to match the vmStructs changes? No, I greped through SA and ageTable is not used there. Thanks, David L > Thanks, > David H. > -------- > >> Testing: JPRT. >> >> >> Thanks, >> David L From stefan.karlsson at oracle.com Wed Jan 13 09:53:57 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Jan 2016 10:53:57 +0100 Subject: RFR: 8146690: Make all classes in GC follow the naming convention. In-Reply-To: <56961117.2030908@oracle.com> References: <56961117.2030908@oracle.com> Message-ID: <56961EB5.305@oracle.com> Looks good. Thanks, StefanK On 2016-01-13 09:55, David Lindholm wrote: > Hi, > > My latest cleanup effort has been to make sure that all class names in > GC follow the CamelCase naming convention. Almost all classes does > this already, but there are a few that doesn't. For a list of these > classes, see https://bugs.openjdk.java.net/browse/JDK-8146690 > > Please review this patch that renames these classes to follow the > naming convention. > > I have not changed names of the gc vm operations, since all vm > operations throughout hotspot follow the same naming convention > (VM_Operation). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146690 > Webrev: http://cr.openjdk.java.net/~david/JDK-8146690/webrev.00/ > > Testing: JPRT. > > > Thanks, > David L From david.lindholm at oracle.com Wed Jan 13 10:10:29 2016 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 13 Jan 2016 11:10:29 +0100 Subject: RFR: 8146690: Make all classes in GC follow the naming convention. In-Reply-To: <56961EB5.305@oracle.com> References: <56961117.2030908@oracle.com> <56961EB5.305@oracle.com> Message-ID: <56962295.9090603@oracle.com> Stefan, Thanks for the review! /David On 2016-01-13 10:53, Stefan Karlsson wrote: > Looks good. > > Thanks, > StefanK > > On 2016-01-13 09:55, David Lindholm wrote: >> Hi, >> >> My latest cleanup effort has been to make sure that all class names >> in GC follow the CamelCase naming convention. Almost all classes does >> this already, but there are a few that doesn't. For a list of these >> classes, see https://bugs.openjdk.java.net/browse/JDK-8146690 >> >> Please review this patch that renames these classes to follow the >> naming convention. >> >> I have not changed names of the gc vm operations, since all vm >> operations throughout hotspot follow the same naming convention >> (VM_Operation). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146690 >> Webrev: http://cr.openjdk.java.net/~david/JDK-8146690/webrev.00/ >> >> Testing: JPRT. >> >> >> Thanks, >> David L > From erik.helin at oracle.com Wed Jan 13 12:47:07 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 13:47:07 +0100 Subject: RFR: 8146871: Make the clean target silent in hotspot/test/Makefile Message-ID: <20160113124707.GD17653@ehelin.jrpg.bea.com> Hi all, this very small patches silences the 'clean' target in hotspot/test/Makefile (the 'prep' target is already silent). Enhancement: https://bugs.openjdk.java.net/browse/JDK-8146871 Webrev: http://cr.openjdk.java.net/~ehelin/8146871/00/webrev/ Testing: - Buiding locally and verified that the commands are no longer listed - JPRT Thanks, Erik From erik.helin at oracle.com Wed Jan 13 14:01:28 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 15:01:28 +0100 Subject: RFR: Message-ID: <20160113140128.GE17653@ehelin.jrpg.bea.com> Hi all, this patch changes the output directory for hotspot's jtreg tests when run via the top-level Makefile targets such as `make test-hotspot-jtreg`. The current directory is /build//hotspot/linux-x64/testoutput (on an x86-64 machine running Linux). There is no need to place the "testoutput" directory in a directory which name is based on OS and arch, that is already done by the current configuration. Therefore, we can instead place the "testoutput" directory in /build//hotspot/, which is a more reasonable location for the output from hotspot's tests. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8146985 Webrev: http://cr.openjdk.java.net/~ehelin/8146985/00/webrev Testing: - Running `make test-hotspot-jtreg` locally - JPRT (the patch does not affect JPRT since JPRT does not use ALT_OUTPUTDIR) Thanks, Erik From erik.helin at oracle.com Wed Jan 13 14:04:05 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 15:04:05 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <20160113140128.GE17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> Message-ID: <20160113140405.GF17653@ehelin.jrpg.bea.com> (added missing subject) On 2016-01-13, Erik Helin wrote: > Hi all, > > this patch changes the output directory for hotspot's jtreg tests when > run via the top-level Makefile targets such as > `make test-hotspot-jtreg`. > > The current directory is > /build//hotspot/linux-x64/testoutput > (on an x86-64 machine running Linux). There is no need to place the > "testoutput" directory in a directory which name is based on OS and arch, > that is already done by the current configuration. Therefore, we can > instead place the "testoutput" directory in > /build//hotspot/, which is a more reasonable location > for the output from hotspot's tests. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146985 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > > Testing: > - Running `make test-hotspot-jtreg` locally > - JPRT (the patch does not affect JPRT since JPRT does not use > ALT_OUTPUTDIR) > > Thanks, > Erik From erik.joelsson at oracle.com Wed Jan 13 14:19:40 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 15:19:40 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <20160113140405.GF17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> Message-ID: <56965CFC.7020500@oracle.com> Looks reasonable to me, but I very rarely run hotspot tests. /Erik On 2016-01-13 15:04, Erik Helin wrote: > (added missing subject) > > On 2016-01-13, Erik Helin wrote: >> Hi all, >> >> this patch changes the output directory for hotspot's jtreg tests when >> run via the top-level Makefile targets such as >> `make test-hotspot-jtreg`. >> >> The current directory is >> /build//hotspot/linux-x64/testoutput >> (on an x86-64 machine running Linux). There is no need to place the >> "testoutput" directory in a directory which name is based on OS and arch, >> that is already done by the current configuration. Therefore, we can >> instead place the "testoutput" directory in >> /build//hotspot/, which is a more reasonable location >> for the output from hotspot's tests. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146985 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >> >> Testing: >> - Running `make test-hotspot-jtreg` locally >> - JPRT (the patch does not affect JPRT since JPRT does not use >> ALT_OUTPUTDIR) >> >> Thanks, >> Erik From staffan.larsen at oracle.com Wed Jan 13 14:59:03 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 13 Jan 2016 15:59:03 +0100 Subject: RFR: In-Reply-To: <20160113140128.GE17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> Message-ID: <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> Looks good! (Although /build//testoutput/hotspot/ could be even better?) Thanks, /Staffan > On 13 jan. 2016, at 15:01, Erik Helin wrote: > > Hi all, > > this patch changes the output directory for hotspot's jtreg tests when > run via the top-level Makefile targets such as > `make test-hotspot-jtreg`. > > The current directory is > /build//hotspot/linux-x64/testoutput > (on an x86-64 machine running Linux). There is no need to place the > "testoutput" directory in a directory which name is based on OS and arch, > that is already done by the current configuration. Therefore, we can > instead place the "testoutput" directory in > /build//hotspot/, which is a more reasonable location > for the output from hotspot's tests. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146985 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > > Testing: > - Running `make test-hotspot-jtreg` locally > - JPRT (the patch does not affect JPRT since JPRT does not use > ALT_OUTPUTDIR) > > Thanks, > Erik From erik.helin at oracle.com Wed Jan 13 15:11:32 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 16:11:32 +0100 Subject: RFR: In-Reply-To: <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> Message-ID: <20160113151132.GH17653@ehelin.jrpg.bea.com> On 2016-01-13, Staffan Larsen wrote: > Looks good! Thanks! On 2016-01-13, Staffan Larsen wrote: > (Although /build//testoutput/hotspot/ could be even better?) Doesn't really matter to me, I'm fine with either hotspot/testoutput or testoutput/hotspot. Anyone else have a preference? Thanks, Erik > Thanks, > /Staffan > > > > On 13 jan. 2016, at 15:01, Erik Helin wrote: > > > > Hi all, > > > > this patch changes the output directory for hotspot's jtreg tests when > > run via the top-level Makefile targets such as > > `make test-hotspot-jtreg`. > > > > The current directory is > > /build//hotspot/linux-x64/testoutput > > (on an x86-64 machine running Linux). There is no need to place the > > "testoutput" directory in a directory which name is based on OS and arch, > > that is already done by the current configuration. Therefore, we can > > instead place the "testoutput" directory in > > /build//hotspot/, which is a more reasonable location > > for the output from hotspot's tests. > > > > Enhancement: > > https://bugs.openjdk.java.net/browse/JDK-8146985 > > > > Webrev: > > http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > > > > Testing: > > - Running `make test-hotspot-jtreg` locally > > - JPRT (the patch does not affect JPRT since JPRT does not use > > ALT_OUTPUTDIR) > > > > Thanks, > > Erik > From erik.helin at oracle.com Wed Jan 13 16:32:09 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Jan 2016 17:32:09 +0100 Subject: RFR: 8146994: Move internal vm tests to a separate file Message-ID: <20160113163209.GJ17653@ehelin.jrpg.bea.com> Hi all, this patch moves the internal vm tests (the ones executed via -XX:+ExecuteInternalVMTests) to new files: utilities/internalVMTests.{hpp,cpp} Please note that this patch only moves the tests (and adds includes required to build) on purpose, I have more patches coming that cleans up the internal vm tests a bit. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8146994 Webrev: http://cr.openjdk.java.net/~ehelin/8146994/00/ Testing: - Running test locally - Running tests in JPRT Thanks, Erik From coleen.phillimore at oracle.com Wed Jan 13 16:46:09 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Jan 2016 11:46:09 -0500 Subject: RFR: 8146994: Move internal vm tests to a separate file In-Reply-To: <20160113163209.GJ17653@ehelin.jrpg.bea.com> References: <20160113163209.GJ17653@ehelin.jrpg.bea.com> Message-ID: <56967F51.8080400@oracle.com> This looks good. Now we can find them more easily. Coleen On 1/13/16 11:32 AM, Erik Helin wrote: > Hi all, > > this patch moves the internal vm tests (the ones executed via > -XX:+ExecuteInternalVMTests) to new files: > utilities/internalVMTests.{hpp,cpp} > > Please note that this patch only moves the tests (and adds includes > required to build) on purpose, I have more patches coming that cleans up > the internal vm tests a bit. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146994 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146994/00/ > > Testing: > - Running test locally > - Running tests in JPRT > > Thanks, > Erik From dmitry.dmitriev at oracle.com Wed Jan 13 17:11:41 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 13 Jan 2016 20:11:41 +0300 Subject: RFR: 8144578: TestOptionsWithRanges test only ever uses the default collector Message-ID: <5696854D.1000604@oracle.com> Hello, Please review small enhancement to the command line option validation test framework which allow to run test with different GCs. Few comments: 1) Code which executed for testing was moved from JVMOptionsUtils.java to separate class(JVMStartup.java) to avoid overhead at java start-up for determining vm and gc type. 2) runJavaWithParam method in JVMOption.java was refactored to avoid code duplication. JBS: https://bugs.openjdk.java.net/browse/JDK-8144578 webrev.00: http://cr.openjdk.java.net/~ddmitriev/8144578/webrev.00/ Testing: tested on all platforms with different gc by RBT, failed flags were temporary removed from testing in TestOptionsWithRanges.java Thanks, Dmitry From sangheon.kim at oracle.com Wed Jan 13 18:50:57 2016 From: sangheon.kim at oracle.com (sangheon) Date: Wed, 13 Jan 2016 10:50:57 -0800 Subject: RFR: 8144578: TestOptionsWithRanges test only ever uses the default collector In-Reply-To: <5696854D.1000604@oracle.com> References: <5696854D.1000604@oracle.com> Message-ID: <56969C91.9050003@oracle.com> Hi Dmitry, Thank you for fixing this. Overall seems good. -------------------------------------------------------------------- test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java 87 /* 88 * JDK-8144578 89 * Temporarily remove testing of max range for ParGCArrayScanChunk because 90 * JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC is used 91 */ 92 excludeTestMaxRange("ParGCArrayScanChunk"); issue number should be 8145204. -------------------------------------------------------------------- test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java line 181 - if (name.startsWith("G1")) { - option.addPrepend("-XX:+UseG1GC"); - } - - if (name.startsWith("CMS")) { - option.addPrepend("-XX:+UseConcMarkSweepGC"); - } - Is this change really needed for dedicated gc flags(starting with "G1" or "CMS")? I thought this CR is targeted for non-dedicated gc flags such as TLABWasteIncrement. And if you still think that above lines should be removed, please remove line 224 as well. 224 case "NewSizeThreadIncrease": 225 option.addPrepend("-XX:+UseSerialGC"); Thanks, Sangheon On 01/13/2016 09:11 AM, Dmitry Dmitriev wrote: > Hello, > > Please review small enhancement to the command line option validation > test framework which allow to run test with different GCs. > Few comments: > 1) Code which executed for testing was moved from JVMOptionsUtils.java > to separate class(JVMStartup.java) to avoid overhead at java start-up > for determining vm and gc type. > 2) runJavaWithParam method in JVMOption.java was refactored to avoid > code duplication. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8144578 > webrev.00: http://cr.openjdk.java.net/~ddmitriev/8144578/webrev.00/ > > Testing: tested on all platforms with different gc by RBT, failed > flags were temporary removed from testing in TestOptionsWithRanges.java > > Thanks, > Dmitry From mikael.vidstedt at oracle.com Wed Jan 13 18:54:18 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 13 Jan 2016 10:54:18 -0800 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <20160113140405.GF17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> Message-ID: <56969D5A.1020203@oracle.com> The logic in this file (hotspot/test/Makefile) is very similar to that of jdk/test/Makefile, as a matter of fact some of it has been copy pasted. It would be nice if the output dir paths would be set up the same way in both cases, to avoid confusion and all of that. It would be even better to share the logic all together to avoid duplication, but that's a separate issue. Cheers, Mikael On 2016-01-13 06:04, Erik Helin wrote: > (added missing subject) > > On 2016-01-13, Erik Helin wrote: >> Hi all, >> >> this patch changes the output directory for hotspot's jtreg tests when >> run via the top-level Makefile targets such as >> `make test-hotspot-jtreg`. >> >> The current directory is >> /build//hotspot/linux-x64/testoutput >> (on an x86-64 machine running Linux). There is no need to place the >> "testoutput" directory in a directory which name is based on OS and arch, >> that is already done by the current configuration. Therefore, we can >> instead place the "testoutput" directory in >> /build//hotspot/, which is a more reasonable location >> for the output from hotspot's tests. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146985 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >> >> Testing: >> - Running `make test-hotspot-jtreg` locally >> - JPRT (the patch does not affect JPRT since JPRT does not use >> ALT_OUTPUTDIR) >> >> Thanks, >> Erik From mikael.vidstedt at oracle.com Wed Jan 13 18:54:59 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 13 Jan 2016 10:54:59 -0800 Subject: RFR: 8146871: Make the clean target silent in hotspot/test/Makefile In-Reply-To: <20160113124707.GD17653@ehelin.jrpg.bea.com> References: <20160113124707.GD17653@ehelin.jrpg.bea.com> Message-ID: <56969D83.1050906@oracle.com> Loos good, and is already true for the corresponding logic in jdk/test/Makefile. Cheers, Mikael On 2016-01-13 04:47, Erik Helin wrote: > Hi all, > > this very small patches silences the 'clean' target in > hotspot/test/Makefile (the 'prep' target is already silent). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146871 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146871/00/webrev/ > > Testing: > - Buiding locally and verified that the commands are no longer listed > - JPRT > > Thanks, > Erik From erik.joelsson at oracle.com Wed Jan 13 19:02:27 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Jan 2016 20:02:27 +0100 Subject: RFR: 8146871: Make the clean target silent in hotspot/test/Makefile In-Reply-To: <56969D83.1050906@oracle.com> References: <20160113124707.GD17653@ehelin.jrpg.bea.com> <56969D83.1050906@oracle.com> Message-ID: <56969F43.6070206@oracle.com> If it's the same in jdk/test/Makefile, then I have no objections. Keep it consistent. Ok from me. /Erik On 2016-01-13 19:54, Mikael Vidstedt wrote: > > Loos good, and is already true for the corresponding logic in > jdk/test/Makefile. > > Cheers, > Mikael > > On 2016-01-13 04:47, Erik Helin wrote: >> Hi all, >> >> this very small patches silences the 'clean' target in >> hotspot/test/Makefile (the 'prep' target is already silent). >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146871 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146871/00/webrev/ >> >> Testing: >> - Buiding locally and verified that the commands are no longer listed >> - JPRT >> >> Thanks, >> Erik > From staffan.larsen at oracle.com Wed Jan 13 19:36:18 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 13 Jan 2016 20:36:18 +0100 Subject: RFR: In-Reply-To: <20160113151132.GH17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <876885C7-0EB8-4AC1-952C-F614888735F9@oracle.com> <20160113151132.GH17653@ehelin.jrpg.bea.com> Message-ID: <7B8310A1-5290-497C-B9AD-B4D3B8DB69EF@oracle.com> > On 13 jan. 2016, at 16:11, Erik Helin wrote: > > On 2016-01-13, Staffan Larsen wrote: >> Looks good! > > Thanks! > > On 2016-01-13, Staffan Larsen wrote: >> (Although /build//testoutput/hotspot/ could be even better?) > > Doesn't really matter to me, I'm fine with either hotspot/testoutput or > testoutput/hotspot. Anyone else have a preference? I don?t have a strong preference - feel free to commit the patch as is. /Staffan > > Thanks, > Erik > >> Thanks, >> /Staffan >> >> >>> On 13 jan. 2016, at 15:01, Erik Helin wrote: >>> >>> Hi all, >>> >>> this patch changes the output directory for hotspot's jtreg tests when >>> run via the top-level Makefile targets such as >>> `make test-hotspot-jtreg`. >>> >>> The current directory is >>> /build//hotspot/linux-x64/testoutput >>> (on an x86-64 machine running Linux). There is no need to place the >>> "testoutput" directory in a directory which name is based on OS and arch, >>> that is already done by the current configuration. Therefore, we can >>> instead place the "testoutput" directory in >>> /build//hotspot/, which is a more reasonable location >>> for the output from hotspot's tests. >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8146985 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >>> >>> Testing: >>> - Running `make test-hotspot-jtreg` locally >>> - JPRT (the patch does not affect JPRT since JPRT does not use >>> ALT_OUTPUTDIR) >>> >>> Thanks, >>> Erik >> From kim.barrett at oracle.com Wed Jan 13 23:13:31 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 13 Jan 2016 18:13:31 -0500 Subject: RFR: 8146994: Move internal vm tests to a separate file In-Reply-To: <20160113163209.GJ17653@ehelin.jrpg.bea.com> References: <20160113163209.GJ17653@ehelin.jrpg.bea.com> Message-ID: On Jan 13, 2016, at 11:32 AM, Erik Helin wrote: > > Hi all, > > this patch moves the internal vm tests (the ones executed via > -XX:+ExecuteInternalVMTests) to new files: > utilities/internalVMTests.{hpp,cpp} > > Please note that this patch only moves the tests (and adds includes > required to build) on purpose, I have more patches coming that cleans up > the internal vm tests a bit. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146994 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146994/00/ > > Testing: > - Running test locally > - Running tests in JPRT > > Thanks, > Erik Looks good. From mikael.vidstedt at oracle.com Wed Jan 13 23:27:57 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 13 Jan 2016 15:27:57 -0800 Subject: RFR: 8146994: Move internal vm tests to a separate file In-Reply-To: <20160113163209.GJ17653@ehelin.jrpg.bea.com> References: <20160113163209.GJ17653@ehelin.jrpg.bea.com> Message-ID: <5696DD7D.5020306@oracle.com> Beautiful! Cheers, Mikael On 2016-01-13 08:32, Erik Helin wrote: > Hi all, > > this patch moves the internal vm tests (the ones executed via > -XX:+ExecuteInternalVMTests) to new files: > utilities/internalVMTests.{hpp,cpp} > > Please note that this patch only moves the tests (and adds includes > required to build) on purpose, I have more patches coming that cleans up > the internal vm tests a bit. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146994 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146994/00/ > > Testing: > - Running test locally > - Running tests in JPRT > > Thanks, > Erik From david.holmes at oracle.com Thu Jan 14 04:15:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jan 2016 14:15:56 +1000 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <56969D5A.1020203@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> <56969D5A.1020203@oracle.com> Message-ID: <569720FC.7080409@oracle.com> Sorry I don't understand the change. AFAICS ALT_OUTPUTDIR could be anything - no guarantee that it already contains the "CONF" directory. Any why only change one path: ifdef ALT_OUTPUTDIR ! ABS_BUILD_ROOT = $(ALT_OUTPUTDIR)/hotspot else ABS_BUILD_ROOT = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH) ?? When do we take each path? David ----- On 14/01/2016 4:54 AM, Mikael Vidstedt wrote: > > The logic in this file (hotspot/test/Makefile) is very similar to that > of jdk/test/Makefile, as a matter of fact some of it has been copy > pasted. It would be nice if the output dir paths would be set up the > same way in both cases, to avoid confusion and all of that. > > It would be even better to share the logic all together to avoid > duplication, but that's a separate issue. > > Cheers, > Mikael > > On 2016-01-13 06:04, Erik Helin wrote: >> (added missing subject) >> >> On 2016-01-13, Erik Helin wrote: >>> Hi all, >>> >>> this patch changes the output directory for hotspot's jtreg tests when >>> run via the top-level Makefile targets such as >>> `make test-hotspot-jtreg`. >>> >>> The current directory is >>> /build//hotspot/linux-x64/testoutput >>> (on an x86-64 machine running Linux). There is no need to place the >>> "testoutput" directory in a directory which name is based on OS and >>> arch, >>> that is already done by the current configuration. Therefore, we can >>> instead place the "testoutput" directory in >>> /build//hotspot/, which is a more reasonable location >>> for the output from hotspot's tests. >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8146985 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >>> >>> Testing: >>> - Running `make test-hotspot-jtreg` locally >>> - JPRT (the patch does not affect JPRT since JPRT does not use >>> ALT_OUTPUTDIR) >>> >>> Thanks, >>> Erik > From stefan.karlsson at oracle.com Thu Jan 14 07:52:42 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Jan 2016 08:52:42 +0100 Subject: RFR: 8146994: Move internal vm tests to a separate file In-Reply-To: <20160113163209.GJ17653@ehelin.jrpg.bea.com> References: <20160113163209.GJ17653@ehelin.jrpg.bea.com> Message-ID: <569753CA.2000902@oracle.com> Hi Erik, Thanks for moving the tests! Could you make sure you order the includes with the #if sections at the end. It's also important that you include utilites/macros.hpp before the #if sections, otherwise they will evaluate to false although the defines are set to true in that file. So, change: 29 #include "classfile/altHashing.hpp" 30 #include "gc/shared/collectedHeap.hpp" 31 #include "gc/shared/gcTimer.hpp" 32 #if INCLUDE_ALL_GCS 33 #include "gc/g1/heapRegionRemSet.hpp" 34 #endif 35 #include "compiler/directivesParser.hpp" 36 #include "memory/guardedMemory.hpp" 37 #include "utilities/json.hpp" 38 #include "utilities/ostream.hpp" 39 #include "utilities/internalVMTests.hpp" 40 #include "utilities/quickSort.hpp" 41 #if INCLUDE_VM_STRUCTS 42 #include "runtime/vmStructs.hpp" 43 #endif to #include "classfile/altHashing.hpp" #include "compiler/directivesParser.hpp" #include "gc/shared/collectedHeap.hpp" #include "gc/shared/gcTimer.hpp" #include "memory/guardedMemory.hpp" #include "utilities/json.hpp" #include "utilities/macros.hpp" #include "utilities/ostream.hpp" #include "utilities/internalVMTests.hpp" #include "utilities/quickSort.hpp" #if INCLUDE_ALL_GCS #include "gc/g1/heapRegionRemSet.hpp" #endif #if INCLUDE_VM_STRUCTS #include "runtime/vmStructs.hpp" #endif Thanks, StefanK On 2016-01-13 17:32, Erik Helin wrote: > Hi all, > > this patch moves the internal vm tests (the ones executed via > -XX:+ExecuteInternalVMTests) to new files: > utilities/internalVMTests.{hpp,cpp} > > Please note that this patch only moves the tests (and adds includes > required to build) on purpose, I have more patches coming that cleans up > the internal vm tests a bit. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146994 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146994/00/ > > Testing: > - Running test locally > - Running tests in JPRT > > Thanks, > Erik From marcus.larsson at oracle.com Thu Jan 14 08:17:38 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 14 Jan 2016 09:17:38 +0100 Subject: Adding help information to log tags In-Reply-To: <5695ADA1.7040503@oracle.com> References: <567A2EC7.6070801@oracle.com> <567B07EE.3050500@oracle.com> <5695ADA1.7040503@oracle.com> Message-ID: <569759A2.8050106@oracle.com> This could be a good idea. Not all tags make sense in isolation though, but perhaps we can come up with at least some sort of description for these tags. Thanks, Marcus On 01/13/2016 02:51 AM, Ioi Lam wrote: > I have filed JDK-8146948: Add help information to log tags > > https://bugs.openjdk.java.net/browse/JDK-8146948 > > - Ioi > > On 12/23/15 12:45 PM, Rachel Protacio wrote: >> That seems like a good idea to me! It'd be helpful for the user and >> also anyone looking at the actual code in logTag.hpp >> Rachel >> >> On 12/23/2015 12:19 AM, Ioi Lam wrote: >>> Now there are a lot of log tags [1], and it looks like many more >>> will be added. I start to wonder what 'ihop' or 'rt' would do ... >>> >>> Would it make sense to add help information that can be printed to >>> the user, like >>> >>> #define LOG_TAG_LIST \ >>> LOG_TAG(alloc, "this prints something about alloc") \ >>> LOG_TAG(age, "blah blah") \ >>> >>> $ java -Xlog:help=alloc >>> alloc - this prints something about alloc >>> >>> $ java -Xlog:help=all >>> alloc - this prints something about alloc >>> age - blah blah >>> >>> >>> ----------------- >>> >>> [1] The list of log tags as of today in jdk9/hs-rt/hotspot >>> >>> #define LOG_TAG_LIST \ >>> LOG_TAG(alloc) \ >>> LOG_TAG(age) \ >>> LOG_TAG(barrier) \ >>> LOG_TAG(bot) \ >>> LOG_TAG(census) \ >>> LOG_TAG(classhisto) \ >>> LOG_TAG(classinit) \ >>> LOG_TAG(comp) \ >>> LOG_TAG(compaction) \ >>> LOG_TAG(cpu) \ >>> LOG_TAG(cset) \ >>> LOG_TAG(defaultmethods) \ >>> LOG_TAG(ergo) \ >>> LOG_TAG(exceptions) \ >>> LOG_TAG(exit) \ >>> LOG_TAG(freelist) \ >>> LOG_TAG(gc) \ >>> LOG_TAG(heap) \ >>> LOG_TAG(humongous) \ >>> LOG_TAG(ihop) \ >>> LOG_TAG(jni) \ >>> LOG_TAG(liveness) \ >>> LOG_TAG(logging) \ >>> LOG_TAG(marking) \ >>> LOG_TAG(metaspace) \ >>> LOG_TAG(monitorinflation) \ >>> LOG_TAG(phases) \ >>> LOG_TAG(plab) \ >>> LOG_TAG(promotion) \ >>> LOG_TAG(ref) \ >>> LOG_TAG(refine) \ >>> LOG_TAG(region) \ >>> LOG_TAG(remset) \ >>> LOG_TAG(rt) \ >>> LOG_TAG(safepoint) \ >>> LOG_TAG(scavenge) \ >>> LOG_TAG(scrub) \ >>> LOG_TAG(start) \ >>> LOG_TAG(state) \ >>> LOG_TAG(stats) \ >>> LOG_TAG(stringdedup) \ >>> LOG_TAG(survivor) \ >>> LOG_TAG(svc) \ >>> LOG_TAG(sweep) \ >>> LOG_TAG(task) \ >>> LOG_TAG(tlab) \ >>> LOG_TAG(time) \ >>> LOG_TAG(verify) \ >>> LOG_TAG(vmoperation) >>> >>> >> > From erik.helin at oracle.com Thu Jan 14 11:41:31 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 14 Jan 2016 12:41:31 +0100 Subject: RFR: 8146994: Move internal vm tests to a separate file In-Reply-To: <569753CA.2000902@oracle.com> References: <20160113163209.GJ17653@ehelin.jrpg.bea.com> <569753CA.2000902@oracle.com> Message-ID: <20160114114131.GK17653@ehelin.jrpg.bea.com> On 2016-01-14, Stefan Karlsson wrote: > Hi Erik, > > Thanks for moving the tests! Thanks for reviewing! > Could you make sure you order the includes with the #if sections at the end. > It's also important that you include utilites/macros.hpp before the #if > sections, otherwise they will evaluate to false although the defines are set > to true in that file. > > So, change: > > 29 #include "classfile/altHashing.hpp" > 30 #include "gc/shared/collectedHeap.hpp" > 31 #include "gc/shared/gcTimer.hpp" > 32 #if INCLUDE_ALL_GCS > 33 #include "gc/g1/heapRegionRemSet.hpp" > 34 #endif > 35 #include "compiler/directivesParser.hpp" > 36 #include "memory/guardedMemory.hpp" > 37 #include "utilities/json.hpp" > 38 #include "utilities/ostream.hpp" > 39 #include "utilities/internalVMTests.hpp" > 40 #include "utilities/quickSort.hpp" > 41 #if INCLUDE_VM_STRUCTS > 42 #include "runtime/vmStructs.hpp" > 43 #endif > > to > > #include "classfile/altHashing.hpp" > #include "compiler/directivesParser.hpp" > #include "gc/shared/collectedHeap.hpp" > #include "gc/shared/gcTimer.hpp" > #include "memory/guardedMemory.hpp" > #include "utilities/json.hpp" > #include "utilities/macros.hpp" > #include "utilities/ostream.hpp" > #include "utilities/internalVMTests.hpp" > #include "utilities/quickSort.hpp" > #if INCLUDE_ALL_GCS > #include "gc/g1/heapRegionRemSet.hpp" > #endif > #if INCLUDE_VM_STRUCTS > #include "runtime/vmStructs.hpp" > #endif Sure, new patches are available at: - full: http://cr.openjdk.java.net/~ehelin/8146994/01/ - inc: http://cr.openjdk.java.net/~ehelin/8146994/01/inc/ Thanks, Erik > Thanks, > StefanK > > On 2016-01-13 17:32, Erik Helin wrote: > >Hi all, > > > >this patch moves the internal vm tests (the ones executed via > >-XX:+ExecuteInternalVMTests) to new files: > >utilities/internalVMTests.{hpp,cpp} > > > >Please note that this patch only moves the tests (and adds includes > >required to build) on purpose, I have more patches coming that cleans up > >the internal vm tests a bit. > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8146994 > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8146994/00/ > > > >Testing: > >- Running test locally > >- Running tests in JPRT > > > >Thanks, > >Erik > From stefan.karlsson at oracle.com Thu Jan 14 13:18:40 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Jan 2016 14:18:40 +0100 Subject: RFR: 8146994: Move internal vm tests to a separate file In-Reply-To: <20160114114131.GK17653@ehelin.jrpg.bea.com> References: <20160113163209.GJ17653@ehelin.jrpg.bea.com> <569753CA.2000902@oracle.com> <20160114114131.GK17653@ehelin.jrpg.bea.com> Message-ID: <5697A030.1070709@oracle.com> Looks good. Thanks, StefanK On 2016-01-14 12:41, Erik Helin wrote: > On 2016-01-14, Stefan Karlsson wrote: >> Hi Erik, >> >> Thanks for moving the tests! > Thanks for reviewing! > >> Could you make sure you order the includes with the #if sections at the end. >> It's also important that you include utilites/macros.hpp before the #if >> sections, otherwise they will evaluate to false although the defines are set >> to true in that file. >> >> So, change: >> >> 29 #include "classfile/altHashing.hpp" >> 30 #include "gc/shared/collectedHeap.hpp" >> 31 #include "gc/shared/gcTimer.hpp" >> 32 #if INCLUDE_ALL_GCS >> 33 #include "gc/g1/heapRegionRemSet.hpp" >> 34 #endif >> 35 #include "compiler/directivesParser.hpp" >> 36 #include "memory/guardedMemory.hpp" >> 37 #include "utilities/json.hpp" >> 38 #include "utilities/ostream.hpp" >> 39 #include "utilities/internalVMTests.hpp" >> 40 #include "utilities/quickSort.hpp" >> 41 #if INCLUDE_VM_STRUCTS >> 42 #include "runtime/vmStructs.hpp" >> 43 #endif >> >> to >> >> #include "classfile/altHashing.hpp" >> #include "compiler/directivesParser.hpp" >> #include "gc/shared/collectedHeap.hpp" >> #include "gc/shared/gcTimer.hpp" >> #include "memory/guardedMemory.hpp" >> #include "utilities/json.hpp" >> #include "utilities/macros.hpp" >> #include "utilities/ostream.hpp" >> #include "utilities/internalVMTests.hpp" >> #include "utilities/quickSort.hpp" >> #if INCLUDE_ALL_GCS >> #include "gc/g1/heapRegionRemSet.hpp" >> #endif >> #if INCLUDE_VM_STRUCTS >> #include "runtime/vmStructs.hpp" >> #endif > Sure, new patches are available at: > - full: http://cr.openjdk.java.net/~ehelin/8146994/01/ > - inc: http://cr.openjdk.java.net/~ehelin/8146994/01/inc/ > > Thanks, > Erik > >> Thanks, >> StefanK >> >> On 2016-01-13 17:32, Erik Helin wrote: >>> Hi all, >>> >>> this patch moves the internal vm tests (the ones executed via >>> -XX:+ExecuteInternalVMTests) to new files: >>> utilities/internalVMTests.{hpp,cpp} >>> >>> Please note that this patch only moves the tests (and adds includes >>> required to build) on purpose, I have more patches coming that cleans up >>> the internal vm tests a bit. >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8146994 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8146994/00/ >>> >>> Testing: >>> - Running test locally >>> - Running tests in JPRT >>> >>> Thanks, >>> Erik From dmitry.dmitriev at oracle.com Thu Jan 14 13:59:47 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 14 Jan 2016 16:59:47 +0300 Subject: RFR: 8144578: TestOptionsWithRanges test only ever uses the default collector In-Reply-To: <56969C91.9050003@oracle.com> References: <5696854D.1000604@oracle.com> <56969C91.9050003@oracle.com> Message-ID: <5697A9D3.1000700@oracle.com> Hi Sangheon, Thank you for the review! Updated webrev: http://cr.openjdk.java.net/~ddmitriev/8144578/webrev.01/ Comments inline. On 13.01.2016 21:50, sangheon wrote: > Hi Dmitry, > > Thank you for fixing this. > Overall seems good. > > -------------------------------------------------------------------- > test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java > > 87 /* > 88 * JDK-8144578 > 89 * Temporarily remove testing of max range for ParGCArrayScanChunk > because > 90 * JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC > is used > 91 */ > 92 excludeTestMaxRange("ParGCArrayScanChunk"); > > issue number should be 8145204. Fixed. > > -------------------------------------------------------------------- > test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java > > line 181 > > - if (name.startsWith("G1")) { > - option.addPrepend("-XX:+UseG1GC"); > - } > - > - if (name.startsWith("CMS")) { > - option.addPrepend("-XX:+UseConcMarkSweepGC"); > - } > - > > Is this change really needed for dedicated gc flags(starting with "G1" > or "CMS")? > I thought this CR is targeted for non-dedicated gc flags such as > TLABWasteIncrement. I return deleted lines. Thanks, Dmitry > > And if you still think that above lines should be removed, please > remove line 224 as well. > > 224 case "NewSizeThreadIncrease": > 225 option.addPrepend("-XX:+UseSerialGC"); > > > Thanks, > Sangheon > > > On 01/13/2016 09:11 AM, Dmitry Dmitriev wrote: >> Hello, >> >> Please review small enhancement to the command line option validation >> test framework which allow to run test with different GCs. >> Few comments: >> 1) Code which executed for testing was moved from >> JVMOptionsUtils.java to separate class(JVMStartup.java) to avoid >> overhead at java start-up for determining vm and gc type. >> 2) runJavaWithParam method in JVMOption.java was refactored to avoid >> code duplication. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8144578 >> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8144578/webrev.00/ >> >> Testing: tested on all platforms with different gc by RBT, failed >> flags were temporary removed from testing in TestOptionsWithRanges.java >> >> Thanks, >> Dmitry > From magnus.ihse.bursie at oracle.com Thu Jan 14 15:00:31 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 16:00:31 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com> Message-ID: <5697B80F.4050905@oracle.com> On 2015-12-18 15:11, Wang Weijun wrote: > Hi Vinnie > > I take a look and it includes a change for src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the Java_sun_security_mscapi_KeyStore_getKeyLength() function. > > It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the java side. Is the function useless now? Max, Is your intention here that you think the patch should remove the entire Java_sun_security_mscapi_KeyStore_getKeyLength function? /Magnus > > Thanks > Max > >> On Dec 16, 2015, at 9:50 PM, Magnus Ihse Bursie wrote: >> >> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. >> >> This patch is provided by Timo Kinnunen . I am sponsoring this patch. >> >> The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. >> >> I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 >> >> /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 14 15:05:11 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 16:05:11 +0100 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <98B07F13-1D90-4DEC-AAED-D791F4666BF7@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> <98B07F13-1D90-4DEC-AAED-D791F4666BF7@oracle.com> Message-ID: <5697B927.6090008@oracle.com> On 2016-01-05 03:25, Kim Barrett wrote: > On Dec 18, 2015, at 7:41 PM, Kim Barrett wrote: >> On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 >>> >>> /Magnus >> I only looked at hotspot files. >> >> [?] >> There are a couple of "TBD"s below that I need to spend more time on. >> > Back from holiday, and here?s my comments on those two TBDs Kim, Thank you for your feedback. Since I'm only the sponsor of this patch, not the developer, I'll let Timo answer your questions and discuss his choices. /Magnus > > ------------------------------------------------------------------------------ > hotspot/agent/src/share/native/sadis.c > 96 return (int)strlen(buf); > > The only call to the (file-scoped) getLastErrorString function is > Java_sun_jvm_hotspot_asm_Disassembler_load_1library, which ignores the > result. It would be better to change the return type of > getLastErrorString to void and update the return statements > accordingly. > > ------------------------------------------------------------------------------ > hotspot/src/share/vm/adlc/arena.hpp > 74 // Usual (non-placement) deallocation function to allow placement delete use size_t > 75 // See 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2. > 76 void operator delete(void* p); > > and associated code in the .cpp file. > > I think this is another C++11 change: > http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#429 > > I think the proposed code change is OK, although the comment is > problematic: [basic.stc.dynamic.deallocation] is C++03 3.7.3.2 and > C++11 3.7.4.2. Also, the standard change that leads to this code > change is in C++11 5.3.4 [expr.new] paragraph 20 (C++02 p 19). > > Also, I *think* with the addition of the one-arg operator delete we > don't actually use the two-arg form. If so, then I suggest removing > it and the proposed new comment for the one-arg form. > > ------------------------------------------------------------------------------ > From erik.helin at oracle.com Thu Jan 14 16:03:05 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 14 Jan 2016 17:03:05 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <569720FC.7080409@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> <56969D5A.1020203@oracle.com> <569720FC.7080409@oracle.com> Message-ID: <20160114160304.GM17653@ehelin.jrpg.bea.com> On 2016-01-14, David Holmes wrote: > Sorry I don't understand the change. AFAICS ALT_OUTPUTDIR could be anything > - no guarantee that it already contains the "CONF" directory. > > Any why only change one path: > > ifdef ALT_OUTPUTDIR > ! ABS_BUILD_ROOT = $(ALT_OUTPUTDIR)/hotspot > else > ABS_BUILD_ROOT = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH) > > ?? When do we take each path? The only "oficially" supported way of using the hotspot Makefiles is to use the Makefiles in the top-level repo (e.g. jdk9/hs-rt). The Makefiles in the top-level repo will always set ALT_OUTPUTDIR to /build/. Hence, for any developer using these Makefiles, ALT_OUTPUTDIR will always point to the current configuration. If anyone is using ALT_OUTPUTDIR in some other way, then they are "on their own" (i.e. they will have to adjust their scripts). The one exception to this is JPRT, which does not use ALT_OUTPUTDIR at all, and therefore uses the "else" branch. I don't want to change the behaviour in JPRT, therefore I only changed the "then" branch. Thanks, Erik > David > ----- > > On 14/01/2016 4:54 AM, Mikael Vidstedt wrote: > > > >The logic in this file (hotspot/test/Makefile) is very similar to that > >of jdk/test/Makefile, as a matter of fact some of it has been copy > >pasted. It would be nice if the output dir paths would be set up the > >same way in both cases, to avoid confusion and all of that. > > > >It would be even better to share the logic all together to avoid > >duplication, but that's a separate issue. > > > >Cheers, > >Mikael > > > >On 2016-01-13 06:04, Erik Helin wrote: > >>(added missing subject) > >> > >>On 2016-01-13, Erik Helin wrote: > >>>Hi all, > >>> > >>>this patch changes the output directory for hotspot's jtreg tests when > >>>run via the top-level Makefile targets such as > >>>`make test-hotspot-jtreg`. > >>> > >>>The current directory is > >>>/build//hotspot/linux-x64/testoutput > >>>(on an x86-64 machine running Linux). There is no need to place the > >>>"testoutput" directory in a directory which name is based on OS and > >>>arch, > >>>that is already done by the current configuration. Therefore, we can > >>>instead place the "testoutput" directory in > >>>/build//hotspot/, which is a more reasonable location > >>>for the output from hotspot's tests. > >>> > >>>Enhancement: > >>>https://bugs.openjdk.java.net/browse/JDK-8146985 > >>> > >>>Webrev: > >>>http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > >>> > >>>Testing: > >>>- Running `make test-hotspot-jtreg` locally > >>>- JPRT (the patch does not affect JPRT since JPRT does not use > >>> ALT_OUTPUTDIR) > >>> > >>>Thanks, > >>>Erik > > From erik.helin at oracle.com Thu Jan 14 16:19:24 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 14 Jan 2016 17:19:24 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <56969D5A.1020203@oracle.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> <56969D5A.1020203@oracle.com> Message-ID: <20160114161924.GN17653@ehelin.jrpg.bea.com> On 2016-01-13, Mikael Vidstedt wrote: > The logic in this file (hotspot/test/Makefile) is very similar to that of > jdk/test/Makefile, as a matter of fact some of it has been copy pasted. The benefit is that if you learn one of the Makefiles, you can quickly pick learn the other one ;) On 2016-01-13, Mikael Vidstedt wrote: > It would be nice if the output dir paths would be set up the same way > in both cases, to avoid confusion and all of that. Yep, agree, and looking at jdk/test/Makefile, it does things slightly different. When running one of jtreg groups jdk_*, core_* or svc_* via the top-level Makefiles, then the results will end up in: /build//testoutput/ Given the current feedback, the proposed change is to put the hotspot results in: /build//testoutput/hotspot We could align jdk/test/Makefile and hotspot/test/Makefile by having the hotspot results in /build/testoutput/ as well. The jtreg groups with identical suffixes are already prefixed by their folder (e.g. jdk_svc, hotspot_svc), so there shouldn't be any name clashes. I will send out a new patch soon. Thanks, Erik > It would be even better to share the logic all together to avoid > duplication, but that's a separate issue. > > Cheers, > Mikael > > On 2016-01-13 06:04, Erik Helin wrote: > >(added missing subject) > > > >On 2016-01-13, Erik Helin wrote: > >>Hi all, > >> > >>this patch changes the output directory for hotspot's jtreg tests when > >>run via the top-level Makefile targets such as > >>`make test-hotspot-jtreg`. > >> > >>The current directory is > >>/build//hotspot/linux-x64/testoutput > >>(on an x86-64 machine running Linux). There is no need to place the > >>"testoutput" directory in a directory which name is based on OS and arch, > >>that is already done by the current configuration. Therefore, we can > >>instead place the "testoutput" directory in > >>/build//hotspot/, which is a more reasonable location > >>for the output from hotspot's tests. > >> > >>Enhancement: > >>https://bugs.openjdk.java.net/browse/JDK-8146985 > >> > >>Webrev: > >>http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > >> > >>Testing: > >>- Running `make test-hotspot-jtreg` locally > >>- JPRT (the patch does not affect JPRT since JPRT does not use > >> ALT_OUTPUTDIR) > >> > >>Thanks, > >>Erik > From sangheon.kim at oracle.com Thu Jan 14 17:18:25 2016 From: sangheon.kim at oracle.com (sangheon) Date: Thu, 14 Jan 2016 09:18:25 -0800 Subject: RFR: 8144578: TestOptionsWithRanges test only ever uses the default collector In-Reply-To: <5697A9D3.1000700@oracle.com> References: <5696854D.1000604@oracle.com> <56969C91.9050003@oracle.com> <5697A9D3.1000700@oracle.com> Message-ID: <5697D861.4010803@oracle.com> Hi Dmitry, Looks good to me. Thanks, Sangheon On 01/14/2016 05:59 AM, Dmitry Dmitriev wrote: > Hi Sangheon, > > Thank you for the review! Updated webrev: > http://cr.openjdk.java.net/~ddmitriev/8144578/webrev.01/ > > Comments inline. > > On 13.01.2016 21:50, sangheon wrote: >> Hi Dmitry, >> >> Thank you for fixing this. >> Overall seems good. >> >> -------------------------------------------------------------------- >> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >> >> 87 /* >> 88 * JDK-8144578 >> 89 * Temporarily remove testing of max range for ParGCArrayScanChunk >> because >> 90 * JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC >> is used >> 91 */ >> 92 excludeTestMaxRange("ParGCArrayScanChunk"); >> >> issue number should be 8145204. > Fixed. >> >> -------------------------------------------------------------------- >> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >> >> line 181 >> >> - if (name.startsWith("G1")) { >> - option.addPrepend("-XX:+UseG1GC"); >> - } >> - >> - if (name.startsWith("CMS")) { >> - option.addPrepend("-XX:+UseConcMarkSweepGC"); >> - } >> - >> >> Is this change really needed for dedicated gc flags(starting with >> "G1" or "CMS")? >> I thought this CR is targeted for non-dedicated gc flags such as >> TLABWasteIncrement. > I return deleted lines. > > Thanks, > Dmitry >> >> And if you still think that above lines should be removed, please >> remove line 224 as well. >> >> 224 case "NewSizeThreadIncrease": >> 225 option.addPrepend("-XX:+UseSerialGC"); >> >> >> Thanks, >> Sangheon >> >> >> On 01/13/2016 09:11 AM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Please review small enhancement to the command line option >>> validation test framework which allow to run test with different GCs. >>> Few comments: >>> 1) Code which executed for testing was moved from >>> JVMOptionsUtils.java to separate class(JVMStartup.java) to avoid >>> overhead at java start-up for determining vm and gc type. >>> 2) runJavaWithParam method in JVMOption.java was refactored to avoid >>> code duplication. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8144578 >>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8144578/webrev.00/ >>> >>> Testing: tested on all platforms with different gc by RBT, failed >>> flags were temporary removed from testing in TestOptionsWithRanges.java >>> >>> Thanks, >>> Dmitry >> > From dmitry.dmitriev at oracle.com Thu Jan 14 17:19:55 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 14 Jan 2016 20:19:55 +0300 Subject: RFR: 8144578: TestOptionsWithRanges test only ever uses the default collector In-Reply-To: <5697D861.4010803@oracle.com> References: <5696854D.1000604@oracle.com> <56969C91.9050003@oracle.com> <5697A9D3.1000700@oracle.com> <5697D861.4010803@oracle.com> Message-ID: <5697D8BB.6070604@oracle.com> Sangheon, thank you for the review! Dmitry On 14.01.2016 20:18, sangheon wrote: > Hi Dmitry, > > Looks good to me. > > Thanks, > Sangheon > > > On 01/14/2016 05:59 AM, Dmitry Dmitriev wrote: >> Hi Sangheon, >> >> Thank you for the review! Updated webrev: >> http://cr.openjdk.java.net/~ddmitriev/8144578/webrev.01/ >> >> Comments inline. >> >> On 13.01.2016 21:50, sangheon wrote: >>> Hi Dmitry, >>> >>> Thank you for fixing this. >>> Overall seems good. >>> >>> -------------------------------------------------------------------- >>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>> >>> 87 /* >>> 88 * JDK-8144578 >>> 89 * Temporarily remove testing of max range for ParGCArrayScanChunk >>> because >>> 90 * JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC >>> is used >>> 91 */ >>> 92 excludeTestMaxRange("ParGCArrayScanChunk"); >>> >>> issue number should be 8145204. >> Fixed. >>> >>> -------------------------------------------------------------------- >>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >>> >>> line 181 >>> >>> - if (name.startsWith("G1")) { >>> - option.addPrepend("-XX:+UseG1GC"); >>> - } >>> - >>> - if (name.startsWith("CMS")) { >>> - option.addPrepend("-XX:+UseConcMarkSweepGC"); >>> - } >>> - >>> >>> Is this change really needed for dedicated gc flags(starting with >>> "G1" or "CMS")? >>> I thought this CR is targeted for non-dedicated gc flags such as >>> TLABWasteIncrement. >> I return deleted lines. >> >> Thanks, >> Dmitry >>> >>> And if you still think that above lines should be removed, please >>> remove line 224 as well. >>> >>> 224 case "NewSizeThreadIncrease": >>> 225 option.addPrepend("-XX:+UseSerialGC"); >>> >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 01/13/2016 09:11 AM, Dmitry Dmitriev wrote: >>>> Hello, >>>> >>>> Please review small enhancement to the command line option >>>> validation test framework which allow to run test with different GCs. >>>> Few comments: >>>> 1) Code which executed for testing was moved from >>>> JVMOptionsUtils.java to separate class(JVMStartup.java) to avoid >>>> overhead at java start-up for determining vm and gc type. >>>> 2) runJavaWithParam method in JVMOption.java was refactored to >>>> avoid code duplication. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8144578 >>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8144578/webrev.00/ >>>> >>>> Testing: tested on all platforms with different gc by RBT, failed >>>> flags were temporary removed from testing in >>>> TestOptionsWithRanges.java >>>> >>>> Thanks, >>>> Dmitry >>> >> > From kim.barrett at oracle.com Thu Jan 14 23:06:17 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 14 Jan 2016 18:06:17 -0500 Subject: RFR: 8146994: Move internal vm tests to a separate file In-Reply-To: <20160114114131.GK17653@ehelin.jrpg.bea.com> References: <20160113163209.GJ17653@ehelin.jrpg.bea.com> <569753CA.2000902@oracle.com> <20160114114131.GK17653@ehelin.jrpg.bea.com> Message-ID: <365C8F75-01DC-4011-B43E-4E7CD4B8E60D@oracle.com> On Jan 14, 2016, at 6:41 AM, Erik Helin wrote: > > Sure, new patches are available at: > - full: http://cr.openjdk.java.net/~ehelin/8146994/01/ > - inc: http://cr.openjdk.java.net/~ehelin/8146994/01/inc/ Looks good. From weijun.wang at oracle.com Fri Jan 15 00:39:30 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 15 Jan 2016 08:39:30 +0800 Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition In-Reply-To: <5697B80F.4050905@oracle.com> References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com> <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com> <5697B80F.4050905@oracle.com> Message-ID: <1411F578-C3A7-473D-9407-F10E018DF75E@oracle.com> > On Jan 14, 2016, at 11:00 PM, Magnus Ihse Bursie wrote: > > On 2015-12-18 15:11, Wang Weijun wrote: >> Hi Vinnie >> >> I take a look and it includes a change for src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the Java_sun_security_mscapi_KeyStore_getKeyLength() function. >> >> It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the java side. Is the function useless now? > > Max, > > Is your intention here that you think the patch should remove the entire Java_sun_security_mscapi_KeyStore_getKeyLength function? Yes, I hope so. --Max > > /Magnus > >> >> Thanks >> Max >> >>> On Dec 16, 2015, at 9:50 PM, Magnus Ihse Bursie wrote: >>> >>> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. >>> >>> This patch is provided by Timo Kinnunen . I am sponsoring this patch. >>> >>> The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well. >>> >>> I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01 >>> >>> /Magnus > From david.holmes at oracle.com Fri Jan 15 02:18:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jan 2016 12:18:34 +1000 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tets to build/conf/hotspot/testoutput In-Reply-To: <20160114160304.GM17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160113140405.GF17653@ehelin.jrpg.bea.com> <56969D5A.1020203@oracle.com> <569720FC.7080409@oracle.com> <20160114160304.GM17653@ehelin.jrpg.bea.com> Message-ID: <569856FA.40702@oracle.com> On 15/01/2016 2:03 AM, Erik Helin wrote: > On 2016-01-14, David Holmes wrote: >> Sorry I don't understand the change. AFAICS ALT_OUTPUTDIR could be anything >> - no guarantee that it already contains the "CONF" directory. >> >> Any why only change one path: >> >> ifdef ALT_OUTPUTDIR >> ! ABS_BUILD_ROOT = $(ALT_OUTPUTDIR)/hotspot >> else >> ABS_BUILD_ROOT = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH) >> >> ?? When do we take each path? > > The only "oficially" supported way of using the hotspot Makefiles is to > use the Makefiles in the top-level repo (e.g. jdk9/hs-rt). The Makefiles > in the top-level repo will always set ALT_OUTPUTDIR to > /build/. Hence, for any developer using these > Makefiles, ALT_OUTPUTDIR will always point to the current configuration. You're right - what I should have said is that there is no guarantee that the conf directory contains os-cpu. But regardless, for any given conf there is only one os-cpu pair so having that in the path is pointless, so the change is fine. > If anyone is using ALT_OUTPUTDIR in some other way, then they are "on > their own" (i.e. they will have to adjust their scripts). > > The one exception to this is JPRT, which does not use ALT_OUTPUTDIR at > all, and therefore uses the "else" branch. I don't want to change the > behaviour in JPRT, therefore I only changed the "then" branch. Okay -makes good sense. Thanks, David > Thanks, > Erik > >> David >> ----- >> >> On 14/01/2016 4:54 AM, Mikael Vidstedt wrote: >>> >>> The logic in this file (hotspot/test/Makefile) is very similar to that >>> of jdk/test/Makefile, as a matter of fact some of it has been copy >>> pasted. It would be nice if the output dir paths would be set up the >>> same way in both cases, to avoid confusion and all of that. >>> >>> It would be even better to share the logic all together to avoid >>> duplication, but that's a separate issue. >>> >>> Cheers, >>> Mikael >>> >>> On 2016-01-13 06:04, Erik Helin wrote: >>>> (added missing subject) >>>> >>>> On 2016-01-13, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this patch changes the output directory for hotspot's jtreg tests when >>>>> run via the top-level Makefile targets such as >>>>> `make test-hotspot-jtreg`. >>>>> >>>>> The current directory is >>>>> /build//hotspot/linux-x64/testoutput >>>>> (on an x86-64 machine running Linux). There is no need to place the >>>>> "testoutput" directory in a directory which name is based on OS and >>>>> arch, >>>>> that is already done by the current configuration. Therefore, we can >>>>> instead place the "testoutput" directory in >>>>> /build//hotspot/, which is a more reasonable location >>>>> for the output from hotspot's tests. >>>>> >>>>> Enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146985 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >>>>> >>>>> Testing: >>>>> - Running `make test-hotspot-jtreg` locally >>>>> - JPRT (the patch does not affect JPRT since JPRT does not use >>>>> ALT_OUTPUTDIR) >>>>> >>>>> Thanks, >>>>> Erik >>> From volker.simonis at gmail.com Fri Jan 15 15:39:37 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Jan 2016 16:39:37 +0100 Subject: RFR: 8057752: WhiteBox extension support for testing In-Reply-To: <54106895.9030906@oracle.com> References: <540DC2B9.3000505@oracle.com> <1536244.eiS3300VYN@mgerdin03> <54103778.5060406@oracle.com> <119f01cfcd00$e01c5140$a054f3c0$@oracle.com> <54106895.9030906@oracle.com> Message-ID: Hi everybody, sorry for the late question, but I'm just looking at the WhiteBox API and I'm wondering what this "extension support" is all about? Currently WhiteBox::register_extended() is an empty method and the few WhiteBox methods added with this change (e.g. getHeapUsageForContext()) are neither registered in the VM nor are they used in anywhere within the OpenJDK. Does "extension" mean "Oracle proprietary" in this context (i.e. do you have another WhiteBox::register_extended() in your closed sources which register the mentioned functions)? Or did I misunderstand the whole code? Thank you and best regards, Volker On Wed, Sep 10, 2014 at 5:04 PM, Stefan Johansson wrote: > On 2014-09-10 16:09, Christian Tornqvist wrote: >> >> Hi Stefan, >> >> This looks good. > > Thanks Christian. > Stefan > >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf >> Of >> Stefan Johansson >> Sent: Wednesday, September 10, 2014 7:35 AM >> To: Mikael Gerdin; hotspot-dev at openjdk.java.net >> Subject: Re: RFR: 8057752: WhiteBox extension support for testing >> >> Thanks for reviewing this Mikael. >> >> Made a small addition to allow Windows to handle empty extensions: >> http://cr.openjdk.java.net/~sjohanss/8057752/webrev.00-01/ >> >> Stefan >> >> On 2014-09-10 11:11, Mikael Gerdin wrote: >>> >>> Stefan, >>> >>> On Monday 08 September 2014 16.52.41 Stefan Johansson wrote: >>>> >>>> Hi, >>>> >>>> Please review these changes for RFE: >>>> https://bugs.openjdk.java.net/browse/JDK-8057752 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjohanss/8057752/webrev.00/ >>> >>> Looks good. >>> >>>> Summary: >>>> Added the call to register_extended to make it possible extend the >>>> WhiteBox API. The Java API is still defined in WhiteBox.java, if the >>>> extension methods are not defined by an extension a linker error will >>>> occur. >>> >>> Right, the code is designed so that it's possible to use mismatching >>> versions of WhiteBox.java as long as you avoid calling the unlinkable >> >> methods. >>> >>> /Mikael >>> >>>> Stefan >> >> > From erik.helin at oracle.com Fri Jan 15 16:13:29 2016 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 15 Jan 2016 17:13:29 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tests In-Reply-To: <20160113140128.GE17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> Message-ID: <20160115161329.GQ17653@ehelin.jrpg.bea.com> Hi all, I have updated the patch based on feedback and comments. hotspot/test/Makefile is now aligned with jdk/test/Makefile and now stores the ouput from the jtreg tests in: /build//testoutput/ Since the jtreg groups are prefixed with the name of the repository, e.g. hotspot_svc, jdk_svc, there won't be any name clashes. Webrev: http://cr.openjdk.java.net/~ehelin/8146985/01/ Testing: - Running `make test-hotspot-jtreg` and verified that is uses the correct directory for test output. - Running JPRT and verified that it works with the new directory name. Since JPRT does not use ALT_OUTPUTDIR, the output will be stored in build/-/testoutput/ which JPRT seems to handle just fine. Thanks, Erik On 2016-01-13, Erik Helin wrote: > Hi all, > > this patch changes the output directory for hotspot's jtreg tests when > run via the top-level Makefile targets such as > `make test-hotspot-jtreg`. > > The current directory is > /build//hotspot/linux-x64/testoutput > (on an x86-64 machine running Linux). There is no need to place the > "testoutput" directory in a directory which name is based on OS and arch, > that is already done by the current configuration. Therefore, we can > instead place the "testoutput" directory in > /build//hotspot/, which is a more reasonable location > for the output from hotspot's tests. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8146985 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/00/webrev > > Testing: > - Running `make test-hotspot-jtreg` locally > - JPRT (the patch does not affect JPRT since JPRT does not use > ALT_OUTPUTDIR) > > Thanks, > Erik From erik.joelsson at oracle.com Fri Jan 15 16:17:26 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Jan 2016 17:17:26 +0100 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tests In-Reply-To: <20160115161329.GQ17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160115161329.GQ17653@ehelin.jrpg.bea.com> Message-ID: <56991B96.3070801@oracle.com> Looks good. /Erik On 2016-01-15 17:13, Erik Helin wrote: > Hi all, > > I have updated the patch based on feedback and comments. > hotspot/test/Makefile is now aligned with jdk/test/Makefile and now > stores the ouput from the jtreg tests in: > /build//testoutput/ > Since the jtreg groups are prefixed with the name of the repository, > e.g. hotspot_svc, jdk_svc, there won't be any name clashes. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/01/ > > Testing: > - Running `make test-hotspot-jtreg` and verified that is uses the > correct directory for test output. > - Running JPRT and verified that it works with the new directory name. > Since JPRT does not use ALT_OUTPUTDIR, the output will be stored in > build/-/testoutput/ > which JPRT seems to handle just fine. > > Thanks, > Erik > > On 2016-01-13, Erik Helin wrote: >> Hi all, >> >> this patch changes the output directory for hotspot's jtreg tests when >> run via the top-level Makefile targets such as >> `make test-hotspot-jtreg`. >> >> The current directory is >> /build//hotspot/linux-x64/testoutput >> (on an x86-64 machine running Linux). There is no need to place the >> "testoutput" directory in a directory which name is based on OS and arch, >> that is already done by the current configuration. Therefore, we can >> instead place the "testoutput" directory in >> /build//hotspot/, which is a more reasonable location >> for the output from hotspot's tests. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146985 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >> >> Testing: >> - Running `make test-hotspot-jtreg` locally >> - JPRT (the patch does not affect JPRT since JPRT does not use >> ALT_OUTPUTDIR) >> >> Thanks, >> Erik From mikael.gerdin at oracle.com Fri Jan 15 17:04:57 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 15 Jan 2016 18:04:57 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets Message-ID: <569926B9.4070806@oracle.com> Hi all, As per the previous discussion in mid-December[0] about moving the _vtable_length field to class Klass, here's the first RFR and webrev, according to my suggested plan[1]: > My current plan is to first modify the vtable_length_offset accessor to > return a byte offset (which is what it's translated to by all callers). > > Then I'll tackle moving the _vtable_len field to Klass. > > Finally I'll try to consolidate the vtable related methods to Klass, > where they belong. This change actually consists of three changes: * modifying InstanceKlass::vtable_length_offset to become a byte offset and use the ByteSize type to communicate the scaling. * modifying InstanceKlass::vtable_start_offset to become a byte offset and use the ByteSize type, for symmetry reasons mainly. * adding a vtableEntry::size_in_bytes() since in many places the vtable entry size is used in combination with the vtable start to compute a byte offset for vtable lookups. I don't foresee any issues with the fact that the byte offset is represented as an int, for two reasons: 1) If the offset of any of these grows to over 2 gigabytes then we have a huge footprint problem with InstanceKlass 2) The offsets are converted to byte offsets and stored in ints already in the cpu specific code I've modified. Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ Testing: JPRT on Oracle supported platforms, testing on AARCH64 and PPC64 would be much appreciated, appropriate mailing lists have been CC:ed to notify them of the request. [0] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html Thanks! /Mikael From sgehwolf at redhat.com Fri Jan 15 18:46:13 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Jan 2016 19:46:13 +0100 Subject: [9] RFR(XS): 8147482: Zero build fails after 8144953 Message-ID: <1452883573.3564.64.camel@redhat.com> Hi, Could somebody please review and sponsor this trivial change to bytecodeInterpreter.cpp. It fixes a Zero-only build problem. Webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147482/webrev.01/ Bug:?https://bugs.openjdk.java.net/browse/JDK-8147482 Zero builds fine in release/fastdebug/slowdebug variants after this. Thanks, Severin From coleen.phillimore at oracle.com Fri Jan 15 19:04:42 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Jan 2016 14:04:42 -0500 Subject: [9] RFR(XS): 8147482: Zero build fails after 8144953 In-Reply-To: <1452883573.3564.64.camel@redhat.com> References: <1452883573.3564.64.camel@redhat.com> Message-ID: <569942CA.9090605@oracle.com> Severin, this looks good. The compilation failure was because Zero didn't compile when this change was made. I'll sponsor it. Can you send me the export file? Thanks, Coleen On 1/15/16 1:46 PM, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this trivial change to > bytecodeInterpreter.cpp. It fixes a Zero-only build problem. > > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147482/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8147482 > > Zero builds fine in release/fastdebug/slowdebug variants after this. > > Thanks, > Severin From volker.simonis at gmail.com Fri Jan 15 19:20:46 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Jan 2016 20:20:46 +0100 Subject: [9] RFR(XS): 8147482: Zero build fails after 8144953 In-Reply-To: <1452883573.3564.64.camel@redhat.com> References: <1452883573.3564.64.camel@redhat.com> Message-ID: Hi Severin, the change looks good. Unfortunately I can't sponsor it because it is in shared code. Regards, Volker On Fri, Jan 15, 2016 at 7:46 PM, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this trivial change to > bytecodeInterpreter.cpp. It fixes a Zero-only build problem. > > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147482/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8147482 > > Zero builds fine in release/fastdebug/slowdebug variants after this. > > Thanks, > Severin From coleen.phillimore at oracle.com Fri Jan 15 19:52:08 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Jan 2016 14:52:08 -0500 Subject: [9] RFR(XS): 8147482: Zero build fails after 8144953 In-Reply-To: References: <1452883573.3564.64.camel@redhat.com> Message-ID: <56994DE8.2060209@oracle.com> On 1/15/16 2:20 PM, Volker Simonis wrote: > Hi Severin, > > the change looks good. > > Unfortunately I can't sponsor it because it is in shared code. Actually, since it's in Zero only, I think it would be okay to push directly. It's not technically in the cpu/zero/vm directory but these files are only used for Zero. Alas, we don't test Zero with JPRT. If we start doing this, a. it wouldn't break so often and b. we'd have to sponsor just to make sure it doesn't break and prevent other integration jobs from going through. Thanks, Coleen > > Regards, > Volker > > > On Fri, Jan 15, 2016 at 7:46 PM, Severin Gehwolf wrote: >> Hi, >> >> Could somebody please review and sponsor this trivial change to >> bytecodeInterpreter.cpp. It fixes a Zero-only build problem. >> >> Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147482/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147482 >> >> Zero builds fine in release/fastdebug/slowdebug variants after this. >> >> Thanks, >> Severin From mikael.vidstedt at oracle.com Fri Jan 15 19:53:21 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Jan 2016 11:53:21 -0800 Subject: RFR: 8146985: Change output directory for hotspot's jtreg tests In-Reply-To: <20160115161329.GQ17653@ehelin.jrpg.bea.com> References: <20160113140128.GE17653@ehelin.jrpg.bea.com> <20160115161329.GQ17653@ehelin.jrpg.bea.com> Message-ID: <56994E31.7050600@oracle.com> Looks good! I suggest as a follow up change to align the variable names and the (JPRT) "else" part with jdk/test/Makefile. Cheers, Mikael On 2016-01-15 08:13, Erik Helin wrote: > Hi all, > > I have updated the patch based on feedback and comments. > hotspot/test/Makefile is now aligned with jdk/test/Makefile and now > stores the ouput from the jtreg tests in: > /build//testoutput/ > Since the jtreg groups are prefixed with the name of the repository, > e.g. hotspot_svc, jdk_svc, there won't be any name clashes. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8146985/01/ > > Testing: > - Running `make test-hotspot-jtreg` and verified that is uses the > correct directory for test output. > - Running JPRT and verified that it works with the new directory name. > Since JPRT does not use ALT_OUTPUTDIR, the output will be stored in > build/-/testoutput/ > which JPRT seems to handle just fine. > > Thanks, > Erik > > On 2016-01-13, Erik Helin wrote: >> Hi all, >> >> this patch changes the output directory for hotspot's jtreg tests when >> run via the top-level Makefile targets such as >> `make test-hotspot-jtreg`. >> >> The current directory is >> /build//hotspot/linux-x64/testoutput >> (on an x86-64 machine running Linux). There is no need to place the >> "testoutput" directory in a directory which name is based on OS and arch, >> that is already done by the current configuration. Therefore, we can >> instead place the "testoutput" directory in >> /build//hotspot/, which is a more reasonable location >> for the output from hotspot's tests. >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8146985 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8146985/00/webrev >> >> Testing: >> - Running `make test-hotspot-jtreg` locally >> - JPRT (the patch does not affect JPRT since JPRT does not use >> ALT_OUTPUTDIR) >> >> Thanks, >> Erik From alejandro.murillo at oracle.com Fri Jan 15 21:51:57 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 15 Jan 2016 14:51:57 -0700 Subject: [9] RFR 8146653: Debug version missing in hs_err files and on internal version after Verona Message-ID: <569969FD.80302@oracle.com> Please review the following fix for JDK-8146653 : Debug version missing in hs_err files and on internal version after Verona Webrev: http://cr.openjdk.java.net/~amurillo/9/8146653/ Background: Verona removed the debug info from version related system properties and that's now specified on a new system property called jdk.debug. The version header spitted in hs_err files was updated to include debug info based on that change. That info was also missing on the output for -Xinternalversion Thanks -- Alejandro From daniel.daugherty at oracle.com Fri Jan 15 22:09:04 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jan 2016 15:09:04 -0700 Subject: [9] RFR 8146653: Debug version missing in hs_err files and on internal version after Verona In-Reply-To: <569969FD.80302@oracle.com> References: <569969FD.80302@oracle.com> Message-ID: <56996E00.9000104@oracle.com> On 1/15/16 2:51 PM, Alejandro E Murillo wrote: > > Please review the following fix for JDK-8146653 > : > Debug version missing in hs_err files and on internal version after > Verona > > Webrev: http://cr.openjdk.java.net/~amurillo/9/8146653/ Your version of webrev generated broken nav links for the "frames" version. Shows 404... src/share/vm/runtime/vm_version.cpp L242: return strcmp(DEBUG_LEVEL, "release") ? L243: VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX L244: : L245: VMNAME " (" INTERNAL_VERSION_SUFFIX; No implied booleans on this part: strcmp(DEBUG_LEVEL, "release") Also I think this would be more HotSpot style: return strcmp(DEBUG_LEVEL, "release") == 0 ? VMNAME " (" INTERNAL_VERSION_SUFFIX : VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX; where the "usual case" is first and the indenting is more HotSpot like... L258: return strcmp(DEBUG_LEVEL, "release") ? DEBUG_LEVEL " " : ""; Similarly here: return strcmp(DEBUG_LEVEL, "release") == 0 ? "" : DEBUG_LEVEL; src/share/vm/runtime/vm_version.hpp No comments. src/share/vm/utilities/vmError.cpp L234: const char* runtime_version = JDK_Version::runtime_version() != NULL ? L235: JDK_Version::runtime_version() : ""; L236: const char* jdk_debug_level = Abstract_VM_Version::alternate_jdk_debug_level() != NULL ? L237: Abstract_VM_Version::alternate_jdk_debug_level() : ""; L237 indent needs three more spaces. So does L235, but that's not your issue. L239: st->print_cr("# JRE version: %s (%s) (%sbuild %s)", runtime_name, buf, L240: jdk_debug_level, runtime_version); L240 indent has one too many spaces. Dan > > Background: > Verona removed the debug info from version related system properties > and that's now specified on a new system property called jdk.debug. > The version header spitted in hs_err files was updated to include > debug info based on that change. > That info was also missing on the output for -Xinternalversion > > Thanks > From alejandro.murillo at oracle.com Fri Jan 15 23:31:12 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 15 Jan 2016 16:31:12 -0700 Subject: [9] RFR 8146653: Debug version missing in hs_err files and on internal version after Verona In-Reply-To: <56996E00.9000104@oracle.com> References: <569969FD.80302@oracle.com> <56996E00.9000104@oracle.com> Message-ID: <56998140.5020205@oracle.com> Hi Dan, thanks a lot for the prompt review I applied all the changes, revised webrev (with proper links) is here: http://cr.openjdk.java.net/~amurillo/9/8146653/index.html Thanks Alejandro On 1/15/2016 3:09 PM, Daniel D. Daugherty wrote: > On 1/15/16 2:51 PM, Alejandro E Murillo wrote: >> >> Please review the following fix for JDK-8146653 >> : >> Debug version missing in hs_err files and on internal version after >> Verona >> >> Webrev: http://cr.openjdk.java.net/~amurillo/9/8146653/ > > Your version of webrev generated broken nav links for > the "frames" version. Shows 404... > > > src/share/vm/runtime/vm_version.cpp > L242: return strcmp(DEBUG_LEVEL, "release") ? > L243: VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX > L244: : > L245: VMNAME " (" INTERNAL_VERSION_SUFFIX; > > No implied booleans on this part: strcmp(DEBUG_LEVEL, "release") > > Also I think this would be more HotSpot style: > > return strcmp(DEBUG_LEVEL, "release") == 0 > ? VMNAME " (" INTERNAL_VERSION_SUFFIX > : VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX; > > where the "usual case" is first and the indenting is more > HotSpot like... > > L258: return strcmp(DEBUG_LEVEL, "release") ? DEBUG_LEVEL " " : ""; > > Similarly here: > > return strcmp(DEBUG_LEVEL, "release") == 0 ? "" : DEBUG_LEVEL; > > src/share/vm/runtime/vm_version.hpp > No comments. > > src/share/vm/utilities/vmError.cpp > L234: const char* runtime_version = > JDK_Version::runtime_version() != NULL ? > L235: JDK_Version::runtime_version() : ""; > L236: const char* jdk_debug_level = > Abstract_VM_Version::alternate_jdk_debug_level() != NULL ? > L237: Abstract_VM_Version::alternate_jdk_debug_level() : ""; > > L237 indent needs three more spaces. So does L235, but that's > not your issue. > > L239: st->print_cr("# JRE version: %s (%s) (%sbuild %s)", > runtime_name, buf, > L240: jdk_debug_level, runtime_version); > > L240 indent has one too many spaces. > > Dan > >> >> Background: >> Verona removed the debug info from version related system properties >> and that's now specified on a new system property called jdk.debug. >> The version header spitted in hs_err files was updated to include >> debug info based on that change. >> That info was also missing on the output for -Xinternalversion >> >> Thanks >> > -- Alejandro From daniel.daugherty at oracle.com Sat Jan 16 00:07:38 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jan 2016 17:07:38 -0700 Subject: [9] RFR 8146653: Debug version missing in hs_err files and on internal version after Verona In-Reply-To: <56998140.5020205@oracle.com> References: <569969FD.80302@oracle.com> <56996E00.9000104@oracle.com> <56998140.5020205@oracle.com> Message-ID: <569989CA.3080208@oracle.com> On 1/15/16 4:31 PM, Alejandro E Murillo wrote: > Hi Dan, thanks a lot for the prompt review I figured you wanted this done quickly since it is causing nightly analysis confusion... :-) > I applied all the changes, revised webrev (with proper links) is here: > > http://cr.openjdk.java.net/~amurillo/9/8146653/index.html Forgot to remind about updating copyright years in the first round... src/share/vm/runtime/vm_version.hpp No comments. src/share/vm/runtime/vm_version.cpp No comments. src/share/vm/utilities/vmError.cpp No comments. Thumbs up! Dan > > Thanks > Alejandro > > On 1/15/2016 3:09 PM, Daniel D. Daugherty wrote: >> On 1/15/16 2:51 PM, Alejandro E Murillo wrote: >>> >>> Please review the following fix for JDK-8146653 >>> : >>> Debug version missing in hs_err files and on internal version after >>> Verona >>> >>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8146653/ >> >> Your version of webrev generated broken nav links for >> the "frames" version. Shows 404... >> >> >> src/share/vm/runtime/vm_version.cpp >> L242: return strcmp(DEBUG_LEVEL, "release") ? >> L243: VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX >> L244: : >> L245: VMNAME " (" INTERNAL_VERSION_SUFFIX; >> >> No implied booleans on this part: strcmp(DEBUG_LEVEL, "release") >> >> Also I think this would be more HotSpot style: >> >> return strcmp(DEBUG_LEVEL, "release") == 0 >> ? VMNAME " (" INTERNAL_VERSION_SUFFIX >> : VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX; >> >> where the "usual case" is first and the indenting is more >> HotSpot like... >> >> L258: return strcmp(DEBUG_LEVEL, "release") ? DEBUG_LEVEL " " : >> ""; >> >> Similarly here: >> >> return strcmp(DEBUG_LEVEL, "release") == 0 ? "" : DEBUG_LEVEL; >> >> src/share/vm/runtime/vm_version.hpp >> No comments. >> >> src/share/vm/utilities/vmError.cpp >> L234: const char* runtime_version = >> JDK_Version::runtime_version() != NULL ? >> L235: JDK_Version::runtime_version() : ""; >> L236: const char* jdk_debug_level = >> Abstract_VM_Version::alternate_jdk_debug_level() != NULL ? >> L237: Abstract_VM_Version::alternate_jdk_debug_level() : ""; >> >> L237 indent needs three more spaces. So does L235, but that's >> not your issue. >> >> L239: st->print_cr("# JRE version: %s (%s) (%sbuild %s)", >> runtime_name, buf, >> L240: jdk_debug_level, runtime_version); >> >> L240 indent has one too many spaces. >> >> Dan >> >>> >>> Background: >>> Verona removed the debug info from version related system properties >>> and that's now specified on a new system property called jdk.debug. >>> The version header spitted in hs_err files was updated to include >>> debug info based on that change. >>> That info was also missing on the output for -Xinternalversion >>> >>> Thanks >>> >> > From volker.simonis at gmail.com Sat Jan 16 10:43:50 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 16 Jan 2016 11:43:50 +0100 Subject: [9] RFR(XS): 8147482: Zero build fails after 8144953 In-Reply-To: <56994DE8.2060209@oracle.com> References: <1452883573.3564.64.camel@redhat.com> <56994DE8.2060209@oracle.com> Message-ID: Hi Coleen, I totally agree and I'd like to but there have been complaints before when we pushed ppc64 or AIX only changes to shared directories. So until we don't get a general and clear agreement on this topic I'd like to ask you to be so kind and do the push. Thank you and best regards, Volker On Friday, January 15, 2016, Coleen Phillimore wrote: > > > On 1/15/16 2:20 PM, Volker Simonis wrote: > >> Hi Severin, >> >> the change looks good. >> >> Unfortunately I can't sponsor it because it is in shared code. >> > > Actually, since it's in Zero only, I think it would be okay to push > directly. It's not technically in the cpu/zero/vm directory but these > files are only used for Zero. > > Alas, we don't test Zero with JPRT. If we start doing this, a. it > wouldn't break so often and b. we'd have to sponsor just to make sure it > doesn't break and prevent other integration jobs from going through. > > Thanks, > Coleen > >> >> Regards, >> Volker >> >> >> On Fri, Jan 15, 2016 at 7:46 PM, Severin Gehwolf >> wrote: >> >>> Hi, >>> >>> Could somebody please review and sponsor this trivial change to >>> bytecodeInterpreter.cpp. It fixes a Zero-only build problem. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147482/webrev.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147482 >>> >>> Zero builds fine in release/fastdebug/slowdebug variants after this. >>> >>> Thanks, >>> Severin >>> >> > From coleen.phillimore at oracle.com Sat Jan 16 20:28:57 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sat, 16 Jan 2016 15:28:57 -0500 Subject: [9] RFR(XS): 8147482: Zero build fails after 8144953 In-Reply-To: References: <1452883573.3564.64.camel@redhat.com> <56994DE8.2060209@oracle.com> Message-ID: <569AA809.5080309@oracle.com> Ok, I checked it in with author sgehwolf, through JPRT although JPRT doesn't build it. Thanks for the contribution Severin. Coleen On 1/16/16 5:43 AM, Volker Simonis wrote: > Hi Coleen, > > I totally agree and I'd like to but there have been complaints before > when we pushed ppc64 or AIX only changes to shared directories. > > So until we don't get a general and clear agreement on this topic I'd > like to ask you to be so kind and do the push. > > Thank you and best regards, > Volker > > On Friday, January 15, 2016, Coleen Phillimore > > > wrote: > > > > On 1/15/16 2:20 PM, Volker Simonis wrote: > > Hi Severin, > > the change looks good. > > Unfortunately I can't sponsor it because it is in shared code. > > > Actually, since it's in Zero only, I think it would be okay to > push directly. It's not technically in the cpu/zero/vm directory > but these files are only used for Zero. > > Alas, we don't test Zero with JPRT. If we start doing this, a. it > wouldn't break so often and b. we'd have to sponsor just to make > sure it doesn't break and prevent other integration jobs from > going through. > > Thanks, > Coleen > > > Regards, > Volker > > > On Fri, Jan 15, 2016 at 7:46 PM, Severin Gehwolf > wrote: > > Hi, > > Could somebody please review and sponsor this trivial > change to > bytecodeInterpreter.cpp. It fixes a Zero-only build problem. > > Webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147482/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147482 > > Zero builds fine in release/fastdebug/slowdebug variants > after this. > > Thanks, > Severin > > From david.holmes at oracle.com Mon Jan 18 04:05:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Jan 2016 14:05:57 +1000 Subject: [9] RFR 8146653: Debug version missing in hs_err files and on internal version after Verona In-Reply-To: <56998140.5020205@oracle.com> References: <569969FD.80302@oracle.com> <56996E00.9000104@oracle.com> <56998140.5020205@oracle.com> Message-ID: <569C64A5.1020904@oracle.com> Hi Alejandro, On 16/01/2016 9:31 AM, Alejandro E Murillo wrote: > > Hi Dan, thanks a lot for the prompt review > I applied all the changes, revised webrev (with proper links) is here: > > http://cr.openjdk.java.net/~amurillo/9/8146653/index.html Seeing this all together now I don't think alternate_jdk_debug_level warrants being added to Abstract_VM_version. The logic could be used directly inline in VMError.cpp. If it were used more than once then perhaps ... though printable_jdk_debug_level might be a better name in that case (still not a great name but better IMHO :) ). Thanks, David > Thanks > Alejandro > > On 1/15/2016 3:09 PM, Daniel D. Daugherty wrote: >> On 1/15/16 2:51 PM, Alejandro E Murillo wrote: >>> >>> Please review the following fix for JDK-8146653 >>> : >>> Debug version missing in hs_err files and on internal version after >>> Verona >>> >>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8146653/ >> >> Your version of webrev generated broken nav links for >> the "frames" version. Shows 404... >> >> >> src/share/vm/runtime/vm_version.cpp >> L242: return strcmp(DEBUG_LEVEL, "release") ? >> L243: VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX >> L244: : >> L245: VMNAME " (" INTERNAL_VERSION_SUFFIX; >> >> No implied booleans on this part: strcmp(DEBUG_LEVEL, "release") >> >> Also I think this would be more HotSpot style: >> >> return strcmp(DEBUG_LEVEL, "release") == 0 >> ? VMNAME " (" INTERNAL_VERSION_SUFFIX >> : VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX; >> >> where the "usual case" is first and the indenting is more >> HotSpot like... >> >> L258: return strcmp(DEBUG_LEVEL, "release") ? DEBUG_LEVEL " " : ""; >> >> Similarly here: >> >> return strcmp(DEBUG_LEVEL, "release") == 0 ? "" : DEBUG_LEVEL; >> >> src/share/vm/runtime/vm_version.hpp >> No comments. >> >> src/share/vm/utilities/vmError.cpp >> L234: const char* runtime_version = >> JDK_Version::runtime_version() != NULL ? >> L235: JDK_Version::runtime_version() : ""; >> L236: const char* jdk_debug_level = >> Abstract_VM_Version::alternate_jdk_debug_level() != NULL ? >> L237: Abstract_VM_Version::alternate_jdk_debug_level() : ""; >> >> L237 indent needs three more spaces. So does L235, but that's >> not your issue. >> >> L239: st->print_cr("# JRE version: %s (%s) (%sbuild %s)", >> runtime_name, buf, >> L240: jdk_debug_level, runtime_version); >> >> L240 indent has one too many spaces. >> >> Dan >> >>> >>> Background: >>> Verona removed the debug info from version related system properties >>> and that's now specified on a new system property called jdk.debug. >>> The version header spitted in hs_err files was updated to include >>> debug info based on that change. >>> That info was also missing on the output for -Xinternalversion >>> >>> Thanks >>> >> > From sgehwolf at redhat.com Mon Jan 18 09:36:59 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Jan 2016 10:36:59 +0100 Subject: [9] RFR(XS): 8147482: Zero build fails after 8144953 In-Reply-To: <569AA809.5080309@oracle.com> References: <1452883573.3564.64.camel@redhat.com> <56994DE8.2060209@oracle.com> <569AA809.5080309@oracle.com> Message-ID: <1453109819.3343.1.camel@redhat.com> On Sat, 2016-01-16 at 15:28 -0500, Coleen Phillimore wrote: > Ok, I checked it in with author sgehwolf, through JPRT although JPRT? > doesn't build it. > Thanks for the contribution Severin. > Coleen Thanks Volker and Coleen! Cheers, Severin > On 1/16/16 5:43 AM, Volker Simonis wrote: > > Hi Coleen, > > > > I totally agree and I'd like to but there have been complaints before? > > when we pushed ppc64 or AIX only changes to shared directories. > > > > So until we don't get a general and clear agreement on this topic I'd? > > like to ask you to be so kind and do the push. > > > > Thank you and best regards, > > Volker > > > > On Friday, January 15, 2016, Coleen Phillimore? > > >? > > wrote: > > > > > > > > ????On 1/15/16 2:20 PM, Volker Simonis wrote: > > > > ????????Hi Severin, > > > > ????????the change looks good. > > > > ????????Unfortunately I can't sponsor it because it is in shared code. > > > > > > ????Actually, since it's in Zero only, I think it would be okay to > > ????push directly.???It's not technically in the cpu/zero/vm directory > > ????but these files are only used for Zero. > > > > ????Alas, we don't test Zero with JPRT.??If we start doing this, a. it > > ????wouldn't break so often and b. we'd have to sponsor just to make > > ????sure it doesn't break and prevent other integration jobs from > > ????going through. > > > > ????Thanks, > > ????Coleen > > > > > > ????????Regards, > > ????????Volker > > > > > > ????????On Fri, Jan 15, 2016 at 7:46 PM, Severin Gehwolf > > ???????? wrote: > > > > ????????????Hi, > > > > ????????????Could somebody please review and sponsor this trivial > > ????????????change to > > ????????????bytecodeInterpreter.cpp. It fixes a Zero-only build problem. > > > > ????????????Webrev: > > ????????????http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147482/webrev.01/ > > ???????????? > > ????????????Bug: https://bugs.openjdk.java.net/browse/JDK-8147482 > > > > ????????????Zero builds fine in release/fastdebug/slowdebug variants > > ????????????after this. > > > > ????????????Thanks, > > ????????????Severin > > > > > From volker.simonis at gmail.com Mon Jan 18 10:53:54 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Jan 2016 11:53:54 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569926B9.4070806@oracle.com> References: <569926B9.4070806@oracle.com> Message-ID: Hi Mikael, your change builds and runs fine on ppc64. Thanks for considering ppc64 in your patch, Volker On Fri, Jan 15, 2016 at 6:04 PM, Mikael Gerdin wrote: > Hi all, > > As per the previous discussion in mid-December[0] about moving the > _vtable_length field to class Klass, here's the first RFR and webrev, > according to my suggested plan[1]: > >> My current plan is to first modify the vtable_length_offset accessor to >> return a byte offset (which is what it's translated to by all callers). >> >> Then I'll tackle moving the _vtable_len field to Klass. >> >> Finally I'll try to consolidate the vtable related methods to Klass, >> where they belong. > > > This change actually consists of three changes: > * modifying InstanceKlass::vtable_length_offset to become a byte offset and > use the ByteSize type to communicate the scaling. > * modifying InstanceKlass::vtable_start_offset to become a byte offset and > use the ByteSize type, for symmetry reasons mainly. > * adding a vtableEntry::size_in_bytes() since in many places the vtable > entry size is used in combination with the vtable start to compute a byte > offset for vtable lookups. > > I don't foresee any issues with the fact that the byte offset is represented > as an int, for two reasons: > 1) If the offset of any of these grows to over 2 gigabytes then we have a > huge footprint problem with InstanceKlass > 2) The offsets are converted to byte offsets and stored in ints already in > the cpu specific code I've modified. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 > Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ > > Testing: JPRT on Oracle supported platforms, testing on AARCH64 and PPC64 > would be much appreciated, appropriate mailing lists have been CC:ed to > notify them of the request. > > > [0] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html > > Thanks! > /Mikael From stefan.johansson at oracle.com Mon Jan 18 13:24:31 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 18 Jan 2016 14:24:31 +0100 Subject: RFR: 8057752: WhiteBox extension support for testing In-Reply-To: References: <540DC2B9.3000505@oracle.com> <1536244.eiS3300VYN@mgerdin03> <54103778.5060406@oracle.com> <119f01cfcd00$e01c5140$a054f3c0$@oracle.com> <54106895.9030906@oracle.com> Message-ID: <569CE78F.9080005@oracle.com> Hi Volker, On 2016-01-15 16:39, Volker Simonis wrote: > Hi everybody, > > sorry for the late question, but I'm just looking at the WhiteBox API > and I'm wondering what this "extension support" is all about? > > Currently WhiteBox::register_extended() is an empty method and the few > WhiteBox methods added with this change (e.g. > getHeapUsageForContext()) are neither registered in the VM nor are > they used in anywhere within the OpenJDK. > > Does "extension" mean "Oracle proprietary" in this context (i.e. do > you have another WhiteBox::register_extended() in your closed sources > which register the mentioned functions)? Or did I misunderstand the > whole code? Yes, there is a closed version of WhiteBox::register_extended(). Thanks, Stefan > > Thank you and best regards, > Volker > > > On Wed, Sep 10, 2014 at 5:04 PM, Stefan Johansson > wrote: >> On 2014-09-10 16:09, Christian Tornqvist wrote: >>> Hi Stefan, >>> >>> This looks good. >> Thanks Christian. >> Stefan >> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf >>> Of >>> Stefan Johansson >>> Sent: Wednesday, September 10, 2014 7:35 AM >>> To: Mikael Gerdin; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR: 8057752: WhiteBox extension support for testing >>> >>> Thanks for reviewing this Mikael. >>> >>> Made a small addition to allow Windows to handle empty extensions: >>> http://cr.openjdk.java.net/~sjohanss/8057752/webrev.00-01/ >>> >>> Stefan >>> >>> On 2014-09-10 11:11, Mikael Gerdin wrote: >>>> Stefan, >>>> >>>> On Monday 08 September 2014 16.52.41 Stefan Johansson wrote: >>>>> Hi, >>>>> >>>>> Please review these changes for RFE: >>>>> https://bugs.openjdk.java.net/browse/JDK-8057752 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sjohanss/8057752/webrev.00/ >>>> Looks good. >>>> >>>>> Summary: >>>>> Added the call to register_extended to make it possible extend the >>>>> WhiteBox API. The Java API is still defined in WhiteBox.java, if the >>>>> extension methods are not defined by an extension a linker error will >>>>> occur. >>>> Right, the code is designed so that it's possible to use mismatching >>>> versions of WhiteBox.java as long as you avoid calling the unlinkable >>> methods. >>>> /Mikael >>>> >>>>> Stefan >>> From volker.simonis at gmail.com Mon Jan 18 14:08:02 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Jan 2016 15:08:02 +0100 Subject: RFR: 8057752: WhiteBox extension support for testing In-Reply-To: <569CE78F.9080005@oracle.com> References: <540DC2B9.3000505@oracle.com> <1536244.eiS3300VYN@mgerdin03> <54103778.5060406@oracle.com> <119f01cfcd00$e01c5140$a054f3c0$@oracle.com> <54106895.9030906@oracle.com> <569CE78F.9080005@oracle.com> Message-ID: OK, then I understand the change :) Thanks for the info, Volker On Mon, Jan 18, 2016 at 2:24 PM, Stefan Johansson wrote: > Hi Volker, > > On 2016-01-15 16:39, Volker Simonis wrote: >> >> Hi everybody, >> >> sorry for the late question, but I'm just looking at the WhiteBox API >> and I'm wondering what this "extension support" is all about? >> >> Currently WhiteBox::register_extended() is an empty method and the few >> WhiteBox methods added with this change (e.g. >> getHeapUsageForContext()) are neither registered in the VM nor are >> they used in anywhere within the OpenJDK. >> >> Does "extension" mean "Oracle proprietary" in this context (i.e. do >> you have another WhiteBox::register_extended() in your closed sources >> which register the mentioned functions)? Or did I misunderstand the >> whole code? > > Yes, there is a closed version of WhiteBox::register_extended(). > > Thanks, > Stefan > > >> >> Thank you and best regards, >> Volker >> >> >> On Wed, Sep 10, 2014 at 5:04 PM, Stefan Johansson >> wrote: >>> >>> On 2014-09-10 16:09, Christian Tornqvist wrote: >>>> >>>> Hi Stefan, >>>> >>>> This looks good. >>> >>> Thanks Christian. >>> Stefan >>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>>> Behalf >>>> Of >>>> Stefan Johansson >>>> Sent: Wednesday, September 10, 2014 7:35 AM >>>> To: Mikael Gerdin; hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR: 8057752: WhiteBox extension support for testing >>>> >>>> Thanks for reviewing this Mikael. >>>> >>>> Made a small addition to allow Windows to handle empty extensions: >>>> http://cr.openjdk.java.net/~sjohanss/8057752/webrev.00-01/ >>>> >>>> Stefan >>>> >>>> On 2014-09-10 11:11, Mikael Gerdin wrote: >>>>> >>>>> Stefan, >>>>> >>>>> On Monday 08 September 2014 16.52.41 Stefan Johansson wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review these changes for RFE: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8057752 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sjohanss/8057752/webrev.00/ >>>>> >>>>> Looks good. >>>>> >>>>>> Summary: >>>>>> Added the call to register_extended to make it possible extend the >>>>>> WhiteBox API. The Java API is still defined in WhiteBox.java, if the >>>>>> extension methods are not defined by an extension a linker error will >>>>>> occur. >>>>> >>>>> Right, the code is designed so that it's possible to use mismatching >>>>> versions of WhiteBox.java as long as you avoid calling the unlinkable >>>> >>>> methods. >>>>> >>>>> /Mikael >>>>> >>>>>> Stefan >>>> >>>> > From igor.ignatyev at oracle.com Mon Jan 18 15:27:58 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 18 Jan 2016 18:27:58 +0300 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform In-Reply-To: References: <4CE12B2E-FDEF-48E0-AA84-E410DC09CE53@oracle.com> Message-ID: <6B22808F-2CD4-4E2C-AC47-C51B04C4AD13@oracle.com> Filipp, no, I think all of them can be done later and separately, however I?d really appreciate if you help us w/ some of them. I?ll integrate your patch from [1] shortly. [1] http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ Thanks, Igor > On Jan 11, 2016, at 2:07 PM, Filipp Zhinkin wrote: > > Igor, > > So, do you want me to include any other changes for this CR? > > Regards, > Filipp. > > On Wed, Jan 6, 2016 at 4:00 PM, Filipp Zhinkin wrote: >> Hi Igor, >> >> here are RFEs for tests relocation and ClassFileInstaller relocation: >> https://bugs.openjdk.java.net/browse/JDK-8146549 >> https://bugs.openjdk.java.net/browse/JDK-8146550 >> >> Thanks, >> Filipp. >> >> On Sat, Jan 2, 2016 at 2:59 PM, Igor Ignatyev wrote: >>> Hi Filipp, >>> >>> there is no options to make ?@library /test/lib? works. there is ?external.lib.roots? property in TEST.ROOT files, which adds additional root for @library. I noticed that there is no /test/lib-test isn?t a part of any test-suites, hence moving test to test/lib-test implies extra work in infra. given that I think it?ll be better to do it lately and separately from 8066599. please file an RFE for that. >>> >>> on 2nd question, I think it makes sense to move ClassFileInstaller to jdk.test.lib and annotate ClassFileInstaller in both jdk/test/lib/testlibrary/ and hotspot/test/testlibrary/ w/ @Deprectate. and I also think it?d be better to do it separately. >>> >>> Thanks, >>> Igor >>> >>>> On Dec 25, 2015, at 12:41 PM, Filipp Zhinkin wrote: >>>> >>>> Hi Igor, >>>> >>>> thanks for looking at this change. >>>> >>>> On Thu, Dec 24, 2015 at 9:24 PM, Igor Ignatyev wrote: >>>>> Hi Filipp, >>>>> >>>>> could you please move TestMutuallyExclusivePlatformPredicates and TestPlatformIsTieredSupported from hotspot/testlibrary_tests/ to test/lib-test and update it according to your changes? please note that we started to use packages in our tests. >>>> >>>> Sure, I'll move it. >>>> >>>> Do I need to pass any specific options to jtreg to make '@library >>>> /test/lib' work? >>>> At the moment jtreg can't locate it unless I specify >>>> '/../../test/lib/share/classes'. >>>> >>>> Does it make sense to also move ClassFileInstaller to jdk.test.lib? >>>> >>>> >>>> Thanks, >>>> Filipp. >>>> >>>>> >>>>> otherwise looks good to me. >>>>> >>>>> Thanks, >>>>> ? Igor >>>>> >>>>>> On Dec 22, 2015, at 10:36 AM, Filipp Zhinkin wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> please review a small change that adds VM mode checking methods to >>>>>> jdk.test.lib.Platform. >>>>>> I didn't touch Platform class from hotspot/test/testlibrary, because >>>>>> it is already deprecated and at some point of time all hs tests will >>>>>> be updated to use j.t.l.Platform instead. >>>>>> Update of hs tests that use own logic to check VM mode is tracked by >>>>>> JDK-8145848 [1]. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 >>>>>> Testing: on local machine with different VM modes. >>>>>> >>>>>> Regards, >>>>>> Filipp. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8145848 >>>>> >>> From erik.helin at oracle.com Mon Jan 18 17:11:08 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 18 Jan 2016 18:11:08 +0100 Subject: RFR: 8147012: Fix includes in internalVMTests.cpp Message-ID: <20160118171108.GA25049@ehelin.jrpg.bea.com> Hi all, this patch fixes the includes in src/share/vm/utilities/internalVMTests.cpp - all test functions should be declared using "forward declarations" [0] to ensure fast compilation and also enable an better `run_unit_test` macro (this will be introduced in a future patch). The patch is touches quite a few files but it is easy to verify the changes per file and internalVMTests.cpp. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8147012 Webrev: http://cr.openjdk.java.net/~ehelin/8147012/00/ Testing: - Running `make test-hotspot-internal` locally on Linux x86-64 - JPRT Thanks, Erik [0]: https://en.wikipedia.org/wiki/Forward_declaration From filipp.zhinkin at gmail.com Tue Jan 19 07:32:14 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Tue, 19 Jan 2016 10:32:14 +0300 Subject: RFR (S): JDK-8066599: Add methods to check VM mode to c.o.j.t.Platform In-Reply-To: <6B22808F-2CD4-4E2C-AC47-C51B04C4AD13@oracle.com> References: <4CE12B2E-FDEF-48E0-AA84-E410DC09CE53@oracle.com> <6B22808F-2CD4-4E2C-AC47-C51B04C4AD13@oracle.com> Message-ID: Igor, thanks for the review and integration! Filipp. On Mon, Jan 18, 2016 at 6:27 PM, Igor Ignatyev wrote: > Filipp, > > no, I think all of them can be done later and separately, however I?d really appreciate if you help us w/ some of them. > > I?ll integrate your patch from [1] shortly. > > [1] http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ > > Thanks, > Igor > >> On Jan 11, 2016, at 2:07 PM, Filipp Zhinkin wrote: >> >> Igor, >> >> So, do you want me to include any other changes for this CR? >> >> Regards, >> Filipp. >> >> On Wed, Jan 6, 2016 at 4:00 PM, Filipp Zhinkin wrote: >>> Hi Igor, >>> >>> here are RFEs for tests relocation and ClassFileInstaller relocation: >>> https://bugs.openjdk.java.net/browse/JDK-8146549 >>> https://bugs.openjdk.java.net/browse/JDK-8146550 >>> >>> Thanks, >>> Filipp. >>> >>> On Sat, Jan 2, 2016 at 2:59 PM, Igor Ignatyev wrote: >>>> Hi Filipp, >>>> >>>> there is no options to make ?@library /test/lib? works. there is ?external.lib.roots? property in TEST.ROOT files, which adds additional root for @library. I noticed that there is no /test/lib-test isn?t a part of any test-suites, hence moving test to test/lib-test implies extra work in infra. given that I think it?ll be better to do it lately and separately from 8066599. please file an RFE for that. >>>> >>>> on 2nd question, I think it makes sense to move ClassFileInstaller to jdk.test.lib and annotate ClassFileInstaller in both jdk/test/lib/testlibrary/ and hotspot/test/testlibrary/ w/ @Deprectate. and I also think it?d be better to do it separately. >>>> >>>> Thanks, >>>> Igor >>>> >>>>> On Dec 25, 2015, at 12:41 PM, Filipp Zhinkin wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> thanks for looking at this change. >>>>> >>>>> On Thu, Dec 24, 2015 at 9:24 PM, Igor Ignatyev wrote: >>>>>> Hi Filipp, >>>>>> >>>>>> could you please move TestMutuallyExclusivePlatformPredicates and TestPlatformIsTieredSupported from hotspot/testlibrary_tests/ to test/lib-test and update it according to your changes? please note that we started to use packages in our tests. >>>>> >>>>> Sure, I'll move it. >>>>> >>>>> Do I need to pass any specific options to jtreg to make '@library >>>>> /test/lib' work? >>>>> At the moment jtreg can't locate it unless I specify >>>>> '/../../test/lib/share/classes'. >>>>> >>>>> Does it make sense to also move ClassFileInstaller to jdk.test.lib? >>>>> >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>>> >>>>>> otherwise looks good to me. >>>>>> >>>>>> Thanks, >>>>>> ? Igor >>>>>> >>>>>>> On Dec 22, 2015, at 10:36 AM, Filipp Zhinkin wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> please review a small change that adds VM mode checking methods to >>>>>>> jdk.test.lib.Platform. >>>>>>> I didn't touch Platform class from hotspot/test/testlibrary, because >>>>>>> it is already deprecated and at some point of time all hs tests will >>>>>>> be updated to use j.t.l.Platform instead. >>>>>>> Update of hs tests that use own logic to check VM mode is tracked by >>>>>>> JDK-8145848 [1]. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066599/webrev.00/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066599 >>>>>>> Testing: on local machine with different VM modes. >>>>>>> >>>>>>> Regards, >>>>>>> Filipp. >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8145848 >>>>>> >>>> > From mikael.gerdin at oracle.com Tue Jan 19 07:41:46 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Jan 2016 08:41:46 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: References: <569926B9.4070806@oracle.com> Message-ID: <569DE8BA.4000809@oracle.com> Hi Volker, On 2016-01-18 11:53, Volker Simonis wrote: > Hi Mikael, > > your change builds and runs fine on ppc64. Thanks for testing the changes. /Mikael > > > Thanks for considering ppc64 in your patch, > Volker > > > On Fri, Jan 15, 2016 at 6:04 PM, Mikael Gerdin wrote: >> Hi all, >> >> As per the previous discussion in mid-December[0] about moving the >> _vtable_length field to class Klass, here's the first RFR and webrev, >> according to my suggested plan[1]: >> >>> My current plan is to first modify the vtable_length_offset accessor to >>> return a byte offset (which is what it's translated to by all callers). >>> >>> Then I'll tackle moving the _vtable_len field to Klass. >>> >>> Finally I'll try to consolidate the vtable related methods to Klass, >>> where they belong. >> >> >> This change actually consists of three changes: >> * modifying InstanceKlass::vtable_length_offset to become a byte offset and >> use the ByteSize type to communicate the scaling. >> * modifying InstanceKlass::vtable_start_offset to become a byte offset and >> use the ByteSize type, for symmetry reasons mainly. >> * adding a vtableEntry::size_in_bytes() since in many places the vtable >> entry size is used in combination with the vtable start to compute a byte >> offset for vtable lookups. >> >> I don't foresee any issues with the fact that the byte offset is represented >> as an int, for two reasons: >> 1) If the offset of any of these grows to over 2 gigabytes then we have a >> huge footprint problem with InstanceKlass >> 2) The offsets are converted to byte offsets and stored in ints already in >> the cpu specific code I've modified. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >> >> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and PPC64 >> would be much appreciated, appropriate mailing lists have been CC:ed to >> notify them of the request. >> >> >> [0] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >> >> Thanks! >> /Mikael From stefan.karlsson at oracle.com Tue Jan 19 07:48:11 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 19 Jan 2016 08:48:11 +0100 Subject: RFR: 8147012: Fix includes in internalVMTests.cpp In-Reply-To: <20160118171108.GA25049@ehelin.jrpg.bea.com> References: <20160118171108.GA25049@ehelin.jrpg.bea.com> Message-ID: <569DEA3B.9070401@oracle.com> Hi Erik, Looks fine to me. StefanK On 2016-01-18 18:11, Erik Helin wrote: > Hi all, > > this patch fixes the includes in > src/share/vm/utilities/internalVMTests.cpp - all test functions should be > declared using "forward declarations" [0] to ensure fast compilation and > also enable an better `run_unit_test` macro (this will be introduced in a > future patch). > > The patch is touches quite a few files but it is easy to verify the > changes per file and internalVMTests.cpp. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8147012 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8147012/00/ > > Testing: > - Running `make test-hotspot-internal` locally on Linux x86-64 > - JPRT > > Thanks, > Erik > > [0]: https://en.wikipedia.org/wiki/Forward_declaration From mikael.gerdin at oracle.com Tue Jan 19 09:28:43 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Jan 2016 10:28:43 +0100 Subject: RFR: 8147012: Fix includes in internalVMTests.cpp In-Reply-To: <20160118171108.GA25049@ehelin.jrpg.bea.com> References: <20160118171108.GA25049@ehelin.jrpg.bea.com> Message-ID: <569E01CB.5070003@oracle.com> Hi Erik, On 2016-01-18 18:11, Erik Helin wrote: > Hi all, > > this patch fixes the includes in > src/share/vm/utilities/internalVMTests.cpp - all test functions should be > declared using "forward declarations" [0] to ensure fast compilation and > also enable an better `run_unit_test` macro (this will be introduced in a > future patch). > > The patch is touches quite a few files but it is easy to verify the > changes per file and internalVMTests.cpp. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8147012 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8147012/00/ Looks good to me. /Mikael > > Testing: > - Running `make test-hotspot-internal` locally on Linux x86-64 > - JPRT > > Thanks, > Erik > > [0]: https://en.wikipedia.org/wiki/Forward_declaration > From erik.helin at oracle.com Tue Jan 19 10:00:11 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 19 Jan 2016 11:00:11 +0100 Subject: RFR: 8147012: Fix includes in internalVMTests.cpp In-Reply-To: <569E01CB.5070003@oracle.com> References: <20160118171108.GA25049@ehelin.jrpg.bea.com> <569E01CB.5070003@oracle.com> Message-ID: <20160119100011.GC25049@ehelin.jrpg.bea.com> On 2016-01-19, Mikael Gerdin wrote: > Hi Erik, > > On 2016-01-18 18:11, Erik Helin wrote: > >Hi all, > > > >this patch fixes the includes in > >src/share/vm/utilities/internalVMTests.cpp - all test functions should be > >declared using "forward declarations" [0] to ensure fast compilation and > >also enable an better `run_unit_test` macro (this will be introduced in a > >future patch). > > > >The patch is touches quite a few files but it is easy to verify the > >changes per file and internalVMTests.cpp. > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8147012 > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8147012/00/ > > Looks good to me. Thanks! Erik > /Mikael > > > > >Testing: > >- Running `make test-hotspot-internal` locally on Linux x86-64 > >- JPRT > > > >Thanks, > >Erik > > > >[0]: https://en.wikipedia.org/wiki/Forward_declaration > > > > From erik.helin at oracle.com Tue Jan 19 10:00:22 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 19 Jan 2016 11:00:22 +0100 Subject: RFR: 8147012: Fix includes in internalVMTests.cpp In-Reply-To: <569DEA3B.9070401@oracle.com> References: <20160118171108.GA25049@ehelin.jrpg.bea.com> <569DEA3B.9070401@oracle.com> Message-ID: <20160119100022.GD25049@ehelin.jrpg.bea.com> On 2016-01-19, Stefan Karlssson wrote: > Hi Erik, > > Looks fine to me. Thanks! Erik > StefanK > > On 2016-01-18 18:11, Erik Helin wrote: > >Hi all, > > > >this patch fixes the includes in > >src/share/vm/utilities/internalVMTests.cpp - all test functions should be > >declared using "forward declarations" [0] to ensure fast compilation and > >also enable an better `run_unit_test` macro (this will be introduced in a > >future patch). > > > >The patch is touches quite a few files but it is easy to verify the > >changes per file and internalVMTests.cpp. > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8147012 > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8147012/00/ > > > >Testing: > >- Running `make test-hotspot-internal` locally on Linux x86-64 > >- JPRT > > > >Thanks, > >Erik > > > >[0]: https://en.wikipedia.org/wiki/Forward_declaration > From edward.nevill at gmail.com Tue Jan 19 10:07:05 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 19 Jan 2016 10:07:05 +0000 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569926B9.4070806@oracle.com> References: <569926B9.4070806@oracle.com> Message-ID: <1453198025.25458.8.camel@mylittlepony.linaroharston> Hi Mikael, I tried a release and fastdebug build on aarch64. The release build builds fine and passes a basic smoke test but the fastdebug build fails with the following errors. /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp: In static member function 'static void CompilerToVM::Data::initialize()': /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp:153:37: error: cannot convert 'ByteSize' to 'int' in assignment InstanceKlass_vtable_start_offset = InstanceKlass::vtable_start_offset(); ^ /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp:154:38: error: cannot convert 'ByteSize' to 'int' in assignment InstanceKlass_vtable_length_offset = InstanceKlass::vtable_length_offset() * HeapWordSize; ^ After fixing these the fastdebug build completed and passed the same basic tests. All the best, Ed. On Fri, 2016-01-15 at 18:04 +0100, Mikael Gerdin wrote: > Hi all, > > As per the previous discussion in mid-December[0] about moving the > _vtable_length field to class Klass, here's the first RFR and webrev, > according to my suggested plan[1]: > > > My current plan is to first modify the vtable_length_offset accessor to > > return a byte offset (which is what it's translated to by all callers). > > > > Then I'll tackle moving the _vtable_len field to Klass. > > > > Finally I'll try to consolidate the vtable related methods to Klass, > > where they belong. > > This change actually consists of three changes: > * modifying InstanceKlass::vtable_length_offset to become a byte offset > and use the ByteSize type to communicate the scaling. > * modifying InstanceKlass::vtable_start_offset to become a byte offset > and use the ByteSize type, for symmetry reasons mainly. > * adding a vtableEntry::size_in_bytes() since in many places the vtable > entry size is used in combination with the vtable start to compute a > byte offset for vtable lookups. > > I don't foresee any issues with the fact that the byte offset is > represented as an int, for two reasons: > 1) If the offset of any of these grows to over 2 gigabytes then we have > a huge footprint problem with InstanceKlass > 2) The offsets are converted to byte offsets and stored in ints already > in the cpu specific code I've modified. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 > Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ > > Testing: JPRT on Oracle supported platforms, testing on AARCH64 and > PPC64 would be much appreciated, appropriate mailing lists have been > CC:ed to notify them of the request. > > > [0] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html > > Thanks! > /Mikael From mikael.gerdin at oracle.com Tue Jan 19 10:27:58 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Jan 2016 11:27:58 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <1453198025.25458.8.camel@mylittlepony.linaroharston> References: <569926B9.4070806@oracle.com> <1453198025.25458.8.camel@mylittlepony.linaroharston> Message-ID: <569E0FAE.8020305@oracle.com> Hi Edward, On 2016-01-19 11:07, Edward Nevill wrote: > Hi Mikael, > > I tried a release and fastdebug build on aarch64. The release build builds fine and passes a basic smoke test but the fastdebug build fails with the following errors. > > /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp: In static member function 'static void CompilerToVM::Data::initialize()': > /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp:153:37: error: cannot convert 'ByteSize' to 'int' in assignment > InstanceKlass_vtable_start_offset = InstanceKlass::vtable_start_offset(); > ^ > /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp:154:38: error: cannot convert 'ByteSize' to 'int' in assignment > InstanceKlass_vtable_length_offset = InstanceKlass::vtable_length_offset() * HeapWordSize; > ^ > After fixing these the fastdebug build completed and passed the same basic tests. Thanks for testing! As to the compilation failures this is probably due to me creating the patch before hs-comp was merged into hs-rt. I'll rebase it and fix the jvmci issue. /Mikael > > All the best, > Ed. > > On Fri, 2016-01-15 at 18:04 +0100, Mikael Gerdin wrote: >> Hi all, >> >> As per the previous discussion in mid-December[0] about moving the >> _vtable_length field to class Klass, here's the first RFR and webrev, >> according to my suggested plan[1]: >> >>> My current plan is to first modify the vtable_length_offset accessor to >>> return a byte offset (which is what it's translated to by all callers). >>> >>> Then I'll tackle moving the _vtable_len field to Klass. >>> >>> Finally I'll try to consolidate the vtable related methods to Klass, >>> where they belong. >> >> This change actually consists of three changes: >> * modifying InstanceKlass::vtable_length_offset to become a byte offset >> and use the ByteSize type to communicate the scaling. >> * modifying InstanceKlass::vtable_start_offset to become a byte offset >> and use the ByteSize type, for symmetry reasons mainly. >> * adding a vtableEntry::size_in_bytes() since in many places the vtable >> entry size is used in combination with the vtable start to compute a >> byte offset for vtable lookups. >> >> I don't foresee any issues with the fact that the byte offset is >> represented as an int, for two reasons: >> 1) If the offset of any of these grows to over 2 gigabytes then we have >> a huge footprint problem with InstanceKlass >> 2) The offsets are converted to byte offsets and stored in ints already >> in the cpu specific code I've modified. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >> >> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >> PPC64 would be much appreciated, appropriate mailing lists have been >> CC:ed to notify them of the request. >> >> >> [0] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >> >> Thanks! >> /Mikael > > From coleen.phillimore at oracle.com Tue Jan 19 15:47:23 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 19 Jan 2016 10:47:23 -0500 Subject: RFR: 8147012: Fix includes in internalVMTests.cpp In-Reply-To: <20160118171108.GA25049@ehelin.jrpg.bea.com> References: <20160118171108.GA25049@ehelin.jrpg.bea.com> Message-ID: <569E5A8B.8030909@oracle.com> This looks good to me also, thanks for moving the internal tests, and the last one I added. Coleen On 1/18/16 12:11 PM, Erik Helin wrote: > Hi all, > > this patch fixes the includes in > src/share/vm/utilities/internalVMTests.cpp - all test functions should be > declared using "forward declarations" [0] to ensure fast compilation and > also enable an better `run_unit_test` macro (this will be introduced in a > future patch). > > The patch is touches quite a few files but it is easy to verify the > changes per file and internalVMTests.cpp. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8147012 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8147012/00/ > > Testing: > - Running `make test-hotspot-internal` locally on Linux x86-64 > - JPRT > > Thanks, > Erik > > [0]: https://en.wikipedia.org/wiki/Forward_declaration From ktruong.nguyen at gmail.com Sat Jan 16 01:54:23 2016 From: ktruong.nguyen at gmail.com (Khanh Nguyen) Date: Fri, 15 Jan 2016 17:54:23 -0800 Subject: Off-heap object space Message-ID: Hi, I want to implement an off-heap, non-GC, non-contiguous object space. Of course my naive approach is to call os::malloc or the existing macro AllocateHeap(). Also I did turn the compressed oops flags off. But I'm facing this undeterministic issue: randomly the JVM crashes. That is, sometimes my program can successfully run (with the correct result). And sometimes it crashes (in library code) Partial crash log is this: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fd71102681d, pid=6741, tid=140562059818752 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-debug-khanhtn1_2016_01_15_17_06-b00) # Java VM: OpenJDK 64-Bit Server VM (25.0-b70-debug interpreted mode linux-amd64 ) # Problematic frame: # j java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 # # Core dump written. Default location: /lv_scratch/scratch/khanh/openjdk8/core or core.6741 # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00007fd72000a800): JavaThread "main" [_thread_in_Java, id=6742, stack(0x00007fd72794f000,0x00007fd727a50000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), si_addr=0x00007fd723ee00be Registers: RAX=0x00007fd6110fc818, RBX=0x00007fd0ae129248, RCX=0x0000000000000000, RDX=0x0000003fe88800be RSP=0x00007fd727a4e428, RBP=0x00007fd727a4e480, RSI=0x00007fd727a4e3b8, RDI=0x0000000001200020 R8 =0x0000000000000000, R9 =0x0000000000000024, R10=0x00007f973b660000, R11=0x00007fd727a4e390 R12=0x00007fd711000564, R13=0x00007fd0ae124bb3, R14=0x00007fd727a4e4f0, R15=0x00007fd72000a800 RIP=0x00007fd71102681d, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 TRAPNO=0x000000000000000e Stack: [0x00007fd72794f000,0x00007fd727a50000], sp=0x00007fd727a4e428, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 j java.util.HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+9 j EmptyMethod.generateHashMap()Ljava/util/HashMap;+44 j EmptyMethod.runTest(I)V+24 j EmptyMethod.main([Ljava/lang/String;)V+97 v ~StubRoutines::call_stub V [libjvm.so+0x823762] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x680 V [libjvm.so+0xaaae44] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x3a V [libjvm.so+0x8230db] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x7d V [libjvm.so+0x837185] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x1ca V [libjvm.so+0x84d31e] jni_CallStaticVoidMethod+0x385 C [libjli.so+0x8012] JavaMain+0x89a --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x00007fd72014c000 JavaThread "Service Thread" daemon [_thread_blocked, id=6765, stack(0x00007fd0a9e37000,0x00007fd0a9f38000)] 0x00007fd720142800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=6764, stack(0x00007fd0a9f38000,0x00007fd0aa039000)] 0x00007fd7200e9000 JavaThread "Finalizer" daemon [_thread_blocked, id=6763, stack(0x00007fd110058000,0x00007fd110159000)] 0x00007fd7200e6800 JavaThread "Reference Handler" daemon [_thread_blocked, id=6762, stack(0x00007fd0aa039000,0x00007fd0aa13a000)] =>0x00007fd72000a800 JavaThread "main" [_thread_in_Java, id=6742, stack(0x00007fd72794f000,0x00007fd727a50000)] Other Threads: 0x00007fd7200db800 VMThread [stack: 0x00007fd0aa13a000,0x00007fd0aa23b000] [id=6761] 0x00007fd720150000 WatcherThread [stack: 0x00007fd0a9d36000,0x00007fd0a9e37000] [id=6766] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap: PSYoungGen total 5120K, used 2088K [0x00007fd611000000, 0x00007fd611b00000, 0x00007fd711000000) eden space 4096K, 25% used [0x00007fd611000000,0x00007fd61110a278,0x00007fd611400000) from space 1024K, 100% used [0x00007fd611400000,0x00007fd611500000,0x00007fd611500000) to space 1536K, 0% used [0x00007fd611980000,0x00007fd611980000,0x00007fd611b00000) ParOldGen total 512512K, used 1128K [0x00007fd411000000, 0x00007fd430480000, 0x00007fd611000000) object space 512512K, 0% used [0x00007fd411000000,0x00007fd41111a0c0,0x00007fd430480000) Metaspace used 3255K, capacity 4108K, committed 4352K, reserved 8192K Card table byte_map: [0x00007fd7256e8000,0x00007fd726ee9000] byte_map_base: 0x00007f973b660000 Marking Bits: (ParMarkBitMap*) 0x00007fd728f79340 Begin Bits: [0x00007fd0b0000000, 0x00007fd0bc000000) End Bits: [0x00007fd0bc000000, 0x00007fd0c8000000) Polling page: 0x00007fd7291f5000 CodeCache: size=245760Kb used=1439Kb max_used=1439Kb free=244320Kb bounds [0x00007fd711000000, 0x00007fd711270000, 0x00007fd720000000] total_blobs=189 nmethods=0 adapters=164 compilation: disabled (interpreter mode) Using gdb doesn't show anything interesting unfortunately #2 0x00007fd023d393a3 in os::abort (dump_core=true) at /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:1563 #3 0x00007fd023efacdd in VMError::report_and_die (this=0x7fd023293d00) at /scratch/khanh/openjdk8/hotspot/src/share/vm/utilities/vmError.cpp:1078 #4 0x00007fd023d453d9 in JVM_handle_linux_signal (sig=11, info=0x7fd023293fb0, ucVoid=0x7fd023293e80, abort_if_unrecognized=1) at /scratch/khanh/openjdk8/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:534 #5 0x00007fd023d3eebf in signalHandler (sig=11, info=0x7fd023293fb0, uc=0x7fd023293e80) at /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4278 #6 #7 0x00007fd00d02681d in ?? () #8 0x00007fcf0d0feee0 in ?? () #9 0x0000000000000002 in ?? () #10 0x00007fc9e95c9c58 in ?? () #11 0x00007fd023294440 in ?? () #12 0x00007fca09c71bb0 in ?? () #13 0x00007fd0232944f0 in ?? () #14 0x00007fca09c74e30 in ?? () #15 0x0000000000000000 in ?? () So my questions, specifically, are 1) Why SEGV_ACCERR? And any idea of where the problem might be? 2) In theory, it should be straightforward for me to have an off-heap space where I can allocate objects in. I don't understand why there is a random crash like what I have. I mean if I violate some implicit rules in Hotspot, my program should fail always. Any pointers/suggestions are greatly appreciated. Thank you, From aph at redhat.com Tue Jan 19 16:15:02 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Jan 2016 16:15:02 +0000 Subject: PING: 8146709: AArch64: Incorrect use of ADRP for byte_map_base In-Reply-To: <5693C7AB.90103@redhat.com> References: <5693C7AB.90103@redhat.com> Message-ID: <569E6106.3090603@redhat.com> Need an official JDK9 reviewer, please. Andrew. -------------- next part -------------- An embedded message was scrubbed... From: Andrew Haley Subject: RFR: 8146709: AArch64: Incorrect use of ADRP for byte_map_base Date: Mon, 11 Jan 2016 15:18:03 +0000 Size: 4562 URL: From roland.westrelin at oracle.com Tue Jan 19 16:18:04 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Jan 2016 17:18:04 +0100 Subject: RFR: 8146709: AArch64: Incorrect use of ADRP for byte_map_base In-Reply-To: <5693C7AB.90103@redhat.com> References: <5693C7AB.90103@redhat.com> Message-ID: <884EC0E7-121E-4483-9FC5-20CF78EC141C@oracle.com> > http://cr.openjdk.java.net/~aph/8146709-2/ Looks good to me. Roland. From alejandro.murillo at oracle.com Tue Jan 19 16:48:29 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 19 Jan 2016 09:48:29 -0700 Subject: [9] RFR 8146653: Debug version missing in hs_err files and on internal version after Verona In-Reply-To: <569989CA.3080208@oracle.com> References: <569969FD.80302@oracle.com> <56996E00.9000104@oracle.com> <56998140.5020205@oracle.com> <569989CA.3080208@oracle.com> Message-ID: <569E68DD.7050703@oracle.com> On 1/15/2016 5:07 PM, Daniel D. Daugherty wrote: > On 1/15/16 4:31 PM, Alejandro E Murillo wrote: >> Hi Dan, thanks a lot for the prompt review > > I figured you wanted this done quickly since it is causing > nightly analysis confusion... :-) > I'll get this in asap. > >> I applied all the changes, revised webrev (with proper links) is here: >> >> http://cr.openjdk.java.net/~amurillo/9/8146653/index.html > > Forgot to remind about updating copyright years in the first round... right. Will fix those > > src/share/vm/runtime/vm_version.hpp > No comments. > > src/share/vm/runtime/vm_version.cpp > No comments. > > src/share/vm/utilities/vmError.cpp > No comments. > > Thumbs up! Thanks Alejandro > > Dan > > > >> >> Thanks >> Alejandro >> >> On 1/15/2016 3:09 PM, Daniel D. Daugherty wrote: >>> On 1/15/16 2:51 PM, Alejandro E Murillo wrote: >>>> >>>> Please review the following fix for JDK-8146653 >>>> : >>>> Debug version missing in hs_err files and on internal version after >>>> Verona >>>> >>>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8146653/ >>> >>> Your version of webrev generated broken nav links for >>> the "frames" version. Shows 404... >>> >>> >>> src/share/vm/runtime/vm_version.cpp >>> L242: return strcmp(DEBUG_LEVEL, "release") ? >>> L243: VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX >>> L244: : >>> L245: VMNAME " (" INTERNAL_VERSION_SUFFIX; >>> >>> No implied booleans on this part: strcmp(DEBUG_LEVEL, >>> "release") >>> >>> Also I think this would be more HotSpot style: >>> >>> return strcmp(DEBUG_LEVEL, "release") == 0 >>> ? VMNAME " (" INTERNAL_VERSION_SUFFIX >>> : VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX; >>> >>> where the "usual case" is first and the indenting is more >>> HotSpot like... >>> >>> L258: return strcmp(DEBUG_LEVEL, "release") ? DEBUG_LEVEL " " >>> : ""; >>> >>> Similarly here: >>> >>> return strcmp(DEBUG_LEVEL, "release") == 0 ? "" : DEBUG_LEVEL; >>> >>> src/share/vm/runtime/vm_version.hpp >>> No comments. >>> >>> src/share/vm/utilities/vmError.cpp >>> L234: const char* runtime_version = >>> JDK_Version::runtime_version() != NULL ? >>> L235: JDK_Version::runtime_version() : ""; >>> L236: const char* jdk_debug_level = >>> Abstract_VM_Version::alternate_jdk_debug_level() != NULL ? >>> L237: Abstract_VM_Version::alternate_jdk_debug_level() : ""; >>> >>> L237 indent needs three more spaces. So does L235, but that's >>> not your issue. >>> >>> L239: st->print_cr("# JRE version: %s (%s) (%sbuild %s)", >>> runtime_name, buf, >>> L240: jdk_debug_level, runtime_version); >>> >>> L240 indent has one too many spaces. >>> >>> Dan >>> >>>> >>>> Background: >>>> Verona removed the debug info from version related system >>>> properties and that's now specified on a new system property called >>>> jdk.debug. >>>> The version header spitted in hs_err files was updated to include >>>> debug info based on that change. >>>> That info was also missing on the output for -Xinternalversion >>>> >>>> Thanks >>>> >>> >> > -- Alejandro From alejandro.murillo at oracle.com Tue Jan 19 17:05:16 2016 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 19 Jan 2016 10:05:16 -0700 Subject: [9] RFR 8146653: Debug version missing in hs_err files and on internal version after Verona In-Reply-To: <569C64A5.1020904@oracle.com> References: <569969FD.80302@oracle.com> <56996E00.9000104@oracle.com> <56998140.5020205@oracle.com> <569C64A5.1020904@oracle.com> Message-ID: <569E6CCC.8040508@oracle.com> On 1/17/2016 9:05 PM, David Holmes wrote: > Hi Alejandro, > > On 16/01/2016 9:31 AM, Alejandro E Murillo wrote: >> >> Hi Dan, thanks a lot for the prompt review >> I applied all the changes, revised webrev (with proper links) is here: >> >> http://cr.openjdk.java.net/~amurillo/9/8146653/index.html > > Seeing this all together now I don't think alternate_jdk_debug_level > warrants being added to Abstract_VM_version. The logic could be used > directly inline in VMError.cpp. If it were used more than once then > perhaps ... though printable_jdk_debug_level might be a better name in > that case (still not a great name but better IMHO :) ). Now that you mention it, there's some library code that may also use it. There's also the code to check for not provided, which will have to replicate, so I think I'll keep it. But I'll change the name to "printable" Thanks for this review and the discussion prior to sending this out Alejandro > > Thanks, > David > > >> Thanks >> Alejandro >> >> On 1/15/2016 3:09 PM, Daniel D. Daugherty wrote: >>> On 1/15/16 2:51 PM, Alejandro E Murillo wrote: >>>> >>>> Please review the following fix for JDK-8146653 >>>> : >>>> Debug version missing in hs_err files and on internal version after >>>> Verona >>>> >>>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8146653/ >>> >>> Your version of webrev generated broken nav links for >>> the "frames" version. Shows 404... >>> >>> >>> src/share/vm/runtime/vm_version.cpp >>> L242: return strcmp(DEBUG_LEVEL, "release") ? >>> L243: VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX >>> L244: : >>> L245: VMNAME " (" INTERNAL_VERSION_SUFFIX; >>> >>> No implied booleans on this part: strcmp(DEBUG_LEVEL, >>> "release") >>> >>> Also I think this would be more HotSpot style: >>> >>> return strcmp(DEBUG_LEVEL, "release") == 0 >>> ? VMNAME " (" INTERNAL_VERSION_SUFFIX >>> : VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX; >>> >>> where the "usual case" is first and the indenting is more >>> HotSpot like... >>> >>> L258: return strcmp(DEBUG_LEVEL, "release") ? DEBUG_LEVEL " " >>> : ""; >>> >>> Similarly here: >>> >>> return strcmp(DEBUG_LEVEL, "release") == 0 ? "" : DEBUG_LEVEL; >>> >>> src/share/vm/runtime/vm_version.hpp >>> No comments. >>> >>> src/share/vm/utilities/vmError.cpp >>> L234: const char* runtime_version = >>> JDK_Version::runtime_version() != NULL ? >>> L235: JDK_Version::runtime_version() : ""; >>> L236: const char* jdk_debug_level = >>> Abstract_VM_Version::alternate_jdk_debug_level() != NULL ? >>> L237: Abstract_VM_Version::alternate_jdk_debug_level() : ""; >>> >>> L237 indent needs three more spaces. So does L235, but that's >>> not your issue. >>> >>> L239: st->print_cr("# JRE version: %s (%s) (%sbuild %s)", >>> runtime_name, buf, >>> L240: jdk_debug_level, runtime_version); >>> >>> L240 indent has one too many spaces. >>> >>> Dan >>> >>>> >>>> Background: >>>> Verona removed the debug info from version related system properties >>>> and that's now specified on a new system property called jdk.debug. >>>> The version header spitted in hs_err files was updated to include >>>> debug info based on that change. >>>> That info was also missing on the output for -Xinternalversion >>>> >>>> Thanks >>>> >>> >> -- Alejandro From jesper.wilhelmsson at oracle.com Tue Jan 19 17:51:24 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Jan 2016 18:51:24 +0100 Subject: jdk9/hs-rt is CLOSED due to stabilization effort Message-ID: <569E779C.2000107@oracle.com> Hi, TLDR; We are closing jdk9/hs-rt for any pushes not related to fixing the bugs mentioned below. Since we are many developers working in jdk9/hs-rt these days it has proven challenging to find a nightly snapshot that passes the criteria [1] to be integrated into jdk9/hs. Currently there are three issues that has escaped to main and these needs to get fixed asap for us to be able to push jdk9/hs to jdk9/dev: JDK-8146751 - jdk/test/tools/launcher/TooSmallStackSize.java failed on Mac OS JDK-8147477 - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing for the jdk9/hs snapshot control job JDK-8146449 - Use unified logging for stacktrace event tests There is an increasing pile of changes in jdk9/hs (150+) so it is getting urgent to integrate. To be able to get these fixes in to jdk9/hs we need to get a clean hs-rt to push. Currently there are four bugs labeled integration blockers [2]: JDK-8147494 - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does not exist" JDK-8147481 - VM crash fatal error: corrupted C heap JDK-8147477 - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing for the jdk9/hs snapshot control job JDK-8147475 - compiler/jvmci/code/SimpleDebugInfoTest.java fails in Assembler::locate_operand: ShouldNotReachHere() (One is actually the same as in main.) To be able to get fixes for these issues in asap without risking introducing new failures we need to close hs-rt for all pushes. So, please do not push any changes not directly related to fixing the issues above to jdk9/hs-rt before further notice. Thanks, /Jesper [1] The criteria to integrate new changes into main is that there can not be any new bugs introduced by these new changes. We say that there are no new bugs if a change passes two nightlies without making any noise. [2] https://bugs.openjdk.java.net/issues/?filter=24183 From daniel.daugherty at oracle.com Tue Jan 19 19:29:53 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jan 2016 12:29:53 -0700 Subject: jdk9/hs-rt is CLOSED due to stabilization effort In-Reply-To: <569E779C.2000107@oracle.com> References: <569E779C.2000107@oracle.com> Message-ID: <569E8EB1.5050307@oracle.com> In an effort to clear the integration_blocker bugs that apply to Alejandro's 2016.01.14 snapshot, I'm pushing the following fix to JDK9-hs right now: JDK-8147629 quarantine tests failing in 2016.01.14 PIT snapshot https://bugs.openjdk.java.net/browse/JDK-8147629 This should take care of the current integration_blockers that apply to Alejandro's 2016.01.14 snapshot. This does not address the integration_blockers that apply to JDK9-hs-rt. Dan On 1/19/16 10:51 AM, Jesper Wilhelmsson wrote: > Hi, > > TLDR; We are closing jdk9/hs-rt for any pushes not related to fixing > the bugs mentioned below. > > > Since we are many developers working in jdk9/hs-rt these days it has > proven challenging to find a nightly snapshot that passes the criteria > [1] to be integrated into jdk9/hs. > > Currently there are three issues that has escaped to main and these > needs to get fixed asap for us to be able to push jdk9/hs to jdk9/dev: > > JDK-8146751 - jdk/test/tools/launcher/TooSmallStackSize.java failed on > Mac OS > > JDK-8147477 - > com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing > for the jdk9/hs snapshot control job > > JDK-8146449 - Use unified logging for stacktrace event tests > > > There is an increasing pile of changes in jdk9/hs (150+) so it is > getting urgent to integrate. To be able to get these fixes in to > jdk9/hs we need to get a clean hs-rt to push. Currently there are four > bugs labeled integration blockers [2]: > > JDK-8147494 - > com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with > "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does > not exist" > > JDK-8147481 - VM crash fatal error: corrupted C heap > > JDK-8147477 - > com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is failing > for the jdk9/hs snapshot control job > > JDK-8147475 - compiler/jvmci/code/SimpleDebugInfoTest.java fails in > Assembler::locate_operand: ShouldNotReachHere() > > > (One is actually the same as in main.) > > To be able to get fixes for these issues in asap without risking > introducing new failures we need to close hs-rt for all pushes. > > So, please do not push any changes not directly related to fixing the > issues above to jdk9/hs-rt before further notice. > > Thanks, > /Jesper > > > [1] The criteria to integrate new changes into main is that there can > not be any new bugs introduced by these new changes. We say that there > are no new bugs if a change passes two nightlies without making any > noise. > > [2] https://bugs.openjdk.java.net/issues/?filter=24183 From jesper.wilhelmsson at oracle.com Tue Jan 19 20:18:06 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Jan 2016 21:18:06 +0100 Subject: jdk9/hs-rt is CLOSED due to stabilization effort In-Reply-To: <569E8EB1.5050307@oracle.com> References: <569E779C.2000107@oracle.com> <569E8EB1.5050307@oracle.com> Message-ID: <569E99FE.9060601@oracle.com> Thanks Dan! That releases the pressure on hs-rt somewhat but we will keep it closed until we have a snapshot that we can push. /Jesper Den 19/1/16 kl. 20:29, skrev Daniel D. Daugherty: > In an effort to clear the integration_blocker bugs that apply to > Alejandro's 2016.01.14 snapshot, I'm pushing the following fix to > JDK9-hs right now: > > JDK-8147629 quarantine tests failing in 2016.01.14 PIT snapshot > https://bugs.openjdk.java.net/browse/JDK-8147629 > > This should take care of the current integration_blockers that > apply to Alejandro's 2016.01.14 snapshot. This does not address > the integration_blockers that apply to JDK9-hs-rt. > > Dan > > > > On 1/19/16 10:51 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> TLDR; We are closing jdk9/hs-rt for any pushes not related to fixing the bugs >> mentioned below. >> >> >> Since we are many developers working in jdk9/hs-rt these days it has proven >> challenging to find a nightly snapshot that passes the criteria [1] to be >> integrated into jdk9/hs. >> >> Currently there are three issues that has escaped to main and these needs to >> get fixed asap for us to be able to push jdk9/hs to jdk9/dev: >> >> JDK-8146751 - jdk/test/tools/launcher/TooSmallStackSize.java failed on Mac OS >> >> JDK-8147477 - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is >> failing for the jdk9/hs snapshot control job >> >> JDK-8146449 - Use unified logging for stacktrace event tests >> >> >> There is an increasing pile of changes in jdk9/hs (150+) so it is getting >> urgent to integrate. To be able to get these fixes in to jdk9/hs we need to >> get a clean hs-rt to push. Currently there are four bugs labeled integration >> blockers [2]: >> >> JDK-8147494 - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java >> fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' >> does not exist" >> >> JDK-8147481 - VM crash fatal error: corrupted C heap >> >> JDK-8147477 - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is >> failing for the jdk9/hs snapshot control job >> >> JDK-8147475 - compiler/jvmci/code/SimpleDebugInfoTest.java fails in >> Assembler::locate_operand: ShouldNotReachHere() >> >> >> (One is actually the same as in main.) >> >> To be able to get fixes for these issues in asap without risking introducing >> new failures we need to close hs-rt for all pushes. >> >> So, please do not push any changes not directly related to fixing the issues >> above to jdk9/hs-rt before further notice. >> >> Thanks, >> /Jesper >> >> >> [1] The criteria to integrate new changes into main is that there can not be >> any new bugs introduced by these new changes. We say that there are no new >> bugs if a change passes two nightlies without making any noise. >> >> [2] https://bugs.openjdk.java.net/issues/?filter=24183 > From rachel.protacio at oracle.com Tue Jan 19 20:51:57 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 19 Jan 2016 15:51:57 -0500 Subject: RFR (XS): 8147494: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does not exist" Message-ID: <569EA1ED.9090501@oracle.com> Hi, Please review this fix to the jdk test bug. The issue was that the test initialized the now-aliased TraceExceptions flag, then looked for its origin, but because of the aliasing, the test was failing. I substituted a different product option, CheckJNICalls, as it is unlikely to be converted to Unified Logging, and since it allows CheckOrigin to test what it was meant to test. Open webrev: http://cr.openjdk.java.net/~rprotacio/8147494/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147494 This passed local jtreg testing. I'll gladly run other testing on it (JPRT on all platforms?) if someone would be able to give me the command to do so! Thanks, Rachel From daniel.daugherty at oracle.com Tue Jan 19 20:56:39 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jan 2016 13:56:39 -0700 Subject: jdk9/hs-rt is CLOSED due to stabilization effort In-Reply-To: <569E99FE.9060601@oracle.com> References: <569E779C.2000107@oracle.com> <569E8EB1.5050307@oracle.com> <569E99FE.9060601@oracle.com> Message-ID: <569EA307.4000000@oracle.com> On 1/19/16 1:18 PM, Jesper Wilhelmsson wrote: > Thanks Dan! > > That releases the pressure on hs-rt somewhat but we will keep it > closed until we have a snapshot that we can push. Total agreement. That's why I wrote my last sentence: > This does not address > the integration_blockers that apply to JDK9-hs-rt. but I could have been more clear that I concur with closing JDK9-hs-rt. Dan > /Jesper > > Den 19/1/16 kl. 20:29, skrev Daniel D. Daugherty: >> In an effort to clear the integration_blocker bugs that apply to >> Alejandro's 2016.01.14 snapshot, I'm pushing the following fix to >> JDK9-hs right now: >> >> JDK-8147629 quarantine tests failing in 2016.01.14 PIT snapshot >> https://bugs.openjdk.java.net/browse/JDK-8147629 >> >> This should take care of the current integration_blockers that >> apply to Alejandro's 2016.01.14 snapshot. This does not address >> the integration_blockers that apply to JDK9-hs-rt. >> >> Dan >> >> >> >> On 1/19/16 10:51 AM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> TLDR; We are closing jdk9/hs-rt for any pushes not related to fixing >>> the bugs >>> mentioned below. >>> >>> >>> Since we are many developers working in jdk9/hs-rt these days it has >>> proven >>> challenging to find a nightly snapshot that passes the criteria [1] >>> to be >>> integrated into jdk9/hs. >>> >>> Currently there are three issues that has escaped to main and these >>> needs to >>> get fixed asap for us to be able to push jdk9/hs to jdk9/dev: >>> >>> JDK-8146751 - jdk/test/tools/launcher/TooSmallStackSize.java failed >>> on Mac OS >>> >>> JDK-8147477 - >>> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is >>> failing for the jdk9/hs snapshot control job >>> >>> JDK-8146449 - Use unified logging for stacktrace event tests >>> >>> >>> There is an increasing pile of changes in jdk9/hs (150+) so it is >>> getting >>> urgent to integrate. To be able to get these fixes in to jdk9/hs we >>> need to >>> get a clean hs-rt to push. Currently there are four bugs labeled >>> integration >>> blockers [2]: >>> >>> JDK-8147494 - >>> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java >>> fails with "java.lang.IllegalArgumentException: VM option >>> 'TraceExceptions' >>> does not exist" >>> >>> JDK-8147481 - VM crash fatal error: corrupted C heap >>> >>> JDK-8147477 - >>> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java is >>> failing for the jdk9/hs snapshot control job >>> >>> JDK-8147475 - compiler/jvmci/code/SimpleDebugInfoTest.java fails in >>> Assembler::locate_operand: ShouldNotReachHere() >>> >>> >>> (One is actually the same as in main.) >>> >>> To be able to get fixes for these issues in asap without risking >>> introducing >>> new failures we need to close hs-rt for all pushes. >>> >>> So, please do not push any changes not directly related to fixing >>> the issues >>> above to jdk9/hs-rt before further notice. >>> >>> Thanks, >>> /Jesper >>> >>> >>> [1] The criteria to integrate new changes into main is that there >>> can not be >>> any new bugs introduced by these new changes. We say that there are >>> no new >>> bugs if a change passes two nightlies without making any noise. >>> >>> [2] https://bugs.openjdk.java.net/issues/?filter=24183 >> From harold.seigel at oracle.com Tue Jan 19 21:00:08 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 19 Jan 2016 16:00:08 -0500 Subject: RFR (XS): 8147494: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does not exist" In-Reply-To: <569EA1ED.9090501@oracle.com> References: <569EA1ED.9090501@oracle.com> Message-ID: <569EA3D8.80000@oracle.com> Hi Rachel, The fix looks good. Since your fix only changes a test, I don't see the benefit of running additional tests on this change. Harold On 1/19/2016 3:51 PM, Rachel Protacio wrote: > Hi, > > Please review this fix to the jdk test bug. The issue was that the > test initialized the now-aliased TraceExceptions flag, then looked for > its origin, but because of the aliasing, the test was failing. I > substituted a different product option, CheckJNICalls, as it is > unlikely to be converted to Unified Logging, and since it allows > CheckOrigin to test what it was meant to test. > > Open webrev: http://cr.openjdk.java.net/~rprotacio/8147494/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8147494 > > This passed local jtreg testing. I'll gladly run other testing on it > (JPRT on all platforms?) if someone would be able to give me the > command to do so! > > Thanks, > Rachel From rachel.protacio at oracle.com Tue Jan 19 21:02:00 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 19 Jan 2016 16:02:00 -0500 Subject: RFR (XS): 8147494: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does not exist" In-Reply-To: <569EA3D8.80000@oracle.com> References: <569EA1ED.9090501@oracle.com> <569EA3D8.80000@oracle.com> Message-ID: <569EA448.4000701@oracle.com> Hi Harold, Sounds good. Thanks for the review, Rachel On 1/19/2016 4:00 PM, harold seigel wrote: > Hi Rachel, > > The fix looks good. > > Since your fix only changes a test, I don't see the benefit of running > additional tests on this change. > > Harold > > On 1/19/2016 3:51 PM, Rachel Protacio wrote: >> Hi, >> >> Please review this fix to the jdk test bug. The issue was that the >> test initialized the now-aliased TraceExceptions flag, then looked >> for its origin, but because of the aliasing, the test was failing. I >> substituted a different product option, CheckJNICalls, as it is >> unlikely to be converted to Unified Logging, and since it allows >> CheckOrigin to test what it was meant to test. >> >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8147494/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147494 >> >> This passed local jtreg testing. I'll gladly run other testing on it >> (JPRT on all platforms?) if someone would be able to give me the >> command to do so! >> >> Thanks, >> Rachel > From coleen.phillimore at oracle.com Tue Jan 19 21:05:29 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 19 Jan 2016 16:05:29 -0500 Subject: RFR (XS): 8147494: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does not exist" In-Reply-To: <569EA3D8.80000@oracle.com> References: <569EA1ED.9090501@oracle.com> <569EA3D8.80000@oracle.com> Message-ID: <569EA519.5020300@oracle.com> On 1/19/16 4:00 PM, harold seigel wrote: > Hi Rachel, > > The fix looks good. > > Since your fix only changes a test, I don't see the benefit of running > additional tests on this change. I agree with Harold on both points. Coleen > > Harold > > On 1/19/2016 3:51 PM, Rachel Protacio wrote: >> Hi, >> >> Please review this fix to the jdk test bug. The issue was that the >> test initialized the now-aliased TraceExceptions flag, then looked >> for its origin, but because of the aliasing, the test was failing. I >> substituted a different product option, CheckJNICalls, as it is >> unlikely to be converted to Unified Logging, and since it allows >> CheckOrigin to test what it was meant to test. >> >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8147494/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147494 >> >> This passed local jtreg testing. I'll gladly run other testing on it >> (JPRT on all platforms?) if someone would be able to give me the >> command to do so! >> >> Thanks, >> Rachel > From daniel.daugherty at oracle.com Tue Jan 19 21:12:00 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jan 2016 14:12:00 -0700 Subject: RFR (XS): 8147494: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does not exist" In-Reply-To: <569EA519.5020300@oracle.com> References: <569EA1ED.9090501@oracle.com> <569EA3D8.80000@oracle.com> <569EA519.5020300@oracle.com> Message-ID: <569EA6A0.4070206@oracle.com> On 1/19/16 2:05 PM, Coleen Phillimore wrote: > > > On 1/19/16 4:00 PM, harold seigel wrote: >> Hi Rachel, >> >> The fix looks good. >> >> Since your fix only changes a test, I don't see the benefit of >> running additional tests on this change. > > I agree with Harold on both points. Thumbs up on the change. I also concur that the risk of fix is very low. Dan > > Coleen > >> >> Harold >> >> On 1/19/2016 3:51 PM, Rachel Protacio wrote: >>> Hi, >>> >>> Please review this fix to the jdk test bug. The issue was that the >>> test initialized the now-aliased TraceExceptions flag, then looked >>> for its origin, but because of the aliasing, the test was failing. I >>> substituted a different product option, CheckJNICalls, as it is >>> unlikely to be converted to Unified Logging, and since it allows >>> CheckOrigin to test what it was meant to test. >>> >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8147494/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147494 >>> >>> This passed local jtreg testing. I'll gladly run other testing on it >>> (JPRT on all platforms?) if someone would be able to give me the >>> command to do so! >>> >>> Thanks, >>> Rachel >> > From rachel.protacio at oracle.com Tue Jan 19 21:27:33 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 19 Jan 2016 16:27:33 -0500 Subject: RFR (XS): 8147494: com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java fails with "java.lang.IllegalArgumentException: VM option 'TraceExceptions' does not exist" In-Reply-To: <569EA6A0.4070206@oracle.com> References: <569EA1ED.9090501@oracle.com> <569EA3D8.80000@oracle.com> <569EA519.5020300@oracle.com> <569EA6A0.4070206@oracle.com> Message-ID: <569EAA45.8050305@oracle.com> Thanks, Coleen and Dan! I'll go ahead and commit now so we can un-block the issue. Rachel On 1/19/2016 4:12 PM, Daniel D. Daugherty wrote: > On 1/19/16 2:05 PM, Coleen Phillimore wrote: >> >> >> On 1/19/16 4:00 PM, harold seigel wrote: >>> Hi Rachel, >>> >>> The fix looks good. >>> >>> Since your fix only changes a test, I don't see the benefit of >>> running additional tests on this change. >> >> I agree with Harold on both points. > > Thumbs up on the change. > > I also concur that the risk of fix is very low. > > Dan > > >> >> Coleen >> >>> >>> Harold >>> >>> On 1/19/2016 3:51 PM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> Please review this fix to the jdk test bug. The issue was that the >>>> test initialized the now-aliased TraceExceptions flag, then looked >>>> for its origin, but because of the aliasing, the test was failing. >>>> I substituted a different product option, CheckJNICalls, as it is >>>> unlikely to be converted to Unified Logging, and since it allows >>>> CheckOrigin to test what it was meant to test. >>>> >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8147494/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147494 >>>> >>>> This passed local jtreg testing. I'll gladly run other testing on >>>> it (JPRT on all platforms?) if someone would be able to give me the >>>> command to do so! >>>> >>>> Thanks, >>>> Rachel >>> >> > From kim.barrett at oracle.com Tue Jan 19 23:40:34 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 19 Jan 2016 18:40:34 -0500 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> Message-ID: On Jan 12, 2016, at 10:25 AM, Kim Barrett wrote: > > Please review this fix to some problems in logStream::write and the > facilities used to implement it. > > 1. logStream::write no longer attempt to reformat the already > formatted accumulated output. [Fixing this led to the discovery of > the issues below.] > > 2. Fixed Log<>::vwrite test for overflow of the initial buffer, which > didn't allow for the trailing NUL. > > 3. Fixed Log<>::vwrite to copy the va_list arguments before first > format attempt and use that copy if a second format attempt is > needed, rather than incorrectly reusing the original (now possibly > modified) va_list. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8146793 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8146793/webrev.00/ > > Testing: > JPRT > Locally verified printing a "%" to a log stream works, by running > TestPrintGCDetailsVerbose (after fixing it for JDK-8146728). I have reviews from Marcus Larsson and Rachel Protacio (thank you), but lack a *R*eviewer. From john.r.rose at oracle.com Tue Jan 19 23:55:36 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Jan 2016 15:55:36 -0800 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> Message-ID: <17F38477-524C-4499-94BF-1BADF57BCA3B@oracle.com> On Jan 12, 2016, at 7:25 AM, Kim Barrett wrote: > > Please review this fix to some problems in logStream::write and the > facilities used to implement it. > > 1. logStream::write no longer attempt to reformat the already > formatted accumulated output. [Fixing this led to the discovery of > the issues below.] > > 2. Fixed Log<>::vwrite test for overflow of the initial buffer, which > didn't allow for the trailing NUL. > > 3. Fixed Log<>::vwrite to copy the va_list arguments before first > format attempt and use that copy if a second format attempt is > needed, rather than incorrectly reusing the original (now possibly > modified) va_list. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8146793 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8146793/webrev.00/ > > Testing: > JPRT > Locally verified printing a "%" to a log stream works, by running > TestPrintGCDetailsVerbose (after fixing it for JDK-8146728). The previous logging facility includes, at the corresponding cut point, optimizations for no-% and %s-only format strings, to avoid trips through the sprintf engine and needless copying. Please see: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/utilities/ostream.cpp#l90 In other words, let's not do the buffer-buffer rhumba if we don't need to. This is an excellent moment to incorporate those optimizations in the new logging system. Nice catches on the va_copy and buffer overrun. How did you find the log_func(foo) instead of log_func("%s", foo)? Please tell me it was a gcc warning; if not then we have some software rot going on. Reviewed. ? John From kim.barrett at oracle.com Wed Jan 20 01:07:10 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 19 Jan 2016 20:07:10 -0500 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <17F38477-524C-4499-94BF-1BADF57BCA3B@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> <17F38477-524C-4499-94BF-1BADF57BCA3B@oracle.com> Message-ID: <2E1EE1D0-0F64-42D6-BBB6-87EC9A0A6A2D@oracle.com> On Jan 19, 2016, at 6:55 PM, John Rose wrote: > > On Jan 12, 2016, at 7:25 AM, Kim Barrett wrote: >> >> Please review this fix to some problems in logStream::write and the >> facilities used to implement it. >> >> 1. logStream::write no longer attempt to reformat the already >> formatted accumulated output. [Fixing this led to the discovery of >> the issues below.] >> >> 2. Fixed Log<>::vwrite test for overflow of the initial buffer, which >> didn't allow for the trailing NUL. >> >> 3. Fixed Log<>::vwrite to copy the va_list arguments before first >> format attempt and use that copy if a second format attempt is >> needed, rather than incorrectly reusing the original (now possibly >> modified) va_list. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8146793 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8146793/webrev.00/ >> >> Testing: >> JPRT >> Locally verified printing a "%" to a log stream works, by running >> TestPrintGCDetailsVerbose (after fixing it for JDK-8146728). > > The previous logging facility includes, at the corresponding cut point, > optimizations for no-% and %s-only format strings, to avoid trips > through the sprintf engine and needless copying. Please see: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/utilities/ostream.cpp#l90 > > In other words, let's not do the buffer-buffer rhumba if we don't need to. > > This is an excellent moment to incorporate those optimizations > in the new logging system. It doesn't look like the logging code has anything like that. I think it would need to be an addition to Log<>::vwrite. [I'd thought about trying to improve this path from logStream some way, but decided I was mostly interested in fixing the crashing bug, and could leave optimizing this path to others if needed.] I'll file an RFE for this. > Nice catches on the va_copy and buffer overrun. How did you find > the log_func(foo) instead of log_func("%s", foo)? Please tell me it > was a gcc warning; if not then we have some software rot going on. Sorry, but I found it the hard way, via a crash (I think it was the assert in Log<>::vwrite). logStream::_log_func is a function pointer. Maybe we can attach an ATTRIBUTE_PRINTF to the data member and/or to the logStream constructor argument? And maybe that would produce the desired warnings? I think attaching that attribute would have generated a warning for the non-literal format string being passed to _log_func. > Reviewed. Thanks. From john.r.rose at oracle.com Wed Jan 20 02:06:15 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Jan 2016 18:06:15 -0800 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <2E1EE1D0-0F64-42D6-BBB6-87EC9A0A6A2D@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> <17F38477-524C-4499-94BF-1BADF57BCA3B@oracle.com> <2E1EE1D0-0F64-42D6-BBB6-87EC9A0A6A2D@oracle.com> Message-ID: <689EDF13-743A-42C0-AF9C-847CB18AD1A9@oracle.com> On Jan 19, 2016, at 5:07 PM, Kim Barrett wrote: > > It doesn't look like the logging code has anything like that. I think > it would need to be an addition to Log<>::vwrite. [I'd thought about > trying to improve this path from logStream some way, but decided I was > mostly interested in fixing the crashing bug, and could leave > optimizing this path to others if needed.] I'll file an RFE for this. Thank you. If you get inspired to roll this in now, I'd support that. >> Nice catches on the va_copy and buffer overrun. How did you find >> the log_func(foo) instead of log_func("%s", foo)? Please tell me it >> was a gcc warning; if not then we have some software rot going on. > > Sorry, but I found it the hard way, via a crash (I think it was the > assert in Log<>::vwrite). logStream::_log_func is a function pointer. > Maybe we can attach an ATTRIBUTE_PRINTF to the data member and/or to > the logStream constructor argument? And maybe that would produce the > desired warnings? I think attaching that attribute would have > generated a warning for the non-literal format string being passed to > _log_func. OK, yes; that's what I mean by software rot. We went to a lot of trouble to annotate and fix the the format problems, and now they are building up again as people add new functions without the annotation. Putting in the annotations is really part of making a firm fix to the "%s" problem, not just reacting to crashers as they show up. Fix the root cause, not just the crash. ? John From david.holmes at oracle.com Wed Jan 20 03:53:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2016 13:53:29 +1000 Subject: [9] RFR 8146653: Debug version missing in hs_err files and on internal version after Verona In-Reply-To: <569E6CCC.8040508@oracle.com> References: <569969FD.80302@oracle.com> <56996E00.9000104@oracle.com> <56998140.5020205@oracle.com> <569C64A5.1020904@oracle.com> <569E6CCC.8040508@oracle.com> Message-ID: <569F04B9.10501@oracle.com> On 20/01/2016 3:05 AM, Alejandro E Murillo wrote: > > On 1/17/2016 9:05 PM, David Holmes wrote: >> Hi Alejandro, >> >> On 16/01/2016 9:31 AM, Alejandro E Murillo wrote: >>> >>> Hi Dan, thanks a lot for the prompt review >>> I applied all the changes, revised webrev (with proper links) is here: >>> >>> http://cr.openjdk.java.net/~amurillo/9/8146653/index.html >> >> Seeing this all together now I don't think alternate_jdk_debug_level >> warrants being added to Abstract_VM_version. The logic could be used >> directly inline in VMError.cpp. If it were used more than once then >> perhaps ... though printable_jdk_debug_level might be a better name in >> that case (still not a great name but better IMHO :) ). > Now that you mention it, there's some library code that may also use it. > There's also the code to check for not provided, which will have to > replicate, > so I think I'll keep it. But I'll change the name to "printable" Ok. Thanks, David > Thanks for this review and the discussion prior to sending this out > Alejandro > >> >> Thanks, >> David >> >> >>> Thanks >>> Alejandro >>> >>> On 1/15/2016 3:09 PM, Daniel D. Daugherty wrote: >>>> On 1/15/16 2:51 PM, Alejandro E Murillo wrote: >>>>> >>>>> Please review the following fix for JDK-8146653 >>>>> : >>>>> Debug version missing in hs_err files and on internal version after >>>>> Verona >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8146653/ >>>> >>>> Your version of webrev generated broken nav links for >>>> the "frames" version. Shows 404... >>>> >>>> >>>> src/share/vm/runtime/vm_version.cpp >>>> L242: return strcmp(DEBUG_LEVEL, "release") ? >>>> L243: VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX >>>> L244: : >>>> L245: VMNAME " (" INTERNAL_VERSION_SUFFIX; >>>> >>>> No implied booleans on this part: strcmp(DEBUG_LEVEL, >>>> "release") >>>> >>>> Also I think this would be more HotSpot style: >>>> >>>> return strcmp(DEBUG_LEVEL, "release") == 0 >>>> ? VMNAME " (" INTERNAL_VERSION_SUFFIX >>>> : VMNAME " (" DEBUG_LEVEL " " INTERNAL_VERSION_SUFFIX; >>>> >>>> where the "usual case" is first and the indenting is more >>>> HotSpot like... >>>> >>>> L258: return strcmp(DEBUG_LEVEL, "release") ? DEBUG_LEVEL " " >>>> : ""; >>>> >>>> Similarly here: >>>> >>>> return strcmp(DEBUG_LEVEL, "release") == 0 ? "" : DEBUG_LEVEL; >>>> >>>> src/share/vm/runtime/vm_version.hpp >>>> No comments. >>>> >>>> src/share/vm/utilities/vmError.cpp >>>> L234: const char* runtime_version = >>>> JDK_Version::runtime_version() != NULL ? >>>> L235: JDK_Version::runtime_version() : ""; >>>> L236: const char* jdk_debug_level = >>>> Abstract_VM_Version::alternate_jdk_debug_level() != NULL ? >>>> L237: Abstract_VM_Version::alternate_jdk_debug_level() : ""; >>>> >>>> L237 indent needs three more spaces. So does L235, but that's >>>> not your issue. >>>> >>>> L239: st->print_cr("# JRE version: %s (%s) (%sbuild %s)", >>>> runtime_name, buf, >>>> L240: jdk_debug_level, runtime_version); >>>> >>>> L240 indent has one too many spaces. >>>> >>>> Dan >>>> >>>>> >>>>> Background: >>>>> Verona removed the debug info from version related system properties >>>>> and that's now specified on a new system property called jdk.debug. >>>>> The version header spitted in hs_err files was updated to include >>>>> debug info based on that change. >>>>> That info was also missing on the output for -Xinternalversion >>>>> >>>>> Thanks >>>>> >>>> >>> > From david.holmes at oracle.com Wed Jan 20 04:00:02 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2016 14:00:02 +1000 Subject: Off-heap object space In-Reply-To: References: Message-ID: <569F0642.1060902@oracle.com> Hi, > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), > si_addr=0x00007fd723ee00be This address is not suitably aligned for an Object - they require 8-byte alignment. David On 16/01/2016 11:54 AM, Khanh Nguyen wrote: > Hi, > > I want to implement an off-heap, non-GC, non-contiguous object space. Of > course my naive approach is to call os::malloc or the existing macro > AllocateHeap(). Also I did turn the compressed oops flags off. But I'm > facing this undeterministic issue: randomly the JVM crashes. That is, > sometimes my program can successfully run (with the correct result). And > sometimes it crashes (in library code) > > Partial crash log is this: > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fd71102681d, pid=6741, tid=140562059818752 > # > # JRE version: OpenJDK Runtime Environment (8.0) (build > 1.8.0-internal-debug-khanhtn1_2016_01_15_17_06-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.0-b70-debug interpreted mode > linux-amd64 ) > # Problematic frame: > # j > java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 > # > # Core dump written. Default location: > /lv_scratch/scratch/khanh/openjdk8/core or core.6741 > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00007fd72000a800): JavaThread "main" [_thread_in_Java, > id=6742, stack(0x00007fd72794f000,0x00007fd727a50000)] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), > si_addr=0x00007fd723ee00be > > Registers: > RAX=0x00007fd6110fc818, RBX=0x00007fd0ae129248, RCX=0x0000000000000000, > RDX=0x0000003fe88800be > RSP=0x00007fd727a4e428, RBP=0x00007fd727a4e480, RSI=0x00007fd727a4e3b8, > RDI=0x0000000001200020 > R8 =0x0000000000000000, R9 =0x0000000000000024, R10=0x00007f973b660000, > R11=0x00007fd727a4e390 > R12=0x00007fd711000564, R13=0x00007fd0ae124bb3, R14=0x00007fd727a4e4f0, > R15=0x00007fd72000a800 > RIP=0x00007fd71102681d, EFLAGS=0x0000000000010206, > CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > > Stack: [0x00007fd72794f000,0x00007fd727a50000], sp=0x00007fd727a4e428, > free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > j > java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 > j > java.util.HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+9 > j EmptyMethod.generateHashMap()Ljava/util/HashMap;+44 > j EmptyMethod.runTest(I)V+24 > j EmptyMethod.main([Ljava/lang/String;)V+97 > v ~StubRoutines::call_stub > V [libjvm.so+0x823762] JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*)+0x680 > V [libjvm.so+0xaaae44] os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*)+0x3a > V [libjvm.so+0x8230db] JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*)+0x7d > V [libjvm.so+0x837185] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, > JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x1ca > V [libjvm.so+0x84d31e] jni_CallStaticVoidMethod+0x385 > C [libjli.so+0x8012] JavaMain+0x89a > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x00007fd72014c000 JavaThread "Service Thread" daemon [_thread_blocked, > id=6765, stack(0x00007fd0a9e37000,0x00007fd0a9f38000)] > 0x00007fd720142800 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=6764, stack(0x00007fd0a9f38000,0x00007fd0aa039000)] > 0x00007fd7200e9000 JavaThread "Finalizer" daemon [_thread_blocked, > id=6763, stack(0x00007fd110058000,0x00007fd110159000)] > 0x00007fd7200e6800 JavaThread "Reference Handler" daemon > [_thread_blocked, id=6762, stack(0x00007fd0aa039000,0x00007fd0aa13a000)] > =>0x00007fd72000a800 JavaThread "main" [_thread_in_Java, id=6742, > stack(0x00007fd72794f000,0x00007fd727a50000)] > > Other Threads: > 0x00007fd7200db800 VMThread [stack: > 0x00007fd0aa13a000,0x00007fd0aa23b000] [id=6761] > 0x00007fd720150000 WatcherThread [stack: > 0x00007fd0a9d36000,0x00007fd0a9e37000] [id=6766] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap: > PSYoungGen total 5120K, used 2088K [0x00007fd611000000, > 0x00007fd611b00000, 0x00007fd711000000) > eden space 4096K, 25% used > [0x00007fd611000000,0x00007fd61110a278,0x00007fd611400000) > from space 1024K, 100% used > [0x00007fd611400000,0x00007fd611500000,0x00007fd611500000) > to space 1536K, 0% used > [0x00007fd611980000,0x00007fd611980000,0x00007fd611b00000) > ParOldGen total 512512K, used 1128K [0x00007fd411000000, > 0x00007fd430480000, 0x00007fd611000000) > object space 512512K, 0% used > [0x00007fd411000000,0x00007fd41111a0c0,0x00007fd430480000) > Metaspace used 3255K, capacity 4108K, committed 4352K, reserved 8192K > > Card table byte_map: [0x00007fd7256e8000,0x00007fd726ee9000] byte_map_base: > 0x00007f973b660000 > > Marking Bits: (ParMarkBitMap*) 0x00007fd728f79340 > Begin Bits: [0x00007fd0b0000000, 0x00007fd0bc000000) > End Bits: [0x00007fd0bc000000, 0x00007fd0c8000000) > > Polling page: 0x00007fd7291f5000 > > CodeCache: size=245760Kb used=1439Kb max_used=1439Kb free=244320Kb > bounds [0x00007fd711000000, 0x00007fd711270000, 0x00007fd720000000] > total_blobs=189 nmethods=0 adapters=164 > compilation: disabled (interpreter mode) > > > Using gdb doesn't show anything interesting unfortunately > #2 0x00007fd023d393a3 in os::abort (dump_core=true) at > /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:1563 > #3 0x00007fd023efacdd in VMError::report_and_die (this=0x7fd023293d00) at > /scratch/khanh/openjdk8/hotspot/src/share/vm/utilities/vmError.cpp:1078 > #4 0x00007fd023d453d9 in JVM_handle_linux_signal (sig=11, > info=0x7fd023293fb0, ucVoid=0x7fd023293e80, abort_if_unrecognized=1) at > /scratch/khanh/openjdk8/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:534 > #5 0x00007fd023d3eebf in signalHandler (sig=11, info=0x7fd023293fb0, > uc=0x7fd023293e80) at > /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4278 > #6 > #7 0x00007fd00d02681d in ?? () > #8 0x00007fcf0d0feee0 in ?? () > #9 0x0000000000000002 in ?? () > #10 0x00007fc9e95c9c58 in ?? () > #11 0x00007fd023294440 in ?? () > #12 0x00007fca09c71bb0 in ?? () > #13 0x00007fd0232944f0 in ?? () > #14 0x00007fca09c74e30 in ?? () > #15 0x0000000000000000 in ?? () > > So my questions, specifically, are > 1) Why SEGV_ACCERR? And any idea of where the problem might be? > > 2) In theory, it should be straightforward for me to have an off-heap space > where I can allocate objects in. I don't understand why there is a random > crash like what I have. I mean if I violate some implicit rules in Hotspot, > my program should fail always. > > Any pointers/suggestions are greatly appreciated. > > Thank you, > From david.holmes at oracle.com Wed Jan 20 04:53:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2016 14:53:18 +1000 Subject: Off-heap object space In-Reply-To: References: <569F0642.1060902@oracle.com> Message-ID: <569F12BE.2050608@oracle.com> On 20/01/2016 2:27 PM, Khanh Nguyen wrote: > On Tue, Jan 19, 2016 at 8:00 PM, David Holmes > wrote: > > Hi, > > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), > > si_addr=0x00007fd723ee00be > > This address is not suitably aligned for an Object - they require > 8-byte alignment. > > I believe the address is not pointing to an Object (at least objects > that are allocated in my off-heap space). I printed all address of > objects allocated in my space and the address of si_addr is always > higher than the last object's address printed. Also it doesn't belong to > the address range that I reserved for my space. Well it appears to be an alignment issue regardless. You need to track down exactly what that address is supposed to be (from core file). I couldn't seem to map it to any of the used memory areas. David > > > David > > > On 16/01/2016 11:54 AM, Khanh Nguyen wrote: > > Hi, > > I want to implement an off-heap, non-GC, non-contiguous object > space. Of > course my naive approach is to call os::malloc or the existing macro > AllocateHeap(). Also I did turn the compressed oops flags off. > But I'm > facing this undeterministic issue: randomly the JVM crashes. > That is, > sometimes my program can successfully run (with the correct > result). And > sometimes it crashes (in library code) > > Partial crash log is this: > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fd71102681d, pid=6741, > tid=140562059818752 > # > # JRE version: OpenJDK Runtime Environment (8.0) (build > 1.8.0-internal-debug-khanhtn1_2016_01_15_17_06-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.0-b70-debug interpreted mode > linux-amd64 ) > # Problematic frame: > # j > > java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 > # > # Core dump written. Default location: > /lv_scratch/scratch/khanh/openjdk8/core or core.6741 > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00007fd72000a800): JavaThread "main" > [_thread_in_Java, > id=6742, stack(0x00007fd72794f000,0x00007fd727a50000)] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), > si_addr=0x00007fd723ee00be > > Registers: > RAX=0x00007fd6110fc818, RBX=0x00007fd0ae129248, > RCX=0x0000000000000000, > RDX=0x0000003fe88800be > RSP=0x00007fd727a4e428, RBP=0x00007fd727a4e480, > RSI=0x00007fd727a4e3b8, > RDI=0x0000000001200020 > R8 =0x0000000000000000, R9 =0x0000000000000024, > R10=0x00007f973b660000, > R11=0x00007fd727a4e390 > R12=0x00007fd711000564, R13=0x00007fd0ae124bb3, > R14=0x00007fd727a4e4f0, > R15=0x00007fd72000a800 > RIP=0x00007fd71102681d, EFLAGS=0x0000000000010206, > CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > > Stack: [0x00007fd72794f000,0x00007fd727a50000], > sp=0x00007fd727a4e428, > free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native > code) > j > > java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 > j > > java.util.HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+9 > j EmptyMethod.generateHashMap()Ljava/util/HashMap;+44 > j EmptyMethod.runTest(I)V+24 > j EmptyMethod.main([Ljava/lang/String;)V+97 > v ~StubRoutines::call_stub > V [libjvm.so+0x823762] JavaCalls::call_helper(JavaValue*, > methodHandle*, > JavaCallArguments*, Thread*)+0x680 > V [libjvm.so+0xaaae44] os::os_exception_wrapper(void > (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, > methodHandle*, > JavaCallArguments*, Thread*)+0x3a > V [libjvm.so+0x8230db] JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*)+0x7d > V [libjvm.so+0x837185] jni_invoke_static(JNIEnv_*, JavaValue*, > _jobject*, > JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x1ca > V [libjvm.so+0x84d31e] jni_CallStaticVoidMethod+0x385 > C [libjli.so+0x8012] JavaMain+0x89a > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x00007fd72014c000 JavaThread "Service Thread" daemon > [_thread_blocked, > id=6765, stack(0x00007fd0a9e37000,0x00007fd0a9f38000)] > 0x00007fd720142800 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=6764, > stack(0x00007fd0a9f38000,0x00007fd0aa039000)] > 0x00007fd7200e9000 JavaThread "Finalizer" daemon > [_thread_blocked, > id=6763, stack(0x00007fd110058000,0x00007fd110159000)] > 0x00007fd7200e6800 JavaThread "Reference Handler" daemon > [_thread_blocked, id=6762, > stack(0x00007fd0aa039000,0x00007fd0aa13a000)] > =>0x00007fd72000a800 JavaThread "main" [_thread_in_Java, id=6742, > stack(0x00007fd72794f000,0x00007fd727a50000)] > > Other Threads: > 0x00007fd7200db800 VMThread [stack: > 0x00007fd0aa13a000,0x00007fd0aa23b000] [id=6761] > 0x00007fd720150000 WatcherThread [stack: > 0x00007fd0a9d36000,0x00007fd0a9e37000] [id=6766] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap: > PSYoungGen total 5120K, used 2088K [0x00007fd611000000, > 0x00007fd611b00000, 0x00007fd711000000) > eden space 4096K, 25% used > [0x00007fd611000000,0x00007fd61110a278,0x00007fd611400000) > from space 1024K, 100% used > [0x00007fd611400000,0x00007fd611500000,0x00007fd611500000) > to space 1536K, 0% used > [0x00007fd611980000,0x00007fd611980000,0x00007fd611b00000) > ParOldGen total 512512K, used 1128K [0x00007fd411000000, > 0x00007fd430480000, 0x00007fd611000000) > object space 512512K, 0% used > [0x00007fd411000000,0x00007fd41111a0c0,0x00007fd430480000) > Metaspace used 3255K, capacity 4108K, committed 4352K, > reserved 8192K > > Card table byte_map: [0x00007fd7256e8000,0x00007fd726ee9000] > byte_map_base: > 0x00007f973b660000 > > Marking Bits: (ParMarkBitMap*) 0x00007fd728f79340 > Begin Bits: [0x00007fd0b0000000, 0x00007fd0bc000000) > End Bits: [0x00007fd0bc000000, 0x00007fd0c8000000) > > Polling page: 0x00007fd7291f5000 > > CodeCache: size=245760Kb used=1439Kb max_used=1439Kb free=244320Kb > bounds [0x00007fd711000000, 0x00007fd711270000, > 0x00007fd720000000] > total_blobs=189 nmethods=0 adapters=164 > compilation: disabled (interpreter mode) > > > Using gdb doesn't show anything interesting unfortunately > #2 0x00007fd023d393a3 in os::abort (dump_core=true) at > /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:1563 > #3 0x00007fd023efacdd in VMError::report_and_die > (this=0x7fd023293d00) at > /scratch/khanh/openjdk8/hotspot/src/share/vm/utilities/vmError.cpp:1078 > #4 0x00007fd023d453d9 in JVM_handle_linux_signal (sig=11, > info=0x7fd023293fb0, ucVoid=0x7fd023293e80, > abort_if_unrecognized=1) at > /scratch/khanh/openjdk8/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:534 > #5 0x00007fd023d3eebf in signalHandler (sig=11, > info=0x7fd023293fb0, > uc=0x7fd023293e80) at > /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4278 > #6 > #7 0x00007fd00d02681d in ?? () > #8 0x00007fcf0d0feee0 in ?? () > #9 0x0000000000000002 in ?? () > #10 0x00007fc9e95c9c58 in ?? () > #11 0x00007fd023294440 in ?? () > #12 0x00007fca09c71bb0 in ?? () > #13 0x00007fd0232944f0 in ?? () > #14 0x00007fca09c74e30 in ?? () > #15 0x0000000000000000 in ?? () > > So my questions, specifically, are > 1) Why SEGV_ACCERR? And any idea of where the problem might be? > > 2) In theory, it should be straightforward for me to have an > off-heap space > where I can allocate objects in. I don't understand why there is > a random > crash like what I have. I mean if I violate some implicit rules > in Hotspot, > my program should fail always. > > Any pointers/suggestions are greatly appreciated. > > Thank you, > > From mikael.gerdin at oracle.com Wed Jan 20 07:22:10 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Jan 2016 08:22:10 +0100 Subject: Off-heap object space In-Reply-To: References: Message-ID: <569F35A2.50401@oracle.com> Hi, On 2016-01-16 02:54, Khanh Nguyen wrote: > Hi, > > I want to implement an off-heap, non-GC, non-contiguous object space. Of > course my naive approach is to call os::malloc or the existing macro > AllocateHeap(). Also I did turn the compressed oops flags off. But I'm > facing this undeterministic issue: randomly the JVM crashes. That is, > sometimes my program can successfully run (with the correct result). And > sometimes it crashes (in library code) > > Partial crash log is this: > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fd71102681d, pid=6741, tid=140562059818752 > # > # JRE version: OpenJDK Runtime Environment (8.0) (build > 1.8.0-internal-debug-khanhtn1_2016_01_15_17_06-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.0-b70-debug interpreted mode > linux-amd64 ) > # Problematic frame: > # j > java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 > # > # Core dump written. Default location: > /lv_scratch/scratch/khanh/openjdk8/core or core.6741 > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00007fd72000a800): JavaThread "main" [_thread_in_Java, > id=6742, stack(0x00007fd72794f000,0x00007fd727a50000)] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), > si_addr=0x00007fd723ee00be > > Registers: > RAX=0x00007fd6110fc818, RBX=0x00007fd0ae129248, RCX=0x0000000000000000, > RDX=0x0000003fe88800be > RSP=0x00007fd727a4e428, RBP=0x00007fd727a4e480, RSI=0x00007fd727a4e3b8, > RDI=0x0000000001200020 > R8 =0x0000000000000000, R9 =0x0000000000000024, R10=0x00007f973b660000, > R11=0x00007fd727a4e390 > R12=0x00007fd711000564, R13=0x00007fd0ae124bb3, R14=0x00007fd727a4e4f0, > R15=0x00007fd72000a800 > RIP=0x00007fd71102681d, EFLAGS=0x0000000000010206, > CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > > Stack: [0x00007fd72794f000,0x00007fd727a50000], sp=0x00007fd727a4e428, > free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > j > java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 > j > java.util.HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+9 > j EmptyMethod.generateHashMap()Ljava/util/HashMap;+44 > j EmptyMethod.runTest(I)V+24 > j EmptyMethod.main([Ljava/lang/String;)V+97 > v ~StubRoutines::call_stub > V [libjvm.so+0x823762] JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*)+0x680 > V [libjvm.so+0xaaae44] os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*)+0x3a > V [libjvm.so+0x8230db] JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*)+0x7d > V [libjvm.so+0x837185] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, > JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x1ca > V [libjvm.so+0x84d31e] jni_CallStaticVoidMethod+0x385 > C [libjli.so+0x8012] JavaMain+0x89a > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x00007fd72014c000 JavaThread "Service Thread" daemon [_thread_blocked, > id=6765, stack(0x00007fd0a9e37000,0x00007fd0a9f38000)] > 0x00007fd720142800 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=6764, stack(0x00007fd0a9f38000,0x00007fd0aa039000)] > 0x00007fd7200e9000 JavaThread "Finalizer" daemon [_thread_blocked, > id=6763, stack(0x00007fd110058000,0x00007fd110159000)] > 0x00007fd7200e6800 JavaThread "Reference Handler" daemon > [_thread_blocked, id=6762, stack(0x00007fd0aa039000,0x00007fd0aa13a000)] > =>0x00007fd72000a800 JavaThread "main" [_thread_in_Java, id=6742, > stack(0x00007fd72794f000,0x00007fd727a50000)] > > Other Threads: > 0x00007fd7200db800 VMThread [stack: > 0x00007fd0aa13a000,0x00007fd0aa23b000] [id=6761] > 0x00007fd720150000 WatcherThread [stack: > 0x00007fd0a9d36000,0x00007fd0a9e37000] [id=6766] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap: > PSYoungGen total 5120K, used 2088K [0x00007fd611000000, > 0x00007fd611b00000, 0x00007fd711000000) > eden space 4096K, 25% used > [0x00007fd611000000,0x00007fd61110a278,0x00007fd611400000) > from space 1024K, 100% used > [0x00007fd611400000,0x00007fd611500000,0x00007fd611500000) > to space 1536K, 0% used > [0x00007fd611980000,0x00007fd611980000,0x00007fd611b00000) > ParOldGen total 512512K, used 1128K [0x00007fd411000000, > 0x00007fd430480000, 0x00007fd611000000) > object space 512512K, 0% used > [0x00007fd411000000,0x00007fd41111a0c0,0x00007fd430480000) > Metaspace used 3255K, capacity 4108K, committed 4352K, reserved 8192K > > Card table byte_map: [0x00007fd7256e8000,0x00007fd726ee9000] byte_map_base: > 0x00007f973b660000 > > Marking Bits: (ParMarkBitMap*) 0x00007fd728f79340 > Begin Bits: [0x00007fd0b0000000, 0x00007fd0bc000000) > End Bits: [0x00007fd0bc000000, 0x00007fd0c8000000) > > Polling page: 0x00007fd7291f5000 > > CodeCache: size=245760Kb used=1439Kb max_used=1439Kb free=244320Kb > bounds [0x00007fd711000000, 0x00007fd711270000, 0x00007fd720000000] > total_blobs=189 nmethods=0 adapters=164 > compilation: disabled (interpreter mode) > > > Using gdb doesn't show anything interesting unfortunately > #2 0x00007fd023d393a3 in os::abort (dump_core=true) at > /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:1563 > #3 0x00007fd023efacdd in VMError::report_and_die (this=0x7fd023293d00) at > /scratch/khanh/openjdk8/hotspot/src/share/vm/utilities/vmError.cpp:1078 > #4 0x00007fd023d453d9 in JVM_handle_linux_signal (sig=11, > info=0x7fd023293fb0, ucVoid=0x7fd023293e80, abort_if_unrecognized=1) at > /scratch/khanh/openjdk8/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:534 > #5 0x00007fd023d3eebf in signalHandler (sig=11, info=0x7fd023293fb0, > uc=0x7fd023293e80) at > /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4278 > #6 > #7 0x00007fd00d02681d in ?? () > #8 0x00007fcf0d0feee0 in ?? () > #9 0x0000000000000002 in ?? () > #10 0x00007fc9e95c9c58 in ?? () > #11 0x00007fd023294440 in ?? () > #12 0x00007fca09c71bb0 in ?? () > #13 0x00007fd0232944f0 in ?? () > #14 0x00007fca09c74e30 in ?? () > #15 0x0000000000000000 in ?? () > > So my questions, specifically, are > 1) Why SEGV_ACCERR? And any idea of where the problem might be? > > 2) In theory, it should be straightforward for me to have an off-heap space > where I can allocate objects in. I don't understand why there is a random > crash like what I have. I mean if I violate some implicit rules in Hotspot, > my program should fail always. This is not the case. Due to how the garbage collectors operate, every write to an object field is accompanied by a write to a "card table" used to keep track of object references from the old generation into the young generation. These card table writes are compiled in to the JIT-compiled methods and in order to call methods on your "off heap" objects you would need the card table to span all of the memory in which your off heap objects reside. This is essentially one of the core reasons why noncontiguous heaps are not such a simple problem to solve as some people suspect. There are a lot of performance advantages to having a known, fixed maximum heap size and a fixed region of memory where the objects are located. Regards /Mikael > > Any pointers/suggestions are greatly appreciated. > > Thank you, > From ktruong.nguyen at gmail.com Wed Jan 20 07:35:14 2016 From: ktruong.nguyen at gmail.com (Khanh Nguyen) Date: Tue, 19 Jan 2016 23:35:14 -0800 Subject: Off-heap object space In-Reply-To: <569F35A2.50401@oracle.com> References: <569F35A2.50401@oracle.com> Message-ID: Hi Mikael, As I understand it, card table marking is there only to prevent leaks since objects in young generation can be solely reached from old generation. Let's say I don't care about those off-heap objects right now, i.e., I'm willing to let them be leaks. Then I don't need a card table for off-heap memory. That's exactly my situation right now: I have malloced a space, have objects allocated in it and boom, JVM just crashes (randomly) On Tue, Jan 19, 2016 at 11:22 PM, Mikael Gerdin wrote: > Hi, > > > On 2016-01-16 02:54, Khanh Nguyen wrote: > >> Hi, >> >> I want to implement an off-heap, non-GC, non-contiguous object space. Of >> course my naive approach is to call os::malloc or the existing macro >> AllocateHeap(). Also I did turn the compressed oops flags off. But I'm >> facing this undeterministic issue: randomly the JVM crashes. That is, >> sometimes my program can successfully run (with the correct result). And >> sometimes it crashes (in library code) >> >> Partial crash log is this: >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007fd71102681d, pid=6741, tid=140562059818752 >> # >> # JRE version: OpenJDK Runtime Environment (8.0) (build >> 1.8.0-internal-debug-khanhtn1_2016_01_15_17_06-b00) >> # Java VM: OpenJDK 64-Bit Server VM (25.0-b70-debug interpreted mode >> linux-amd64 ) >> # Problematic frame: >> # j >> >> java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 >> # >> # Core dump written. Default location: >> /lv_scratch/scratch/khanh/openjdk8/core or core.6741 >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00007fd72000a800): JavaThread "main" [_thread_in_Java, >> id=6742, stack(0x00007fd72794f000,0x00007fd727a50000)] >> >> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), >> si_addr=0x00007fd723ee00be >> >> Registers: >> RAX=0x00007fd6110fc818, RBX=0x00007fd0ae129248, RCX=0x0000000000000000, >> RDX=0x0000003fe88800be >> RSP=0x00007fd727a4e428, RBP=0x00007fd727a4e480, RSI=0x00007fd727a4e3b8, >> RDI=0x0000000001200020 >> R8 =0x0000000000000000, R9 =0x0000000000000024, R10=0x00007f973b660000, >> R11=0x00007fd727a4e390 >> R12=0x00007fd711000564, R13=0x00007fd0ae124bb3, R14=0x00007fd727a4e4f0, >> R15=0x00007fd72000a800 >> RIP=0x00007fd71102681d, EFLAGS=0x0000000000010206, >> CSGSFS=0x0000000000000033, ERR=0x0000000000000006 >> TRAPNO=0x000000000000000e >> >> Stack: [0x00007fd72794f000,0x00007fd727a50000], sp=0x00007fd727a4e428, >> free space=1021k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> j >> >> java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 >> j >> >> java.util.HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+9 >> j EmptyMethod.generateHashMap()Ljava/util/HashMap;+44 >> j EmptyMethod.runTest(I)V+24 >> j EmptyMethod.main([Ljava/lang/String;)V+97 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x823762] JavaCalls::call_helper(JavaValue*, methodHandle*, >> JavaCallArguments*, Thread*)+0x680 >> V [libjvm.so+0xaaae44] os::os_exception_wrapper(void (*)(JavaValue*, >> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >> JavaCallArguments*, Thread*)+0x3a >> V [libjvm.so+0x8230db] JavaCalls::call(JavaValue*, methodHandle, >> JavaCallArguments*, Thread*)+0x7d >> V [libjvm.so+0x837185] jni_invoke_static(JNIEnv_*, JavaValue*, >> _jobject*, >> JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x1ca >> V [libjvm.so+0x84d31e] jni_CallStaticVoidMethod+0x385 >> C [libjli.so+0x8012] JavaMain+0x89a >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x00007fd72014c000 JavaThread "Service Thread" daemon [_thread_blocked, >> id=6765, stack(0x00007fd0a9e37000,0x00007fd0a9f38000)] >> 0x00007fd720142800 JavaThread "Signal Dispatcher" daemon >> [_thread_blocked, id=6764, stack(0x00007fd0a9f38000,0x00007fd0aa039000)] >> 0x00007fd7200e9000 JavaThread "Finalizer" daemon [_thread_blocked, >> id=6763, stack(0x00007fd110058000,0x00007fd110159000)] >> 0x00007fd7200e6800 JavaThread "Reference Handler" daemon >> [_thread_blocked, id=6762, stack(0x00007fd0aa039000,0x00007fd0aa13a000)] >> =>0x00007fd72000a800 JavaThread "main" [_thread_in_Java, id=6742, >> stack(0x00007fd72794f000,0x00007fd727a50000)] >> >> Other Threads: >> 0x00007fd7200db800 VMThread [stack: >> 0x00007fd0aa13a000,0x00007fd0aa23b000] [id=6761] >> 0x00007fd720150000 WatcherThread [stack: >> 0x00007fd0a9d36000,0x00007fd0a9e37000] [id=6766] >> >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: None >> >> Heap: >> PSYoungGen total 5120K, used 2088K [0x00007fd611000000, >> 0x00007fd611b00000, 0x00007fd711000000) >> eden space 4096K, 25% used >> [0x00007fd611000000,0x00007fd61110a278,0x00007fd611400000) >> from space 1024K, 100% used >> [0x00007fd611400000,0x00007fd611500000,0x00007fd611500000) >> to space 1536K, 0% used >> [0x00007fd611980000,0x00007fd611980000,0x00007fd611b00000) >> ParOldGen total 512512K, used 1128K [0x00007fd411000000, >> 0x00007fd430480000, 0x00007fd611000000) >> object space 512512K, 0% used >> [0x00007fd411000000,0x00007fd41111a0c0,0x00007fd430480000) >> Metaspace used 3255K, capacity 4108K, committed 4352K, reserved >> 8192K >> >> Card table byte_map: [0x00007fd7256e8000,0x00007fd726ee9000] >> byte_map_base: >> 0x00007f973b660000 >> >> Marking Bits: (ParMarkBitMap*) 0x00007fd728f79340 >> Begin Bits: [0x00007fd0b0000000, 0x00007fd0bc000000) >> End Bits: [0x00007fd0bc000000, 0x00007fd0c8000000) >> >> Polling page: 0x00007fd7291f5000 >> >> CodeCache: size=245760Kb used=1439Kb max_used=1439Kb free=244320Kb >> bounds [0x00007fd711000000, 0x00007fd711270000, 0x00007fd720000000] >> total_blobs=189 nmethods=0 adapters=164 >> compilation: disabled (interpreter mode) >> >> >> Using gdb doesn't show anything interesting unfortunately >> #2 0x00007fd023d393a3 in os::abort (dump_core=true) at >> /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:1563 >> #3 0x00007fd023efacdd in VMError::report_and_die (this=0x7fd023293d00) at >> /scratch/khanh/openjdk8/hotspot/src/share/vm/utilities/vmError.cpp:1078 >> #4 0x00007fd023d453d9 in JVM_handle_linux_signal (sig=11, >> info=0x7fd023293fb0, ucVoid=0x7fd023293e80, abort_if_unrecognized=1) at >> >> /scratch/khanh/openjdk8/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:534 >> #5 0x00007fd023d3eebf in signalHandler (sig=11, info=0x7fd023293fb0, >> uc=0x7fd023293e80) at >> /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4278 >> #6 >> #7 0x00007fd00d02681d in ?? () >> #8 0x00007fcf0d0feee0 in ?? () >> #9 0x0000000000000002 in ?? () >> #10 0x00007fc9e95c9c58 in ?? () >> #11 0x00007fd023294440 in ?? () >> #12 0x00007fca09c71bb0 in ?? () >> #13 0x00007fd0232944f0 in ?? () >> #14 0x00007fca09c74e30 in ?? () >> #15 0x0000000000000000 in ?? () >> >> So my questions, specifically, are >> 1) Why SEGV_ACCERR? And any idea of where the problem might be? >> >> 2) In theory, it should be straightforward for me to have an off-heap >> space >> where I can allocate objects in. I don't understand why there is a random >> crash like what I have. I mean if I violate some implicit rules in >> Hotspot, >> my program should fail always. >> > > This is not the case. > Due to how the garbage collectors operate, every write to an object field > is accompanied by a write to a "card table" used to keep track of object > references from the old generation into the young generation. > > These card table writes are compiled in to the JIT-compiled methods and in > order to call methods on your "off heap" objects you would need the card > table to span all of the memory in which your off heap objects reside. > > This is essentially one of the core reasons why noncontiguous heaps are > not such a simple problem to solve as some people suspect. > There are a lot of performance advantages to having a known, fixed maximum > heap size and a fixed region of memory where the objects are located. > > Regards > /Mikael > > > >> Any pointers/suggestions are greatly appreciated. >> >> Thank you, >> >> From adinn at redhat.com Wed Jan 20 09:53:40 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 20 Jan 2016 09:53:40 +0000 Subject: Off-heap object space In-Reply-To: References: <569F35A2.50401@oracle.com> Message-ID: <569F5924.3040301@redhat.com> On 20/01/16 07:35, Khanh Nguyen wrote: > As I understand it, card table marking is there only to prevent leaks since > objects in young generation can be solely reached from old generation. > Let's say I don't care about those off-heap objects right now, i.e., I'm > willing to let them be leaks. Then I don't need a card table for off-heap > memory. > That's exactly my situation right now: I have malloced a space, have > objects allocated in it and boom, JVM just crashes (randomly) I am afraid your statement above about why card table marking is needed only addresses part of a much bigger picture. There is a lot more to managing memory than preventing leaks. Card table marking is only one technique that may be used to achieve several inter-related goals which a GC must address. I suggest you do some background reading on garbage collection in order to understand why the assumption that you can simply allocate a memory region and use it to house objects is over-simple. Richard Jones' book on garbage collection provides a very comprehensive account. You will probably find the first edition (Garbage Collection: Algorithms for Automatic Dynamic Memory Management by Richard Jones & Rafael Lins) more helpful than the later revised edition as the former provides a more comprehensive explanation of the basic ideas. However, both books are well worth reading. My personal view is that an understanding of the information the first book presents (if not also the second one) is a pre-requisite for anyone attempting to improve the way the JVM manages memory. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From jesper.wilhelmsson at oracle.com Wed Jan 20 11:19:07 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 20 Jan 2016 12:19:07 +0100 Subject: RFR(s): JDK-8147791 - Reenable tests that was temporarily quarantined in jdk9/hs Message-ID: <569F6D2B.9090806@oracle.com> Hi, Please review this trivial change to re-enable the tests that was quarantined in main yesterday. The quarantining change has been pulled into hs-rt and we want to enable the tests again since the fixes for the original bugs are already in hs-rt. Bug: https://bugs.openjdk.java.net/browse/JDK-8147791 Webrev: http://cr.openjdk.java.net/~jwilhelm/8147791/webrev.00/ Thanks, /Jesper From david.holmes at oracle.com Wed Jan 20 12:07:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jan 2016 22:07:20 +1000 Subject: RFR(s): JDK-8147791 - Reenable tests that was temporarily quarantined in jdk9/hs In-Reply-To: <569F6D2B.9090806@oracle.com> References: <569F6D2B.9090806@oracle.com> Message-ID: <569F7878.9050600@oracle.com> Looks good. Thanks, David On 20/01/2016 9:19 PM, Jesper Wilhelmsson wrote: > Hi, > > Please review this trivial change to re-enable the tests that was > quarantined in main yesterday. The quarantining change has been pulled > into hs-rt and we want to enable the tests again since the fixes for the > original bugs are already in hs-rt. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147791 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8147791/webrev.00/ > > Thanks, > /Jesper From jesper.wilhelmsson at oracle.com Wed Jan 20 12:15:32 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 20 Jan 2016 13:15:32 +0100 Subject: RFR(s): JDK-8147791 - Reenable tests that was temporarily quarantined in jdk9/hs In-Reply-To: <569F7878.9050600@oracle.com> References: <569F6D2B.9090806@oracle.com> <569F7878.9050600@oracle.com> Message-ID: <569F7A64.5070702@oracle.com> Thanks for looking! /Jesper Den 20/1/16 kl. 13:07, skrev David Holmes: > Looks good. > > Thanks, > David > > On 20/01/2016 9:19 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this trivial change to re-enable the tests that was >> quarantined in main yesterday. The quarantining change has been pulled >> into hs-rt and we want to enable the tests again since the fixes for the >> original bugs are already in hs-rt. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147791 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8147791/webrev.00/ >> >> Thanks, >> /Jesper From mikael.gerdin at oracle.com Wed Jan 20 12:28:39 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Jan 2016 13:28:39 +0100 Subject: RFR(s): JDK-8147791 - Reenable tests that was temporarily quarantined in jdk9/hs In-Reply-To: <569F6D2B.9090806@oracle.com> References: <569F6D2B.9090806@oracle.com> Message-ID: <569F7D77.6020802@oracle.com> Hi, On 2016-01-20 12:19, Jesper Wilhelmsson wrote: > Hi, > > Please review this trivial change to re-enable the tests that was > quarantined in main yesterday. The quarantining change has been pulled > into hs-rt and we want to enable the tests again since the fixes for the > original bugs are already in hs-rt. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147791 > Webrev: http://cr.openjdk.java.net/~jwilhelm/8147791/webrev.00/ Looks good. /Mikael > > Thanks, > /Jesper From jesper.wilhelmsson at oracle.com Wed Jan 20 12:29:58 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 20 Jan 2016 13:29:58 +0100 Subject: RFR(s): JDK-8147791 - Reenable tests that was temporarily quarantined in jdk9/hs In-Reply-To: <569F7D77.6020802@oracle.com> References: <569F6D2B.9090806@oracle.com> <569F7D77.6020802@oracle.com> Message-ID: <569F7DC6.7040707@oracle.com> Thanks! /Jesper Den 20/1/16 kl. 13:28, skrev Mikael Gerdin: > Hi, > > On 2016-01-20 12:19, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this trivial change to re-enable the tests that was >> quarantined in main yesterday. The quarantining change has been pulled >> into hs-rt and we want to enable the tests again since the fixes for the >> original bugs are already in hs-rt. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147791 >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8147791/webrev.00/ > > Looks good. > /Mikael > >> >> Thanks, >> /Jesper > From mikael.gerdin at oracle.com Wed Jan 20 12:31:30 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Jan 2016 13:31:30 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569926B9.4070806@oracle.com> References: <569926B9.4070806@oracle.com> Message-ID: <569F7E22.3090905@oracle.com> Hi again, I've rebased the on hs-rt and had to include some additional changes for JVMCI. I've also updated the copyright years. Unfortunately I can't generate an incremental webrev since i rebased the patch and there's no good way that I know of to make that work with webrev. New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ Testing: JPRT again (which includes the JVMCI jtreg tests) /Mikael On 2016-01-15 18:04, Mikael Gerdin wrote: > Hi all, > > As per the previous discussion in mid-December[0] about moving the > _vtable_length field to class Klass, here's the first RFR and webrev, > according to my suggested plan[1]: > >> My current plan is to first modify the vtable_length_offset accessor to >> return a byte offset (which is what it's translated to by all callers). >> >> Then I'll tackle moving the _vtable_len field to Klass. >> >> Finally I'll try to consolidate the vtable related methods to Klass, >> where they belong. > > This change actually consists of three changes: > * modifying InstanceKlass::vtable_length_offset to become a byte offset > and use the ByteSize type to communicate the scaling. > * modifying InstanceKlass::vtable_start_offset to become a byte offset > and use the ByteSize type, for symmetry reasons mainly. > * adding a vtableEntry::size_in_bytes() since in many places the vtable > entry size is used in combination with the vtable start to compute a > byte offset for vtable lookups. > > I don't foresee any issues with the fact that the byte offset is > represented as an int, for two reasons: > 1) If the offset of any of these grows to over 2 gigabytes then we have > a huge footprint problem with InstanceKlass > 2) The offsets are converted to byte offsets and stored in ints already > in the cpu specific code I've modified. > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 > Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ > > Testing: JPRT on Oracle supported platforms, testing on AARCH64 and > PPC64 would be much appreciated, appropriate mailing lists have been > CC:ed to notify them of the request. > > > [0] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html > > > Thanks! > /Mikael From aaron.grunthal at infinite-source.de Wed Jan 20 13:26:15 2016 From: aaron.grunthal at infinite-source.de (Aaron Grunthal) Date: Wed, 20 Jan 2016 14:26:15 +0100 Subject: Off-heap object space In-Reply-To: References: Message-ID: <569F8AF7.6050104@infinite-source.de> You might want to take a look at jillegal, which implements offheap object allocations among other things. https://github.com/serkan-ozal/jillegal On 16.01.2016 02:54, Khanh Nguyen wrote: > Hi, > > I want to implement an off-heap, non-GC, non-contiguous object space. Of > course my naive approach is to call os::malloc or the existing macro > AllocateHeap(). Also I did turn the compressed oops flags off. But I'm > facing this undeterministic issue: randomly the JVM crashes. That is, > sometimes my program can successfully run (with the correct result). And > sometimes it crashes (in library code) From coleen.phillimore at oracle.com Wed Jan 20 14:24:22 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Jan 2016 09:24:22 -0500 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569F7E22.3090905@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> Message-ID: <569F9896.9030009@oracle.com> http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/src/share/vm/oops/klassVtable.hpp.udiff.html I thought this would return ByteSize? This looks really good. Although I thought you were going to move _vtable_len to Klass ? Coleen On 1/20/16 7:31 AM, Mikael Gerdin wrote: > Hi again, > > I've rebased the on hs-rt and had to include some additional changes > for JVMCI. > I've also updated the copyright years. > Unfortunately I can't generate an incremental webrev since i rebased > the patch and there's no good way that I know of to make that work > with webrev. > > New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ > > Testing: JPRT again (which includes the JVMCI jtreg tests) > > /Mikael > > On 2016-01-15 18:04, Mikael Gerdin wrote: >> Hi all, >> >> As per the previous discussion in mid-December[0] about moving the >> _vtable_length field to class Klass, here's the first RFR and webrev, >> according to my suggested plan[1]: >> >>> My current plan is to first modify the vtable_length_offset accessor to >>> return a byte offset (which is what it's translated to by all callers). >>> >>> Then I'll tackle moving the _vtable_len field to Klass. >>> >>> Finally I'll try to consolidate the vtable related methods to Klass, >>> where they belong. >> >> This change actually consists of three changes: >> * modifying InstanceKlass::vtable_length_offset to become a byte offset >> and use the ByteSize type to communicate the scaling. >> * modifying InstanceKlass::vtable_start_offset to become a byte offset >> and use the ByteSize type, for symmetry reasons mainly. >> * adding a vtableEntry::size_in_bytes() since in many places the vtable >> entry size is used in combination with the vtable start to compute a >> byte offset for vtable lookups. >> >> I don't foresee any issues with the fact that the byte offset is >> represented as an int, for two reasons: >> 1) If the offset of any of these grows to over 2 gigabytes then we have >> a huge footprint problem with InstanceKlass >> 2) The offsets are converted to byte offsets and stored in ints already >> in the cpu specific code I've modified. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >> >> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >> PPC64 would be much appreciated, appropriate mailing lists have been >> CC:ed to notify them of the request. >> >> >> [0] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >> >> >> >> Thanks! >> /Mikael > From ktruong.nguyen at gmail.com Wed Jan 20 15:51:30 2016 From: ktruong.nguyen at gmail.com (Khanh Nguyen) Date: Wed, 20 Jan 2016 07:51:30 -0800 Subject: Off-heap object space In-Reply-To: <569F8AF7.6050104@infinite-source.de> References: <569F8AF7.6050104@infinite-source.de> Message-ID: Thanks for the pointer. On Jan 20, 2016 5:26 AM, "Aaron Grunthal" wrote: > You might want to take a look at jillegal, which implements offheap > object allocations among other things. > > https://github.com/serkan-ozal/jillegal > > On 16.01.2016 02:54, Khanh Nguyen wrote: > > Hi, > > > > I want to implement an off-heap, non-GC, non-contiguous object space. Of > > course my naive approach is to call os::malloc or the existing macro > > AllocateHeap(). Also I did turn the compressed oops flags off. But I'm > > facing this undeterministic issue: randomly the JVM crashes. That is, > > sometimes my program can successfully run (with the correct result). And > > sometimes it crashes (in library code) > > From kim.barrett at oracle.com Wed Jan 20 17:22:49 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 20 Jan 2016 12:22:49 -0500 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569F9896.9030009@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> <569F9896.9030009@oracle.com> Message-ID: On Jan 20, 2016, at 9:24 AM, Coleen Phillimore wrote: > > [,,,] Although I thought you were going to move _vtable_len to Klass ? That move comes later - see the plan discussed in [1] from Mikael?s original review request. >> On 2016-01-15 18:04, Mikael Gerdin wrote: >>> Hi all, >>> >>> As per the previous discussion in mid-December[0] about moving the >>> _vtable_length field to class Klass, here's the first RFR and webrev, >>> according to my suggested plan[1]: >>> >>> [?] >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html From coleen.phillimore at oracle.com Wed Jan 20 17:53:43 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Jan 2016 12:53:43 -0500 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> <569F9896.9030009@oracle.com> Message-ID: <569FC9A7.7000101@oracle.com> On 1/20/16 12:22 PM, Kim Barrett wrote: > On Jan 20, 2016, at 9:24 AM, Coleen Phillimore wrote: >> [,,,] Although I thought you were going to move _vtable_len to Klass ? > That move comes later - see the plan discussed in [1] from Mikael?s original review request. I see. Although all the same places have to be changed from InstanceKlass:: to Klass:: That hopefully will be a boring code review. Coleen > >>> On 2016-01-15 18:04, Mikael Gerdin wrote: >>>> Hi all, >>>> >>>> As per the previous discussion in mid-December[0] about moving the >>>> _vtable_length field to class Klass, here's the first RFR and webrev, >>>> according to my suggested plan[1]: >>>> >>>> [?] >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html From mikael.gerdin at oracle.com Wed Jan 20 18:23:05 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Jan 2016 19:23:05 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569FC9A7.7000101@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> <569F9896.9030009@oracle.com> <569FC9A7.7000101@oracle.com> Message-ID: <569FD089.4050702@oracle.com> Hi Coleen, On 2016-01-20 18:53, Coleen Phillimore wrote: > > > On 1/20/16 12:22 PM, Kim Barrett wrote: >> On Jan 20, 2016, at 9:24 AM, Coleen Phillimore >> wrote: >>> [,,,] Although I thought you were going to move _vtable_len to Klass ? >> That move comes later - see the plan discussed in [1] from Mikael?s >> original review request. > > I see. Although all the same places have to be changed from > InstanceKlass:: to Klass:: That hopefully will be a boring code review. Yes, it will be fairly boring. I wanted to separate the three changes primarily for the purpose of getting them tested separately. /Mikael > Coleen > >> >>>> On 2016-01-15 18:04, Mikael Gerdin wrote: >>>>> Hi all, >>>>> >>>>> As per the previous discussion in mid-December[0] about moving the >>>>> _vtable_length field to class Klass, here's the first RFR and webrev, >>>>> according to my suggested plan[1]: >>>>> >>>>> [?] >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >>>>> > From mikael.gerdin at oracle.com Wed Jan 20 18:28:01 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Jan 2016 19:28:01 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569F9896.9030009@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> <569F9896.9030009@oracle.com> Message-ID: <569FD1B1.4000504@oracle.com> Hi Coleen, On 2016-01-20 15:24, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/src/share/vm/oops/klassVtable.hpp.udiff.html > > > I thought this would return ByteSize? I thought about it but there wasn't really any precedent for using ByteSize, instead several methods had the _in_bytes suffix and in that case I thought that forcing all users to do in_bytes(klassVtable::size_in_bytes()) would be a bit too much. In the case of the InstanceKlass variants some architectures have Address objects in their assembler implementations which allow me to pass a ByteSize, allowing me to skip the in_bytes(..) in at least some cases. > > This looks really good. Although I thought you were going to move > _vtable_len to Klass ? As Kim said, that's coming up next. Thanks for the review. /Mikael > > Coleen > > On 1/20/16 7:31 AM, Mikael Gerdin wrote: >> Hi again, >> >> I've rebased the on hs-rt and had to include some additional changes >> for JVMCI. >> I've also updated the copyright years. >> Unfortunately I can't generate an incremental webrev since i rebased >> the patch and there's no good way that I know of to make that work >> with webrev. >> >> New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ >> >> Testing: JPRT again (which includes the JVMCI jtreg tests) >> >> /Mikael >> >> On 2016-01-15 18:04, Mikael Gerdin wrote: >>> Hi all, >>> >>> As per the previous discussion in mid-December[0] about moving the >>> _vtable_length field to class Klass, here's the first RFR and webrev, >>> according to my suggested plan[1]: >>> >>>> My current plan is to first modify the vtable_length_offset accessor to >>>> return a byte offset (which is what it's translated to by all callers). >>>> >>>> Then I'll tackle moving the _vtable_len field to Klass. >>>> >>>> Finally I'll try to consolidate the vtable related methods to Klass, >>>> where they belong. >>> >>> This change actually consists of three changes: >>> * modifying InstanceKlass::vtable_length_offset to become a byte offset >>> and use the ByteSize type to communicate the scaling. >>> * modifying InstanceKlass::vtable_start_offset to become a byte offset >>> and use the ByteSize type, for symmetry reasons mainly. >>> * adding a vtableEntry::size_in_bytes() since in many places the vtable >>> entry size is used in combination with the vtable start to compute a >>> byte offset for vtable lookups. >>> >>> I don't foresee any issues with the fact that the byte offset is >>> represented as an int, for two reasons: >>> 1) If the offset of any of these grows to over 2 gigabytes then we have >>> a huge footprint problem with InstanceKlass >>> 2) The offsets are converted to byte offsets and stored in ints already >>> in the cpu specific code I've modified. >>> >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >>> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >>> >>> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >>> PPC64 would be much appreciated, appropriate mailing lists have been >>> CC:ed to notify them of the request. >>> >>> >>> [0] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >>> >>> >>> >>> Thanks! >>> /Mikael >> > From kim.barrett at oracle.com Wed Jan 20 21:17:45 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 20 Jan 2016 16:17:45 -0500 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <689EDF13-743A-42C0-AF9C-847CB18AD1A9@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> <17F38477-524C-4499-94BF-1BADF57BCA3B@oracle.com> <2E1EE1D0-0F64-42D6-BBB6-87EC9A0A6A2D@oracle.com> <689EDF13-743A-42C0-AF9C-847CB18AD1A9@oracle.com> Message-ID: <24AC3E4D-4DD4-4DB1-BCD7-A5A7193386CF@oracle.com> On Jan 19, 2016, at 9:06 PM, John Rose wrote: > > On Jan 19, 2016, at 5:07 PM, Kim Barrett wrote: >> >> It doesn't look like the logging code has anything like that. I think >> it would need to be an addition to Log<>::vwrite. [...] I'll file an RFE for this. > > Thank you. If you get inspired to roll this in now, I'd support that. I decided not to take that on right now, instead filing https://bugs.openjdk.java.net/browse/JDK-8147866 >>> Nice catches on the va_copy and buffer overrun. How did you find >>> the log_func(foo) instead of log_func("%s", foo)? Please tell me it >>> was a gcc warning; if not then we have some software rot going on. >> >> Sorry, but I found it the hard way, via a crash (I think it was the >> assert in Log<>::vwrite). logStream::_log_func is a function pointer. >> Maybe we can attach an ATTRIBUTE_PRINTF to the data member and/or to >> the logStream constructor argument? And maybe that would produce the >> desired warnings? I think attaching that attribute would have >> generated a warning for the non-literal format string being passed to >> _log_func. > > OK, yes; that's what I mean by software rot. We went to a lot of > trouble to annotate and fix the the format problems, and now they > are building up again as people add new functions without the > annotation. Putting in the annotations is really part of making > a firm fix to the "%s" problem, not just reacting to crashers as > they show up. Fix the root cause, not just the crash. Agreed that we want to maintain our format attribute annotations. The logging package appears to have that. It looks like this one case of a pointer to a format function was simply overlooked. I tried adding the attribute with the original code, and indeed it does result in a warning: error: format not a string literal and no format arguments [-Werror=format-security] Which is a useful warning here; correct diagnosis and handling of the warning would have prevented the re-format bug. So here?s a new set of webrevs: full: http://cr.openjdk.java.net/~kbarrett/8146793/webrev.01/ incr: http://cr.openjdk.java.net/~kbarrett/8146793/webrev.01.inc/ From chris.plummer at oracle.com Thu Jan 21 03:17:35 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 20 Jan 2016 19:17:35 -0800 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <569F7E22.3090905@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> Message-ID: <56A04DCF.9090204@oracle.com> Hi Mikael, The changes look good except I think you should get someone from the compiler team to make sure the change in HotSpotResolvedJavaMethodImpl.java and HotSpotVMConfig.java are ok. I'm not sure why you chose to remove instanceKlassVtableStartOffset() rather than just fix it. I think some of your changes may conflict with my changes for JDK-8143608. Coleen is pushing JDK-8143608 for me once hs-rt opens up. I'd appreciate it if you could wait until after then before doing your push. thanks, Chris On 1/20/16 4:31 AM, Mikael Gerdin wrote: > Hi again, > > I've rebased the on hs-rt and had to include some additional changes > for JVMCI. > I've also updated the copyright years. > Unfortunately I can't generate an incremental webrev since i rebased > the patch and there's no good way that I know of to make that work > with webrev. > > New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ > > Testing: JPRT again (which includes the JVMCI jtreg tests) > > /Mikael > > On 2016-01-15 18:04, Mikael Gerdin wrote: >> Hi all, >> >> As per the previous discussion in mid-December[0] about moving the >> _vtable_length field to class Klass, here's the first RFR and webrev, >> according to my suggested plan[1]: >> >>> My current plan is to first modify the vtable_length_offset accessor to >>> return a byte offset (which is what it's translated to by all callers). >>> >>> Then I'll tackle moving the _vtable_len field to Klass. >>> >>> Finally I'll try to consolidate the vtable related methods to Klass, >>> where they belong. >> >> This change actually consists of three changes: >> * modifying InstanceKlass::vtable_length_offset to become a byte offset >> and use the ByteSize type to communicate the scaling. >> * modifying InstanceKlass::vtable_start_offset to become a byte offset >> and use the ByteSize type, for symmetry reasons mainly. >> * adding a vtableEntry::size_in_bytes() since in many places the vtable >> entry size is used in combination with the vtable start to compute a >> byte offset for vtable lookups. >> >> I don't foresee any issues with the fact that the byte offset is >> represented as an int, for two reasons: >> 1) If the offset of any of these grows to over 2 gigabytes then we have >> a huge footprint problem with InstanceKlass >> 2) The offsets are converted to byte offsets and stored in ints already >> in the cpu specific code I've modified. >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >> >> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >> PPC64 would be much appreciated, appropriate mailing lists have been >> CC:ed to notify them of the request. >> >> >> [0] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >> >> >> >> Thanks! >> /Mikael > From ktruong.nguyen at gmail.com Wed Jan 20 04:27:15 2016 From: ktruong.nguyen at gmail.com (Khanh Nguyen) Date: Tue, 19 Jan 2016 20:27:15 -0800 Subject: Off-heap object space In-Reply-To: <569F0642.1060902@oracle.com> References: <569F0642.1060902@oracle.com> Message-ID: On Tue, Jan 19, 2016 at 8:00 PM, David Holmes wrote: > Hi, > > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), > > si_addr=0x00007fd723ee00be > > This address is not suitably aligned for an Object - they require 8-byte > alignment. I believe the address is not pointing to an Object (at least objects that are allocated in my off-heap space). I printed all address of objects allocated in my space and the address of si_addr is always higher than the last object's address printed. Also it doesn't belong to the address range that I reserved for my space. > > > David > > > On 16/01/2016 11:54 AM, Khanh Nguyen wrote: > >> Hi, >> >> I want to implement an off-heap, non-GC, non-contiguous object space. Of >> course my naive approach is to call os::malloc or the existing macro >> AllocateHeap(). Also I did turn the compressed oops flags off. But I'm >> facing this undeterministic issue: randomly the JVM crashes. That is, >> sometimes my program can successfully run (with the correct result). And >> sometimes it crashes (in library code) >> >> Partial crash log is this: >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007fd71102681d, pid=6741, tid=140562059818752 >> # >> # JRE version: OpenJDK Runtime Environment (8.0) (build >> 1.8.0-internal-debug-khanhtn1_2016_01_15_17_06-b00) >> # Java VM: OpenJDK 64-Bit Server VM (25.0-b70-debug interpreted mode >> linux-amd64 ) >> # Problematic frame: >> # j >> >> java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 >> # >> # Core dump written. Default location: >> /lv_scratch/scratch/khanh/openjdk8/core or core.6741 >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00007fd72000a800): JavaThread "main" [_thread_in_Java, >> id=6742, stack(0x00007fd72794f000,0x00007fd727a50000)] >> >> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), >> si_addr=0x00007fd723ee00be >> >> Registers: >> RAX=0x00007fd6110fc818, RBX=0x00007fd0ae129248, RCX=0x0000000000000000, >> RDX=0x0000003fe88800be >> RSP=0x00007fd727a4e428, RBP=0x00007fd727a4e480, RSI=0x00007fd727a4e3b8, >> RDI=0x0000000001200020 >> R8 =0x0000000000000000, R9 =0x0000000000000024, R10=0x00007f973b660000, >> R11=0x00007fd727a4e390 >> R12=0x00007fd711000564, R13=0x00007fd0ae124bb3, R14=0x00007fd727a4e4f0, >> R15=0x00007fd72000a800 >> RIP=0x00007fd71102681d, EFLAGS=0x0000000000010206, >> CSGSFS=0x0000000000000033, ERR=0x0000000000000006 >> TRAPNO=0x000000000000000e >> >> Stack: [0x00007fd72794f000,0x00007fd727a50000], sp=0x00007fd727a4e428, >> free space=1021k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> j >> >> java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;+56 >> j >> >> java.util.HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+9 >> j EmptyMethod.generateHashMap()Ljava/util/HashMap;+44 >> j EmptyMethod.runTest(I)V+24 >> j EmptyMethod.main([Ljava/lang/String;)V+97 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x823762] JavaCalls::call_helper(JavaValue*, methodHandle*, >> JavaCallArguments*, Thread*)+0x680 >> V [libjvm.so+0xaaae44] os::os_exception_wrapper(void (*)(JavaValue*, >> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >> JavaCallArguments*, Thread*)+0x3a >> V [libjvm.so+0x8230db] JavaCalls::call(JavaValue*, methodHandle, >> JavaCallArguments*, Thread*)+0x7d >> V [libjvm.so+0x837185] jni_invoke_static(JNIEnv_*, JavaValue*, >> _jobject*, >> JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x1ca >> V [libjvm.so+0x84d31e] jni_CallStaticVoidMethod+0x385 >> C [libjli.so+0x8012] JavaMain+0x89a >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x00007fd72014c000 JavaThread "Service Thread" daemon [_thread_blocked, >> id=6765, stack(0x00007fd0a9e37000,0x00007fd0a9f38000)] >> 0x00007fd720142800 JavaThread "Signal Dispatcher" daemon >> [_thread_blocked, id=6764, stack(0x00007fd0a9f38000,0x00007fd0aa039000)] >> 0x00007fd7200e9000 JavaThread "Finalizer" daemon [_thread_blocked, >> id=6763, stack(0x00007fd110058000,0x00007fd110159000)] >> 0x00007fd7200e6800 JavaThread "Reference Handler" daemon >> [_thread_blocked, id=6762, stack(0x00007fd0aa039000,0x00007fd0aa13a000)] >> =>0x00007fd72000a800 JavaThread "main" [_thread_in_Java, id=6742, >> stack(0x00007fd72794f000,0x00007fd727a50000)] >> >> Other Threads: >> 0x00007fd7200db800 VMThread [stack: >> 0x00007fd0aa13a000,0x00007fd0aa23b000] [id=6761] >> 0x00007fd720150000 WatcherThread [stack: >> 0x00007fd0a9d36000,0x00007fd0a9e37000] [id=6766] >> >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: None >> >> Heap: >> PSYoungGen total 5120K, used 2088K [0x00007fd611000000, >> 0x00007fd611b00000, 0x00007fd711000000) >> eden space 4096K, 25% used >> [0x00007fd611000000,0x00007fd61110a278,0x00007fd611400000) >> from space 1024K, 100% used >> [0x00007fd611400000,0x00007fd611500000,0x00007fd611500000) >> to space 1536K, 0% used >> [0x00007fd611980000,0x00007fd611980000,0x00007fd611b00000) >> ParOldGen total 512512K, used 1128K [0x00007fd411000000, >> 0x00007fd430480000, 0x00007fd611000000) >> object space 512512K, 0% used >> [0x00007fd411000000,0x00007fd41111a0c0,0x00007fd430480000) >> Metaspace used 3255K, capacity 4108K, committed 4352K, reserved >> 8192K >> >> Card table byte_map: [0x00007fd7256e8000,0x00007fd726ee9000] >> byte_map_base: >> 0x00007f973b660000 >> >> Marking Bits: (ParMarkBitMap*) 0x00007fd728f79340 >> Begin Bits: [0x00007fd0b0000000, 0x00007fd0bc000000) >> End Bits: [0x00007fd0bc000000, 0x00007fd0c8000000) >> >> Polling page: 0x00007fd7291f5000 >> >> CodeCache: size=245760Kb used=1439Kb max_used=1439Kb free=244320Kb >> bounds [0x00007fd711000000, 0x00007fd711270000, 0x00007fd720000000] >> total_blobs=189 nmethods=0 adapters=164 >> compilation: disabled (interpreter mode) >> >> >> Using gdb doesn't show anything interesting unfortunately >> #2 0x00007fd023d393a3 in os::abort (dump_core=true) at >> /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:1563 >> #3 0x00007fd023efacdd in VMError::report_and_die (this=0x7fd023293d00) at >> /scratch/khanh/openjdk8/hotspot/src/share/vm/utilities/vmError.cpp:1078 >> #4 0x00007fd023d453d9 in JVM_handle_linux_signal (sig=11, >> info=0x7fd023293fb0, ucVoid=0x7fd023293e80, abort_if_unrecognized=1) at >> >> /scratch/khanh/openjdk8/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:534 >> #5 0x00007fd023d3eebf in signalHandler (sig=11, info=0x7fd023293fb0, >> uc=0x7fd023293e80) at >> /scratch/khanh/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4278 >> #6 >> #7 0x00007fd00d02681d in ?? () >> #8 0x00007fcf0d0feee0 in ?? () >> #9 0x0000000000000002 in ?? () >> #10 0x00007fc9e95c9c58 in ?? () >> #11 0x00007fd023294440 in ?? () >> #12 0x00007fca09c71bb0 in ?? () >> #13 0x00007fd0232944f0 in ?? () >> #14 0x00007fca09c74e30 in ?? () >> #15 0x0000000000000000 in ?? () >> >> So my questions, specifically, are >> 1) Why SEGV_ACCERR? And any idea of where the problem might be? >> >> 2) In theory, it should be straightforward for me to have an off-heap >> space >> where I can allocate objects in. I don't understand why there is a random >> crash like what I have. I mean if I violate some implicit rules in >> Hotspot, >> my program should fail always. >> >> Any pointers/suggestions are greatly appreciated. >> >> Thank you, >> >> From john.r.rose at oracle.com Thu Jan 21 07:38:23 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 20 Jan 2016 23:38:23 -0800 Subject: RFR: 8146793: logStream::write re-formats string In-Reply-To: <24AC3E4D-4DD4-4DB1-BCD7-A5A7193386CF@oracle.com> References: <753C97D8-9BBE-4399-A503-B6175A62D9CD@oracle.com> <17F38477-524C-4499-94BF-1BADF57BCA3B@oracle.com> <2E1EE1D0-0F64-42D6-BBB6-87EC9A0A6A2D@oracle.com> <689EDF13-743A-42C0-AF9C-847CB18AD1A9@oracle.com> <24AC3E4D-4DD4-4DB1-BCD7-A5A7193386CF@oracle.com> Message-ID: Yes, that's it. Thanks! ? John > On Jan 20, 2016, at 1:17 PM, Kim Barrett wrote: > >> On Jan 19, 2016, at 9:06 PM, John Rose wrote: >> >>> On Jan 19, 2016, at 5:07 PM, Kim Barrett wrote: >>> >>> It doesn't look like the logging code has anything like that. I think >>> it would need to be an addition to Log<>::vwrite. [...] I'll file an RFE for this. >> >> Thank you. If you get inspired to roll this in now, I'd support that. > > I decided not to take that on right now, instead filing > https://bugs.openjdk.java.net/browse/JDK-8147866 > >>>> Nice catches on the va_copy and buffer overrun. How did you find >>>> the log_func(foo) instead of log_func("%s", foo)? Please tell me it >>>> was a gcc warning; if not then we have some software rot going on. >>> >>> Sorry, but I found it the hard way, via a crash (I think it was the >>> assert in Log<>::vwrite). logStream::_log_func is a function pointer. >>> Maybe we can attach an ATTRIBUTE_PRINTF to the data member and/or to >>> the logStream constructor argument? And maybe that would produce the >>> desired warnings? I think attaching that attribute would have >>> generated a warning for the non-literal format string being passed to >>> _log_func. >> >> OK, yes; that's what I mean by software rot. We went to a lot of >> trouble to annotate and fix the the format problems, and now they >> are building up again as people add new functions without the >> annotation. Putting in the annotations is really part of making >> a firm fix to the "%s" problem, not just reacting to crashers as >> they show up. Fix the root cause, not just the crash. > > Agreed that we want to maintain our format attribute annotations. The > logging package appears to have that. It looks like this one case of a > pointer to a format function was simply overlooked. > > I tried adding the attribute with the original code, and indeed it does result in a warning: > > error: format not a string literal and no format arguments [-Werror=format-security] > > Which is a useful warning here; correct diagnosis and handling of the > warning would have prevented the re-format bug. > > So here?s a new set of webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8146793/webrev.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8146793/webrev.01.inc/ > From per.liden at oracle.com Thu Jan 21 08:02:52 2016 From: per.liden at oracle.com (Per Liden) Date: Thu, 21 Jan 2016 09:02:52 +0100 Subject: RFR(s) 8147918: Rename develop_log_is_enabled() to log_develop_is_enabled() Message-ID: <56A090AC.5030606@oracle.com> Hi, All logging macros exposed for public consumption by the Unified logging framework follows the naming convention "log_*", except for develop_log_is_enabled(). This patch renames that macro to log_develop_is_enabled(). With such a rename we will have: log_trace log_debug log_info log_warning log_error log_is_enabled followed by the develop versions: log_develop_trace log_develop_debug log_develop_info log_develop_warning log_develop_error log_develop_is_enabled (instead of develop_log_is_enabled) Webrev: http://cr.openjdk.java.net/~pliden/8147918/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147918 cheers, Per From david.holmes at oracle.com Thu Jan 21 08:24:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jan 2016 18:24:05 +1000 Subject: RFR(s) 8147918: Rename develop_log_is_enabled() to log_develop_is_enabled() In-Reply-To: <56A090AC.5030606@oracle.com> References: <56A090AC.5030606@oracle.com> Message-ID: <56A095A5.3090500@oracle.com> Looks good to me! Thanks, David On 21/01/2016 6:02 PM, Per Liden wrote: > Hi, > > All logging macros exposed for public consumption by the Unified logging > framework follows the naming convention "log_*", except for > develop_log_is_enabled(). This patch renames that macro to > log_develop_is_enabled(). With such a rename we will have: > > log_trace > log_debug > log_info > log_warning > log_error > log_is_enabled > > followed by the develop versions: > > log_develop_trace > log_develop_debug > log_develop_info > log_develop_warning > log_develop_error > log_develop_is_enabled (instead of develop_log_is_enabled) > > > Webrev: http://cr.openjdk.java.net/~pliden/8147918/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147918 > > cheers, > Per From bengt.rutisson at oracle.com Thu Jan 21 08:34:03 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 21 Jan 2016 09:34:03 +0100 Subject: RFR(s) 8147918: Rename develop_log_is_enabled() to log_develop_is_enabled() In-Reply-To: <56A090AC.5030606@oracle.com> References: <56A090AC.5030606@oracle.com> Message-ID: <56A097FB.40809@oracle.com> Hi Per, Looks good. Thanks, Bengt On 2016-01-21 09:02, Per Liden wrote: > Hi, > > All logging macros exposed for public consumption by the Unified > logging framework follows the naming convention "log_*", except for > develop_log_is_enabled(). This patch renames that macro to > log_develop_is_enabled(). With such a rename we will have: > > log_trace > log_debug > log_info > log_warning > log_error > log_is_enabled > > followed by the develop versions: > > log_develop_trace > log_develop_debug > log_develop_info > log_develop_warning > log_develop_error > log_develop_is_enabled (instead of develop_log_is_enabled) > > > Webrev: http://cr.openjdk.java.net/~pliden/8147918/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147918 > > cheers, > Per From magnus.ihse.bursie at oracle.com Thu Jan 21 10:37:36 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 Jan 2016 11:37:36 +0100 Subject: build_vm_def.sh broken on macosx? Message-ID: <56A0B4F0.1040103@oracle.com> Hi, It seems that build_vm_def.sh is broken on macosx. The script lists all from *.o using nm, and filters them using this awk expression: '{ if ($3 ~ /^_ZTV/ || $3 ~ /^gHotSpotVM/) print "\t" $3 }' However, the typical output from nm on macosx looks like this: __ZTV10methodOper __ZTV11MachNopNode That is, only a single column, and two leading underscore. The awk expression will fail to match anything, and an empty vm.def will be produced. If I modify the script to: '{ if ($1 ~ /^__ZTV/ || $1 ~ /^_gHotSpotVM/) print "\t" $1 }' then it will match and print these symbols. The build_vm_def.sh script has not been modified since 2013, so if this ever worked, then most likely the nm output has changed in Xcode at some point. My main concern here is the new hotspot build. Does this mean that the vm.def fills no purpose on the macosx build, and that the whole process of running nm on all object files can be skipped? Or is this a bug that has not been discovered? If so, it should be fixed in the old build. /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 21 14:01:22 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 21 Jan 2016 15:01:22 +0100 Subject: build_vm_def.sh broken on macosx? In-Reply-To: <56A0B4F0.1040103@oracle.com> References: <56A0B4F0.1040103@oracle.com> Message-ID: <56A0E4B2.60400@oracle.com> On 2016-01-21 11:37, Magnus Ihse Bursie wrote: > Hi, > > It seems that build_vm_def.sh is broken on macosx. The script lists > all from *.o using nm, and filters them using this awk expression: > '{ if ($3 ~ /^_ZTV/ || $3 ~ /^gHotSpotVM/) print "\t" $3 }' > > However, the typical output from nm on macosx looks like this: > __ZTV10methodOper > __ZTV11MachNopNode > > That is, only a single column, and two leading underscore. The awk > expression will fail to match anything, and an empty vm.def will be > produced. > > If I modify the script to: > '{ if ($1 ~ /^__ZTV/ || $1 ~ /^_gHotSpotVM/) print "\t" $1 }' > then it will match and print these symbols. However, then the linker will fail, spewing out tons of ld: warning: cannot export hidden symbol vtable for sarI_mem_1Node from ad_x86_64_misc.o I believe this is the result of compiling with -fvisibility=hidden, but I have not dug any further into the issue. /Magnus > > The build_vm_def.sh script has not been modified since 2013, so if > this ever worked, then most likely the nm output has changed in Xcode > at some point. > > My main concern here is the new hotspot build. Does this mean that the > vm.def fills no purpose on the macosx build, and that the whole > process of running nm on all object files can be skipped? Or is this a > bug that has not been discovered? If so, it should be fixed in the old > build. > > /Magnus From per.liden at oracle.com Thu Jan 21 17:26:23 2016 From: per.liden at oracle.com (Per Liden) Date: Thu, 21 Jan 2016 18:26:23 +0100 Subject: RFR(s) 8147918: Rename develop_log_is_enabled() to log_develop_is_enabled() In-Reply-To: <56A095A5.3090500@oracle.com> References: <56A090AC.5030606@oracle.com> <56A095A5.3090500@oracle.com> Message-ID: <56A114BF.7060702@oracle.com> Thanks David, thanks Bengt! cheers, Per On 2016-01-21 09:24, David Holmes wrote: > Looks good to me! > > Thanks, > David > > On 21/01/2016 6:02 PM, Per Liden wrote: >> Hi, >> >> All logging macros exposed for public consumption by the Unified logging >> framework follows the naming convention "log_*", except for >> develop_log_is_enabled(). This patch renames that macro to >> log_develop_is_enabled(). With such a rename we will have: >> >> log_trace >> log_debug >> log_info >> log_warning >> log_error >> log_is_enabled >> >> followed by the develop versions: >> >> log_develop_trace >> log_develop_debug >> log_develop_info >> log_develop_warning >> log_develop_error >> log_develop_is_enabled (instead of develop_log_is_enabled) >> >> >> Webrev: http://cr.openjdk.java.net/~pliden/8147918/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147918 >> >> cheers, >> Per From mikael.gerdin at oracle.com Fri Jan 22 09:46:32 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 22 Jan 2016 10:46:32 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <56A04DCF.9090204@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> <56A04DCF.9090204@oracle.com> Message-ID: <56A1FA78.3090608@oracle.com> Hi Chris, On 2016-01-21 04:17, Chris Plummer wrote: > Hi Mikael, > > The changes look good except I think you should get someone from the > compiler team to make sure the change in > HotSpotResolvedJavaMethodImpl.java and HotSpotVMConfig.java are ok. I'm > not sure why you chose to remove instanceKlassVtableStartOffset() rather > than just fix it. I'm cc:ing hotspot-compiler-dev and graal-dev to see if I can get someone to ok the JVMCI parts. The reason for removing the method is that the only reason for it being a method was to apply the wordSize scaling on the value and since I changed the offset to be a byte offset it does not need scaling and can be treated similar to the other constants in HotSpotVMConfig which are accessed without any accessor method. > > I think some of your changes may conflict with my changes for > JDK-8143608. Coleen is pushing JDK-8143608 for me once hs-rt opens up. > I'd appreciate it if you could wait until after then before doing your > push. Will do, would you mind pinging me when you've integrated 8143608? /Mikael > > thanks, > > Chris > > On 1/20/16 4:31 AM, Mikael Gerdin wrote: >> Hi again, >> >> I've rebased the on hs-rt and had to include some additional changes >> for JVMCI. >> I've also updated the copyright years. >> Unfortunately I can't generate an incremental webrev since i rebased >> the patch and there's no good way that I know of to make that work >> with webrev. >> >> New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ >> >> Testing: JPRT again (which includes the JVMCI jtreg tests) >> >> /Mikael >> >> On 2016-01-15 18:04, Mikael Gerdin wrote: >>> Hi all, >>> >>> As per the previous discussion in mid-December[0] about moving the >>> _vtable_length field to class Klass, here's the first RFR and webrev, >>> according to my suggested plan[1]: >>> >>>> My current plan is to first modify the vtable_length_offset accessor to >>>> return a byte offset (which is what it's translated to by all callers). >>>> >>>> Then I'll tackle moving the _vtable_len field to Klass. >>>> >>>> Finally I'll try to consolidate the vtable related methods to Klass, >>>> where they belong. >>> >>> This change actually consists of three changes: >>> * modifying InstanceKlass::vtable_length_offset to become a byte offset >>> and use the ByteSize type to communicate the scaling. >>> * modifying InstanceKlass::vtable_start_offset to become a byte offset >>> and use the ByteSize type, for symmetry reasons mainly. >>> * adding a vtableEntry::size_in_bytes() since in many places the vtable >>> entry size is used in combination with the vtable start to compute a >>> byte offset for vtable lookups. >>> >>> I don't foresee any issues with the fact that the byte offset is >>> represented as an int, for two reasons: >>> 1) If the offset of any of these grows to over 2 gigabytes then we have >>> a huge footprint problem with InstanceKlass >>> 2) The offsets are converted to byte offsets and stored in ints already >>> in the cpu specific code I've modified. >>> >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >>> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >>> >>> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >>> PPC64 would be much appreciated, appropriate mailing lists have been >>> CC:ed to notify them of the request. >>> >>> >>> [0] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >>> >>> >>> >>> Thanks! >>> /Mikael >> > From coleen.phillimore at oracle.com Fri Jan 22 14:04:13 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Jan 2016 09:04:13 -0500 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <56A1FA78.3090608@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> <56A04DCF.9090204@oracle.com> <56A1FA78.3090608@oracle.com> Message-ID: <56A236DD.6020301@oracle.com> On 1/22/16 4:46 AM, Mikael Gerdin wrote: > Hi Chris, > > On 2016-01-21 04:17, Chris Plummer wrote: >> Hi Mikael, >> >> The changes look good except I think you should get someone from the >> compiler team to make sure the change in >> HotSpotResolvedJavaMethodImpl.java and HotSpotVMConfig.java are ok. I'm >> not sure why you chose to remove instanceKlassVtableStartOffset() rather >> than just fix it. > > I'm cc:ing hotspot-compiler-dev and graal-dev to see if I can get > someone to ok the JVMCI parts. > > The reason for removing the method is that the only reason for it > being a method was to apply the wordSize scaling on the value and > since I changed the offset to be a byte offset it does not need > scaling and can be treated similar to the other constants in > HotSpotVMConfig which are accessed without any accessor method. > >> >> I think some of your changes may conflict with my changes for >> JDK-8143608. Coleen is pushing JDK-8143608 for me once hs-rt opens up. >> I'd appreciate it if you could wait until after then before doing your >> push. > > Will do, would you mind pinging me when you've integrated 8143608? I'm waiting for the repo to open, but yes, I'll let you know. Coleen > > /Mikael > >> >> thanks, >> >> Chris >> >> On 1/20/16 4:31 AM, Mikael Gerdin wrote: >>> Hi again, >>> >>> I've rebased the on hs-rt and had to include some additional changes >>> for JVMCI. >>> I've also updated the copyright years. >>> Unfortunately I can't generate an incremental webrev since i rebased >>> the patch and there's no good way that I know of to make that work >>> with webrev. >>> >>> New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ >>> >>> Testing: JPRT again (which includes the JVMCI jtreg tests) >>> >>> /Mikael >>> >>> On 2016-01-15 18:04, Mikael Gerdin wrote: >>>> Hi all, >>>> >>>> As per the previous discussion in mid-December[0] about moving the >>>> _vtable_length field to class Klass, here's the first RFR and webrev, >>>> according to my suggested plan[1]: >>>> >>>>> My current plan is to first modify the vtable_length_offset >>>>> accessor to >>>>> return a byte offset (which is what it's translated to by all >>>>> callers). >>>>> >>>>> Then I'll tackle moving the _vtable_len field to Klass. >>>>> >>>>> Finally I'll try to consolidate the vtable related methods to Klass, >>>>> where they belong. >>>> >>>> This change actually consists of three changes: >>>> * modifying InstanceKlass::vtable_length_offset to become a byte >>>> offset >>>> and use the ByteSize type to communicate the scaling. >>>> * modifying InstanceKlass::vtable_start_offset to become a byte offset >>>> and use the ByteSize type, for symmetry reasons mainly. >>>> * adding a vtableEntry::size_in_bytes() since in many places the >>>> vtable >>>> entry size is used in combination with the vtable start to compute a >>>> byte offset for vtable lookups. >>>> >>>> I don't foresee any issues with the fact that the byte offset is >>>> represented as an int, for two reasons: >>>> 1) If the offset of any of these grows to over 2 gigabytes then we >>>> have >>>> a huge footprint problem with InstanceKlass >>>> 2) The offsets are converted to byte offsets and stored in ints >>>> already >>>> in the cpu specific code I've modified. >>>> >>>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >>>> >>>> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >>>> PPC64 would be much appreciated, appropriate mailing lists have been >>>> CC:ed to notify them of the request. >>>> >>>> >>>> [0] >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >>>> >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >>>> >>>> >>>> >>>> >>>> Thanks! >>>> /Mikael >>> >> > From mikael.gerdin at oracle.com Fri Jan 22 15:49:11 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 22 Jan 2016 16:49:11 +0100 Subject: RFR(M) 8148047: Move the vtable length field to Klass Message-ID: <56A24F77.6030804@oracle.com> Hi all, Here's the second part of the set of changes to move most of the vtable related code to Klass. This change consists of the following parts: * Move the field _vtable_len to Klass, making its accessor nonvirtual. -> Ensure that this does not result in any footprint regression by moving TRACE_DEFINE_KLASS_TRACE_ID in Klass and _itable_len in InstanceKlass to fill out alignment gaps. -> Move vtable_length_offset to Klass. Move vtable_start_offset to Klass to keep the code consistent. vtable_start_offset depends on the size of InstanceKlass and must therefore be defined outside of klass.hpp. * Update all locations to refer to Klass::vtable_{length,start}_offset instead of InstanceKlass. * Modify SA to look for _vtable_len in Klass. * Rename CompilerToVM::Data::InstanceKlass_vtable_{length,start}_offset and jdk.vm.ci.hotspot.HotSpotVMConfig.instanceKlassVtable{Length,Start}Offset to properly represent where the offsets are coming from. Webrev: http://cr.openjdk.java.net/~mgerdin/8148047/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8148047 Testing: JPRT on Oracle supported platforms. As in the previous change I've updated the PPC64 and AARCH64 ports but I have not tested the changes. Build and test feedback from porters is most welcome! Thanks /Mikael From jesper.wilhelmsson at oracle.com Fri Jan 22 17:09:19 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 22 Jan 2016 18:09:19 +0100 Subject: Current status of hs-rt Message-ID: <56A2623F.30503@oracle.com> Hi, We are currently hoping for the Thursday snapshot to be the one. The Thursday nightly hasn't finished yet but so far it looks OK. Right now there are two questions that needs to be resolved regarding this nightly. New failures may still show up. 1. One new bug was filed, JDK-8148052. Is this a blocker or not? 2. Is stressHierarchy003 in the GC baseline a known failure or a new one? Plus the big question that is still under investigation; Is JDK-8147865 a blocker or not. If the answer to these questions are [not, known, not], and the Friday nightly shows no surprises, we are good to integrate to main and open hs-rt for normal business on Monday. Thanks for your patience! /Jesper From jesper.wilhelmsson at oracle.com Fri Jan 22 17:12:23 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 22 Jan 2016 18:12:23 +0100 Subject: Current status of hs-rt In-Reply-To: <56A2623F.30503@oracle.com> References: <56A2623F.30503@oracle.com> Message-ID: <56A262F7.3040600@oracle.com> I just realized... Will there be a Friday nightly since there is some maintenance going on? /Jesper Den 22/1/16 kl. 18:09, skrev Jesper Wilhelmsson: > Hi, > > We are currently hoping for the Thursday snapshot to be the one. The Thursday > nightly hasn't finished yet but so far it looks OK. Right now there are two > questions that needs to be resolved regarding this nightly. New failures may > still show up. > > 1. One new bug was filed, JDK-8148052. Is this a blocker or not? > > 2. Is stressHierarchy003 in the GC baseline a known failure or a new one? > > Plus the big question that is still under investigation; Is JDK-8147865 a > blocker or not. > > If the answer to these questions are [not, known, not], and the Friday nightly > shows no surprises, we are good to integrate to main and open hs-rt for normal > business on Monday. > > Thanks for your patience! > /Jesper From daniel.daugherty at oracle.com Fri Jan 22 17:18:15 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 22 Jan 2016 10:18:15 -0700 Subject: Current status of hs-rt In-Reply-To: <56A262F7.3040600@oracle.com> References: <56A2623F.30503@oracle.com> <56A262F7.3040600@oracle.com> Message-ID: <56A26457.6070605@oracle.com> Doubtful. Dan On 1/22/16 10:12 AM, Jesper Wilhelmsson wrote: > I just realized... Will there be a Friday nightly since there is some > maintenance going on? > /Jesper > > Den 22/1/16 kl. 18:09, skrev Jesper Wilhelmsson: >> Hi, >> >> We are currently hoping for the Thursday snapshot to be the one. The >> Thursday >> nightly hasn't finished yet but so far it looks OK. Right now there >> are two >> questions that needs to be resolved regarding this nightly. New >> failures may >> still show up. >> >> 1. One new bug was filed, JDK-8148052. Is this a blocker or not? >> >> 2. Is stressHierarchy003 in the GC baseline a known failure or a new >> one? >> >> Plus the big question that is still under investigation; Is >> JDK-8147865 a >> blocker or not. >> >> If the answer to these questions are [not, known, not], and the >> Friday nightly >> shows no surprises, we are good to integrate to main and open hs-rt >> for normal >> business on Monday. >> >> Thanks for your patience! >> /Jesper From daniel.daugherty at oracle.com Fri Jan 22 17:27:30 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 22 Jan 2016 10:27:30 -0700 Subject: Current status of hs-rt In-Reply-To: <56A26457.6070605@oracle.com> References: <56A2623F.30503@oracle.com> <56A262F7.3040600@oracle.com> <56A26457.6070605@oracle.com> Message-ID: <56A26682.6070300@oracle.com> Ummmm... I'm having trouble looking at Aurora results for the new bug JDK-8148052... The Aurora server says that it is down... Dan On 1/22/16 10:18 AM, Daniel D. Daugherty wrote: > Doubtful. > > Dan > > On 1/22/16 10:12 AM, Jesper Wilhelmsson wrote: >> I just realized... Will there be a Friday nightly since there is some >> maintenance going on? >> /Jesper >> >> Den 22/1/16 kl. 18:09, skrev Jesper Wilhelmsson: >>> Hi, >>> >>> We are currently hoping for the Thursday snapshot to be the one. The >>> Thursday >>> nightly hasn't finished yet but so far it looks OK. Right now there >>> are two >>> questions that needs to be resolved regarding this nightly. New >>> failures may >>> still show up. >>> >>> 1. One new bug was filed, JDK-8148052. Is this a blocker or not? >>> >>> 2. Is stressHierarchy003 in the GC baseline a known failure or a new >>> one? >>> >>> Plus the big question that is still under investigation; Is >>> JDK-8147865 a >>> blocker or not. >>> >>> If the answer to these questions are [not, known, not], and the >>> Friday nightly >>> shows no surprises, we are good to integrate to main and open hs-rt >>> for normal >>> business on Monday. >>> >>> Thanks for your patience! >>> /Jesper > From christian.thalinger at oracle.com Fri Jan 22 18:01:38 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Jan 2016 08:01:38 -1000 Subject: RFR(M) 8148047: Move the vtable length field to Klass In-Reply-To: <56A24F77.6030804@oracle.com> References: <56A24F77.6030804@oracle.com> Message-ID: <3776D93D-4E6C-41F5-8F9C-E43B8D03AEEB@oracle.com> > On Jan 22, 2016, at 5:49 AM, Mikael Gerdin wrote: > > Hi all, > > Here's the second part of the set of changes to move most of the vtable related code to Klass. > > This change consists of the following parts: > * Move the field _vtable_len to Klass, making its accessor nonvirtual. > -> Ensure that this does not result in any footprint regression by moving TRACE_DEFINE_KLASS_TRACE_ID in Klass and _itable_len in InstanceKlass to fill out alignment gaps. > -> Move vtable_length_offset to Klass. Move vtable_start_offset to Klass to keep the code consistent. vtable_start_offset depends on the size of InstanceKlass and must therefore be defined outside of klass.hpp. > > * Update all locations to refer to Klass::vtable_{length,start}_offset instead of InstanceKlass. > > * Modify SA to look for _vtable_len in Klass. > > * Rename CompilerToVM::Data::InstanceKlass_vtable_{length,start}_offset > and jdk.vm.ci.hotspot.HotSpotVMConfig.instanceKlassVtable{Length,Start}Offset to properly represent where the offsets are coming from. We have to be careful with name changes in HotSpotVMConfig because that basically means we are changing the API (kind of, since the fields are public). Graal doesn?t use these fields only JVMCI itself so that change is good. > > > Webrev: http://cr.openjdk.java.net/~mgerdin/8148047/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8148047 > > Testing: JPRT on Oracle supported platforms. > > As in the previous change I've updated the PPC64 and AARCH64 ports but I have not tested the changes. Build and test feedback from porters is most welcome! > > Thanks > /Mikael From george.triantafillou at oracle.com Fri Jan 22 18:55:00 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 22 Jan 2016 13:55:00 -0500 Subject: Current status of hs-rt In-Reply-To: <56A26682.6070300@oracle.com> References: <56A2623F.30503@oracle.com> <56A262F7.3040600@oracle.com> <56A26457.6070605@oracle.com> <56A26682.6070300@oracle.com> Message-ID: <56A27B04.5040303@oracle.com> Yup, Aurora has been having trouble since late morning today. -George On 1/22/2016 12:27 PM, Daniel D. Daugherty wrote: > Ummmm... I'm having trouble looking at Aurora results for the new bug > JDK-8148052... The Aurora server says that it is down... > > Dan > > On 1/22/16 10:18 AM, Daniel D. Daugherty wrote: >> Doubtful. >> >> Dan >> >> On 1/22/16 10:12 AM, Jesper Wilhelmsson wrote: >>> I just realized... Will there be a Friday nightly since there is >>> some maintenance going on? >>> /Jesper >>> >>> Den 22/1/16 kl. 18:09, skrev Jesper Wilhelmsson: >>>> Hi, >>>> >>>> We are currently hoping for the Thursday snapshot to be the one. >>>> The Thursday >>>> nightly hasn't finished yet but so far it looks OK. Right now there >>>> are two >>>> questions that needs to be resolved regarding this nightly. New >>>> failures may >>>> still show up. >>>> >>>> 1. One new bug was filed, JDK-8148052. Is this a blocker or not? >>>> >>>> 2. Is stressHierarchy003 in the GC baseline a known failure or a >>>> new one? >>>> >>>> Plus the big question that is still under investigation; Is >>>> JDK-8147865 a >>>> blocker or not. >>>> >>>> If the answer to these questions are [not, known, not], and the >>>> Friday nightly >>>> shows no surprises, we are good to integrate to main and open hs-rt >>>> for normal >>>> business on Monday. >>>> >>>> Thanks for your patience! >>>> /Jesper >> > From chris.plummer at oracle.com Fri Jan 22 19:21:07 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Jan 2016 11:21:07 -0800 Subject: RFR(M) 8148047: Move the vtable length field to Klass In-Reply-To: <56A24F77.6030804@oracle.com> References: <56A24F77.6030804@oracle.com> Message-ID: <56A28123.3090203@oracle.com> Hi Mikael, On 1/22/16 7:49 AM, Mikael Gerdin wrote: > Hi all, > > Here's the second part of the set of changes to move most of the > vtable related code to Klass. > > This change consists of the following parts: > * Move the field _vtable_len to Klass, making its accessor nonvirtual. > -> Ensure that this does not result in any footprint regression by > moving TRACE_DEFINE_KLASS_TRACE_ID in Klass and _itable_len in > InstanceKlass to fill out alignment gaps. I also double checked this, including with minimal VM. The sizeof(Klass) remains unchanged. And your relocation of InstanceKlass::_itable_len should result in InstanceKlass being 8 bytes smaller on 64-bit, although I did not double check that. > -> Move vtable_length_offset to Klass. Move vtable_start_offset to > Klass to keep the code consistent. vtable_start_offset depends on the > size of InstanceKlass and must therefore be defined outside of klass.hpp. The abstraction has kind of gone awry: 662 ByteSize Klass::vtable_start_offset() { 663 return in_ByteSize(InstanceKlass::header_size() * wordSize); 664 } Note the reference to InstanceKlass. I understand why you are doing this. All Klass subclasses have their sizes padded out to the size of InstanceKlass so the vtable is always in the same place. I was just wondering if there is a cleaner way. I guess the abstraction was broken before your changes, but in a different place. We used to call InstanceKlass::vtable_start_offset() even for array types. Now you instead call Klass::vtable_start_offset(), and it does the dirty deed of referencing InstanceKlass. I guess I'm ok with it. Just wanted to point it out in case you had more thoughts. > > * Update all locations to refer to Klass::vtable_{length,start}_offset > instead of InstanceKlass. Looks good. > > * Modify SA to look for _vtable_len in Klass. Looks good. > > * Rename CompilerToVM::Data::InstanceKlass_vtable_{length,start}_offset > and > jdk.vm.ci.hotspot.HotSpotVMConfig.instanceKlassVtable{Length,Start}Offset > to properly represent where the offsets are coming from. Looks good. > > > Webrev: http://cr.openjdk.java.net/~mgerdin/8148047/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8148047 > > Testing: JPRT on Oracle supported platforms. > > As in the previous change I've updated the PPC64 and AARCH64 ports but > I have not tested the changes. Build and test feedback from porters is > most welcome! Cheers, Chris > > Thanks > /Mikael From david.holmes at oracle.com Mon Jan 25 01:51:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jan 2016 11:51:30 +1000 Subject: RFR(xs): 8148053: Remove unused log tags In-Reply-To: <56A24401.3050909@oracle.com> References: <56A24401.3050909@oracle.com> Message-ID: <56A57FA2.1010507@oracle.com> Hi Robbin, Looks good to me too! But as we all play with UL perhaps a broader review/heads-up on hotspot-dev (now cc'd) in case any one is planning on using those. I almost used "rt" in a change I'm working on, but have added "os" instead. Thanks, David On 23/01/2016 1:00 AM, Robbin Ehn wrote: > Hi, > > Please review, this removes unused tags in UL. > > Testing: > Passed RBT build > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148053 > Webrev: http://cr.openjdk.java.net/~mlarsson/rehn/8148053/ > > Thanks and thanks Marcus for hosting! > > /Robbin From bengt.rutisson at oracle.com Mon Jan 25 08:07:46 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 25 Jan 2016 09:07:46 +0100 Subject: Current status of hs-rt In-Reply-To: <56A2623F.30503@oracle.com> References: <56A2623F.30503@oracle.com> Message-ID: <56A5D7D2.9050803@oracle.com> On 2016-01-22 18:09, Jesper Wilhelmsson wrote: > Hi, > > We are currently hoping for the Thursday snapshot to be the one. The > Thursday nightly hasn't finished yet but so far it looks OK. Right now > there are two questions that needs to be resolved regarding this > nightly. New failures may still show up. > > 1. One new bug was filed, JDK-8148052. Is this a blocker or not? This is most likely due to the changes I made to the StackTraceEvents last Thursday. I assigned the bug to me, but since Aurora is still down I can't investigate the failure that easily. I will try to see what I can do. I'm pretty sure this is a problem with the test and not the product. So, I don't think it needs to be a blocker. Bengt > > 2. Is stressHierarchy003 in the GC baseline a known failure or a new one? > > Plus the big question that is still under investigation; Is > JDK-8147865 a blocker or not. > > If the answer to these questions are [not, known, not], and the Friday > nightly shows no surprises, we are good to integrate to main and open > hs-rt for normal business on Monday. > > Thanks for your patience! > /Jesper From robbin.ehn at oracle.com Mon Jan 25 08:38:04 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 25 Jan 2016 09:38:04 +0100 Subject: RFR(xs): 8148053: Remove unused log tags In-Reply-To: <56A57FA2.1010507@oracle.com> References: <56A24401.3050909@oracle.com> <56A57FA2.1010507@oracle.com> Message-ID: <56A5DEEC.9080103@oracle.com> Thanks David! /Robbin On 01/25/2016 02:51 AM, David Holmes wrote: > Hi Robbin, > > Looks good to me too! But as we all play with UL perhaps a broader > review/heads-up on hotspot-dev (now cc'd) in case any one is planning on > using those. I almost used "rt" in a change I'm working on, but have > added "os" instead. > > Thanks, > David > > On 23/01/2016 1:00 AM, Robbin Ehn wrote: >> Hi, >> >> Please review, this removes unused tags in UL. >> >> Testing: >> Passed RBT build >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148053 >> Webrev: http://cr.openjdk.java.net/~mlarsson/rehn/8148053/ >> >> Thanks and thanks Marcus for hosting! >> >> /Robbin From tobias.hartmann at oracle.com Mon Jan 25 09:59:37 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 25 Jan 2016 10:59:37 +0100 Subject: [8u] Request for approval: Backport of 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type Message-ID: <56A5F209.3060704@oracle.com> Hi, please approve and review the following backport to 8u. 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type https://bugs.openjdk.java.net/browse/JDK-8147548 http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de The fix was pushed to hs-comp on January, 18 and nightly testing showed no problems. Unfortunately, the changes do not apply cleanly to 8u-dev because several enhancements that affect related code were not backported to 8. Here is a new webrev: http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.00/ I did additional performance and correctness testing to verify that the backport works fine and does not introduce a regression. Thanks, Tobias From sean.coffey at oracle.com Mon Jan 25 10:34:03 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 25 Jan 2016 10:34:03 +0000 Subject: [8u] Request for approval: Backport of 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type In-Reply-To: <56A5F209.3060704@oracle.com> References: <56A5F209.3060704@oracle.com> Message-ID: <56A5FA1B.2070000@oracle.com> Approved but subject to peer code review before pushing. Regards, Sean. On 25/01/16 09:59, Tobias Hartmann wrote: > Hi, > > please approve and review the following backport to 8u. > > 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type > https://bugs.openjdk.java.net/browse/JDK-8147548 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de > > The fix was pushed to hs-comp on January, 18 and nightly testing showed no problems. Unfortunately, the changes do not apply cleanly to 8u-dev because several enhancements that affect related code were not backported to 8. Here is a new webrev: > http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.00/ > > I did additional performance and correctness testing to verify that the backport works fine and does not introduce a regression. > > Thanks, > Tobias From tobias.hartmann at oracle.com Mon Jan 25 11:27:43 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 25 Jan 2016 12:27:43 +0100 Subject: [8u] Request for approval: Backport of 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type In-Reply-To: <56A5FA1B.2070000@oracle.com> References: <56A5F209.3060704@oracle.com> <56A5FA1B.2070000@oracle.com> Message-ID: <56A606AF.4010500@oracle.com> Thanks, Sean. Best, Tobias On 25.01.2016 11:34, Se?n Coffey wrote: > Approved but subject to peer code review before pushing. > > Regards, > Sean. > > On 25/01/16 09:59, Tobias Hartmann wrote: >> Hi, >> >> please approve and review the following backport to 8u. >> >> 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type >> https://bugs.openjdk.java.net/browse/JDK-8147548 >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de >> >> The fix was pushed to hs-comp on January, 18 and nightly testing showed no problems. Unfortunately, the changes do not apply cleanly to 8u-dev because several enhancements that affect related code were not backported to 8. Here is a new webrev: >> http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.00/ >> >> I did additional performance and correctness testing to verify that the backport works fine and does not introduce a regression. >> >> Thanks, >> Tobias > From mikael.gerdin at oracle.com Mon Jan 25 14:34:44 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 25 Jan 2016 15:34:44 +0100 Subject: RFR(M) 8148047: Move the vtable length field to Klass In-Reply-To: <56A28123.3090203@oracle.com> References: <56A24F77.6030804@oracle.com> <56A28123.3090203@oracle.com> Message-ID: <56A63284.8090608@oracle.com> Hi Chris, On 2016-01-22 20:21, Chris Plummer wrote: > Hi Mikael, > > On 1/22/16 7:49 AM, Mikael Gerdin wrote: >> Hi all, >> >> Here's the second part of the set of changes to move most of the >> vtable related code to Klass. >> >> This change consists of the following parts: >> * Move the field _vtable_len to Klass, making its accessor nonvirtual. >> -> Ensure that this does not result in any footprint regression by >> moving TRACE_DEFINE_KLASS_TRACE_ID in Klass and _itable_len in >> InstanceKlass to fill out alignment gaps. > I also double checked this, including with minimal VM. The sizeof(Klass) > remains unchanged. Thanks for verifying. > > And your relocation of InstanceKlass::_itable_len should result in > InstanceKlass being 8 bytes smaller on 64-bit, although I did not double > check that. >> -> Move vtable_length_offset to Klass. Move vtable_start_offset to >> Klass to keep the code consistent. vtable_start_offset depends on the >> size of InstanceKlass and must therefore be defined outside of klass.hpp. > The abstraction has kind of gone awry: > > 662 ByteSize Klass::vtable_start_offset() { > 663 return in_ByteSize(InstanceKlass::header_size() * wordSize); > 664 } > > Note the reference to InstanceKlass. I understand why you are doing > this. All Klass subclasses have their sizes padded out to the size of > InstanceKlass so the vtable is always in the same place. I was just > wondering if there is a cleaner way. I guess the abstraction was broken > before your changes, but in a different place. We used to call > InstanceKlass::vtable_start_offset() even for array types. Now you > instead call Klass::vtable_start_offset(), and it does the dirty deed of > referencing InstanceKlass. I guess I'm ok with it. Just wanted to point > it out in case you had more thoughts. I agree that it's not the nicest abstraction, I could "hide" it in a static field in Klass or Universe or something, but that's just sweeping the problem under the rug. On a slightly related topic, I did consider attempting to add some sort of assertion that InstanceKlass is indeed the largest of all subclasses of Klass, otherwise this code would be broken. For example if someone had the idea of adding a sufficiently large field to a subclass of InstanceKlass then the vtable would conflict with that field. One approach would be to have a protected Klass constructor which takes a template parameter T, where subclasses pass "themselves" and the Klass constructor verifies that sizeof(T) <= sizeof(InstanceKlass) (with or without word size scaling). > >> >> * Update all locations to refer to Klass::vtable_{length,start}_offset >> instead of InstanceKlass. > Looks good. >> >> * Modify SA to look for _vtable_len in Klass. > Looks good. >> >> * Rename CompilerToVM::Data::InstanceKlass_vtable_{length,start}_offset >> and >> jdk.vm.ci.hotspot.HotSpotVMConfig.instanceKlassVtable{Length,Start}Offset >> to properly represent where the offsets are coming from. > Looks good. >> >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8148047/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148047 >> >> Testing: JPRT on Oracle supported platforms. >> >> As in the previous change I've updated the PPC64 and AARCH64 ports but >> I have not tested the changes. Build and test feedback from porters is >> most welcome! > > Cheers, Thanks for the review, Chris. /Mikael > > Chris >> >> Thanks >> /Mikael > From jesper.wilhelmsson at oracle.com Mon Jan 25 16:07:00 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Jan 2016 17:07:00 +0100 Subject: Current status of hs-rt In-Reply-To: <56A2623F.30503@oracle.com> References: <56A2623F.30503@oracle.com> Message-ID: <56A64824.3020004@oracle.com> Hi, We didn't get any nightly testing on Friday due to maintenance, so we are hoping for everything to work tonight instead. JDK-8148052 seems to be a test issue and the related tests are being quarantined. Quarantining tests are usually seen as "safe" changes and since no other changes has been pushed since Thursday we can push the quarantining change to hs-rt now without invalidating the Thursday nightly results. We also need to get a final verdict on JDK-8147865. It is believed to be an older bug and thus not a blocker but due to maintenance this has not been verified yet. Thanks, /Jesper Den 22/1/16 kl. 18:09, skrev Jesper Wilhelmsson: > Hi, > > We are currently hoping for the Thursday snapshot to be the one. The Thursday > nightly hasn't finished yet but so far it looks OK. Right now there are two > questions that needs to be resolved regarding this nightly. New failures may > still show up. > > 1. One new bug was filed, JDK-8148052. Is this a blocker or not? > > 2. Is stressHierarchy003 in the GC baseline a known failure or a new one? > > Plus the big question that is still under investigation; Is JDK-8147865 a > blocker or not. > > If the answer to these questions are [not, known, not], and the Friday nightly > shows no surprises, we are good to integrate to main and open hs-rt for normal > business on Monday. > > Thanks for your patience! > /Jesper From matthias.baesken at sap.com Mon Jan 25 16:37:23 2016 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 25 Jan 2016 16:37:23 +0000 Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F8EA00@DEWDFEMB12B.global.corp.sap> References: <98C2119538350A4E92B3DD08E7B4146801E207D8A2@DEWDFEMB14B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F8EA00@DEWDFEMB12B.global.corp.sap> Message-ID: <98C2119538350A4E92B3DD08E7B4146801F0C5C6D4@DEWDFEMB14B.global.corp.sap> Ping .... any reviewers ?? Best regards, Matthias -----Original Message----- From: Langer, Christoph Sent: Montag, 21. Dezember 2015 23:18 To: Baesken, Matthias ; hotspot-dev at openjdk.java.net Cc: Simonis, Volker Subject: RE: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER Hi Matthias, to me your change looks good. However, I'm no reviewer so you'll need sponsorship from someone else. Can someone please sponsor this? Should it maybe be posted in another list for better visibility? Best regards Christoph -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Baesken, Matthias Sent: Freitag, 18. Dezember 2015 14:30 To: hotspot-dev at openjdk.java.net Cc: Simonis, Volker Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER Hello, can you please review and sponsor this change : https://bugs.openjdk.java.net/browse/JDK-8145740 http://cr.openjdk.java.net/~clanger/webrevs/8145740.0/ Some details : while Visual Studio pragmas in shared code are usually guarded with _MSC_VER in the hotspot codebase ( see for example taskqueue.hpp or compressedStream.cpp ) , the guarding is missing in src/share/vm/utilities/growableArray.hpp , which is not really a "good thing" for other compilers . Thanks and regards, Matthias From volker.simonis at gmail.com Mon Jan 25 16:58:40 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Jan 2016 17:58:40 +0100 Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER In-Reply-To: <98C2119538350A4E92B3DD08E7B4146801F0C5C6D4@DEWDFEMB14B.global.corp.sap> References: <98C2119538350A4E92B3DD08E7B4146801E207D8A2@DEWDFEMB14B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F8EA00@DEWDFEMB12B.global.corp.sap> <98C2119538350A4E92B3DD08E7B4146801F0C5C6D4@DEWDFEMB14B.global.corp.sap> Message-ID: Hi Matthias, this fix is good! The change was initially introduced to appease the Visual Studio compiler. But we shouldn't do that at the cost of provoking warnings with other compilers. Compiler specific pragmas in shared code should be guarded appropriately. Alternatively, we could also disable this warning globally on Windows by placing the pragma into globalDefinitions_visCPP.hpp. Either way, we need a sponsor. David, maybe you can assist? Here's a link to the initial bug which introduced this code: https://bugs.openjdk.java.net/browse/JDK-8074895 The corresponding review thread states: Microsoft describes it as an obsolete warning: https://msdn.microsoft.com/en-us/library/wewb47ee.aspx "This warning is obsolete. It is only generated in Visual Studio 2005 through Visual Studio 2012. It reports a behavior change from the Visual C++ compiler that shipped in Visual Studio .NET when initializing a POD (plain old data) object with (); the compiler default-initializes the object.? Thank you and best regards, Volker On Mon, Jan 25, 2016 at 5:37 PM, Baesken, Matthias wrote: > Ping .... any reviewers ?? > > Best regards, Matthias > > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 21. Dezember 2015 23:18 > To: Baesken, Matthias ; hotspot-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RE: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER > > Hi Matthias, > > to me your change looks good. However, I'm no reviewer so you'll need sponsorship from someone else. > > Can someone please sponsor this? Should it maybe be posted in another list for better visibility? > > Best regards > Christoph > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Baesken, Matthias > Sent: Freitag, 18. Dezember 2015 14:30 > To: hotspot-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER > > Hello, > can you please review and sponsor this change : > > https://bugs.openjdk.java.net/browse/JDK-8145740 > http://cr.openjdk.java.net/~clanger/webrevs/8145740.0/ > > Some details : > > while Visual Studio pragmas in shared code are usually guarded with _MSC_VER in the hotspot codebase > ( see for example taskqueue.hpp or compressedStream.cpp ) , the guarding is missing in src/share/vm/utilities/growableArray.hpp , > which is not really a "good thing" for other compilers . > > > Thanks and regards, Matthias > From chris.plummer at oracle.com Mon Jan 25 17:02:32 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 25 Jan 2016 09:02:32 -0800 Subject: RFR(M) 8148047: Move the vtable length field to Klass In-Reply-To: <56A63284.8090608@oracle.com> References: <56A24F77.6030804@oracle.com> <56A28123.3090203@oracle.com> <56A63284.8090608@oracle.com> Message-ID: <56A65528.9030808@oracle.com> Hi Mikael, On 1/25/16 6:34 AM, Mikael Gerdin wrote: > Hi Chris, > > On 2016-01-22 20:21, Chris Plummer wrote: >> Hi Mikael, >> >> On 1/22/16 7:49 AM, Mikael Gerdin wrote: >>> Hi all, >>> >>> Here's the second part of the set of changes to move most of the >>> vtable related code to Klass. >>> >>> This change consists of the following parts: >>> * Move the field _vtable_len to Klass, making its accessor nonvirtual. >>> -> Ensure that this does not result in any footprint regression by >>> moving TRACE_DEFINE_KLASS_TRACE_ID in Klass and _itable_len in >>> InstanceKlass to fill out alignment gaps. >> I also double checked this, including with minimal VM. The sizeof(Klass) >> remains unchanged. > > Thanks for verifying. > >> >> And your relocation of InstanceKlass::_itable_len should result in >> InstanceKlass being 8 bytes smaller on 64-bit, although I did not double >> check that. >>> -> Move vtable_length_offset to Klass. Move vtable_start_offset to >>> Klass to keep the code consistent. vtable_start_offset depends on the >>> size of InstanceKlass and must therefore be defined outside of >>> klass.hpp. >> The abstraction has kind of gone awry: >> >> 662 ByteSize Klass::vtable_start_offset() { >> 663 return in_ByteSize(InstanceKlass::header_size() * wordSize); >> 664 } >> >> Note the reference to InstanceKlass. I understand why you are doing >> this. All Klass subclasses have their sizes padded out to the size of >> InstanceKlass so the vtable is always in the same place. I was just >> wondering if there is a cleaner way. I guess the abstraction was broken >> before your changes, but in a different place. We used to call >> InstanceKlass::vtable_start_offset() even for array types. Now you >> instead call Klass::vtable_start_offset(), and it does the dirty deed of >> referencing InstanceKlass. I guess I'm ok with it. Just wanted to point >> it out in case you had more thoughts. > > I agree that it's not the nicest abstraction, I could "hide" it in a > static field in Klass or Universe or something, but that's just > sweeping the problem under the rug. > > On a slightly related topic, I did consider attempting to add some > sort of assertion that InstanceKlass is indeed the largest of all > subclasses of Klass, otherwise this code would be broken. For example > if someone had the idea of adding a sufficiently large field to a > subclass of InstanceKlass then the vtable would conflict with that field. I think you meant add a field to a subclass of Klass, not InstanceKlass. > > One approach would be to have a protected Klass constructor which > takes a template parameter T, where subclasses pass "themselves" and > the Klass constructor verifies that sizeof(T) <= sizeof(InstanceKlass) > (with or without word size scaling). There's already a check in place for ArrayKlass subclasses, which do something similar by passing in their own size: int ArrayKlass::static_size(int header_size) { // size of an array klass object assert(header_size <= InstanceKlass::header_size(), "bad header size"); // If this assert fails, see comments in base_create_array_klass. header_size = InstanceKlass::header_size(); int vtable_len = Universe::base_vtable_size(); int size = header_size + vtable_len; return align_object_size(size); } cheers, Chris > > >> >>> >>> * Update all locations to refer to Klass::vtable_{length,start}_offset >>> instead of InstanceKlass. >> Looks good. >>> >>> * Modify SA to look for _vtable_len in Klass. >> Looks good. >>> >>> * Rename CompilerToVM::Data::InstanceKlass_vtable_{length,start}_offset >>> and >>> jdk.vm.ci.hotspot.HotSpotVMConfig.instanceKlassVtable{Length,Start}Offset >>> >>> to properly represent where the offsets are coming from. >> Looks good. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~mgerdin/8148047/webrev.0/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148047 >>> >>> Testing: JPRT on Oracle supported platforms. >>> >>> As in the previous change I've updated the PPC64 and AARCH64 ports but >>> I have not tested the changes. Build and test feedback from porters is >>> most welcome! >> >> Cheers, > > Thanks for the review, Chris. > /Mikael > >> >> Chris >>> >>> Thanks >>> /Mikael >> > From vladimir.kozlov at oracle.com Mon Jan 25 17:49:57 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jan 2016 09:49:57 -0800 Subject: [8u] Request for approval: Backport of 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type In-Reply-To: <56A5F209.3060704@oracle.com> References: <56A5F209.3060704@oracle.com> Message-ID: <56A66045.9050200@oracle.com> RFR for 8u should use original 6675699 bug id and also use it in 8u the changeset comment: https://bugs.openjdk.java.net/browse/JDK-6675699 parse2.cpp I noticed that JDK9 change remove -1 from "num_cases-1". Was it intentional? graphKit.cpp fast_size_limit is used in jdk9 but not in 8u. Why? Thanks, Vladimir On 1/25/16 1:59 AM, Tobias Hartmann wrote: > Hi, > > please approve and review the following backport to 8u. > > 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type > https://bugs.openjdk.java.net/browse/JDK-8147548 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de > > The fix was pushed to hs-comp on January, 18 and nightly testing showed no problems. Unfortunately, the changes do not apply cleanly to 8u-dev because several enhancements that affect related code were not backported to 8. Here is a new webrev: > http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.00/ > > I did additional performance and correctness testing to verify that the backport works fine and does not introduce a regression. > > Thanks, > Tobias > From vladimir.kozlov at oracle.com Mon Jan 25 18:33:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jan 2016 10:33:34 -0800 Subject: RFR (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56A64E34.8020305@oracle.com> References: <56A64E34.8020305@oracle.com> Message-ID: <56A66A7E.20604@oracle.com> Using hotspot-dev instead and added jdk9-dev mailing lists. Changes affect not only JIT (yes, most changes are JIT related). Specifically prims/unsafe.cpp changes. There are no C1 changes? Vladimir On 1/25/16 8:32 AM, Aleksey Shipilev wrote: > Hi, > > I would like to solicit reviews for the slab of VM changes to support > JEP 193 (VarHandles). This portion covers new Unsafe methods. > > Webrev: > http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.00/ > http://cr.openjdk.java.net/~shade/8148146/webrev.hs.00/ > > The patches "almost" pass JPRT, with some failures in closed code, > triggered by adding a large number of new intrinsics. Those failures are > to be addressed separately -- and because of that, this change is not > yet pushable. A preliminary review would be appreciated meanwhile. > > A brief summary of changes: > > a) jdk.internal.misc.Unsafe has new methods. Since we now have split > s.m.Unsafe and j.i.m.Unsafe, this change "safely" extends the private > Unsafe, leaving the other one untouched. > > b) hotspot/test/compiler/unsafe tests are extended for newly added methods. > > c) unsafe.cpp gets the basic native method implementations. Most new > operations are folded to their volatile (the strongest) counterparts, > hoping that compilers would intrinsify them into more performant versions. > > d) C2 intrinsics for x86: > > * Most intrinsics code is covered by platform-independent > LibraryCallKit changes, which means non-x86 architectures are also > partially covered. > > * There are two classes of ops left for platform-dependent code: > WeakCAS and CompareAndExchange nodes. Both seem simple enough to do, but > there are details to be sorted out on each platform -- let's do those > separately. > > * Both LibraryCallKit::inline_unsafe_access and > LCK::inline_unsafe_load_store were modified to accept new access modes, > and generally brushed up to accept the changes. > > * putOrdered intrinsic methods are purged in favor of put*Release > operations. We still keep Unsafe.putOrdered for testability and > compatibility reasons. > > Eyeballing the generated code on x86 yields no obvious problems. Sanity > microbenchmark runs do not show performance regressions on old methods, > and show the expected performance on new methods: > http://cr.openjdk.java.net/~shade/8148146/notes.txt > > Cheers, > -Aleksey > From igor.ignatyev at oracle.com Mon Jan 25 19:36:48 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 25 Jan 2016 22:36:48 +0300 Subject: RFR(S) : 8148012 : get rid of slash-dot-dot in @library directives Message-ID: http://cr.openjdk.java.net/~iignatyev/8148012/webrev.00/ > 31 lines changed: 0 ins; 0 del; 31 mod; Having ?external.lib.roots=/../../' in TEST.ROOT made it possible not to use ?/..? in tests, the latest change in JTreg(https://bugs.openjdk.java.net/browse/CODETOOLS-7901585) made it illegal to have references to directories outside a test suite, so it?s required to fix all such entries for switching to the next jtreg version. the fix basically replaces all '/../../test/lib? w/ ?/test/lib? in @library directives. testing: run the affected tests jbs: https://bugs.openjdk.java.net/browse/JDK-8148012 Thanks, Igor From dmitry.fazunenko at oracle.com Mon Jan 25 20:07:54 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Mon, 25 Jan 2016 23:07:54 +0300 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <56A1FA78.3090608@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> <56A04DCF.9090204@oracle.com> <56A1FA78.3090608@oracle.com> Message-ID: <56A6809A.40104@oracle.com> Hi Igor, The GC part of change looks good. Thanks, Dima On 22.01.2016 12:46, Mikael Gerdin wrote: > Hi Chris, > > On 2016-01-21 04:17, Chris Plummer wrote: >> Hi Mikael, >> >> The changes look good except I think you should get someone from the >> compiler team to make sure the change in >> HotSpotResolvedJavaMethodImpl.java and HotSpotVMConfig.java are ok. I'm >> not sure why you chose to remove instanceKlassVtableStartOffset() rather >> than just fix it. > > I'm cc:ing hotspot-compiler-dev and graal-dev to see if I can get > someone to ok the JVMCI parts. > > The reason for removing the method is that the only reason for it > being a method was to apply the wordSize scaling on the value and > since I changed the offset to be a byte offset it does not need > scaling and can be treated similar to the other constants in > HotSpotVMConfig which are accessed without any accessor method. > >> >> I think some of your changes may conflict with my changes for >> JDK-8143608. Coleen is pushing JDK-8143608 for me once hs-rt opens up. >> I'd appreciate it if you could wait until after then before doing your >> push. > > Will do, would you mind pinging me when you've integrated 8143608? > > /Mikael > >> >> thanks, >> >> Chris >> >> On 1/20/16 4:31 AM, Mikael Gerdin wrote: >>> Hi again, >>> >>> I've rebased the on hs-rt and had to include some additional changes >>> for JVMCI. >>> I've also updated the copyright years. >>> Unfortunately I can't generate an incremental webrev since i rebased >>> the patch and there's no good way that I know of to make that work >>> with webrev. >>> >>> New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ >>> >>> Testing: JPRT again (which includes the JVMCI jtreg tests) >>> >>> /Mikael >>> >>> On 2016-01-15 18:04, Mikael Gerdin wrote: >>>> Hi all, >>>> >>>> As per the previous discussion in mid-December[0] about moving the >>>> _vtable_length field to class Klass, here's the first RFR and webrev, >>>> according to my suggested plan[1]: >>>> >>>>> My current plan is to first modify the vtable_length_offset >>>>> accessor to >>>>> return a byte offset (which is what it's translated to by all >>>>> callers). >>>>> >>>>> Then I'll tackle moving the _vtable_len field to Klass. >>>>> >>>>> Finally I'll try to consolidate the vtable related methods to Klass, >>>>> where they belong. >>>> >>>> This change actually consists of three changes: >>>> * modifying InstanceKlass::vtable_length_offset to become a byte >>>> offset >>>> and use the ByteSize type to communicate the scaling. >>>> * modifying InstanceKlass::vtable_start_offset to become a byte offset >>>> and use the ByteSize type, for symmetry reasons mainly. >>>> * adding a vtableEntry::size_in_bytes() since in many places the >>>> vtable >>>> entry size is used in combination with the vtable start to compute a >>>> byte offset for vtable lookups. >>>> >>>> I don't foresee any issues with the fact that the byte offset is >>>> represented as an int, for two reasons: >>>> 1) If the offset of any of these grows to over 2 gigabytes then we >>>> have >>>> a huge footprint problem with InstanceKlass >>>> 2) The offsets are converted to byte offsets and stored in ints >>>> already >>>> in the cpu specific code I've modified. >>>> >>>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >>>> >>>> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >>>> PPC64 would be much appreciated, appropriate mailing lists have been >>>> CC:ed to notify them of the request. >>>> >>>> >>>> [0] >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >>>> >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >>>> >>>> >>>> >>>> >>>> Thanks! >>>> /Mikael >>> >> > From mikael.vidstedt at oracle.com Tue Jan 26 04:57:09 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 25 Jan 2016 20:57:09 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <565628F5.2080801@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> Message-ID: <56A6FCA5.7040808@oracle.com> I've finally found some time to return to this and have a new version of the patch which looks more promising: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ This uses memcpy to read/write the native data and the preliminary benchmark numbers on linux/x64 shows the expected performance. I'll work on verifying that it doesn't impact other platforms negatively over the next days/weeks. Btw, I also played around with implementing it in pure Java, but there are some issues getting C2 to correctly vectorize the loop given the native data accesses, so the native code seems to be needed for now. Cheers, Mikael On 2015-11-25 13:32, Mikael Vidstedt wrote: > > Have you looked anything at the performance of the generated code? As > you may have seen I was playing around with an alternative > implementation[1] which has the benefit of being pure C++ without > compiler specific hints. That said, when I did some initial > benchmarking of that it did seem like the performance impact was > significant. I didn't have time to look at more in detail why, and > will not have time to return to that until late next week earliest. It > would be interesting to understand what type of performance you see > with your patch. > > Cheers, > Mikael > > > [1] > http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.01/webrev/jdk.patch > > On 2015-11-25 11:42, Coleen Phillimore wrote: >> Sending to core-libs mailing list. >> >> On 11/25/15 2:19 PM, Alexander Smundak wrote: >>> Please take a look at >>> http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00 >>> that fixes the problem. >>> >>> It utilizes the ability of some (GCC and Clang) to declare data >>> alignment explicitly. >>> I have verified it works on x86_64 Linux by running >>> jdk/test/java/nio/Buffer/Basic.java test >>> >>> I need a sponsor. >>> >>> Sasha >> > From chris.plummer at oracle.com Tue Jan 26 07:19:14 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 25 Jan 2016 23:19:14 -0800 Subject: RFR(S) : 8148012 : get rid of slash-dot-dot in @library directives In-Reply-To: References: Message-ID: <56A71DF2.3070805@oracle.com> On 1/25/16 11:36 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8148012/webrev.00/ >> 31 lines changed: 0 ins; 0 del; 31 mod; > Having ?external.lib.roots=/../../' in TEST.ROOT made it possible not to use ?/..? in tests, the latest change in JTreg(https://bugs.openjdk.java.net/browse/CODETOOLS-7901585) made it illegal to have references to directories outside a test suite, so it?s required to fix all such entries for switching to the next jtreg version. the fix basically replaces all '/../../test/lib? w/ ?/test/lib? in @library directives. > > testing: run the affected tests > jbs: https://bugs.openjdk.java.net/browse/JDK-8148012 > > Thanks, > Igor Hi Igor, Your changes look fine. However, your webrev for some reason is listing a few extra revisions and CRs. I'm not sure what's going on with that. (I'm not a "R"eviewer). cheers, Chris From aleksey.shipilev at oracle.com Tue Jan 26 08:05:25 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 26 Jan 2016 11:05:25 +0300 Subject: RFR (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56A66A7E.20604@oracle.com> References: <56A64E34.8020305@oracle.com> <56A66A7E.20604@oracle.com> Message-ID: <56A728C5.8060207@oracle.com> On 01/25/2016 09:33 PM, Vladimir Kozlov wrote: > Using hotspot-dev instead and added jdk9-dev mailing lists. > > Changes affect not only JIT (yes, most changes are JIT related). > Specifically prims/unsafe.cpp changes. Yes. > There are no C1 changes? We have some prototype C1 intrinsics in VarHandles forest, but their quality is questionable at this point. Therefore, this patch includes only C2 intrinsics. > On 1/25/16 8:32 AM, Aleksey Shipilev wrote: >> Hi, >> >> I would like to solicit reviews for the slab of VM changes to support >> JEP 193 (VarHandles). This portion covers new Unsafe methods. >> >> Webrev: >> http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.00/ >> http://cr.openjdk.java.net/~shade/8148146/webrev.hs.00/ Cheers, -Aleksey From tobias.hartmann at oracle.com Tue Jan 26 08:47:39 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Jan 2016 09:47:39 +0100 Subject: [8u] Request for approval: Backport of 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type In-Reply-To: <56A66045.9050200@oracle.com> References: <56A5F209.3060704@oracle.com> <56A66045.9050200@oracle.com> Message-ID: <56A732AB.30103@oracle.com> Hi Vladimir, thanks for the review! On 25.01.2016 18:49, Vladimir Kozlov wrote: > RFR for 8u should use original 6675699 bug id and also use it in 8u the changeset comment: > > https://bugs.openjdk.java.net/browse/JDK-6675699 Right, somehow I got confused because the backport issue was created explicitly. Sorry for that. Here is the correct information (I leave the email subject for history): 6675699: need comprehensive fix for unconstrained ConvI2L with narrowed type https://bugs.openjdk.java.net/browse/JDK-6675699 http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de > parse2.cpp I noticed that JDK9 change remove -1 from "num_cases-1". Was it intentional? Yes, this is intended because the JDK 9 change uses Compile::conv_I2X_index() which already subtracts 1 from ikeytype->_hi: 4019 if (sizetype != NULL) index_max = sizetype->_hi - 1; JDK 8u change uses C->constrained_convI2L() which does not change the ikeytype->_hi. > graphKit.cpp fast_size_limit is used in jdk9 but not in 8u. Why? Thanks for pointing that out. The JDK 8u fix should use 'fast_size_limit' as upper bound as well because it's more accurate than 'max_array_length'. New webrev: http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.01/ Best, Tobias > On 1/25/16 1:59 AM, Tobias Hartmann wrote: >> Hi, >> >> please approve and review the following backport to 8u. >> >> 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type >> https://bugs.openjdk.java.net/browse/JDK-8147548 >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de >> >> The fix was pushed to hs-comp on January, 18 and nightly testing showed no problems. Unfortunately, the changes do not apply cleanly to 8u-dev because several enhancements that affect related code were not backported to 8. Here is a new webrev: >> http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.00/ >> >> I did additional performance and correctness testing to verify that the backport works fine and does not introduce a regression. >> >> Thanks, >> Tobias >> From aph at redhat.com Tue Jan 26 09:04:55 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jan 2016 09:04:55 +0000 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A6FCA5.7040808@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> Message-ID: <56A736B7.4020601@redhat.com> On 26/01/16 04:57, Mikael Vidstedt wrote: > > I've finally found some time to return to this and have a new version of > the patch which looks more promising: > > http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ > > This uses memcpy to read/write the native data and the preliminary > benchmark numbers on linux/x64 shows the expected performance. I'll work > on verifying that it doesn't impact other platforms negatively over the > next days/weeks. I agree that memcpy is the right thing to use. It's portable and is inlined well on production-quality C compilers. Andrew. From dmitry.fazunenko at oracle.com Tue Jan 26 12:02:29 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 26 Jan 2016 15:02:29 +0300 Subject: RFR(S) : 8148012 : get rid of slash-dot-dot in @library directives In-Reply-To: References: Message-ID: <56A76055.5070709@oracle.com> Hi Igor, the GC part of fix looks good! Thank you for caring of GC tests -- Dima On 25.01.2016 22:36, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8148012/webrev.00/ >> 31 lines changed: 0 ins; 0 del; 31 mod; > Having ?external.lib.roots=/../../' in TEST.ROOT made it possible not to use ?/..? in tests, the latest change in JTreg(https://bugs.openjdk.java.net/browse/CODETOOLS-7901585) made it illegal to have references to directories outside a test suite, so it?s required to fix all such entries for switching to the next jtreg version. the fix basically replaces all '/../../test/lib? w/ ?/test/lib? in @library directives. > > testing: run the affected tests > jbs: https://bugs.openjdk.java.net/browse/JDK-8148012 > > Thanks, > Igor From Alan.Bateman at oracle.com Tue Jan 26 12:28:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Jan 2016 12:28:02 +0000 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A6FCA5.7040808@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> Message-ID: <56A76652.5090500@oracle.com> On 26/01/2016 04:57, Mikael Vidstedt wrote: > > I've finally found some time to return to this and have a new version > of the patch which looks more promising: > > http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ > > This uses memcpy to read/write the native data and the preliminary > benchmark numbers on linux/x64 shows the expected performance. I'll > work on verifying that it doesn't impact other platforms negatively > over the next days/weeks. > > Btw, I also played around with implementing it in pure Java, but there > are some issues getting C2 to correctly vectorize the loop given the > native data accesses, so the native code seems to be needed for now. This looks good and maybe it was a good thing that the compiler upgrade ran into this. We eliminated most of the native methods in this area a few years ago but had to leave the byte swapping methods. It would be good to eliminate those some day. -Alan From coleen.phillimore at oracle.com Tue Jan 26 15:49:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Jan 2016 10:49:28 -0500 Subject: RFR (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56A66A7E.20604@oracle.com> References: <56A64E34.8020305@oracle.com> <56A66A7E.20604@oracle.com> Message-ID: <56A79588.8050201@oracle.com> Aleksey, This might be a good time to split vmIntrinsics off from vmSymbols and create new .hpp and .cpp files for them. There are a lot of both now and they're different. Is the implementation of these mostly in library_call.cpp? Also, if there are changes to vmStructs there are likely changes to the serviceability agent duplicated code. If not, then there is no need to make changes to vmStructs. There might be changes to jvmciStructs though. I don't know. Thanks, Coleen On 1/25/16 1:33 PM, Vladimir Kozlov wrote: > Using hotspot-dev instead and added jdk9-dev mailing lists. > > Changes affect not only JIT (yes, most changes are JIT related). > Specifically prims/unsafe.cpp changes. > > There are no C1 changes? > > Vladimir > > On 1/25/16 8:32 AM, Aleksey Shipilev wrote: >> Hi, >> >> I would like to solicit reviews for the slab of VM changes to support >> JEP 193 (VarHandles). This portion covers new Unsafe methods. >> >> Webrev: >> http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.00/ >> http://cr.openjdk.java.net/~shade/8148146/webrev.hs.00/ >> >> The patches "almost" pass JPRT, with some failures in closed code, >> triggered by adding a large number of new intrinsics. Those failures are >> to be addressed separately -- and because of that, this change is not >> yet pushable. A preliminary review would be appreciated meanwhile. >> >> A brief summary of changes: >> >> a) jdk.internal.misc.Unsafe has new methods. Since we now have split >> s.m.Unsafe and j.i.m.Unsafe, this change "safely" extends the private >> Unsafe, leaving the other one untouched. >> >> b) hotspot/test/compiler/unsafe tests are extended for newly added >> methods. >> >> c) unsafe.cpp gets the basic native method implementations. Most new >> operations are folded to their volatile (the strongest) counterparts, >> hoping that compilers would intrinsify them into more performant >> versions. >> >> d) C2 intrinsics for x86: >> >> * Most intrinsics code is covered by platform-independent >> LibraryCallKit changes, which means non-x86 architectures are also >> partially covered. >> >> * There are two classes of ops left for platform-dependent code: >> WeakCAS and CompareAndExchange nodes. Both seem simple enough to do, but >> there are details to be sorted out on each platform -- let's do those >> separately. >> >> * Both LibraryCallKit::inline_unsafe_access and >> LCK::inline_unsafe_load_store were modified to accept new access modes, >> and generally brushed up to accept the changes. >> >> * putOrdered intrinsic methods are purged in favor of put*Release >> operations. We still keep Unsafe.putOrdered for testability and >> compatibility reasons. >> >> Eyeballing the generated code on x86 yields no obvious problems. Sanity >> microbenchmark runs do not show performance regressions on old methods, >> and show the expected performance on new methods: >> http://cr.openjdk.java.net/~shade/8148146/notes.txt >> >> Cheers, >> -Aleksey >> From goetz.lindenmaier at sap.com Tue Jan 26 16:13:23 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Jan 2016 16:13:23 +0000 Subject: Version special case '9' Message-ID: <4295855A5C1DE049A61835A1887419CC41F20DD2@DEWDFEMB12A.global.corp.sap> Hi, We appreciate the new version scheme introduced with JEP 223. It simplifies the versioning and we agree that it is to it's best downward compatible. Unfortunately there is one exception to this. The initial version of a new major release skips the minor and security digits. This makes parsing the string unnecessarily complicated, because the format is not predictable. In this, the JEP also is inconsistent. In chapter "Dropping the initial 1 element from version numbers" it is argued that comparing "9.0.0" to "1.8.0" by digit will show that 9 is newer than 8. But there is no such version as 9.0.0. This is stated in chapter "Version numbers": "The version number does not include trailing zero elements; i.e., $SECURITY is omitted if it has the value zero, and $MINOR is omitted if both $MINOR and $SECURITY have the value zero." Our BussinessObjects applications parse the option string by Float.parseFloat(System.getProperty("java.version").substring(0,3)) This delivers 1.7 for Java 7, but currently crashes for jdk9, as it tries to parse "9-i" from 9-internal. With trailing .0.0, this would see 9.0 and could parse the Java version until Java 99. As a workaround for this, we are now configuring with --with-version-patch=1 which results in version string 9.0.0.1-internal. At another place, we use split() to analyse the version. if (Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ... If there are always 3 numbers, this could be fixed to: if (Integer.parseInt(System.getProperty("java.version").split("\\.")[0]) > 7) || Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ... which was probably in mind when the But with omitting the .0.0, we must also split at '-' and '+': String[] version_elements = System.getProperty("java.version").split("\\.|-|+"); if (Integer.parseInt(version_elements[0]) > 7) || Integer.parseInt(version_elements[1]) > 7)) { ... If you want to check for a version > 9.*.22 it's even more complicated: String[] version_elements = System.getProperty("java.version").split("+|-")[0].split("\\."); if (Integer.parseInt(version_elements[0]) > 9 || (Integer.parseInt(version_elements[0]) == 9 && version_elements.length >= 3 && Integer.parseInt(version_elements[2]) > 22)) { ... So we would appreciate if the JEP was enhanced to always guarantee three version numbers 'x.y.z'. Further, version number 9.0.0.1 breaks the jck test api/java_lang/System/index.html#GetProperty. It fails with: "getJavaSpecVersion0001: Failed. System property 'java.specification.version' does not corresponds to the format 'major.minor.micro'". Maybe a fix of this test is already worked on, we are using jck suite from 9.9.15. Best regards, Goetz. From vladimir.kozlov at oracle.com Tue Jan 26 18:11:23 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Jan 2016 10:11:23 -0800 Subject: [8u] Request for approval: Backport of 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type In-Reply-To: <56A732AB.30103@oracle.com> References: <56A5F209.3060704@oracle.com> <56A66045.9050200@oracle.com> <56A732AB.30103@oracle.com> Message-ID: <56A7B6CB.8050606@oracle.com> Looks good now. Thanks, Vladimir On 1/26/16 12:47 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 25.01.2016 18:49, Vladimir Kozlov wrote: >> RFR for 8u should use original 6675699 bug id and also use it in 8u the changeset comment: >> >> https://bugs.openjdk.java.net/browse/JDK-6675699 > > Right, somehow I got confused because the backport issue was created explicitly. Sorry for that. > > Here is the correct information (I leave the email subject for history): > > 6675699: need comprehensive fix for unconstrained ConvI2L with narrowed type > https://bugs.openjdk.java.net/browse/JDK-6675699 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de > >> parse2.cpp I noticed that JDK9 change remove -1 from "num_cases-1". Was it intentional? > > Yes, this is intended because the JDK 9 change uses Compile::conv_I2X_index() which already subtracts 1 from ikeytype->_hi: > > 4019 if (sizetype != NULL) index_max = sizetype->_hi - 1; > > JDK 8u change uses C->constrained_convI2L() which does not change the ikeytype->_hi. > >> graphKit.cpp fast_size_limit is used in jdk9 but not in 8u. Why? > > Thanks for pointing that out. The JDK 8u fix should use 'fast_size_limit' as upper bound as well because it's more accurate than 'max_array_length'. > > New webrev: > http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.01/ > > Best, > Tobias > >> On 1/25/16 1:59 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please approve and review the following backport to 8u. >>> >>> 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type >>> https://bugs.openjdk.java.net/browse/JDK-8147548 >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de >>> >>> The fix was pushed to hs-comp on January, 18 and nightly testing showed no problems. Unfortunately, the changes do not apply cleanly to 8u-dev because several enhancements that affect related code were not backported to 8. Here is a new webrev: >>> http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.00/ >>> >>> I did additional performance and correctness testing to verify that the backport works fine and does not introduce a regression. >>> >>> Thanks, >>> Tobias >>> From john.r.rose at oracle.com Tue Jan 26 18:32:56 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jan 2016 10:32:56 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A736B7.4020601@redhat.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> Message-ID: <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote: > > I agree that memcpy is the right thing to use. It's portable and is > inlined well on production-quality C compilers. But it is not strong enough to uphold the Java memory model, because it is allows to copy byte-wise, which can tear shorts, ints, or longs, creating illegal race states. So we try to avoid memcpy when we can. ? John From aph at redhat.com Tue Jan 26 18:48:27 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jan 2016 18:48:27 +0000 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> Message-ID: <56A7BF7B.5020006@redhat.com> On 01/26/2016 06:32 PM, John Rose wrote: > On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote: >> >> I agree that memcpy is the right thing to use. It's portable and is >> inlined well on production-quality C compilers. > > But it is not strong enough to uphold the Java memory model, > because it is allows to copy byte-wise, which can tear shorts, > ints, or longs, creating illegal race states. > > So we try to avoid memcpy when we can. Yes, I see. I guess the best we can do is something like the fun and games in Unsafe.{get, put}LongUnaligned(), which always do the best they can to align everything. Andrew. From john.r.rose at oracle.com Tue Jan 26 19:04:01 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jan 2016 11:04:01 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A7BF7B.5020006@redhat.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> <56A7BF7B.5020006@redhat.com> Message-ID: <17C15340-167F-4B33-A6CF-8510EAC2491C@oracle.com> On Jan 26, 2016, at 10:48 AM, Andrew Haley wrote: > > On 01/26/2016 06:32 PM, John Rose wrote: >> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote: >>> >>> I agree that memcpy is the right thing to use. It's portable and is >>> inlined well on production-quality C compilers. >> >> But it is not strong enough to uphold the Java memory model, >> because it is allows to copy byte-wise, which can tear shorts, >> ints, or longs, creating illegal race states. >> >> So we try to avoid memcpy when we can. > > Yes, I see. I guess the best we can do is something like the fun and > games in Unsafe.{get, put}LongUnaligned(), which always do the best > they can to align everything. Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. IMO that's a better starting point than memcpy. Perhaps it can be given an additional parameter (or overloading) to specify a swap size. ? John From aph at redhat.com Tue Jan 26 19:08:00 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Jan 2016 19:08:00 +0000 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <17C15340-167F-4B33-A6CF-8510EAC2491C@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> <56A7BF7B.5020006@redhat.com> <17C15340-167F-4B33-A6CF-8510EAC2491C@oracle.com> Message-ID: <56A7C410.4040301@redhat.com> On 01/26/2016 07:04 PM, John Rose wrote: > Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. > IMO that's a better starting point than memcpy. Perhaps it can be > given an additional parameter (or overloading) to specify a swap size. OK, but conjoint_memory_atomic doesn't guarantee that destination words won't be torn if their source is misaligned: in fact it guarantees that they will will be. Andrew. From john.r.rose at oracle.com Tue Jan 26 19:13:32 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jan 2016 11:13:32 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A7C410.4040301@redhat.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> <56A7BF7B.5020006@redhat.com> <17C15340-167F-4B33-A6CF-8510EAC2491C@oracle.com> <56A7C410.4040301@redhat.com> Message-ID: <713CDD14-7C04-4B33-AC48-6A5474351C97@oracle.com> On Jan 26, 2016, at 11:08 AM, Andrew Haley wrote: > > On 01/26/2016 07:04 PM, John Rose wrote: >> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. >> IMO that's a better starting point than memcpy. Perhaps it can be >> given an additional parameter (or overloading) to specify a swap size. > > OK, but conjoint_memory_atomic doesn't guarantee that destination > words won't be torn if their source is misaligned: in fact it > guarantees that they will will be. That's a good point, and argues for a new function with the stronger guarantee. Actually, it would be perfectly reasonable to strengthen the guarantee on the existing function. I don't think anyone will care about the slight performance change, especially since it is probably favorable. Since it's Unsafe, they are not supposed to care, either. ? John From jesper.wilhelmsson at oracle.com Tue Jan 26 20:33:41 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 26 Jan 2016 21:33:41 +0100 Subject: hs-rt is now OPEN Message-ID: <56A7D825.2040600@oracle.com> Hi, jdk9/hs-rt is now back to normal operations again. Thank you for your patience during this stabilization period! In order for us to keep hs-rt stable it is important that everyone run proper testing on their changes. Remember that JPRT is not the way to test your changes. Use RBT or other dedicated testing where you can make sure that the code you changed is actually executed. Thanks! /Jesper From jesper.wilhelmsson at oracle.com Tue Jan 26 20:52:09 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 26 Jan 2016 21:52:09 +0100 Subject: hs-rt is now OPEN In-Reply-To: <56A7D825.2040600@oracle.com> References: <56A7D825.2040600@oracle.com> Message-ID: <56A7DC79.3090508@oracle.com> I was a bit trigger happy on that mail. Since the first push to hs-rt was to bring in a huge pile of changes from main, and since we have had stability issues with changes coming from main recently it was decided to let these get a nightly before we start adding our own changes. So, the build used for the nightly is picked around 6-7pm PT. Once that is done the gates are open. /Jesper Den 26/1/16 kl. 21:33, skrev Jesper Wilhelmsson: > Hi, > > jdk9/hs-rt is now back to normal operations again. > > Thank you for your patience during this stabilization period! > > In order for us to keep hs-rt stable it is important that everyone run proper > testing on their changes. Remember that JPRT is not the way to test your > changes. Use RBT or other dedicated testing where you can make sure that the > code you changed is actually executed. > > Thanks! > /Jesper From daniel.daugherty at oracle.com Tue Jan 26 21:22:23 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Jan 2016 14:22:23 -0700 Subject: hs-rt is now OPEN In-Reply-To: <56A7DC79.3090508@oracle.com> References: <56A7D825.2040600@oracle.com> <56A7DC79.3090508@oracle.com> Message-ID: <56A7E38F.1080102@oracle.com> The nightly testing cutoff is 1900 PT/2000 MT/2200 ET. Sometimes nightly will pickup a job that finishes a few minutes after that time, but it's best to be in before the cutoff. Dan On 1/26/16 1:52 PM, Jesper Wilhelmsson wrote: > I was a bit trigger happy on that mail. > > Since the first push to hs-rt was to bring in a huge pile of changes > from main, and since we have had stability issues with changes coming > from main recently it was decided to let these get a nightly before we > start adding our own changes. > > So, the build used for the nightly is picked around 6-7pm PT. Once > that is done the gates are open. > /Jesper > > > Den 26/1/16 kl. 21:33, skrev Jesper Wilhelmsson: >> Hi, >> >> jdk9/hs-rt is now back to normal operations again. >> >> Thank you for your patience during this stabilization period! >> >> In order for us to keep hs-rt stable it is important that everyone >> run proper >> testing on their changes. Remember that JPRT is not the way to test your >> changes. Use RBT or other dedicated testing where you can make sure >> that the >> code you changed is actually executed. >> >> Thanks! >> /Jesper From brian.burkhalter at oracle.com Tue Jan 26 16:13:06 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Jan 2016 08:13:06 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A76652.5090500@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A76652.5090500@oracle.com> Message-ID: <56A79B12.7050803@oracle.com> On 1/26/16 4:28 AM, Alan Bateman wrote: > > On 26/01/2016 04:57, Mikael Vidstedt wrote: >> >> I've finally found some time to return to this and have a new version >> of the patch which looks more promising: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ >> >> This uses memcpy to read/write the native data and the preliminary >> benchmark numbers on linux/x64 shows the expected performance. I'll >> work on verifying that it doesn't impact other platforms negatively >> over the next days/weeks. >> >> Btw, I also played around with implementing it in pure Java, but >> there are some issues getting C2 to correctly vectorize the loop >> given the native data accesses, so the native code seems to be needed >> for now. > This looks good and maybe it was a good thing that the compiler > upgrade ran into this. We eliminated most of the native methods in > this area a few years ago but had to leave the byte swapping methods. > It would be good to eliminate those some day. I concur that this looks OK. Don't forget to update the latest copyright year to 2016. Thanks, Brian From david.holmes at oracle.com Wed Jan 27 02:07:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jan 2016 12:07:33 +1000 Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER In-Reply-To: References: <98C2119538350A4E92B3DD08E7B4146801E207D8A2@DEWDFEMB14B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F8EA00@DEWDFEMB12B.global.corp.sap> <98C2119538350A4E92B3DD08E7B4146801F0C5C6D4@DEWDFEMB14B.global.corp.sap> Message-ID: <56A82665.2000005@oracle.com> We seem a bit inconsistent about how we guard compiler specific pragma's in shared code, but the use of _MSC_VER does already exist so this change seems fine to me. I will sponsor it. Thanks, David On 26/01/2016 2:58 AM, Volker Simonis wrote: > Hi Matthias, > > this fix is good! > > The change was initially introduced to appease the Visual Studio > compiler. But we shouldn't do that at the cost of provoking warnings > with other compilers. Compiler specific pragmas in shared code should > be guarded appropriately. Alternatively, we could also disable this > warning globally on Windows by placing the pragma into > globalDefinitions_visCPP.hpp. > > Either way, we need a sponsor. David, maybe you can assist? > > Here's a link to the initial bug which introduced this code: > > https://bugs.openjdk.java.net/browse/JDK-8074895 > > The corresponding review thread states: > > Microsoft describes it as an obsolete warning: > > https://msdn.microsoft.com/en-us/library/wewb47ee.aspx > > "This warning is obsolete. It is only generated in Visual Studio > 2005 through Visual Studio 2012. It reports a behavior change from > the Visual C++ compiler that shipped in Visual Studio .NET when > initializing a POD (plain old data) object with (); the compiler > default-initializes the object.? > > Thank you and best regards, > Volker > > > On Mon, Jan 25, 2016 at 5:37 PM, Baesken, Matthias > wrote: >> Ping .... any reviewers ?? >> >> Best regards, Matthias >> >> -----Original Message----- >> From: Langer, Christoph >> Sent: Montag, 21. Dezember 2015 23:18 >> To: Baesken, Matthias ; hotspot-dev at openjdk.java.net >> Cc: Simonis, Volker >> Subject: RE: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER >> >> Hi Matthias, >> >> to me your change looks good. However, I'm no reviewer so you'll need sponsorship from someone else. >> >> Can someone please sponsor this? Should it maybe be posted in another list for better visibility? >> >> Best regards >> Christoph >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Baesken, Matthias >> Sent: Freitag, 18. Dezember 2015 14:30 >> To: hotspot-dev at openjdk.java.net >> Cc: Simonis, Volker >> Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER >> >> Hello, >> can you please review and sponsor this change : >> >> https://bugs.openjdk.java.net/browse/JDK-8145740 >> http://cr.openjdk.java.net/~clanger/webrevs/8145740.0/ >> >> Some details : >> >> while Visual Studio pragmas in shared code are usually guarded with _MSC_VER in the hotspot codebase >> ( see for example taskqueue.hpp or compressedStream.cpp ) , the guarding is missing in src/share/vm/utilities/growableArray.hpp , >> which is not really a "good thing" for other compilers . >> >> >> Thanks and regards, Matthias >> From david.holmes at oracle.com Wed Jan 27 05:05:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jan 2016 15:05:46 +1000 Subject: RFR(S) : 8148012 : get rid of slash-dot-dot in @library directives In-Reply-To: References: Message-ID: <56A8502A.2070804@oracle.com> Hi Igor, On 26/01/2016 5:36 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8148012/webrev.00/ >> 31 lines changed: 0 ins; 0 del; 31 mod; > > Having ?external.lib.roots=/../../' in TEST.ROOT made it possible not to use ?/..? in tests, the latest change in JTreg(https://bugs.openjdk.java.net/browse/CODETOOLS-7901585) made it illegal to have references to directories outside a test suite, so it?s required to fix all such entries for switching to the next jtreg version. the fix basically replaces all '/../../test/lib? w/ ?/test/lib? in @library directives. I Reviewed the patch and it looks good. Remind me what is in /testlibrary versus /test/lib ?? :) Thanks, David > testing: run the affected tests > jbs: https://bugs.openjdk.java.net/browse/JDK-8148012 > > Thanks, > Igor > From tobias.hartmann at oracle.com Wed Jan 27 07:00:25 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 27 Jan 2016 08:00:25 +0100 Subject: [8u] Request for approval: Backport of 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type In-Reply-To: <56A7B6CB.8050606@oracle.com> References: <56A5F209.3060704@oracle.com> <56A66045.9050200@oracle.com> <56A732AB.30103@oracle.com> <56A7B6CB.8050606@oracle.com> Message-ID: <56A86B09.3000903@oracle.com> Thanks, Vladimir. Best, Tobias On 26.01.2016 19:11, Vladimir Kozlov wrote: > Looks good now. > > Thanks, > Vladimir > > > On 1/26/16 12:47 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 25.01.2016 18:49, Vladimir Kozlov wrote: >>> RFR for 8u should use original 6675699 bug id and also use it in 8u the changeset comment: >>> >>> https://bugs.openjdk.java.net/browse/JDK-6675699 >> >> Right, somehow I got confused because the backport issue was created explicitly. Sorry for that. >> >> Here is the correct information (I leave the email subject for history): >> >> 6675699: need comprehensive fix for unconstrained ConvI2L with narrowed type >> https://bugs.openjdk.java.net/browse/JDK-6675699 >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de >> >>> parse2.cpp I noticed that JDK9 change remove -1 from "num_cases-1". Was it intentional? >> >> Yes, this is intended because the JDK 9 change uses Compile::conv_I2X_index() which already subtracts 1 from ikeytype->_hi: >> >> 4019 if (sizetype != NULL) index_max = sizetype->_hi - 1; >> >> JDK 8u change uses C->constrained_convI2L() which does not change the ikeytype->_hi. >> >>> graphKit.cpp fast_size_limit is used in jdk9 but not in 8u. Why? >> >> Thanks for pointing that out. The JDK 8u fix should use 'fast_size_limit' as upper bound as well because it's more accurate than 'max_array_length'. >> >> New webrev: >> http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.01/ >> >> Best, >> Tobias >> >>> On 1/25/16 1:59 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please approve and review the following backport to 8u. >>>> >>>> 8147548: need comprehensive fix for unconstrained ConvI2L with narrowed type >>>> https://bugs.openjdk.java.net/browse/JDK-8147548 >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020810.html >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bfb7a8a004de >>>> >>>> The fix was pushed to hs-comp on January, 18 and nightly testing showed no problems. Unfortunately, the changes do not apply cleanly to 8u-dev because several enhancements that affect related code were not backported to 8. Here is a new webrev: >>>> http://cr.openjdk.java.net/~thartmann/6675699_8u/webrev.00/ >>>> >>>> I did additional performance and correctness testing to verify that the backport works fine and does not introduce a regression. >>>> >>>> Thanks, >>>> Tobias >>>> From volker.simonis at gmail.com Wed Jan 27 07:07:31 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Jan 2016 08:07:31 +0100 Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by #ifdef _MSC_VER In-Reply-To: <56A82665.2000005@oracle.com> References: <98C2119538350A4E92B3DD08E7B4146801E207D8A2@DEWDFEMB14B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F8EA00@DEWDFEMB12B.global.corp.sap> <98C2119538350A4E92B3DD08E7B4146801F0C5C6D4@DEWDFEMB14B.global.corp.sap> <56A82665.2000005@oracle.com> Message-ID: Thanks a lot David! Volker On Wed, Jan 27, 2016 at 3:07 AM, David Holmes wrote: > We seem a bit inconsistent about how we guard compiler specific pragma's in > shared code, but the use of _MSC_VER does already exist so this change seems > fine to me. > > I will sponsor it. > > Thanks, > David > > > On 26/01/2016 2:58 AM, Volker Simonis wrote: >> >> Hi Matthias, >> >> this fix is good! >> >> The change was initially introduced to appease the Visual Studio >> compiler. But we shouldn't do that at the cost of provoking warnings >> with other compilers. Compiler specific pragmas in shared code should >> be guarded appropriately. Alternatively, we could also disable this >> warning globally on Windows by placing the pragma into >> globalDefinitions_visCPP.hpp. >> >> Either way, we need a sponsor. David, maybe you can assist? >> >> Here's a link to the initial bug which introduced this code: >> >> https://bugs.openjdk.java.net/browse/JDK-8074895 >> >> The corresponding review thread states: >> >> Microsoft describes it as an obsolete warning: >> >> https://msdn.microsoft.com/en-us/library/wewb47ee.aspx >> >> "This warning is obsolete. It is only generated in Visual Studio >> 2005 through Visual Studio 2012. It reports a behavior change from >> the Visual C++ compiler that shipped in Visual Studio .NET when >> initializing a POD (plain old data) object with (); the compiler >> default-initializes the object.? >> >> Thank you and best regards, >> Volker >> >> >> On Mon, Jan 25, 2016 at 5:37 PM, Baesken, Matthias >> wrote: >>> >>> Ping .... any reviewers ?? >>> >>> Best regards, Matthias >>> >>> -----Original Message----- >>> From: Langer, Christoph >>> Sent: Montag, 21. Dezember 2015 23:18 >>> To: Baesken, Matthias ; >>> hotspot-dev at openjdk.java.net >>> Cc: Simonis, Volker >>> Subject: RE: RFR (s) : 8145740: Visual Studio pragmas should be guarded >>> by #ifdef _MSC_VER >>> >>> Hi Matthias, >>> >>> to me your change looks good. However, I'm no reviewer so you'll need >>> sponsorship from someone else. >>> >>> Can someone please sponsor this? Should it maybe be posted in another >>> list for better visibility? >>> >>> Best regards >>> Christoph >>> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf >>> Of Baesken, Matthias >>> Sent: Freitag, 18. Dezember 2015 14:30 >>> To: hotspot-dev at openjdk.java.net >>> Cc: Simonis, Volker >>> Subject: RFR (s) : 8145740: Visual Studio pragmas should be guarded by >>> #ifdef _MSC_VER >>> >>> Hello, >>> can you please review and sponsor this change : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8145740 >>> http://cr.openjdk.java.net/~clanger/webrevs/8145740.0/ >>> >>> Some details : >>> >>> while Visual Studio pragmas in shared code are usually guarded >>> with _MSC_VER in the hotspot codebase >>> ( see for example taskqueue.hpp or compressedStream.cpp ) , the >>> guarding is missing in src/share/vm/utilities/growableArray.hpp , >>> which is not really a "good thing" for other compilers . >>> >>> >>> Thanks and regards, Matthias >>> > From aleksey.shipilev at oracle.com Wed Jan 27 09:09:14 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Jan 2016 12:09:14 +0300 Subject: RFR (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56A79588.8050201@oracle.com> References: <56A64E34.8020305@oracle.com> <56A66A7E.20604@oracle.com> <56A79588.8050201@oracle.com> Message-ID: <56A8893A.8040503@oracle.com> Hi Coleen, On 01/26/2016 06:49 PM, Coleen Phillimore wrote: > This might be a good time to split vmIntrinsics off from vmSymbols and > create new .hpp and .cpp files for them. There are a lot of both now > and they're different. vmSymbols depends on vmIntrinsics: #define VM_SYMBOLS_DO(template do_alias) ... /* class symbols needed by intrinsics */ VM_INTRINSICS_DO(VM_INTRINSIC_IGNORE, template, VM_SYMBOL_IGNORE, VM_SYMBOL_IGNORE, VM_ALIAS_IGNORE) Therefore, splitting out vmIntrinsics would mean vmSymbols would have to include vmIntrinsics anyway, so I don't see the benefit of doing that within this patch. > Is the implementation of these mostly in > library_call.cpp? C2 intrinsics are implemented in library_call.cpp. The subsequent patches would probably bring C1 intrinsics as well, which will reference the same vmIntrinsic symbols. > Also, if there are changes to vmStructs there are likely changes to the > serviceability agent duplicated code. If not, then there is no need to > make changes to vmStructs. Well, I grepped through SA code, and see no references even for the existing CompareAndSwap nodes. Which makes me to believe we would just want to communicate the nodes appropriately through vmStructs table, and be done. This is what the patch already does. > There might be changes to jvmciStructs though. I don't know. I grepped through JVMCI, and found no clear dependencies, except for referenced MH intrinsics, that are not affected by this patch. >> On 1/25/16 8:32 AM, Aleksey Shipilev wrote: >>> Webrev: >>> http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.00/ >>> http://cr.openjdk.java.net/~shade/8148146/webrev.hs.00/ Cheers, -Aleksey From mikael.gerdin at oracle.com Wed Jan 27 12:43:12 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 27 Jan 2016 13:43:12 +0100 Subject: RFR(M) 8148047: Move the vtable length field to Klass In-Reply-To: <56A65528.9030808@oracle.com> References: <56A24F77.6030804@oracle.com> <56A28123.3090203@oracle.com> <56A63284.8090608@oracle.com> <56A65528.9030808@oracle.com> Message-ID: <56A8BB60.5040801@oracle.com> Hi Chris, On 2016-01-25 18:02, Chris Plummer wrote: > Hi Mikael, > > On 1/25/16 6:34 AM, Mikael Gerdin wrote: >> Hi Chris, >> >> On 2016-01-22 20:21, Chris Plummer wrote: >>> Hi Mikael, >>> >>> On 1/22/16 7:49 AM, Mikael Gerdin wrote: >>>> Hi all, >>>> >>>> Here's the second part of the set of changes to move most of the >>>> vtable related code to Klass. >>>> >>>> This change consists of the following parts: >>>> * Move the field _vtable_len to Klass, making its accessor nonvirtual. >>>> -> Ensure that this does not result in any footprint regression by >>>> moving TRACE_DEFINE_KLASS_TRACE_ID in Klass and _itable_len in >>>> InstanceKlass to fill out alignment gaps. >>> I also double checked this, including with minimal VM. The sizeof(Klass) >>> remains unchanged. >> >> Thanks for verifying. >> >>> >>> And your relocation of InstanceKlass::_itable_len should result in >>> InstanceKlass being 8 bytes smaller on 64-bit, although I did not double >>> check that. >>>> -> Move vtable_length_offset to Klass. Move vtable_start_offset to >>>> Klass to keep the code consistent. vtable_start_offset depends on the >>>> size of InstanceKlass and must therefore be defined outside of >>>> klass.hpp. >>> The abstraction has kind of gone awry: >>> >>> 662 ByteSize Klass::vtable_start_offset() { >>> 663 return in_ByteSize(InstanceKlass::header_size() * wordSize); >>> 664 } >>> >>> Note the reference to InstanceKlass. I understand why you are doing >>> this. All Klass subclasses have their sizes padded out to the size of >>> InstanceKlass so the vtable is always in the same place. I was just >>> wondering if there is a cleaner way. I guess the abstraction was broken >>> before your changes, but in a different place. We used to call >>> InstanceKlass::vtable_start_offset() even for array types. Now you >>> instead call Klass::vtable_start_offset(), and it does the dirty deed of >>> referencing InstanceKlass. I guess I'm ok with it. Just wanted to point >>> it out in case you had more thoughts. >> >> I agree that it's not the nicest abstraction, I could "hide" it in a >> static field in Klass or Universe or something, but that's just >> sweeping the problem under the rug. >> >> On a slightly related topic, I did consider attempting to add some >> sort of assertion that InstanceKlass is indeed the largest of all >> subclasses of Klass, otherwise this code would be broken. For example >> if someone had the idea of adding a sufficiently large field to a >> subclass of InstanceKlass then the vtable would conflict with that field. > I think you meant add a field to a subclass of Klass, not InstanceKlass. >> >> One approach would be to have a protected Klass constructor which >> takes a template parameter T, where subclasses pass "themselves" and >> the Klass constructor verifies that sizeof(T) <= sizeof(InstanceKlass) >> (with or without word size scaling). > There's already a check in place for ArrayKlass subclasses, which do > something similar by passing in their own size: > > int ArrayKlass::static_size(int header_size) { > // size of an array klass object > assert(header_size <= InstanceKlass::header_size(), "bad header size"); > // If this assert fails, see comments in base_create_array_klass. > header_size = InstanceKlass::header_size(); > int vtable_len = Universe::base_vtable_size(); > int size = header_size + vtable_len; > return align_object_size(size); > } Oh, I hadn't' noticed that. That's good at least for ArrayKlass then. Thanks for the info /Mikael > > cheers, > > Chris >> >> >>> >>>> >>>> * Update all locations to refer to Klass::vtable_{length,start}_offset >>>> instead of InstanceKlass. >>> Looks good. >>>> >>>> * Modify SA to look for _vtable_len in Klass. >>> Looks good. >>>> >>>> * Rename CompilerToVM::Data::InstanceKlass_vtable_{length,start}_offset >>>> and >>>> jdk.vm.ci.hotspot.HotSpotVMConfig.instanceKlassVtable{Length,Start}Offset >>>> >>>> to properly represent where the offsets are coming from. >>> Looks good. >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8148047/webrev.0/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148047 >>>> >>>> Testing: JPRT on Oracle supported platforms. >>>> >>>> As in the previous change I've updated the PPC64 and AARCH64 ports but >>>> I have not tested the changes. Build and test feedback from porters is >>>> most welcome! >>> >>> Cheers, >> >> Thanks for the review, Chris. >> /Mikael >> >>> >>> Chris >>>> >>>> Thanks >>>> /Mikael >>> >> > From igor.ignatyev at oracle.com Wed Jan 27 12:57:44 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 27 Jan 2016 15:57:44 +0300 Subject: RFR(S) : 8148012 : get rid of slash-dot-dot in @library directives In-Reply-To: <56A8502A.2070804@oracle.com> References: <56A8502A.2070804@oracle.com> Message-ID: <2A88F026-458F-4EE4-AC4C-EB4047EC678F@oracle.com> Hi David, thanks for review. > Remind me what is in /testlibrary versus /test/lib ?? :) one is located in /hotspot/test/ another in , so one contains (is supposed to contain) hotspot specific library, another common used libraries and there is an RFE to make it so. ? Igor > On Jan 27, 2016, at 8:05 AM, David Holmes wrote: > > Hi Igor, > > On 26/01/2016 5:36 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8148012/webrev.00/ >>> 31 lines changed: 0 ins; 0 del; 31 mod; >> >> Having ?external.lib.roots=/../../' in TEST.ROOT made it possible not to use ?/..? in tests, the latest change in JTreg(https://bugs.openjdk.java.net/browse/CODETOOLS-7901585) made it illegal to have references to directories outside a test suite, so it?s required to fix all such entries for switching to the next jtreg version. the fix basically replaces all '/../../test/lib? w/ ?/test/lib? in @library directives. > > I Reviewed the patch and it looks good. > > Remind me what is in /testlibrary versus /test/lib ?? :) > > Thanks, > David > >> testing: run the affected tests >> jbs: https://bugs.openjdk.java.net/browse/JDK-8148012 >> >> Thanks, >> Igor >> From aph at redhat.com Wed Jan 27 13:45:16 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Jan 2016 13:45:16 +0000 Subject: [aarch64-port-dev ] RFR: 8148328: aarch64: avoid unnecessary lsr instructions in stub code In-Reply-To: References: Message-ID: <56A8C9EC.2080209@redhat.com> On 01/27/2016 11:47 AM, Felix Yang wrote: > Please review the following webrev: > http://cr.openjdk.java.net/~fyang/8148328/webrev.00/ > > Jira issue: https://bugs.openjdk.java.net/browse/JDK-8148328 > > This trivial patch eliminates unnecessary lsr instructions in > jbyte_arraycopy and jbyte_disjoint_arraycopy stub. > > Tested with jtreg hotspot & langtools. Is it OK? OK, except that this is C++ so we can declare shift when it is defined: diff --git a/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp b/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp --- a/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp +++ b/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp @@ -962,7 +962,7 @@ __ lea(d, Address(d, count, Address::lsl(exact_log2(-step)))); } - Label done, tail; + Label tail; __ cmp(count, 16/granularity); __ br(Assembler::LO, tail); @@ -987,7 +987,8 @@ } // rscratch2 is the byte adjustment needed to align s. __ cbz(rscratch2, aligned); - __ lsr(rscratch2, rscratch2, exact_log2(granularity)); + int shift = exact_log2(granularity); + if (shift) __ lsr(rscratch2, rscratch2, shift); __ sub(count, count, rscratch2); #if 0 Andrew. From aleksey.shipilev at oracle.com Wed Jan 27 13:55:48 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Jan 2016 16:55:48 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) Message-ID: <56A8CC64.3080500@oracle.com> Hi again, This is a formal pre-integration review thread for JEP 280 ("Indify String Concatenation") integration: http://openjdk.java.net/jeps/280 The JEP is Targeted, the CCC is approved, the code reviews and pre-integration checks are clean. Code changes are happening simultaneously in four components: a) (M) javac changes that emit indy: http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ b) (L) JDK changes with StringConcatFactory and friends, plus fixing the regression tests that do not expect additional indys: http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ c) (XS) Build changes that force emitting the "legacy" inline StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is expected): http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ d) (XS) HotSpot changes that fix a GC regression test that now allocates some metaspace from within the test methods having a string concatenation: http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ These changes were already reviewed by multiple people, and so I would like to keep the comments only for serious breaking issues at this point. (Note that this thread cross-posts over several mailing lists: bike-shedding discussion would get multiplied a lot!) Formal acknowledgements from Reviewers would be appreciated. Pending no show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. Thanks, -Aleksey From paul.sandoz at oracle.com Wed Jan 27 16:31:21 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jan 2016 17:31:21 +0100 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <7E17DDBD-9795-49FA-B83B-DF0F93C13374@oracle.com> I think it quite reasonable to push everything to jdk9/dev. Paul. > On 27 Jan 2016, at 14:55, Aleksey Shipilev wrote: > > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From vladimir.x.ivanov at oracle.com Wed Jan 27 16:47:22 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 27 Jan 2016 19:47:22 +0300 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56A8F49A.4050503@oracle.com> JDK changes looks good! Best regards, Vladimir Ivanov On 1/27/16 4:55 PM, Aleksey Shipilev wrote: > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From coleen.phillimore at oracle.com Wed Jan 27 18:27:23 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Jan 2016 13:27:23 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size Message-ID: <56A90C0B.2050100@oracle.com> Summary: Use align_metadata_size, align_metadata_offset and is_metadata_aligned for metadata rather than align_object_size, etc. Use wordSize rather than HeapWordSize for metadata. Use align_ptr_up rather than align_pointer_up (all the related functions are ptr). Ran RBT quick tests on all platforms along with Chris's Plummers change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist co-located tests because there are SA changes. Reran subset of this after merging. I have a script to update copyrights on commit. It's not a big change, just mostly boring. See the bug comments for more details about the change. open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ bug link https://bugs.openjdk.java.net/browse/JDK-8145628 thanks, Coleen From harold.seigel at oracle.com Wed Jan 27 20:57:35 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 27 Jan 2016 15:57:35 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56A90C0B.2050100@oracle.com> References: <56A90C0B.2050100@oracle.com> Message-ID: <56A92F3F.6080200@oracle.com> Hi Coleen, The changes look good. One comment, these two methods in globalDefinitions.hpp appear to be no-ops: 498 inline intptr_t align_metadata_size(intptr_t size) { 499 return align_size_up(size, 1); 500 } 501 502 inline intptr_t align_metadata_offset(intptr_t offset) { 503 return align_size_up(offset, 1); 504 } Are the size and offset arguments already in words? If so, could you add a comment? Thanks, Harold On 1/27/2016 1:27 PM, Coleen Phillimore wrote: > Summary: Use align_metadata_size, align_metadata_offset and > is_metadata_aligned for metadata rather > than align_object_size, etc. Use wordSize rather than HeapWordSize > for metadata. Use align_ptr_up > rather than align_pointer_up (all the related functions are ptr). > > Ran RBT quick tests on all platforms along with Chris's Plummers > change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist > co-located tests because there are SA changes. Reran subset of this > after merging. > > I have a script to update copyrights on commit. It's not a big change, > just mostly boring. See the bug comments for more details about the > change. > > open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ > bug link https://bugs.openjdk.java.net/browse/JDK-8145628 > > thanks, > Coleen > > From mikael.vidstedt at oracle.com Thu Jan 28 01:13:57 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 27 Jan 2016 17:13:57 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <713CDD14-7C04-4B33-AC48-6A5474351C97@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> <56A7BF7B.5020006@redhat.com> <17C15340-167F-4B33-A6CF-8510EAC2491C@oracle.com> <56A7C410.4040301@redhat.com> <713CDD14-7C04-4B33-AC48-6A5474351C97@oracle.com> Message-ID: <56A96B55.7050301@oracle.com> Just an FYI: I'm working on moving all of this to the Hotspot Copy class and bridging to it via jdk.internal.misc.Unsafe, removing Bits.c altogether. The implementation is working, and the preliminary performance numbers beat the pants off of any of the suggested Bits.c implementations (yay!). I'm currently in the progress of getting some unit tests in place for it all to make sure it covers all the corner cases and then I'll run some real benchmarks to see if it actually lives up to the expectations. Cheers, Mikael On 2016-01-26 11:13, John Rose wrote: > On Jan 26, 2016, at 11:08 AM, Andrew Haley wrote: >> On 01/26/2016 07:04 PM, John Rose wrote: >>> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. >>> IMO that's a better starting point than memcpy. Perhaps it can be >>> given an additional parameter (or overloading) to specify a swap size. >> OK, but conjoint_memory_atomic doesn't guarantee that destination >> words won't be torn if their source is misaligned: in fact it >> guarantees that they will will be. > That's a good point, and argues for a new function with the > stronger guarantee. Actually, it would be perfectly reasonable > to strengthen the guarantee on the existing function. I don't > think anyone will care about the slight performance change, > especially since it is probably favorable. Since it's Unsafe, > they are not supposed to care, either. > > ? John From coleen.phillimore at oracle.com Thu Jan 28 01:56:03 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Jan 2016 20:56:03 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56A92F3F.6080200@oracle.com> References: <56A90C0B.2050100@oracle.com> <56A92F3F.6080200@oracle.com> Message-ID: <56A97533.2000203@oracle.com> On 1/27/16 3:57 PM, harold seigel wrote: > Hi Coleen, > > The changes look good. > > One comment, these two methods in globalDefinitions.hpp appear to be > no-ops: > > 498 inline intptr_t align_metadata_size(intptr_t size) { > 499 return align_size_up(size, 1); > 500 } > 501 > 502 inline intptr_t align_metadata_offset(intptr_t offset) { > 503 return align_size_up(offset, 1); > 504 } > > Are the size and offset arguments already in words? If so, could you > add a comment? Yes, the size given is in words and I'll add a comment. I guess I could have removed align_metadata*() functions. Thank you for reviewing! Coleen > > Thanks, Harold > > > On 1/27/2016 1:27 PM, Coleen Phillimore wrote: >> Summary: Use align_metadata_size, align_metadata_offset and >> is_metadata_aligned for metadata rather >> than align_object_size, etc. Use wordSize rather than HeapWordSize >> for metadata. Use align_ptr_up >> rather than align_pointer_up (all the related functions are ptr). >> >> Ran RBT quick tests on all platforms along with Chris's Plummers >> change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist >> co-located tests because there are SA changes. Reran subset of this >> after merging. >> >> I have a script to update copyrights on commit. It's not a big >> change, just mostly boring. See the bug comments for more details >> about the change. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >> >> thanks, >> Coleen >> >> > From christian.thalinger at oracle.com Thu Jan 28 09:41:58 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Jan 2016 10:41:58 +0100 Subject: RFR(M) 8147461: Use byte offsets for vtable start and vtable length offsets In-Reply-To: <56A1FA78.3090608@oracle.com> References: <569926B9.4070806@oracle.com> <569F7E22.3090905@oracle.com> <56A04DCF.9090204@oracle.com> <56A1FA78.3090608@oracle.com> Message-ID: > On Jan 22, 2016, at 10:46 AM, Mikael Gerdin wrote: > > Hi Chris, > > On 2016-01-21 04:17, Chris Plummer wrote: >> Hi Mikael, >> >> The changes look good except I think you should get someone from the >> compiler team to make sure the change in >> HotSpotResolvedJavaMethodImpl.java and HotSpotVMConfig.java are ok. I'm >> not sure why you chose to remove instanceKlassVtableStartOffset() rather >> than just fix it. > > I'm cc:ing hotspot-compiler-dev and graal-dev to see if I can get someone to ok the JVMCI parts. > > The reason for removing the method is that the only reason for it being a method was to apply the wordSize scaling on the value and since I changed the offset to be a byte offset it does not need scaling and can be treated similar to the other constants in HotSpotVMConfig which are accessed without any accessor method. For the record, the JVMCI changes look good. > >> >> I think some of your changes may conflict with my changes for >> JDK-8143608. Coleen is pushing JDK-8143608 for me once hs-rt opens up. >> I'd appreciate it if you could wait until after then before doing your >> push. > > Will do, would you mind pinging me when you've integrated 8143608? > > /Mikael > >> >> thanks, >> >> Chris >> >> On 1/20/16 4:31 AM, Mikael Gerdin wrote: >>> Hi again, >>> >>> I've rebased the on hs-rt and had to include some additional changes >>> for JVMCI. >>> I've also updated the copyright years. >>> Unfortunately I can't generate an incremental webrev since i rebased >>> the patch and there's no good way that I know of to make that work >>> with webrev. >>> >>> New webrev at: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.1/ >>> >>> Testing: JPRT again (which includes the JVMCI jtreg tests) >>> >>> /Mikael >>> >>> On 2016-01-15 18:04, Mikael Gerdin wrote: >>>> Hi all, >>>> >>>> As per the previous discussion in mid-December[0] about moving the >>>> _vtable_length field to class Klass, here's the first RFR and webrev, >>>> according to my suggested plan[1]: >>>> >>>>> My current plan is to first modify the vtable_length_offset accessor to >>>>> return a byte offset (which is what it's translated to by all callers). >>>>> >>>>> Then I'll tackle moving the _vtable_len field to Klass. >>>>> >>>>> Finally I'll try to consolidate the vtable related methods to Klass, >>>>> where they belong. >>>> >>>> This change actually consists of three changes: >>>> * modifying InstanceKlass::vtable_length_offset to become a byte offset >>>> and use the ByteSize type to communicate the scaling. >>>> * modifying InstanceKlass::vtable_start_offset to become a byte offset >>>> and use the ByteSize type, for symmetry reasons mainly. >>>> * adding a vtableEntry::size_in_bytes() since in many places the vtable >>>> entry size is used in combination with the vtable start to compute a >>>> byte offset for vtable lookups. >>>> >>>> I don't foresee any issues with the fact that the byte offset is >>>> represented as an int, for two reasons: >>>> 1) If the offset of any of these grows to over 2 gigabytes then we have >>>> a huge footprint problem with InstanceKlass >>>> 2) The offsets are converted to byte offsets and stored in ints already >>>> in the cpu specific code I've modified. >>>> >>>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147461 >>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8147461/webrev.0/ >>>> >>>> Testing: JPRT on Oracle supported platforms, testing on AARCH64 and >>>> PPC64 would be much appreciated, appropriate mailing lists have been >>>> CC:ed to notify them of the request. >>>> >>>> >>>> [0] >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021152.html >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-December/021224.html >>>> >>>> >>>> >>>> Thanks! >>>> /Mikael >>> >> > From mikael.gerdin at oracle.com Thu Jan 28 12:54:04 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Jan 2016 13:54:04 +0100 Subject: RFR(M) 8148047: Move the vtable length field to Klass In-Reply-To: <3776D93D-4E6C-41F5-8F9C-E43B8D03AEEB@oracle.com> References: <56A24F77.6030804@oracle.com> <3776D93D-4E6C-41F5-8F9C-E43B8D03AEEB@oracle.com> Message-ID: <56AA0F6C.3060702@oracle.com> Hi Chris, On 2016-01-22 19:01, Christian Thalinger wrote: > >> On Jan 22, 2016, at 5:49 AM, Mikael Gerdin wrote: >> >> Hi all, >> >> Here's the second part of the set of changes to move most of the vtable related code to Klass. >> >> This change consists of the following parts: >> * Move the field _vtable_len to Klass, making its accessor nonvirtual. >> -> Ensure that this does not result in any footprint regression by moving TRACE_DEFINE_KLASS_TRACE_ID in Klass and _itable_len in InstanceKlass to fill out alignment gaps. >> -> Move vtable_length_offset to Klass. Move vtable_start_offset to Klass to keep the code consistent. vtable_start_offset depends on the size of InstanceKlass and must therefore be defined outside of klass.hpp. >> >> * Update all locations to refer to Klass::vtable_{length,start}_offset instead of InstanceKlass. >> >> * Modify SA to look for _vtable_len in Klass. >> >> * Rename CompilerToVM::Data::InstanceKlass_vtable_{length,start}_offset >> and jdk.vm.ci.hotspot.HotSpotVMConfig.instanceKlassVtable{Length,Start}Offset to properly represent where the offsets are coming from. > > We have to be careful with name changes in HotSpotVMConfig because that basically means we are changing the API (kind of, since the fields are public). Graal doesn?t use these fields only JVMCI itself so that change is good. Can I count this as a review of the entire change or is your statement narrowed down to only concern the JVMCI related changes? /Mikael > >> >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8148047/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148047 >> >> Testing: JPRT on Oracle supported platforms. >> >> As in the previous change I've updated the PPC64 and AARCH64 ports but I have not tested the changes. Build and test feedback from porters is most welcome! >> >> Thanks >> /Mikael > From sean.coffey at oracle.com Thu Jan 28 15:21:36 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 28 Jan 2016 15:21:36 +0000 Subject: [8u communication] - Removal of jdk8u60-hs and jdk8u60-dev forests Message-ID: <56AA3200.3060205@oracle.com> To help keep the mercurial server clean of old unnecessary development forests, I'd like to propose that the jdk8u/hs-dev forest be deleted. This is the old hotspot team integration forest that was used in the earlier days of the JDK 8 Updates Project. It's no longer used and all its changes are in the JDK 8u master forest (jdk8u). If I hear no objections before COB Monday 1st February, I'll ask ops team to delete the forest. -- Regards, Sean. From sean.coffey at oracle.com Thu Jan 28 15:23:39 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 28 Jan 2016 15:23:39 +0000 Subject: [8u communication] - Removal of jdk8u/hs-dev forest In-Reply-To: <56AA3200.3060205@oracle.com> References: <56AA3200.3060205@oracle.com> Message-ID: <56AA327B.4090901@oracle.com> Resending with correct Subject title.. Regards, Sean. On 28/01/2016 15:21, Se?n Coffey wrote: > To help keep the mercurial server clean of old unnecessary development > forests, I'd like to propose that the jdk8u/hs-dev forest be deleted. > > This is the old hotspot team integration forest that was used in the > earlier days of the JDK 8 Updates Project. It's no longer used and all > its changes are in the JDK 8u master forest (jdk8u). > > If I hear no objections before COB Monday 1st February, I'll ask ops > team to delete the forest. > From aph at redhat.com Thu Jan 28 16:10:21 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Jan 2016 16:10:21 +0000 Subject: [8u communication] - Removal of jdk8u60-hs and jdk8u60-dev forests In-Reply-To: <56AA3200.3060205@oracle.com> References: <56AA3200.3060205@oracle.com> Message-ID: <56AA3D6D.6060702@redhat.com> On 01/28/2016 03:21 PM, Se?n Coffey wrote: > To help keep the mercurial server clean of old unnecessary development > forests, I'd like to propose that the jdk8u/hs-dev forest be deleted. All of us have, from time to time, done software archaeology in order to discover when a change was made. By definition you cannot know when this might be needed. In my opinion it would make sense to archive this somewhere. Andrew. From mikael.gerdin at oracle.com Thu Jan 28 16:13:25 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Jan 2016 17:13:25 +0100 Subject: RFR(M) 8148481: Devirtualize Klass::vtable Message-ID: <56AA3E25.60409@oracle.com> Hi all, Due to my recent changes in this area, Klass is now responsible for maintaining the offsets and length of the embedded vtable and therefore it makes sense to move all code related to the Java vtables to Klass. This also allows us to remove a few unsafe casts where an ArrayKlass was cast to an InstanceKlass just to get at the methods_at_vtable(). These casts were removed from reflection.cpp, jni.cpp, jvmciCompilerToVM.cpp and linkResolver.cpp, in cpCache.cpp there was an alternate approach to the same problem which I've rewritten to use the new way of accessing the vtable directly through Klass. Some notes: * I took the liberty of changing the return type of start_of_vtable() to vtableEntry* since that is in fact what it is. * method_at_vtable is no longer inline, but I don't think that should be a performance problem since it's usually only being called from link resolving, cpCache or JNI calls, all of which are not particularly hot paths. Bug link: https://bugs.openjdk.java.net/browse/JDK-8148481 Webrev: http://cr.openjdk.java.net/~mgerdin/8148481/webrev.0 Testing: JPRT + RBT on Oracle platforms. /Mikael From maurizio.cimadamore at oracle.com Thu Jan 28 16:34:36 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2016 16:34:36 +0000 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56AA431C.4010008@oracle.com> Langtools changes look fine to me (as discussed on previous review thread). Thanks! Maurizio On 27/01/16 13:55, Aleksey Shipilev wrote: > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: > http://openjdk.java.net/jeps/280 > > The JEP is Targeted, the CCC is approved, the code reviews and > pre-integration checks are clean. > > Code changes are happening simultaneously in four components: > > a) (M) javac changes that emit indy: > http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/ > > b) (L) JDK changes with StringConcatFactory and friends, plus fixing > the regression tests that do not expect additional indys: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/ > > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ > > d) (XS) HotSpot changes that fix a GC regression test that now > allocates some metaspace from within the test methods having a string > concatenation: > http://cr.openjdk.java.net/~shade/8085796/webrev.hs.00/ > > These changes were already reviewed by multiple people, and so I would > like to keep the comments only for serious breaking issues at this > point. (Note that this thread cross-posts over several mailing lists: > bike-shedding discussion would get multiplied a lot!) > > Formal acknowledgements from Reviewers would be appreciated. Pending no > show-stopper comments, I'd like to push this through jdk9/dev in 24 hours. > > Thanks, > -Aleksey > From jon.masamitsu at oracle.com Thu Jan 28 20:41:49 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 28 Jan 2016 12:41:49 -0800 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56A90C0B.2050100@oracle.com> References: <56A90C0B.2050100@oracle.com> Message-ID: <56AA7D0D.1050602@oracle.com> Changes look good. Some minor points (for which I don't need to see another webrev if you decide to make changes based on these) http://cr.openjdk.java.net/~coleenp/8145628.01/webrev/src/share/vm/oops/klassVtable.hpp.udiff.html - static int size() { return sizeof(itableOffsetEntry) / HeapWordSize; } // size in words + static int size() { return sizeof(itableOffsetEntry)/wordSize; } // size in words Surrounding code puts space around the operators. In this case around the " / " seem appropriate. http://cr.openjdk.java.net/~coleenp/8145628.01/webrev/src/share/vm/utilities/globalDefinitions.cpp.frames.html You added 88 assert(wordSize == BytesPerWord, "should be the same since they're used interchangeably"); Many of the changes were like the one above in klassVtable.hpp where HeapWordSize -> wordSize. Do you want to assert "wordSize == HeapWordSize"? Jon On 01/27/2016 10:27 AM, Coleen Phillimore wrote: > Summary: Use align_metadata_size, align_metadata_offset and > is_metadata_aligned for metadata rather > than align_object_size, etc. Use wordSize rather than HeapWordSize > for metadata. Use align_ptr_up > rather than align_pointer_up (all the related functions are ptr). > > Ran RBT quick tests on all platforms along with Chris's Plummers > change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist > co-located tests because there are SA changes. Reran subset of this > after merging. > > I have a script to update copyrights on commit. It's not a big change, > just mostly boring. See the bug comments for more details about the > change. > > open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ > bug link https://bugs.openjdk.java.net/browse/JDK-8145628 > > thanks, > Coleen > > From coleen.phillimore at oracle.com Thu Jan 28 21:04:16 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Jan 2016 16:04:16 -0500 Subject: RFR (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles In-Reply-To: <56A8893A.8040503@oracle.com> References: <56A64E34.8020305@oracle.com> <56A66A7E.20604@oracle.com> <56A79588.8050201@oracle.com> <56A8893A.8040503@oracle.com> Message-ID: <56AA8250.2030308@oracle.com> On 1/27/16 4:09 AM, Aleksey Shipilev wrote: > Hi Coleen, > > On 01/26/2016 06:49 PM, Coleen Phillimore wrote: >> This might be a good time to split vmIntrinsics off from vmSymbols and >> create new .hpp and .cpp files for them. There are a lot of both now >> and they're different. > vmSymbols depends on vmIntrinsics: > > #define VM_SYMBOLS_DO(template do_alias) > ... > > /* class symbols needed by intrinsics */ > VM_INTRINSICS_DO(VM_INTRINSIC_IGNORE, template, VM_SYMBOL_IGNORE, > VM_SYMBOL_IGNORE, VM_ALIAS_IGNORE) > > Therefore, splitting out vmIntrinsics would mean vmSymbols would have to > include vmIntrinsics anyway, so I don't see the benefit of doing that > within this patch. The benefit is encapsulation, but they mutually depend on each other, so it's not that easy. Coleen > >> Is the implementation of these mostly in >> library_call.cpp? > C2 intrinsics are implemented in library_call.cpp. The subsequent > patches would probably bring C1 intrinsics as well, which will reference > the same vmIntrinsic symbols. > > >> Also, if there are changes to vmStructs there are likely changes to the >> serviceability agent duplicated code. If not, then there is no need to >> make changes to vmStructs. > Well, I grepped through SA code, and see no references even for the > existing CompareAndSwap nodes. Which makes me to believe we would just > want to communicate the nodes appropriately through vmStructs table, and > be done. This is what the patch already does. > > >> There might be changes to jvmciStructs though. I don't know. > I grepped through JVMCI, and found no clear dependencies, except for > referenced MH intrinsics, that are not affected by this patch. > > >>> On 1/25/16 8:32 AM, Aleksey Shipilev wrote: >>>> Webrev: >>>> http://cr.openjdk.java.net/~shade/8148146/webrev.jdk.00/ >>>> http://cr.openjdk.java.net/~shade/8148146/webrev.hs.00/ > Cheers, > -Aleksey > > From chris.plummer at oracle.com Thu Jan 28 21:24:54 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 28 Jan 2016 13:24:54 -0800 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56A90C0B.2050100@oracle.com> References: <56A90C0B.2050100@oracle.com> Message-ID: <56AA8726.7030807@oracle.com> Hi Coleen, Can you do some testing with ObjectAlignmentInBytes set to something other than 8? Someone from GC team should apply your patch, grep for align_object_size(), and confirm that the ones you didn't change are correct. I gave a quick look and they look right to me, but I wasn't always certain if object alignment was appropriate in all cases. I see some remaining HeapWordSize references that are suspect, like in Array.java and bytecodeTracer.cpp. I didn't go through all of them since there are about 428. Do they need closer inspection? align_metadata_offset() is not used. It can be removed. Shouldn't align_metadata_size() align to 64-bit like align_object_size() did, and not align to word size? Isn't that what we agreed to? Have you tested CDS? David had concerns about the InstanceKlass::size() not returning the same aligned size as Metachunk::object_alignment(). instanceKlass.hpp: Need to fix the following comment: 97 // sizeof(OopMapBlock) in HeapWords. thanks, Chris On 1/27/16 10:27 AM, Coleen Phillimore wrote: > Summary: Use align_metadata_size, align_metadata_offset and > is_metadata_aligned for metadata rather > than align_object_size, etc. Use wordSize rather than HeapWordSize > for metadata. Use align_ptr_up > rather than align_pointer_up (all the related functions are ptr). > > Ran RBT quick tests on all platforms along with Chris's Plummers > change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist > co-located tests because there are SA changes. Reran subset of this > after merging. > > I have a script to update copyrights on commit. It's not a big change, > just mostly boring. See the bug comments for more details about the > change. > > open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ > bug link https://bugs.openjdk.java.net/browse/JDK-8145628 > > thanks, > Coleen > > From coleen.phillimore at oracle.com Thu Jan 28 21:29:10 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Jan 2016 16:29:10 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56AA7D0D.1050602@oracle.com> References: <56A90C0B.2050100@oracle.com> <56AA7D0D.1050602@oracle.com> Message-ID: <56AA8826.8020603@oracle.com> Jon, Thank you for reviewing. On 1/28/16 3:41 PM, Jon Masamitsu wrote: > Changes look good. Some minor points (for which I don't > need to see another webrev if you decide to make changes > based on these) > > http://cr.openjdk.java.net/~coleenp/8145628.01/webrev/src/share/vm/oops/klassVtable.hpp.udiff.html > > > - static int size() { return sizeof(itableOffsetEntry) / HeapWordSize; > } // size in words > + static int size() { return sizeof(itableOffsetEntry)/wordSize; } // > size in words > > Surrounding code puts space around the operators. In this case around > the " / " seem > appropriate. The spacing around sizeof(Blah)/wordSize is inconsistent in the oops directory. My preference is no spaces. But there was another instance that I'd missed for vtableEntry: - static int size() { - return sizeof(vtableEntry) / sizeof(HeapWord); - } + static int size() { return sizeof(vtableEntry) / wordSize; } I added the spaces because you were nice enough to review my code. > > > http://cr.openjdk.java.net/~coleenp/8145628.01/webrev/src/share/vm/utilities/globalDefinitions.cpp.frames.html > > > You added > > 88 assert(wordSize == BytesPerWord, "should be the same since they're > used interchangeably"); > > Many of the changes were like the one above in klassVtable.hpp where > HeapWordSize -> wordSize. > Do you want to assert "wordSize == HeapWordSize"? Added: assert(wordSize == BytesPerWord, "should be the same since they're used interchangeably"); assert(wordSize == HeapWordSize, "should be the same since they're also used interchangeably"); Thanks! Coleen > > Jon > > > > On 01/27/2016 10:27 AM, Coleen Phillimore wrote: >> Summary: Use align_metadata_size, align_metadata_offset and >> is_metadata_aligned for metadata rather >> than align_object_size, etc. Use wordSize rather than HeapWordSize >> for metadata. Use align_ptr_up >> rather than align_pointer_up (all the related functions are ptr). >> >> Ran RBT quick tests on all platforms along with Chris's Plummers >> change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist >> co-located tests because there are SA changes. Reran subset of this >> after merging. >> >> I have a script to update copyrights on commit. It's not a big >> change, just mostly boring. See the bug comments for more details >> about the change. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >> >> thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Thu Jan 28 21:30:12 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Jan 2016 16:30:12 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56A92F3F.6080200@oracle.com> References: <56A90C0B.2050100@oracle.com> <56A92F3F.6080200@oracle.com> Message-ID: <56AA8864.8000307@oracle.com> On 1/27/16 3:57 PM, harold seigel wrote: > Hi Coleen, > > The changes look good. > > One comment, these two methods in globalDefinitions.hpp appear to be > no-ops: > > 498 inline intptr_t align_metadata_size(intptr_t size) { > 499 return align_size_up(size, 1); > 500 } > 501 > 502 inline intptr_t align_metadata_offset(intptr_t offset) { > 503 return align_size_up(offset, 1); > 504 } > > Are the size and offset arguments already in words? If so, could you > add a comment? Yes, I added a comment once deciding whether to keep this function: // Align metaspace objects by rounding up to natural word boundary // Since the size is given in words this is somewhat of a nop, but // distinguishes it from align_object_size. inline intptr_t align_metadata_size(intptr_t size) { return align_size_up(size, 1); } Thanks, Coleen > > Thanks, Harold > > > On 1/27/2016 1:27 PM, Coleen Phillimore wrote: >> Summary: Use align_metadata_size, align_metadata_offset and >> is_metadata_aligned for metadata rather >> than align_object_size, etc. Use wordSize rather than HeapWordSize >> for metadata. Use align_ptr_up >> rather than align_pointer_up (all the related functions are ptr). >> >> Ran RBT quick tests on all platforms along with Chris's Plummers >> change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist >> co-located tests because there are SA changes. Reran subset of this >> after merging. >> >> I have a script to update copyrights on commit. It's not a big >> change, just mostly boring. See the bug comments for more details >> about the change. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >> >> thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Thu Jan 28 21:41:11 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Jan 2016 16:41:11 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56AA8726.7030807@oracle.com> References: <56A90C0B.2050100@oracle.com> <56AA8726.7030807@oracle.com> Message-ID: <56AA8AF7.8020606@oracle.com> Thank you, Chris for looking at this change. On 1/28/16 4:24 PM, Chris Plummer wrote: > Hi Coleen, > > Can you do some testing with ObjectAlignmentInBytes set to something > other than 8? Okay, I can run one of the testsets with that. I verified it in the debugger mostly. > > Someone from GC team should apply your patch, grep for > align_object_size(), and confirm that the ones you didn't change are > correct. I gave a quick look and they look right to me, but I wasn't > always certain if object alignment was appropriate in all cases. thanks - this is why I'd changed the align_object_size to align_heap_object_size before testing and changed it back, to verify that I didn't miss any. > > I see some remaining HeapWordSize references that are suspect, like in > Array.java and bytecodeTracer.cpp. I didn't go through all of them > since there are about 428. Do they need closer inspection? > > align_metadata_offset() is not used. It can be removed. Okay, I'll remove it. That's a good idea. > > Shouldn't align_metadata_size() align to 64-bit like > align_object_size() did, and not align to word size? Isn't that what > we agreed to? Have you tested CDS? David had concerns about the > InstanceKlass::size() not returning the same aligned size as > Metachunk::object_alignment(). I ran the CDS tests but I could test some more with CDS. We don't want to force the size of objects to be 64 bit (especially Symbol) because Metachunk::object_alignment() is 64 bits. Unfortunately, with the latter, metadata is never aligned on 32 bit boundaries for 32 bit platforms, but to fix this, we have to pass a minimum_alignment parameter to Metaspace::allocate() because the alignment is not a function of the size of the object but what is required from its nonstatic data members. I found MethodCounters, Klass (and subclasses) and ConstantPool has such alignment constraints. Not sizing metadata to 64 bit sizes is a start for making this change. > > instanceKlass.hpp: Need to fix the following comment: > > 97 // sizeof(OopMapBlock) in HeapWords. Fixed, Thanks! Coleen > > thanks, > > Chris > > > On 1/27/16 10:27 AM, Coleen Phillimore wrote: >> Summary: Use align_metadata_size, align_metadata_offset and >> is_metadata_aligned for metadata rather >> than align_object_size, etc. Use wordSize rather than HeapWordSize >> for metadata. Use align_ptr_up >> rather than align_pointer_up (all the related functions are ptr). >> >> Ran RBT quick tests on all platforms along with Chris's Plummers >> change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist >> co-located tests because there are SA changes. Reran subset of this >> after merging. >> >> I have a script to update copyrights on commit. It's not a big >> change, just mostly boring. See the bug comments for more details >> about the change. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >> >> thanks, >> Coleen >> >> > From chris.plummer at oracle.com Thu Jan 28 21:52:52 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 28 Jan 2016 13:52:52 -0800 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56AA8AF7.8020606@oracle.com> References: <56A90C0B.2050100@oracle.com> <56AA8726.7030807@oracle.com> <56AA8AF7.8020606@oracle.com> Message-ID: <56AA8DB4.4050609@oracle.com> On 1/28/16 1:41 PM, Coleen Phillimore wrote: > > Thank you, Chris for looking at this change. > > On 1/28/16 4:24 PM, Chris Plummer wrote: >> Hi Coleen, >> >> Can you do some testing with ObjectAlignmentInBytes set to something >> other than 8? > > Okay, I can run one of the testsets with that. I verified it in the > debugger mostly. >> >> Someone from GC team should apply your patch, grep for >> align_object_size(), and confirm that the ones you didn't change are >> correct. I gave a quick look and they look right to me, but I wasn't >> always certain if object alignment was appropriate in all cases. > > thanks - this is why I'd changed the align_object_size to > align_heap_object_size before testing and changed it back, to verify > that I didn't miss any. >> >> I see some remaining HeapWordSize references that are suspect, like >> in Array.java and bytecodeTracer.cpp. I didn't go through all of them >> since there are about 428. Do they need closer inspection? ??? Any comment? >> >> align_metadata_offset() is not used. It can be removed. > > Okay, I'll remove it. That's a good idea. > >> >> Shouldn't align_metadata_size() align to 64-bit like >> align_object_size() did, and not align to word size? Isn't that what >> we agreed to? Have you tested CDS? David had concerns about the >> InstanceKlass::size() not returning the same aligned size as >> Metachunk::object_alignment(). > > I ran the CDS tests but I could test some more with CDS. We don't > want to force the size of objects to be 64 bit (especially Symbol) > because Metachunk::object_alignment() is 64 bits. Do you mean "just" because? I wasn't necessarily suggesting that all metadata be 64-bit aligned. However, the ones that have their allocation size 64-bit aligned should be. I think David's concern is that he wrote code that computes how much memory is needed for the archive, and it uses size() for that. If the Metachunk allocator allocates more than size() due to the 64-bit alignment of Metachunk::object_alignment(), then he will underestimate the size. You'll need to double check with David to see if I got this right. > Unfortunately, with the latter, metadata is never aligned on 32 bit > boundaries for 32 bit platforms, but to fix this, we have to pass a > minimum_alignment parameter to Metaspace::allocate() because the > alignment is not a function of the size of the object but what is > required from its nonstatic data members. Correct. > I found MethodCounters, Klass (and subclasses) and ConstantPool has > such alignment constraints. Not sizing metadata to 64 bit sizes is a > start for making this change. I agree with that, but just wanted to point out why David may be concerned with this change. >> >> instanceKlass.hpp: Need to fix the following comment: >> >> 97 // sizeof(OopMapBlock) in HeapWords. > Fixed, Thanks! thanks, Chris > > Coleen > >> >> thanks, >> >> Chris >> >> >> On 1/27/16 10:27 AM, Coleen Phillimore wrote: >>> Summary: Use align_metadata_size, align_metadata_offset and >>> is_metadata_aligned for metadata rather >>> than align_object_size, etc. Use wordSize rather than HeapWordSize >>> for metadata. Use align_ptr_up >>> rather than align_pointer_up (all the related functions are ptr). >>> >>> Ran RBT quick tests on all platforms along with Chris's Plummers >>> change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist >>> co-located tests because there are SA changes. Reran subset of >>> this after merging. >>> >>> I have a script to update copyrights on commit. It's not a big >>> change, just mostly boring. See the bug comments for more details >>> about the change. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >>> >>> thanks, >>> Coleen >>> >>> >> > From coleen.phillimore at oracle.com Fri Jan 29 03:31:19 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Jan 2016 22:31:19 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56AA8DB4.4050609@oracle.com> References: <56A90C0B.2050100@oracle.com> <56AA8726.7030807@oracle.com> <56AA8AF7.8020606@oracle.com> <56AA8DB4.4050609@oracle.com> Message-ID: <56AADD07.4080604@oracle.com> Hi Chris, I made a few extra changes because of your question that I didn't answer below, a few HeapWordSize became wordSize. I apologize that I don't know how to create incremental webrevs. See discussion below. open webrev at http://cr.openjdk.java.net/~coleenp/8145628.02/ On 1/28/16 4:52 PM, Chris Plummer wrote: > On 1/28/16 1:41 PM, Coleen Phillimore wrote: >> >> Thank you, Chris for looking at this change. >> >> On 1/28/16 4:24 PM, Chris Plummer wrote: >>> Hi Coleen, >>> >>> Can you do some testing with ObjectAlignmentInBytes set to something >>> other than 8? >> >> Okay, I can run one of the testsets with that. I verified it in the >> debugger mostly. >>> >>> Someone from GC team should apply your patch, grep for >>> align_object_size(), and confirm that the ones you didn't change are >>> correct. I gave a quick look and they look right to me, but I wasn't >>> always certain if object alignment was appropriate in all cases. >> >> thanks - this is why I'd changed the align_object_size to >> align_heap_object_size before testing and changed it back, to verify >> that I didn't miss any. >>> >>> I see some remaining HeapWordSize references that are suspect, like >>> in Array.java and bytecodeTracer.cpp. I didn't go through all of >>> them since there are about 428. Do they need closer inspection? > ??? Any comment? Actually, I tried to get a lot of HeapWordSize in the metadata but the primary focus of the change, despite the title, was to fix align_object_size wasn't used on metadata. That said a quick look at the instances of HeapWordSize led to some that weren't in the heap. I didn't look in Array.java because it's in the SA which isn't maintainable anyway, but I changed a few. There were very few that were not referring to objects in the Java heap. bytecodeTracer was one and there were a couple in metaspace.cpp. The bad news is that's more code to review. See above webrev link. >>> >>> align_metadata_offset() is not used. It can be removed. >> >> Okay, I'll remove it. That's a good idea. >> >>> >>> Shouldn't align_metadata_size() align to 64-bit like >>> align_object_size() did, and not align to word size? Isn't that what >>> we agreed to? Have you tested CDS? David had concerns about the >>> InstanceKlass::size() not returning the same aligned size as >>> Metachunk::object_alignment(). >> >> I ran the CDS tests but I could test some more with CDS. We don't >> want to force the size of objects to be 64 bit (especially Symbol) >> because Metachunk::object_alignment() is 64 bits. > Do you mean "just" because? I wasn't necessarily suggesting that all > metadata be 64-bit aligned. However, the ones that have their > allocation size 64-bit aligned should be. I think David's concern is > that he wrote code that computes how much memory is needed for the > archive, and it uses size() for that. If the Metachunk allocator > allocates more than size() due to the 64-bit alignment of > Metachunk::object_alignment(), then he will underestimate the size. > You'll need to double check with David to see if I got this right. I don't know what code this is but yes, it would be wrong. It also would be wrong if there's any other alignment gaps or space in metaspace chunks because chunks themselves have an allocation granularity. It could be changed back by changing the function align_metaspace_size from 1 to WordsPerLong if you wanted to. I fixed Symbol so that it didn't call align_metaspace_size if this change is needed in the future. I was trying to limit the size of this change to correct align_object_size for metadata. Thanks for looking at this in detail. Coleen >> Unfortunately, with the latter, metadata is never aligned on 32 bit >> boundaries for 32 bit platforms, but to fix this, we have to pass a >> minimum_alignment parameter to Metaspace::allocate() because the >> alignment is not a function of the size of the object but what is >> required from its nonstatic data members. > Correct. >> I found MethodCounters, Klass (and subclasses) and ConstantPool has >> such alignment constraints. Not sizing metadata to 64 bit sizes is a >> start for making this change. > I agree with that, but just wanted to point out why David may be > concerned with this change. >>> >>> instanceKlass.hpp: Need to fix the following comment: >>> >>> 97 // sizeof(OopMapBlock) in HeapWords. >> Fixed, Thanks! > thanks, > > Chris >> >> Coleen >> >>> >>> thanks, >>> >>> Chris >>> >>> >>> On 1/27/16 10:27 AM, Coleen Phillimore wrote: >>>> Summary: Use align_metadata_size, align_metadata_offset and >>>> is_metadata_aligned for metadata rather >>>> than align_object_size, etc. Use wordSize rather than HeapWordSize >>>> for metadata. Use align_ptr_up >>>> rather than align_pointer_up (all the related functions are ptr). >>>> >>>> Ran RBT quick tests on all platforms along with Chris's Plummers >>>> change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist >>>> co-located tests because there are SA changes. Reran subset of >>>> this after merging. >>>> >>>> I have a script to update copyrights on commit. It's not a big >>>> change, just mostly boring. See the bug comments for more details >>>> about the change. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >>>> >>>> thanks, >>>> Coleen >>>> >>>> >>> >> > From coleen.phillimore at oracle.com Fri Jan 29 12:46:49 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 29 Jan 2016 07:46:49 -0500 Subject: RFR 8146984: SIGBUS: bool Method::has_method_vptr(const void*)+0xc Message-ID: <56AB5F39.1060005@oracle.com> Summary: Add address check and use SafeFetchN for Method* vptr access when Method* may be bad pointer. Tested with RBT and failing test case (reproduced 1 in 100 times) with fatal in the 'return's in the change to verify. open webrev at http://cr.openjdk.java.net/~coleenp/8146984/ bug link https://bugs.openjdk.java.net/browse/JDK-8146984 Thanks, Coleen From erik.joelsson at oracle.com Fri Jan 29 13:32:06 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 14:32:06 +0100 Subject: RFR (L) JEP 280: Indify String Concatenation (integration) In-Reply-To: <56A8CC64.3080500@oracle.com> References: <56A8CC64.3080500@oracle.com> Message-ID: <56AB69D6.7060801@oracle.com> On 2016-01-27 14:55, Aleksey Shipilev wrote: > c) (XS) Build changes that force emitting the "legacy" inline > StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is > expected): > http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ In what context do we need pre-JDK 9 bytecode for java.base and jdk.compiler? /Erik From daniel.daugherty at oracle.com Fri Jan 29 16:02:54 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 Jan 2016 09:02:54 -0700 Subject: RFR 8146984: SIGBUS: bool Method::has_method_vptr(const void*)+0xc In-Reply-To: <56AB5F39.1060005@oracle.com> References: <56AB5F39.1060005@oracle.com> Message-ID: <56AB8D2E.7090902@oracle.com> On 1/29/16 5:46 AM, Coleen Phillimore wrote: > Summary: Add address check and use SafeFetchN for Method* vptr access > when Method* may be bad pointer. > > Tested with RBT and failing test case (reproduced 1 in 100 times) with > fatal in the 'return's in the change to verify. > > open webrev at http://cr.openjdk.java.net/~coleenp/8146984/ This one caught my eye because it has to do with sampling... src/share/vm/oops/method.cpp The old code checked "!is_metaspace_object()" and used has_method_vptr((const void*)this). The new code skips the "!is_metaspace_object()" check even after sanity checking the pointer, but you don't really explain why that's OK. The new code also picks up parts of Method::has_method_vptr() which makes me wonder if that's the right place for the fix. Won't other callers to Method::has_method_vptr() be subject to the same crashing mode? Or was the crashing mode only due to the "!is_metaspace_object()" check... Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8146984 > > Thanks, > Coleen > From gerard.ziemski at oracle.com Fri Jan 29 16:51:53 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 29 Jan 2016 10:51:53 -0600 Subject: RFR(M) 8069540: Remove universal binaries support from hotspot build Message-ID: Hi all (and especially the makefiles experts), This fix removes support for building hotspot universal libraries on Mac OS X and simplifies the makefiles. We are still building Mac OS X hotspot libraries as universal libraries, but with only one architecture (x86_64). The rest of JDK is built as plain single architecture libraries and there is no longer any need for this complexity (since we haven't supported 32bit platform on Mac OS X for a while now) Bug link: https://bugs.openjdk.java.net/browse/JDK-8069540 Webrev: http://cr.openjdk.java.net/~gziemski/8069540_jdk_rev2/ Webrev: http://cr.openjdk.java.net/~gziemski/8069540_hotspot_rev2/ Testing: JPRT + RBT on all platforms. cheers From coleen.phillimore at oracle.com Fri Jan 29 16:58:43 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 29 Jan 2016 11:58:43 -0500 Subject: RFR 8146984: SIGBUS: bool Method::has_method_vptr(const void*)+0xc In-Reply-To: <56AB8D2E.7090902@oracle.com> References: <56AB5F39.1060005@oracle.com> <56AB8D2E.7090902@oracle.com> Message-ID: <56AB9A43.1000905@oracle.com> On 1/29/16 11:02 AM, Daniel D. Daugherty wrote: > On 1/29/16 5:46 AM, Coleen Phillimore wrote: >> Summary: Add address check and use SafeFetchN for Method* vptr access >> when Method* may be bad pointer. >> >> Tested with RBT and failing test case (reproduced 1 in 100 times) >> with fatal in the 'return's in the change to verify. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8146984/ > > This one caught my eye because it has to do with sampling... I should mention sampling in all my RFRs then! > > src/share/vm/oops/method.cpp > The old code checked "!is_metaspace_object()" and used > has_method_vptr((const void*)this). > > The new code skips the "!is_metaspace_object()" check even after > sanity > checking the pointer, but you don't really explain why that's OK. is_metaspace_object is a very expensive check. It has to traverse all the metaspace mmap chunks. The new code is more robust in that it sanity checks the pointer first but uses Safefetch to get the vptr. > > The new code also picks up parts of Method::has_method_vptr() which > makes me wonder if that's the right place for the fix. Won't other > callers to Method::has_method_vptr() be subject to the same crashing > mode? Or was the crashing mode only due to the > "!is_metaspace_object()" > check... I should have moved the SafeFetch in to the has_method_vptr. I can't remember why I copied it now. It crashed because the pointer was in metaspace (is_metaspace_object returned true) but wasn't aligned, but the pointer could come from anywhere. Thanks, I'll test out this fix and resend it. Coleen > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8146984 >> >> Thanks, >> Coleen >> > From erik.joelsson at oracle.com Fri Jan 29 17:04:24 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Jan 2016 18:04:24 +0100 Subject: RFR(M) 8069540: Remove universal binaries support from hotspot build In-Reply-To: References: Message-ID: <56AB9B98.9000403@oracle.com> (adding build-dev) Looks good enough to me. /Erik On 2016-01-29 17:51, Gerard Ziemski wrote: > Hi all (and especially the makefiles experts), > > This fix removes support for building hotspot universal libraries on Mac OS X and simplifies the makefiles. > > We are still building Mac OS X hotspot libraries as universal libraries, but with only one architecture (x86_64). The rest of JDK is built as plain single architecture libraries and there is no longer any need for this complexity (since we haven't supported 32bit platform on Mac OS X for a while now) > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8069540 > Webrev: http://cr.openjdk.java.net/~gziemski/8069540_jdk_rev2/ > Webrev: http://cr.openjdk.java.net/~gziemski/8069540_hotspot_rev2/ > > Testing: JPRT + RBT on all platforms. > > > cheers From chris.plummer at oracle.com Fri Jan 29 18:52:54 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 29 Jan 2016 10:52:54 -0800 Subject: RFR(M) 8148481: Devirtualize Klass::vtable In-Reply-To: <56AA3E25.60409@oracle.com> References: <56AA3E25.60409@oracle.com> Message-ID: <56ABB506.1050401@oracle.com> On 1/28/16 8:13 AM, Mikael Gerdin wrote: > Hi all, > > Due to my recent changes in this area, Klass is now responsible for > maintaining the offsets and length of the embedded vtable and > therefore it makes sense to move all code related to the Java vtables > to Klass. > > This also allows us to remove a few unsafe casts where an ArrayKlass > was cast to an InstanceKlass just to get at the methods_at_vtable(). > These casts were removed from reflection.cpp, jni.cpp, > jvmciCompilerToVM.cpp and linkResolver.cpp, in cpCache.cpp there was > an alternate approach to the same problem which I've rewritten to use > the new way of accessing the vtable directly through Klass. > > Some notes: > * I took the liberty of changing the return type of start_of_vtable() > to vtableEntry* since that is in fact what it is. > * method_at_vtable is no longer inline, but I don't think that should > be a performance problem since it's usually only being called from > link resolving, cpCache or JNI calls, all of which are not > particularly hot paths. > > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8148481 > Webrev: http://cr.openjdk.java.net/~mgerdin/8148481/webrev.0 > > Testing: JPRT + RBT on Oracle platforms. > > /Mikael Looks good. Chris From chris.plummer at oracle.com Fri Jan 29 19:15:11 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 29 Jan 2016 11:15:11 -0800 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56AADD07.4080604@oracle.com> References: <56A90C0B.2050100@oracle.com> <56AA8726.7030807@oracle.com> <56AA8AF7.8020606@oracle.com> <56AA8DB4.4050609@oracle.com> <56AADD07.4080604@oracle.com> Message-ID: <56ABBA3F.3030400@oracle.com> Hi Coleen, On 1/28/16 7:31 PM, Coleen Phillimore wrote: > > Hi Chris, > > I made a few extra changes because of your question that I didn't > answer below, a few HeapWordSize became wordSize. I apologize that I > don't know how to create incremental webrevs. See discussion below. > > open webrev at http://cr.openjdk.java.net/~coleenp/8145628.02/ > > On 1/28/16 4:52 PM, Chris Plummer wrote: >> On 1/28/16 1:41 PM, Coleen Phillimore wrote: >>> >>> Thank you, Chris for looking at this change. >>> >>> On 1/28/16 4:24 PM, Chris Plummer wrote: >>>> Hi Coleen, >>>> >>>> Can you do some testing with ObjectAlignmentInBytes set to >>>> something other than 8? >>> >>> Okay, I can run one of the testsets with that. I verified it in the >>> debugger mostly. >>>> >>>> Someone from GC team should apply your patch, grep for >>>> align_object_size(), and confirm that the ones you didn't change >>>> are correct. I gave a quick look and they look right to me, but I >>>> wasn't always certain if object alignment was appropriate in all >>>> cases. >>> >>> thanks - this is why I'd changed the align_object_size to >>> align_heap_object_size before testing and changed it back, to verify >>> that I didn't miss any. >>>> >>>> I see some remaining HeapWordSize references that are suspect, like >>>> in Array.java and bytecodeTracer.cpp. I didn't go through all of >>>> them since there are about 428. Do they need closer inspection? >> ??? Any comment? > > Actually, I tried to get a lot of HeapWordSize in the metadata but the > primary focus of the change, despite the title, was to fix > align_object_size wasn't used on metadata. ok. > That said a quick look at the instances of HeapWordSize led to some > that weren't in the heap. I didn't look in Array.java because it's in > the SA which isn't maintainable anyway, but I changed a few. There > were very few that were not referring to objects in the Java heap. > bytecodeTracer was one and there were a couple in metaspace.cpp. Ok. If you think there may be more, or a more thorough analysis is needed, perhaps just file a bug to get the rest later. As for reviewing your incremental changes, as long as it was just more changes of HeapWordSize to wordSize, I'm sure they are fine. (And yes, I did see that the removal of Symbol size alignment was also added). > > The bad news is that's more code to review. See above webrev link. > >>>> >>>> align_metadata_offset() is not used. It can be removed. >>> >>> Okay, I'll remove it. That's a good idea. >>> >>>> >>>> Shouldn't align_metadata_size() align to 64-bit like >>>> align_object_size() did, and not align to word size? Isn't that >>>> what we agreed to? Have you tested CDS? David had concerns about >>>> the InstanceKlass::size() not returning the same aligned size as >>>> Metachunk::object_alignment(). >>> >>> I ran the CDS tests but I could test some more with CDS. We don't >>> want to force the size of objects to be 64 bit (especially Symbol) >>> because Metachunk::object_alignment() is 64 bits. >> Do you mean "just" because? I wasn't necessarily suggesting that all >> metadata be 64-bit aligned. However, the ones that have their >> allocation size 64-bit aligned should be. I think David's concern is >> that he wrote code that computes how much memory is needed for the >> archive, and it uses size() for that. If the Metachunk allocator >> allocates more than size() due to the 64-bit alignment of >> Metachunk::object_alignment(), then he will underestimate the size. >> You'll need to double check with David to see if I got this right. > > I don't know what code this is but yes, it would be wrong. It also > would be wrong if there's any other alignment gaps or space in > metaspace chunks because chunks themselves have an allocation > granularity. > > It could be changed back by changing the function align_metaspace_size > from 1 to WordsPerLong if you wanted to. > > I fixed Symbol so that it didn't call align_metaspace_size if this > change is needed in the future. > > I was trying to limit the size of this change to correct > align_object_size for metadata. Well, there a few issues being addressed by fixing align_object_size. Using align_object_size was incorrect from a code purity standpoint (it was used on values unrelated to java objects), and was also incorrect when ObjectAlignmentInBytes was not 8. This was the main motivation for making this change. The 3rd issue is that align_object_size by default was doing 8 byte alignment, and this wastes memory on 32-bit. However, as I mentioned there may be some dependencies on this 8 byte alignment due to the metaspace allocator doing 8 byte alignment. If you can get David to say he's ok with just 4-byte size alignment on 32-bit, then I'm ok with this change. Otherwise I think maybe you should stay with 8 byte alignment (including symbols), and file a bug to someday change it to word alignment, and have the metaspace allocator require that you pass in alignment requirements. > > Thanks for looking at this in detail. No problem. Thanks for cleaning this up. Chris > > Coleen > > >>> Unfortunately, with the latter, metadata is never aligned on 32 bit >>> boundaries for 32 bit platforms, but to fix this, we have to pass a >>> minimum_alignment parameter to Metaspace::allocate() because the >>> alignment is not a function of the size of the object but what is >>> required from its nonstatic data members. >> Correct. >>> I found MethodCounters, Klass (and subclasses) and ConstantPool >>> has such alignment constraints. Not sizing metadata to 64 bit sizes >>> is a start for making this change. >> I agree with that, but just wanted to point out why David may be >> concerned with this change. >>>> >>>> instanceKlass.hpp: Need to fix the following comment: >>>> >>>> 97 // sizeof(OopMapBlock) in HeapWords. >>> Fixed, Thanks! >> thanks, >> >> Chris >>> >>> Coleen >>> >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>>> On 1/27/16 10:27 AM, Coleen Phillimore wrote: >>>>> Summary: Use align_metadata_size, align_metadata_offset and >>>>> is_metadata_aligned for metadata rather >>>>> than align_object_size, etc. Use wordSize rather than >>>>> HeapWordSize for metadata. Use align_ptr_up >>>>> rather than align_pointer_up (all the related functions are ptr). >>>>> >>>>> Ran RBT quick tests on all platforms along with Chris's Plummers >>>>> change for 8143608, ran jtreg hotspot tests and nsk.sajdi.testlist >>>>> co-located tests because there are SA changes. Reran subset of >>>>> this after merging. >>>>> >>>>> I have a script to update copyrights on commit. It's not a big >>>>> change, just mostly boring. See the bug comments for more details >>>>> about the change. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Fri Jan 29 19:20:58 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 29 Jan 2016 14:20:58 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56ABBA3F.3030400@oracle.com> References: <56A90C0B.2050100@oracle.com> <56AA8726.7030807@oracle.com> <56AA8AF7.8020606@oracle.com> <56AA8DB4.4050609@oracle.com> <56AADD07.4080604@oracle.com> <56ABBA3F.3030400@oracle.com> Message-ID: <56ABBB9A.50504@oracle.com> Thanks Chris, On 1/29/16 2:15 PM, Chris Plummer wrote: > Hi Coleen, > > On 1/28/16 7:31 PM, Coleen Phillimore wrote: >> >> Hi Chris, >> >> I made a few extra changes because of your question that I didn't >> answer below, a few HeapWordSize became wordSize. I apologize that I >> don't know how to create incremental webrevs. See discussion below. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.02/ >> >> On 1/28/16 4:52 PM, Chris Plummer wrote: >>> On 1/28/16 1:41 PM, Coleen Phillimore wrote: >>>> >>>> Thank you, Chris for looking at this change. >>>> >>>> On 1/28/16 4:24 PM, Chris Plummer wrote: >>>>> Hi Coleen, >>>>> >>>>> Can you do some testing with ObjectAlignmentInBytes set to >>>>> something other than 8? >>>> >>>> Okay, I can run one of the testsets with that. I verified it in >>>> the debugger mostly. >>>>> >>>>> Someone from GC team should apply your patch, grep for >>>>> align_object_size(), and confirm that the ones you didn't change >>>>> are correct. I gave a quick look and they look right to me, but I >>>>> wasn't always certain if object alignment was appropriate in all >>>>> cases. >>>> >>>> thanks - this is why I'd changed the align_object_size to >>>> align_heap_object_size before testing and changed it back, to >>>> verify that I didn't miss any. >>>>> >>>>> I see some remaining HeapWordSize references that are suspect, >>>>> like in Array.java and bytecodeTracer.cpp. I didn't go through all >>>>> of them since there are about 428. Do they need closer inspection? >>> ??? Any comment? >> >> Actually, I tried to get a lot of HeapWordSize in the metadata but >> the primary focus of the change, despite the title, was to fix >> align_object_size wasn't used on metadata. > ok. >> That said a quick look at the instances of HeapWordSize led to some >> that weren't in the heap. I didn't look in Array.java because it's >> in the SA which isn't maintainable anyway, but I changed a few. >> There were very few that were not referring to objects in the Java >> heap. bytecodeTracer was one and there were a couple in metaspace.cpp. > Ok. If you think there may be more, or a more thorough analysis is > needed, perhaps just file a bug to get the rest later. From my look yesterday, there aren't a lot of HeapWordSize left. There are probably still a lot of HeapWord* casts for things that aren't in the Java heap. This is a bigger cleanup that might not make sense to do in one change, but maybe in incremental changes to related code. > > As for reviewing your incremental changes, as long as it was just more > changes of HeapWordSize to wordSize, I'm sure they are fine. (And yes, > I did see that the removal of Symbol size alignment was also added). Good, thanks. >> >> The bad news is that's more code to review. See above webrev link. >> >>>>> >>>>> align_metadata_offset() is not used. It can be removed. >>>> >>>> Okay, I'll remove it. That's a good idea. >>>> >>>>> >>>>> Shouldn't align_metadata_size() align to 64-bit like >>>>> align_object_size() did, and not align to word size? Isn't that >>>>> what we agreed to? Have you tested CDS? David had concerns about >>>>> the InstanceKlass::size() not returning the same aligned size as >>>>> Metachunk::object_alignment(). >>>> >>>> I ran the CDS tests but I could test some more with CDS. We don't >>>> want to force the size of objects to be 64 bit (especially Symbol) >>>> because Metachunk::object_alignment() is 64 bits. >>> Do you mean "just" because? I wasn't necessarily suggesting that all >>> metadata be 64-bit aligned. However, the ones that have their >>> allocation size 64-bit aligned should be. I think David's concern is >>> that he wrote code that computes how much memory is needed for the >>> archive, and it uses size() for that. If the Metachunk allocator >>> allocates more than size() due to the 64-bit alignment of >>> Metachunk::object_alignment(), then he will underestimate the size. >>> You'll need to double check with David to see if I got this right. >> >> I don't know what code this is but yes, it would be wrong. It also >> would be wrong if there's any other alignment gaps or space in >> metaspace chunks because chunks themselves have an allocation >> granularity. >> >> It could be changed back by changing the function >> align_metaspace_size from 1 to WordsPerLong if you wanted to. >> >> I fixed Symbol so that it didn't call align_metaspace_size if this >> change is needed in the future. >> >> I was trying to limit the size of this change to correct >> align_object_size for metadata. > Well, there a few issues being addressed by fixing align_object_size. > Using align_object_size was incorrect from a code purity standpoint > (it was used on values unrelated to java objects), and was also > incorrect when ObjectAlignmentInBytes was not 8. This was the main > motivation for making this change. Exactly. This was higher priority because it was wrong. > > The 3rd issue is that align_object_size by default was doing 8 byte > alignment, and this wastes memory on 32-bit. However, as I mentioned > there may be some dependencies on this 8 byte alignment due to the > metaspace allocator doing 8 byte alignment. If you can get David to > say he's ok with just 4-byte size alignment on 32-bit, then I'm ok > with this change. Otherwise I think maybe you should stay with 8 byte > alignment (including symbols), and file a bug to someday change it to > word alignment, and have the metaspace allocator require that you pass > in alignment requirements. Okay, I can see what David says but I wouldn't change Symbol back. That's mostly unrelated to metadata storage and I can get 32 bit packing for symbols on 32 bit platforms. It probably saves more space than the other more invasive ideas that we've had. Thanks, Coleen >> >> Thanks for looking at this in detail. > No problem. Thanks for cleaning this up. > > Chris >> >> Coleen >> >> >>>> Unfortunately, with the latter, metadata is never aligned on 32 bit >>>> boundaries for 32 bit platforms, but to fix this, we have to pass a >>>> minimum_alignment parameter to Metaspace::allocate() because the >>>> alignment is not a function of the size of the object but what is >>>> required from its nonstatic data members. >>> Correct. >>>> I found MethodCounters, Klass (and subclasses) and ConstantPool >>>> has such alignment constraints. Not sizing metadata to 64 bit sizes >>>> is a start for making this change. >>> I agree with that, but just wanted to point out why David may be >>> concerned with this change. >>>>> >>>>> instanceKlass.hpp: Need to fix the following comment: >>>>> >>>>> 97 // sizeof(OopMapBlock) in HeapWords. >>>> Fixed, Thanks! >>> thanks, >>> >>> Chris >>>> >>>> Coleen >>>> >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> >>>>> On 1/27/16 10:27 AM, Coleen Phillimore wrote: >>>>>> Summary: Use align_metadata_size, align_metadata_offset and >>>>>> is_metadata_aligned for metadata rather >>>>>> than align_object_size, etc. Use wordSize rather than >>>>>> HeapWordSize for metadata. Use align_ptr_up >>>>>> rather than align_pointer_up (all the related functions are ptr). >>>>>> >>>>>> Ran RBT quick tests on all platforms along with Chris's Plummers >>>>>> change for 8143608, ran jtreg hotspot tests and >>>>>> nsk.sajdi.testlist co-located tests because there are SA >>>>>> changes. Reran subset of this after merging. >>>>>> >>>>>> I have a script to update copyrights on commit. It's not a big >>>>>> change, just mostly boring. See the bug comments for more >>>>>> details about the change. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Sat Jan 30 14:27:54 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sat, 30 Jan 2016 09:27:54 -0500 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56ABBB9A.50504@oracle.com> References: <56A90C0B.2050100@oracle.com> <56AA8726.7030807@oracle.com> <56AA8AF7.8020606@oracle.com> <56AA8DB4.4050609@oracle.com> <56AADD07.4080604@oracle.com> <56ABBA3F.3030400@oracle.com> <56ABBB9A.50504@oracle.com> Message-ID: <56ACC86A.8080102@oracle.com> On 1/29/16 2:20 PM, Coleen Phillimore wrote: > > Thanks Chris, > > On 1/29/16 2:15 PM, Chris Plummer wrote: >> Hi Coleen, >> >> On 1/28/16 7:31 PM, Coleen Phillimore wrote: >>> >>> Hi Chris, >>> >>> I made a few extra changes because of your question that I didn't >>> answer below, a few HeapWordSize became wordSize. I apologize that >>> I don't know how to create incremental webrevs. See discussion below. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.02/ >>> >>> On 1/28/16 4:52 PM, Chris Plummer wrote: >>>> On 1/28/16 1:41 PM, Coleen Phillimore wrote: >>>>> >>>>> Thank you, Chris for looking at this change. >>>>> >>>>> On 1/28/16 4:24 PM, Chris Plummer wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> Can you do some testing with ObjectAlignmentInBytes set to >>>>>> something other than 8? >>>>> >>>>> Okay, I can run one of the testsets with that. I verified it in >>>>> the debugger mostly. >>>>>> >>>>>> Someone from GC team should apply your patch, grep for >>>>>> align_object_size(), and confirm that the ones you didn't change >>>>>> are correct. I gave a quick look and they look right to me, but I >>>>>> wasn't always certain if object alignment was appropriate in all >>>>>> cases. >>>>> >>>>> thanks - this is why I'd changed the align_object_size to >>>>> align_heap_object_size before testing and changed it back, to >>>>> verify that I didn't miss any. >>>>>> >>>>>> I see some remaining HeapWordSize references that are suspect, >>>>>> like in Array.java and bytecodeTracer.cpp. I didn't go through >>>>>> all of them since there are about 428. Do they need closer >>>>>> inspection? >>>> ??? Any comment? >>> >>> Actually, I tried to get a lot of HeapWordSize in the metadata but >>> the primary focus of the change, despite the title, was to fix >>> align_object_size wasn't used on metadata. >> ok. >>> That said a quick look at the instances of HeapWordSize led to some >>> that weren't in the heap. I didn't look in Array.java because it's >>> in the SA which isn't maintainable anyway, but I changed a few. >>> There were very few that were not referring to objects in the Java >>> heap. bytecodeTracer was one and there were a couple in metaspace.cpp. >> Ok. If you think there may be more, or a more thorough analysis is >> needed, perhaps just file a bug to get the rest later. > > From my look yesterday, there aren't a lot of HeapWordSize left. There > are probably still a lot of HeapWord* casts for things that aren't in > the Java heap. This is a bigger cleanup that might not make sense to > do in one change, but maybe in incremental changes to related code. > >> >> As for reviewing your incremental changes, as long as it was just >> more changes of HeapWordSize to wordSize, I'm sure they are fine. >> (And yes, I did see that the removal of Symbol size alignment was >> also added). > > Good, thanks. > >>> >>> The bad news is that's more code to review. See above webrev link. >>> >>>>>> >>>>>> align_metadata_offset() is not used. It can be removed. >>>>> >>>>> Okay, I'll remove it. That's a good idea. >>>>> >>>>>> >>>>>> Shouldn't align_metadata_size() align to 64-bit like >>>>>> align_object_size() did, and not align to word size? Isn't that >>>>>> what we agreed to? Have you tested CDS? David had concerns about >>>>>> the InstanceKlass::size() not returning the same aligned size as >>>>>> Metachunk::object_alignment(). >>>>> >>>>> I ran the CDS tests but I could test some more with CDS. We don't >>>>> want to force the size of objects to be 64 bit (especially Symbol) >>>>> because Metachunk::object_alignment() is 64 bits. >>>> Do you mean "just" because? I wasn't necessarily suggesting that >>>> all metadata be 64-bit aligned. However, the ones that have their >>>> allocation size 64-bit aligned should be. I think David's concern >>>> is that he wrote code that computes how much memory is needed for >>>> the archive, and it uses size() for that. If the Metachunk >>>> allocator allocates more than size() due to the 64-bit alignment of >>>> Metachunk::object_alignment(), then he will underestimate the size. >>>> You'll need to double check with David to see if I got this right. >>> >>> I don't know what code this is but yes, it would be wrong. It also >>> would be wrong if there's any other alignment gaps or space in >>> metaspace chunks because chunks themselves have an allocation >>> granularity. >>> >>> It could be changed back by changing the function >>> align_metaspace_size from 1 to WordsPerLong if you wanted to. >>> >>> I fixed Symbol so that it didn't call align_metaspace_size if this >>> change is needed in the future. >>> >>> I was trying to limit the size of this change to correct >>> align_object_size for metadata. >> Well, there a few issues being addressed by fixing align_object_size. >> Using align_object_size was incorrect from a code purity standpoint >> (it was used on values unrelated to java objects), and was also >> incorrect when ObjectAlignmentInBytes was not 8. This was the main >> motivation for making this change. > > Exactly. This was higher priority because it was wrong. >> >> The 3rd issue is that align_object_size by default was doing 8 byte >> alignment, and this wastes memory on 32-bit. However, as I mentioned >> there may be some dependencies on this 8 byte alignment due to the >> metaspace allocator doing 8 byte alignment. If you can get David to >> say he's ok with just 4-byte size alignment on 32-bit, then I'm ok >> with this change. Otherwise I think maybe you should stay with 8 byte >> alignment (including symbols), and file a bug to someday change it to >> word alignment, and have the metaspace allocator require that you >> pass in alignment requirements. > > Okay, I can see what David says but I wouldn't change Symbol back. > That's mostly unrelated to metadata storage and I can get 32 bit > packing for symbols on 32 bit platforms. It probably saves more space > than the other more invasive ideas that we've had. This is reviewed now. If David wants metadata sizing to change back to 64 bits on 32 bit platforms, it's a one line change. I'm going to push it to get the rest in. Thanks, Coleen > > Thanks, > Coleen > >>> >>> Thanks for looking at this in detail. >> No problem. Thanks for cleaning this up. >> >> Chris >>> >>> Coleen >>> >>> >>>>> Unfortunately, with the latter, metadata is never aligned on 32 >>>>> bit boundaries for 32 bit platforms, but to fix this, we have to >>>>> pass a minimum_alignment parameter to Metaspace::allocate() >>>>> because the alignment is not a function of the size of the object >>>>> but what is required from its nonstatic data members. >>>> Correct. >>>>> I found MethodCounters, Klass (and subclasses) and ConstantPool >>>>> has such alignment constraints. Not sizing metadata to 64 bit >>>>> sizes is a start for making this change. >>>> I agree with that, but just wanted to point out why David may be >>>> concerned with this change. >>>>>> >>>>>> instanceKlass.hpp: Need to fix the following comment: >>>>>> >>>>>> 97 // sizeof(OopMapBlock) in HeapWords. >>>>> Fixed, Thanks! >>>> thanks, >>>> >>>> Chris >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On 1/27/16 10:27 AM, Coleen Phillimore wrote: >>>>>>> Summary: Use align_metadata_size, align_metadata_offset and >>>>>>> is_metadata_aligned for metadata rather >>>>>>> than align_object_size, etc. Use wordSize rather than >>>>>>> HeapWordSize for metadata. Use align_ptr_up >>>>>>> rather than align_pointer_up (all the related functions are ptr). >>>>>>> >>>>>>> Ran RBT quick tests on all platforms along with Chris's Plummers >>>>>>> change for 8143608, ran jtreg hotspot tests and >>>>>>> nsk.sajdi.testlist co-located tests because there are SA >>>>>>> changes. Reran subset of this after merging. >>>>>>> >>>>>>> I have a script to update copyrights on commit. It's not a big >>>>>>> change, just mostly boring. See the bug comments for more >>>>>>> details about the change. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Sat Jan 30 14:39:02 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sat, 30 Jan 2016 09:39:02 -0500 Subject: RFR 8146984: SIGBUS: bool Method::has_method_vptr(const void*)+0xc In-Reply-To: <56AB9A43.1000905@oracle.com> References: <56AB5F39.1060005@oracle.com> <56AB8D2E.7090902@oracle.com> <56AB9A43.1000905@oracle.com> Message-ID: <56ACCB06.7060900@oracle.com> I've moved the SafeFetch to has_method_vptr as suggested and retested. http://cr.openjdk.java.net/~coleenp/8146984.02/webrev/ Thanks, Coleen On 1/29/16 11:58 AM, Coleen Phillimore wrote: > > > On 1/29/16 11:02 AM, Daniel D. Daugherty wrote: >> On 1/29/16 5:46 AM, Coleen Phillimore wrote: >>> Summary: Add address check and use SafeFetchN for Method* vptr >>> access when Method* may be bad pointer. >>> >>> Tested with RBT and failing test case (reproduced 1 in 100 times) >>> with fatal in the 'return's in the change to verify. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8146984/ >> >> This one caught my eye because it has to do with sampling... > > I should mention sampling in all my RFRs then! >> >> src/share/vm/oops/method.cpp >> The old code checked "!is_metaspace_object()" and used >> has_method_vptr((const void*)this). >> >> The new code skips the "!is_metaspace_object()" check even after >> sanity >> checking the pointer, but you don't really explain why that's OK. > > is_metaspace_object is a very expensive check. It has to traverse > all the metaspace mmap chunks. The new code is more robust in that > it sanity checks the pointer first but uses Safefetch to get the vptr. > > >> >> The new code also picks up parts of Method::has_method_vptr() which >> makes me wonder if that's the right place for the fix. Won't other >> callers to Method::has_method_vptr() be subject to the same crashing >> mode? Or was the crashing mode only due to the >> "!is_metaspace_object()" >> check... > > I should have moved the SafeFetch in to the has_method_vptr. I can't > remember why I copied it now. It crashed because the pointer was in > metaspace (is_metaspace_object returned true) but wasn't aligned, but > the pointer could come from anywhere. > > Thanks, I'll test out this fix and resend it. > Coleen > >> >> Dan >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8146984 >>> >>> Thanks, >>> Coleen >>> >> > From chris.plummer at oracle.com Sun Jan 31 20:40:44 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 31 Jan 2016 12:40:44 -0800 Subject: RFR 8145628: hotspot metadata classes shouldn't use HeapWordSize or heap related macros like align_object_size In-Reply-To: <56ACC86A.8080102@oracle.com> References: <56A90C0B.2050100@oracle.com> <56AA8726.7030807@oracle.com> <56AA8AF7.8020606@oracle.com> <56AA8DB4.4050609@oracle.com> <56AADD07.4080604@oracle.com> <56ABBA3F.3030400@oracle.com> <56ABBB9A.50504@oracle.com> <56ACC86A.8080102@oracle.com> Message-ID: <56AE714C.1050409@oracle.com> On 1/30/16 6:27 AM, Coleen Phillimore wrote: > > > On 1/29/16 2:20 PM, Coleen Phillimore wrote: >> >> Thanks Chris, >> >> On 1/29/16 2:15 PM, Chris Plummer wrote: >>> Hi Coleen, >>> >>> On 1/28/16 7:31 PM, Coleen Phillimore wrote: >>>> >>>> Hi Chris, >>>> >>>> I made a few extra changes because of your question that I didn't >>>> answer below, a few HeapWordSize became wordSize. I apologize that >>>> I don't know how to create incremental webrevs. See discussion below. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.02/ >>>> >>>> On 1/28/16 4:52 PM, Chris Plummer wrote: >>>>> On 1/28/16 1:41 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Thank you, Chris for looking at this change. >>>>>> >>>>>> On 1/28/16 4:24 PM, Chris Plummer wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> Can you do some testing with ObjectAlignmentInBytes set to >>>>>>> something other than 8? >>>>>> >>>>>> Okay, I can run one of the testsets with that. I verified it in >>>>>> the debugger mostly. >>>>>>> >>>>>>> Someone from GC team should apply your patch, grep for >>>>>>> align_object_size(), and confirm that the ones you didn't change >>>>>>> are correct. I gave a quick look and they look right to me, but >>>>>>> I wasn't always certain if object alignment was appropriate in >>>>>>> all cases. >>>>>> >>>>>> thanks - this is why I'd changed the align_object_size to >>>>>> align_heap_object_size before testing and changed it back, to >>>>>> verify that I didn't miss any. >>>>>>> >>>>>>> I see some remaining HeapWordSize references that are suspect, >>>>>>> like in Array.java and bytecodeTracer.cpp. I didn't go through >>>>>>> all of them since there are about 428. Do they need closer >>>>>>> inspection? >>>>> ??? Any comment? >>>> >>>> Actually, I tried to get a lot of HeapWordSize in the metadata but >>>> the primary focus of the change, despite the title, was to fix >>>> align_object_size wasn't used on metadata. >>> ok. >>>> That said a quick look at the instances of HeapWordSize led to some >>>> that weren't in the heap. I didn't look in Array.java because it's >>>> in the SA which isn't maintainable anyway, but I changed a few. >>>> There were very few that were not referring to objects in the Java >>>> heap. bytecodeTracer was one and there were a couple in metaspace.cpp. >>> Ok. If you think there may be more, or a more thorough analysis is >>> needed, perhaps just file a bug to get the rest later. >> >> From my look yesterday, there aren't a lot of HeapWordSize left. >> There are probably still a lot of HeapWord* casts for things that >> aren't in the Java heap. This is a bigger cleanup that might not >> make sense to do in one change, but maybe in incremental changes to >> related code. >> >>> >>> As for reviewing your incremental changes, as long as it was just >>> more changes of HeapWordSize to wordSize, I'm sure they are fine. >>> (And yes, I did see that the removal of Symbol size alignment was >>> also added). >> >> Good, thanks. >> >>>> >>>> The bad news is that's more code to review. See above webrev link. >>>> >>>>>>> >>>>>>> align_metadata_offset() is not used. It can be removed. >>>>>> >>>>>> Okay, I'll remove it. That's a good idea. >>>>>> >>>>>>> >>>>>>> Shouldn't align_metadata_size() align to 64-bit like >>>>>>> align_object_size() did, and not align to word size? Isn't that >>>>>>> what we agreed to? Have you tested CDS? David had concerns about >>>>>>> the InstanceKlass::size() not returning the same aligned size as >>>>>>> Metachunk::object_alignment(). >>>>>> >>>>>> I ran the CDS tests but I could test some more with CDS. We don't >>>>>> want to force the size of objects to be 64 bit (especially >>>>>> Symbol) because Metachunk::object_alignment() is 64 bits. >>>>> Do you mean "just" because? I wasn't necessarily suggesting that >>>>> all metadata be 64-bit aligned. However, the ones that have their >>>>> allocation size 64-bit aligned should be. I think David's concern >>>>> is that he wrote code that computes how much memory is needed for >>>>> the archive, and it uses size() for that. If the Metachunk >>>>> allocator allocates more than size() due to the 64-bit alignment >>>>> of Metachunk::object_alignment(), then he will underestimate the >>>>> size. You'll need to double check with David to see if I got this >>>>> right. >>>> >>>> I don't know what code this is but yes, it would be wrong. It also >>>> would be wrong if there's any other alignment gaps or space in >>>> metaspace chunks because chunks themselves have an allocation >>>> granularity. >>>> >>>> It could be changed back by changing the function >>>> align_metaspace_size from 1 to WordsPerLong if you wanted to. >>>> >>>> I fixed Symbol so that it didn't call align_metaspace_size if this >>>> change is needed in the future. >>>> >>>> I was trying to limit the size of this change to correct >>>> align_object_size for metadata. >>> Well, there a few issues being addressed by fixing >>> align_object_size. Using align_object_size was incorrect from a code >>> purity standpoint (it was used on values unrelated to java objects), >>> and was also incorrect when ObjectAlignmentInBytes was not 8. This >>> was the main motivation for making this change. >> >> Exactly. This was higher priority because it was wrong. >>> >>> The 3rd issue is that align_object_size by default was doing 8 byte >>> alignment, and this wastes memory on 32-bit. However, as I mentioned >>> there may be some dependencies on this 8 byte alignment due to the >>> metaspace allocator doing 8 byte alignment. If you can get David to >>> say he's ok with just 4-byte size alignment on 32-bit, then I'm ok >>> with this change. Otherwise I think maybe you should stay with 8 >>> byte alignment (including symbols), and file a bug to someday change >>> it to word alignment, and have the metaspace allocator require that >>> you pass in alignment requirements. >> >> Okay, I can see what David says but I wouldn't change Symbol back. >> That's mostly unrelated to metadata storage and I can get 32 bit >> packing for symbols on 32 bit platforms. It probably saves more >> space than the other more invasive ideas that we've had. > > This is reviewed now. If David wants metadata sizing to change back > to 64 bits on 32 bit platforms, it's a one line change. I'm going to > push it to get the rest in. > Thanks, > Coleen Ok. Chris >> >> Thanks, >> Coleen >> >>>> >>>> Thanks for looking at this in detail. >>> No problem. Thanks for cleaning this up. >>> >>> Chris >>>> >>>> Coleen >>>> >>>> >>>>>> Unfortunately, with the latter, metadata is never aligned on 32 >>>>>> bit boundaries for 32 bit platforms, but to fix this, we have to >>>>>> pass a minimum_alignment parameter to Metaspace::allocate() >>>>>> because the alignment is not a function of the size of the object >>>>>> but what is required from its nonstatic data members. >>>>> Correct. >>>>>> I found MethodCounters, Klass (and subclasses) and ConstantPool >>>>>> has such alignment constraints. Not sizing metadata to 64 bit >>>>>> sizes is a start for making this change. >>>>> I agree with that, but just wanted to point out why David may be >>>>> concerned with this change. >>>>>>> >>>>>>> instanceKlass.hpp: Need to fix the following comment: >>>>>>> >>>>>>> 97 // sizeof(OopMapBlock) in HeapWords. >>>>>> Fixed, Thanks! >>>>> thanks, >>>>> >>>>> Chris >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>>> On 1/27/16 10:27 AM, Coleen Phillimore wrote: >>>>>>>> Summary: Use align_metadata_size, align_metadata_offset and >>>>>>>> is_metadata_aligned for metadata rather >>>>>>>> than align_object_size, etc. Use wordSize rather than >>>>>>>> HeapWordSize for metadata. Use align_ptr_up >>>>>>>> rather than align_pointer_up (all the related functions are ptr). >>>>>>>> >>>>>>>> Ran RBT quick tests on all platforms along with Chris's >>>>>>>> Plummers change for 8143608, ran jtreg hotspot tests and >>>>>>>> nsk.sajdi.testlist co-located tests because there are SA >>>>>>>> changes. Reran subset of this after merging. >>>>>>>> >>>>>>>> I have a script to update copyrights on commit. It's not a big >>>>>>>> change, just mostly boring. See the bug comments for more >>>>>>>> details about the change. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8145628.01/ >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8145628 >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >