From sundararajan.athijegannathan at oracle.com Mon Oct 1 03:02:21 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 01 Oct 2018 08:32:21 +0530 Subject: [foreign] RFR 8211275: Binder should check that signature of bound function is compatible with layout descriptions In-Reply-To: <12b07045-bb4e-c45e-0cd5-199c004177f1@oracle.com> References: <12b07045-bb4e-c45e-0cd5-199c004177f1@oracle.com> Message-ID: <5BB18E3D.6080301@oracle.com> Looks good. -Sundar On 28/09/18, 6:10 PM, Maurizio Cimadamore wrote: > Hi, > this is a RFR for the changes discussed in [1] (thanks Jorn!). I've > added few things: > > * ensure that callbacks are checked too > > * refactored the isCompatible method to be more usable from clients > (e.g. reuse logic that throws assertions) > > * added one more testcase to check a simple case of callback mismatch, > just to make sure the logic is executed > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8211275/ > > Cheers > Maurizio > > [1] - > http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002786.html > > From sundararajan.athijegannathan at oracle.com Mon Oct 1 03:06:21 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 01 Oct 2018 08:36:21 +0530 Subject: [foreign] RFR 8211277: Exception when dereferencing null pointer should be more specific In-Reply-To: <3d502c5f-a56b-c856-1b15-a62ab4e8a760@oracle.com> References: <3d502c5f-a56b-c856-1b15-a62ab4e8a760@oracle.com> Message-ID: <5BB18F2D.3000203@oracle.com> Looks good. PS. While I'm fine with the Windows portability EXPORT macro in C code, none of the other existing tests use this. Perhaps we need similar such portability macro elsewhere? Not suggesting for current changeset though. -Sundar On 28/09/18, 6:35 PM, Maurizio Cimadamore wrote: > Hi, > this is a RFR for the changes discussed in [1] (again, thanks Jorn!). > Some minor tweaks: > > * consolidate the code paths for 'throwy' References - new > Reference.OfGrumpy :-) > > * tweaked test to check the exception cause - as otherwise the test > passes even w/o the fix > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8211277/ > > Cheers > Maurizio > > [1] - > http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002796.html > From sundararajan.athijegannathan at oracle.com Mon Oct 1 03:34:10 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 01 Oct 2018 09:04:10 +0530 Subject: [foreign] RFR 8210757: Add binder support for direct native invocation strategy In-Reply-To: References: <3e40cafe-df17-2569-8886-1b2142eb416c@oracle.com> Message-ID: <5BB195B2.9090802@oracle.com> The java portions look good. Haven't reviewed hotspot portions. -Sundar On 28/09/18, 4:49 PM, Maurizio Cimadamore wrote: > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8210757_v2/ > > Maurizio > > > On 28/09/18 12:19, Maurizio Cimadamore wrote: >> This is an updated version of the direct invocation scheme support. >> Very close to the last one, but there are some minor >> refactorings/improvements: >> >> 1) Added a @Stable annotation in DirectNativeInvoker's MH field >> 2) box/unbox routine used by the UniversalXYZ strategies have been >> moved from NativeInvoker to UniversalNativeInvoker >> 3) I revamped the logic which detects whether fastpath is applicable >> - now we create the calling sequence first, and we use that to check >> whether we can fast path it. Some internal benchmark have shown that >> with a large number of symbols, we were doing a lot of work because >> we were trying the fastpath always and then, in case of exception >> fallback to slow path; in such cases we would create calling sequence >> twice. This new technique might also be more friendly w.r.t. Windows >> and other ABIs. >> >> I'd really like to move ahead with this (as this RFR has been out for >> quite a while now) - if there's no other comments I'll go ahead. >> >> Maurizio >> >> >> On 14/09/18 19:04, Maurizio Cimadamore wrote: >>> Hi, >>> as mentioned in [1], this patch adds binder support for the so >>> called 'direct' invocation scheme, which allows for greater native >>> invocation downcall/upcall performances by means of specialized >>> adapters. The core idea, also described in [1], is to define >>> adapters of the kind: >>> >>> invokeNative_V_DDDDD >>> invokeNative_V_JDDDD >>> invokeNative_V_JJDDD >>> invokeNative_V_JJJDD >>> invokeNative_V_JJJJD >>> invokeNative_V_JJJJJ >>> >>> Where long arguments come before double arguments (and do this for >>> each arity e.g. <=5). >>> >>> If all arguments are passed in register, then this reordering >>> doesn't affect behavior, and greatly limits the number of >>> permutations to be supported/generated. >>> >>> The downcall part (java to native) is relative straightforward: the >>> directNativeInvoker.cpp file defines a bunch of native entry points, >>> one per shape, which cast the input address to a function pointer of >>> the desired shape, and then call it: >>> >>> jlong NI_invokeNative_J_JD(JNIEnv *env, jobject _unused, jlong addr, >>> jlong arg0, jdouble arg1) { >>> return ((jlong (*)(jlong, jdouble))addr)(arg0, arg1); >>> } >>> >>> The upcall business is a little trickier: first, if we are only to >>> optimize upcalls where argument passing happens in registers, then >>> it's crucial to note that by the time we get into the assembly stub, >>> all the registers will have been populated by the native code to >>> contain the right arguments in the right places. So we can avoid all >>> the shuffling in the assembly adapter and simply jump onto a C >>> function that looks like this: >>> >>> long specialized_upcall_helper_J(long l0, long l1, long l2, long l3, >>> double d0, double d1, double >>> d2, double d3, >>> unsigned int mask, jobject >>> rec) { ... } >>> >>> Note here that the first 8 arguments are just longs and doubles, and >>> those will be expected to be in registers, according to the System V >>> ABI. (In windows, the situation will be a bit different as less >>> integer registers are available, so this will need some work there). >>> >>> So, to recap, the assembly upcall stub simply 'append' the receiver >>> object and a 'signature mask' in the last two available C registers >>> and then jump onto the helper function. The helper function will >>> find all the desired arguments in the right places - there will be, >>> in the general case, some unused arguments, but that's fine, after >>> all it didn't cost anything to us to load them in the first place! >>> >>> Note that we have three helper variants, one for each return type { >>> long, double, void }. This is required as we need the C helper to >>> return a value of the right type which will generate the right >>> assembly sequence to store the result in the right register (either >>> integer or MMX). >>> >>> So, with three helpers we can support all the shapes with up to 8 >>> arguments. On the Java side we have, of course, to define a >>> specialized entry point for each shape. >>> >>> All the magic for adapting method handle to and from the specialized >>> adapters happen in the DirectSignatureShuffler class; this class is >>> responsible for adapting each argument e.g. from Java to native >>> value, and then reordering the adapted method handle to match the >>> order in which arguments are expected by the adapter (e.g. move all >>> longs in front). The challenge was in having DirectSignatureShuffle >>> to be fully symmetric - e.g. I did not want to have different code >>> paths for upcalls and downcalls, so the code tries quite hard to be >>> parametric in the shuffling direction (java->native or native->java) >>> - which means that adapters will be applied in one way or in the >>> inverse way depending on the shuffling direction (and as to whether >>> we are adapting an argument or a return). Since method handle >>> filters are composable, it all works out quite beautifully. >>> >>> Note that the resulting, adapted MH is stored in a @Stable field to >>> tell the JIT to optimize the heck out of it (as if it were a static >>> constant). >>> >>> This patch contains several other changes - which I discuss briefly >>> below: >>> >>> * we need to setup a framework in which new invocation strategies >>> can be plugged in - note that we now have essentially 4 cases: >>> >>> { NativeInvoker, UpcallHandler } x { Universal, Direct } >>> >>> When the code wants e.g. a NativeInvoker, it asks for one to the >>> NativeInvoker::of factory (UpcallHandler work in a similar way); >>> this factory will attempt to go down the fast path - if an error >>> occurs when computing the fast path, the call will fallback to the >>> universal (slow) path. >>> >>> Most of the changes you see in the Java code are associated to this >>> refactoring - e.g. all clients of NativeInvoker/UpcallHandler should >>> now go through the factory >>> >>> * CallbackImplGenerator had a major issue since the new factory for >>> NativeInvoker wants to bind an address eagerly (this is required >>> e.g. to be forward compatible with linkToNative backend); which >>> means that at construction time we have to get the address of the >>> callback, call the NativeInvoker factory and then stash the target >>> method handle into a field of the anon callback class. Vlad tells me >>> that fields of anon classes are always 'trusted' by the JIT, which >>> means they should be treated as '@Stable' (note that I can't put a >>> @Stable annotation there, since this code will be spinned in >>> user-land). >>> >>> * There are a bunch of properties that can be set to either force >>> slow path or force 'direct' path; in the latter case, if an error >>> occurs when instantiating the direct wrapper, an exception is >>> thrown. This mode is very useful for testing, and I indeed have >>> tried to run all our tests with this flag enabled, to see how many >>> places could not be optimized. >>> >>> * I've also reorganized all the native code in hotspot/prims so that >>> we have a separate file for each scheme (and so that native Java >>> methods could be added where they really belong). This should also >>> help in the long run as it should make adding/removing a given >>> scheme easier. >>> >>> * I've also added a small test which tries to pass structs of >>> different sizes, but I will also work on a more complex test which >>> will stress-test all invocation modes in a more complete fashion. >>> With respect to testing, I've also done a fastdebug build and ran >>> all tests with that (as fastdebug catches way many more hotspot >>> assertion than the product version); everything passed. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8210757/ >>> >>> I'd like to thank Vladimir Ivanov for the prompt support whenever I >>> got stuck down the macro assembler rabbit hole :-) >>> >>> Cheers >>> Maurizio >>> >>> [1] - >>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002652.html >>> >>> >>> >> > From samuel.audet at gmail.com Mon Oct 1 05:29:18 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Mon, 1 Oct 2018 14:29:18 +0900 Subject: on usability In-Reply-To: References: <138140e4ab654e59fa538b5438fdee9d@xs4all.nl> <71d58dfa-4bf2-382a-9449-e726f291b1e9@oracle.com> <3e25bf4a-1a75-357f-be72-fd36cbd3cf15@gmail.com> <1dde768f-2067-de80-2655-a881ae78c771@oracle.com> <39381ab4-f888-f7e9-3764-59b5dba1eca9@gmail.com> Message-ID: Hi, Jorn, Maurizio, I'm not talking about syntactic sugar, I'm fine with Java requiring getters/setters and having an init() call somewhere. What I'm not OK with is, just to call a native function, we have to call something like Libraries.bind() every single time with the name of the class and the path to the library, or save it somewhere in a field, and then what do we do with it? How do we manage it across classes and modules? Why can't the framework do that automatically for us? This is just one example of the usability problems that Panama isn't solving over JNI, that yes Swift or GraalVM is solving, not with wrappers, but at compile time as Maurizio points out. Panama could do the same with an init() function if it decided not to go with vanilla interfaces since the factory method pattern prevents this: You'll need wrappers. Another usability problem is code that is hard to read, like for the layouts, yes, which are neither easy to read nor write, I'm glad Maurizio agrees, but there are no proposal to fix this because we're committed to this approach as it's supposed to make things more general... but they still won't work for C++ templates or computational graphs! So, maybe everyone will want to use Truffle anyway? BTW, Swift does support offsetof(), here's the proposal status: https://github.com/apple/swift-evolution/blob/master/proposals/0210-key-path-offset.md "Status: Implemented (Swift 4.2)": Open source at work! BTW2, the example from GraalVM that I gave isn't from Truffle, it's from the "Substrate VM" codebase: It's completely unrelated. JNI is already very capable. As Maurizio points out in his reply, the whole point of Panama is not to improve the capabilities of JNI, it's to improve the *usability* and the *performance*, but after over 4 years of work, I still do not see how it will be able to fulfill either goals! Let's maybe work on "linkToNative" and get this shipped already to let others work on things like jextract? That might be worth it, but it's not happening. Priorities are elsewhere, although it's not clear to me where exactly. You see, in my opinion, the problem with Panama vs others like GraalVM, LLVM, or Swift is that the link with the community is missing. Decisions are made purely on an internal basis with no communication with the outside. If you Jorn like where Panama is going on a technical basis, that's great, but I'm not, and probably others are not either, but there is no forum to have a discussion about this. In any case, the Java community is a bit wider than OpenJDK, so maybe one day Truffle will get integrated into the JDK before Panama gets anywhere, or Substrate VM will "replace" HotSpot, since AOT is pretty much required for platforms like iOS, Google might become interested in using it for Android too, and everyone's already bundling the JRE with their desktop apps these days anyway. Samuel On 09/26/2018 06:39 PM, Jorn Vernee wrote: > The Swift example looks cool and I can say 2 things about that: > > 1.) Swift seems to have properties (i.e. syntactic sugar for getters and > setter), so It's much easier to inject some code that accesses an > underlying C struct instead of a backing field. I think at least for the > time being, the Java equivalent would be getters and setters. But tbh I > don't see that much usability problems with that, since it's more or > less the same amount of characters to write: `myStruct.x = 10` vs. > `myStruct.x$set(10)` (especially considering auto-completion). It just > doesn't look as fancy. > > 2.) I guess jextract could generate an equivalent of the 2 `Init()` > functions as well for generated structs, and that would be part of the > 'civilisation layer' Maurizio mentioned. With current tech, it would > probably either create and leak a scope internally, or you'd have to > pass a scope. Maybe a long term solution could be something like using a > default scope that is managed by the garbage collector. The generated > struct would not have a tight life-cycle (GC lazily collects objects), > but it would be easier to use. > > The Graal native access stuff uses truffle, i.e. it is baked into the > interpreter. But the truffle interpreter is built to be very > customizeable, so I think doing the same with the Hotspot interpreter > would be far more difficult. But either way, the way Graal maps a C > struct to an interface in that example looks pretty similar to what > panama is doing to me. > > I think panama is making sane choices, and focusing on capability before > usability. panama is just not as far along as the other projects you > mention, and I think more usability (jextract civilization layer) and > better performance (linkToNative backend) are yet to come. > > Jorn > > Samuel Audet schreef op 2018-09-26 03:14: >> We can do a lot of wrapper magic in either Java or C++. JavaCPP >> already does for JNI what Jorn is describing we could do for Panama: >> https://github.com/bytedeco/javacpp-presets/tree/master/systems#the-srcmainjavatestavxjava-source-file >> >> >> If we consider JNI to be "legacy", it makes a lot of sense to try and >> do some acrobatics like that to support legacy systems, but why not >> make the new hotness actually _usable_? Take a look at how Swift does >> it: >> https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift >> >> >> Now that's what I call *usable*. Panama is very far from that level of >> usability. And it's not because the Java language is somehow >> handicapped. Check what the guys over at GraalVM are doing: >> https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.tutorial/src/com/oracle/svm/tutorial/CInterfaceTutorial.java >> >> >> It also features performance that's already apparently higher than JNI: >> https://cornerwings.github.io/2018/07/graal-native-methods/ >> >> Why not do something user friendly like that in Panama's case as well? >> What's the rationale to make it all in the end as complicated to use >> as JNI? Maybe there's something I'm missing, so please point it out. >> >> Samuel >> >> >> On 09/24/2018 10:37 PM, Maurizio Cimadamore wrote: >>> Having a pre-extracted stdlib bundle is something we have considered >>> - quoting from [1]: >>> >>> "Now, since most (all?) of the libraries out there are going to assume >>> the availability of some 'standard library', let's also assume that some >>> extracted artifact for such library is available and that jextract >>> always knows how to find it - this is the equivalent of java.base for >>> the module system, or java.lang for the Java import system. This >>> addresses the bootstrapping issue." >>> >>> In time we'll get there, I don't see any real technical obstacles to >>> get to your 'optimal' snippet. >>> >>> I think there are two aspects that I'd like to draw attention upon: >>> >>> 1) Magic does not come for free. E.g. it might "seem" that JNI has a >>> more direct approach to calling native methods (ease of use issues >>> aside). In reality it's just that the complexity of calling that >>> native method, marshalling arguments, unmarshalling returns, dealing >>> with native thread transitions and what's not has just been pushed >>> under the JVM rug. So, yes, you can "just" call getpid - but the >>> burden is on the VM. Now, the JNI support is already quite complex - >>> I can't honestly imagine a sane way for the VM to support any given >>> invocation scheme that a user might wish to see supported. This is >>> why Panama is betting on Java code + layouts to do the lifting: that >>> way the VM interface can be kept simple (which has significant >>> payoffs - as the resulting code can be optimized much more - see the >>> linkToNative experimental results in [2]). >>> >>> 2) As your example points out, while calling 'getpid' is something >>> that seems 'easy' enough - 'puts' is already some other beast. It >>> takes a pointer to some memory location where the string is stored. >>> The JNI approach is to pass the Java string as is, and then do the >>> wiring in native code. That is, there's no free lunch here - either >>> you do the adaptation in Java, or you do it in native code (**). >>> Panama gives you a rich enough API to do all such adaptations in >>> Java, so that all native calls are... just native calls (again this >>> means more regularity which means more performances). Having opaque >>> native code snippets which do argument adaptation is not very optimal >>> (and optimizable) for the JVM. With Panama you can create a >>> good-looking API which internally uses pointers/scopes and delegates >>> to the right native method - all done in Java. On top of that, our >>> plans cover a so called 'civilization' layer (see [3]), by which >>> users will be able to customize what comes out of jextract in order >>> e.g. to tell that for 'puts' they really want a Java String argument >>> and not a Pointer; again this will be done in a more general >>> way, so that the binder will be pointed at a pair of functions which >>> can be used to map the user provided data to and from native code. >>> >>> (**) for an example of how interfacing with standard libraries needs >>> some kind of wrapping, even in JNI - look at [4]; this file is >>> essentially a collection of system calls which are wrapped by some >>> logic (e.g. to check errno, ...). I claim that there is something >>> _fundamentally_ wrong with code like this, in that the native code is >>> mixing two concerns: (i) performing the required native call and (ii) >>> adjusting input/output/errors of the call in a way that is suitable >>> to the corresponding Java API. Why shouldn't the Java API itself be >>> in charge of doing (ii) ? >>> >>> Maurizio >>> >>> [1] - >>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-August/002560.html >>> >>> [2] - >>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002652.html >>> [3] - >>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001537.html >>> [4] - >>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c#l314 >>> On 24/09/18 13:34, Jorn Vernee wrote: >>>> I agree with the usability point. In C++ it's as simple to call puts >>>> as doing: >>>> >>>> ??? #include >>>> >>>> ??? int main() { >>>> ??????? puts("Hello World!"); >>>> ??? } >>>> >>>> And I think the optimal Java equivalent would be something like: >>>> >>>> ??? import static org.openjdk.stdio.*; >>>> >>>> ??? public class Main { >>>> >>>> ??????? public static void main(String[] args) { >>>> ??????????? puts("Hello World!"); >>>> ??????? } >>>> >>>> ??? } >>>> >>>> This can be facilitated by creating a 'singleton facade' for the >>>> library interface like so: >>>> >>>> ??? public class stdio { >>>> >>>> ??????? private static final stdioImpl lib = >>>> Libraries.bind(lookup(), stdioImpl.class); >>>> >>>> ??????? public static int puts (String message) { >>>> ??????????? try(Scope scope = Scope.newNativeScope()) { >>>> ??????????????? Pointer msg = scope.toCString(message); >>>> ??????????????? return lib.puts(msg); >>>> ??????????? } >>>> ??????? } >>>> >>>> ??????? ... >>>> ??? } >>>> >>>> Such a facade class could be shipped with the JDK or perhaps as an >>>> artifact on maven central, or maybe it could be an additional output >>>> of jextract. >>>> >>>> But there is only so much you can do automagically from the Java >>>> side. When working from C/C++ you have the compiler filling in the >>>> blanks. For instance, it automatically allocates storage for string >>>> literals. Java does that as well for Java string literals `String s >>>> = "Hello";`, but it can not do that for native strings, and you have >>>> to use the Scope API to do that manually. In some cases, like the >>>> above, you can write glue-code to make that automatic, but I think >>>> at some point things become too complex for that, and there will >>>> always be some usability barrier to interop. >>>> >>>> Jorn >>>> >>>> Samuel Audet schreef op 2018-09-24 13:38: >>>>> FWIW, I think the factory method pattern should be reconsidered >>>>> entirely. In C/C++, when we want to call say getpid(), we don't start >>>>> loading stuff up before calling getpid(), we call getpid()! Why not do >>>>> the same from Java? From a usability point of view, not loading stuff >>>>> manually works fine for JavaCPP... >>>>> >>>>> Now, I know you're going to start taking about interfaces and what >>>>> not. You said that you had plans to introduce an entirely new array >>>>> type just to make it more friendly with vector instructions and native >>>>> libraries. Why not start thinking about an "interface" that would be >>>>> friendly to native libraries as well? Why stop at arrays? >>>>> >>>>> Samuel >>>>> From jbvernee at xs4all.nl Mon Oct 1 09:10:15 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Mon, 01 Oct 2018 11:10:15 +0200 Subject: [foreign] RFR 8211277: Exception when dereferencing null pointer should be more specific In-Reply-To: <5BB18F2D.3000203@oracle.com> References: <3d502c5f-a56b-c856-1b15-a62ab4e8a760@oracle.com> <5BB18F2D.3000203@oracle.com> Message-ID: <73defa1d33f9a2a6913406f391d88fff@xs4all.nl> Sundararajan Athijegannathan schreef op 2018-10-01 05:06: > Looks good. > > PS. While I'm fine with the Windows portability EXPORT macro in C > code, none of the other existing tests use this. Perhaps we need > similar such portability macro elsewhere? Not suggesting for current > changeset though. I have them in my local copy for every test, I could make a patch for those as well, but without wider Windows support they're not as meaningful to have right now. Maybe the one in this changeset should be removed as well to be added in later with all the others. > -Sundar > > > On 28/09/18, 6:35 PM, Maurizio Cimadamore wrote: >> Hi, >> this is a RFR for the changes discussed in [1] (again, thanks Jorn!). >> Some minor tweaks: >> >> * consolidate the code paths for 'throwy' References - new >> Reference.OfGrumpy :-) >> >> * tweaked test to check the exception cause - as otherwise the test >> passes even w/o the fix >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8211277/ >> >> Cheers >> Maurizio >> >> [1] - >> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002796.html >> From sundararajan.athijegannathan at oracle.com Mon Oct 1 09:24:57 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 01 Oct 2018 14:54:57 +0530 Subject: [foreign] RFR 8211277: Exception when dereferencing null pointer should be more specific In-Reply-To: <73defa1d33f9a2a6913406f391d88fff@xs4all.nl> References: <3d502c5f-a56b-c856-1b15-a62ab4e8a760@oracle.com> <5BB18F2D.3000203@oracle.com> <73defa1d33f9a2a6913406f391d88fff@xs4all.nl> Message-ID: <5BB1E7E9.6010405@oracle.com> Yes, would be nice to have it consistent & revisit the macro for all tests later as you mentioned. -Sundar On 01/10/18, 2:40 PM, Jorn Vernee wrote: > Sundararajan Athijegannathan schreef op 2018-10-01 05:06: >> Looks good. >> >> PS. While I'm fine with the Windows portability EXPORT macro in C >> code, none of the other existing tests use this. Perhaps we need >> similar such portability macro elsewhere? Not suggesting for current >> changeset though. > > I have them in my local copy for every test, I could make a patch for > those as well, but without wider Windows support they're not as > meaningful to have right now. Maybe the one in this changeset should > be removed as well to be added in later with all the others. > >> -Sundar >> >> >> On 28/09/18, 6:35 PM, Maurizio Cimadamore wrote: >>> Hi, >>> this is a RFR for the changes discussed in [1] (again, thanks >>> Jorn!). Some minor tweaks: >>> >>> * consolidate the code paths for 'throwy' References - new >>> Reference.OfGrumpy :-) >>> >>> * tweaked test to check the exception cause - as otherwise the test >>> passes even w/o the fix >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8211277/ >>> >>> Cheers >>> Maurizio >>> >>> [1] - >>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002796.html >>> From maurizio.cimadamore at oracle.com Mon Oct 1 12:19:16 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 01 Oct 2018 12:19:16 +0000 Subject: hg: panama/dev: 8211275: Binder should check that signature of bound function is compatible with layout descriptions Message-ID: <201810011219.w91CJH6c007937@aojmv0008.oracle.com> Changeset: ab139fcb413c Author: mcimadamore Date: 2018-10-01 13:13 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/ab139fcb413c 8211275: Binder should check that signature of bound function is compatible with layout descriptions Reviewed-by: sundar Contributed-by: jbvernee at xs4all.nl ! src/java.base/share/classes/jdk/internal/foreign/NativeInvoker.java ! src/java.base/share/classes/jdk/internal/foreign/UpcallHandler.java ! src/java.base/share/classes/jdk/internal/foreign/Util.java From maurizio.cimadamore at oracle.com Mon Oct 1 12:24:13 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 01 Oct 2018 12:24:13 +0000 Subject: hg: panama/dev: 8211275: Add test Message-ID: <201810011224.w91CODqA009959@aojmv0008.oracle.com> Changeset: 7cd6f80b1f86 Author: mcimadamore Date: 2018-10-01 13:24 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/7cd6f80b1f86 8211275: Add test Reviewed-by: sundar Contributed-by: jbvernee at xs4all.nl + test/jdk/java/foreign/SignatureMismatchTest.java From maurizio.cimadamore at oracle.com Mon Oct 1 12:32:22 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 01 Oct 2018 12:32:22 +0000 Subject: hg: panama/dev: 8211277: Exception when dereferencing null pointer should be more specific Message-ID: <201810011232.w91CWMH7014904@aojmv0008.oracle.com> Changeset: 32e0052712b1 Author: mcimadamore Date: 2018-10-01 13:32 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/32e0052712b1 8211277: Exception when dereferencing null pointer should be more specific Reviewed-by: sundar Contributed-by: jbvernee at xs4all.nl ! src/java.base/share/classes/java/foreign/memory/Pointer.java ! src/java.base/share/classes/jdk/internal/foreign/ScopeImpl.java ! src/java.base/share/classes/jdk/internal/foreign/memory/BoundedPointer.java ! src/java.base/share/classes/jdk/internal/foreign/memory/LayoutTypeImpl.java ! src/java.base/share/classes/jdk/internal/foreign/memory/References.java + test/jdk/java/foreign/null/NullTest.java + test/jdk/java/foreign/null/libNull.c From maurizio.cimadamore at oracle.com Mon Oct 1 12:32:43 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 1 Oct 2018 13:32:43 +0100 Subject: [foreign] RFR 8211277: Exception when dereferencing null pointer should be more specific In-Reply-To: <5BB1E7E9.6010405@oracle.com> References: <3d502c5f-a56b-c856-1b15-a62ab4e8a760@oracle.com> <5BB18F2D.3000203@oracle.com> <73defa1d33f9a2a6913406f391d88fff@xs4all.nl> <5BB1E7E9.6010405@oracle.com> Message-ID: <1d95be52-ab1b-47b5-9a31-ffd2ba88fc9d@oracle.com> Thanks, I've removed Windows specific #defines and pushed the changeset. Maurizio On 01/10/18 10:24, Sundararajan Athijegannathan wrote: > Yes, would be nice to have it consistent & revisit the macro for all > tests later as you mentioned. > > -Sundar > > On 01/10/18, 2:40 PM, Jorn Vernee wrote: >> Sundararajan Athijegannathan schreef op 2018-10-01 05:06: >>> Looks good. >>> >>> PS. While I'm fine with the Windows portability EXPORT macro in C >>> code, none of the other existing tests use this. Perhaps we need >>> similar such portability macro elsewhere? Not suggesting for current >>> changeset though. >> >> I have them in my local copy for every test, I could make a patch for >> those as well, but without wider Windows support they're not as >> meaningful to have right now. Maybe the one in this changeset should >> be removed as well to be added in later with all the others. >> >>> -Sundar >>> >>> >>> On 28/09/18, 6:35 PM, Maurizio Cimadamore wrote: >>>> Hi, >>>> this is a RFR for the changes discussed in [1] (again, thanks >>>> Jorn!). Some minor tweaks: >>>> >>>> * consolidate the code paths for 'throwy' References - new >>>> Reference.OfGrumpy :-) >>>> >>>> * tweaked test to check the exception cause - as otherwise the test >>>> passes even w/o the fix >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8211277/ >>>> >>>> Cheers >>>> Maurizio >>>> >>>> [1] - >>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002796.html >>>> From sundararajan.athijegannathan at oracle.com Mon Oct 1 12:42:26 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 01 Oct 2018 18:12:26 +0530 Subject: [foreign] RFR 8211281: Strenghten the logic for parsing header declarations Message-ID: <5BB21632.1000706@oracle.com> Looks good. This is a reply to RFR -> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002824.html -Sundar From maurizio.cimadamore at oracle.com Mon Oct 1 13:26:03 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 1 Oct 2018 14:26:03 +0100 Subject: [vectorInstrinsics] merge with upstream failed Message-ID: Hi, the vectorIntrinsics branch failed to merge because of the following conflicts: U src/hotspot/cpu/x86/assembler_x86.cpp U src/hotspot/cpu/x86/macroAssembler_x86.cpp U src/hotspot/cpu/x86/vm_version_x86.hpp U src/hotspot/cpu/x86/x86.ad I tried to take a look but the changes look a bit too deep for me to handle the merge. Could please somebody from the vector team look at the conflicts? To start a merge: $ hg update vectorIntrinsics $ hg merge -r default $ hg commit -m 'manual merge with default' $ hg push Cheers Maurizio From vladimir.x.ivanov at oracle.com Mon Oct 1 18:21:11 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 1 Oct 2018 11:21:11 -0700 Subject: [foreign] RFR 8210757: Add binder support for direct native invocation strategy In-Reply-To: References: <3e40cafe-df17-2569-8886-1b2142eb416c@oracle.com> Message-ID: <1b86c7c5-45d2-71c5-5768-11caa3b6fb8c@oracle.com> Looks very good, Maurizio! Best regards, Vladimir Ivanov On 28/09/2018 04:19, Maurizio Cimadamore wrote: > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8210757_v2/ > > Maurizio > > > On 28/09/18 12:19, Maurizio Cimadamore wrote: >> This is an updated version of the direct invocation scheme support. >> Very close to the last one, but there are some minor >> refactorings/improvements: >> >> 1) Added a @Stable annotation in DirectNativeInvoker's MH field >> 2) box/unbox routine used by the UniversalXYZ strategies have been >> moved from NativeInvoker to UniversalNativeInvoker >> 3) I revamped the logic which detects whether fastpath is applicable - >> now we create the calling sequence first, and we use that to check >> whether we can fast path it. Some internal benchmark have shown that >> with a large number of symbols, we were doing a lot of work because we >> were trying the fastpath always and then, in case of exception >> fallback to slow path; in such cases we would create calling sequence >> twice. This new technique might also be more friendly w.r.t. Windows >> and other ABIs. >> >> I'd really like to move ahead with this (as this RFR has been out for >> quite a while now) - if there's no other comments I'll go ahead. >> >> Maurizio >> >> >> On 14/09/18 19:04, Maurizio Cimadamore wrote: >>> Hi, >>> as mentioned in [1], this patch adds binder support for the so called >>> 'direct' invocation scheme, which allows for greater native >>> invocation downcall/upcall performances by means of specialized >>> adapters. The core idea, also described in [1], is to define adapters >>> of the kind: >>> >>> invokeNative_V_DDDDD >>> invokeNative_V_JDDDD >>> invokeNative_V_JJDDD >>> invokeNative_V_JJJDD >>> invokeNative_V_JJJJD >>> invokeNative_V_JJJJJ >>> >>> Where long arguments come before double arguments (and do this for >>> each arity e.g. <=5). >>> >>> If all arguments are passed in register, then this reordering doesn't >>> affect behavior, and greatly limits the number of permutations to be >>> supported/generated. >>> >>> The downcall part (java to native) is relative straightforward: the >>> directNativeInvoker.cpp file defines a bunch of native entry points, >>> one per shape, which cast the input address to a function pointer of >>> the desired shape, and then call it: >>> >>> jlong NI_invokeNative_J_JD(JNIEnv *env, jobject _unused, jlong addr, >>> jlong arg0, jdouble arg1) { >>> ??? return ((jlong (*)(jlong, jdouble))addr)(arg0, arg1); >>> } >>> >>> The upcall business is a little trickier: first, if we are only to >>> optimize upcalls where argument passing happens in registers, then >>> it's crucial to note that by the time we get into the assembly stub, >>> all the registers will have been populated by the native code to >>> contain the right arguments in the right places. So we can avoid all >>> the shuffling in the assembly adapter and simply jump onto a C >>> function that looks like this: >>> >>> long specialized_upcall_helper_J(long l0, long l1, long l2, long l3, >>> ????????????????????????????????????? double d0, double d1, double >>> d2, double d3, >>> ?????????????????????????????????????? unsigned int mask, jobject >>> rec) { ... } >>> >>> Note here that the first 8 arguments are just longs and doubles, and >>> those will be expected to be in registers, according to the System V >>> ABI. (In windows, the situation will be a bit different as less >>> integer registers are available, so this will need some work there). >>> >>> So, to recap, the assembly upcall stub simply 'append' the receiver >>> object and a 'signature mask' in the last two available C registers >>> and then jump onto the helper function. The helper function will find >>> all the desired arguments in the right places - there will be, in the >>> general case, some unused arguments, but that's fine, after all it >>> didn't cost anything to us to load them in the first place! >>> >>> Note that we have three helper variants, one for each return type { >>> long, double, void }. This is required as we need the C helper to >>> return a value of the right type which will generate the right >>> assembly sequence to store the result in the right register (either >>> integer or MMX). >>> >>> So, with three helpers we can support all the shapes with up to 8 >>> arguments. On the Java side we have, of course, to define a >>> specialized entry point for each shape. >>> >>> All the magic for adapting method handle to and from the specialized >>> adapters happen in the DirectSignatureShuffler class; this class is >>> responsible for adapting each argument e.g. from Java to native >>> value, and then reordering the adapted method handle to match the >>> order in which arguments are expected by the adapter (e.g. move all >>> longs in front). The challenge was in having DirectSignatureShuffle >>> to be fully symmetric - e.g. I did not want to have different code >>> paths for upcalls and downcalls, so the code tries quite hard to be >>> parametric in the shuffling direction (java->native or native->java) >>> - which means that adapters will be applied in one way or in the >>> inverse way depending on the shuffling direction (and as to whether >>> we are adapting an argument or a return). Since method handle filters >>> are composable, it all works out quite beautifully. >>> >>> Note that the resulting, adapted MH is stored in a @Stable field to >>> tell the JIT to optimize the heck out of it (as if it were a static >>> constant). >>> >>> This patch contains several other changes - which I discuss briefly >>> below: >>> >>> * we need to setup a framework in which new invocation strategies can >>> be plugged in - note that we now have essentially 4 cases: >>> >>> { NativeInvoker, UpcallHandler } x { Universal, Direct } >>> >>> When the code wants e.g. a NativeInvoker, it asks for one to the >>> NativeInvoker::of factory (UpcallHandler work in a similar way); this >>> factory will attempt to go down the fast path - if an error occurs >>> when computing the fast path, the call will fallback to the universal >>> (slow) path. >>> >>> Most of the changes you see in the Java code are associated to this >>> refactoring - e.g. all clients of NativeInvoker/UpcallHandler should >>> now go through the factory >>> >>> * CallbackImplGenerator had a major issue since the new factory for >>> NativeInvoker wants to bind an address eagerly (this is required e.g. >>> to be forward compatible with linkToNative backend); which means that >>> at construction time we have to get the address of the callback, call >>> the NativeInvoker factory and then stash the target method handle >>> into a field of the anon callback class. Vlad tells me that fields of >>> anon classes are always 'trusted' by the JIT, which means they should >>> be treated as '@Stable' (note that I can't put a @Stable annotation >>> there, since this code will be spinned in user-land). >>> >>> * There are a bunch of properties that can be set to either force >>> slow path or force 'direct' path; in the latter case, if an error >>> occurs when instantiating the direct wrapper, an exception is thrown. >>> This mode is very useful for testing, and I indeed have tried to run >>> all our tests with this flag enabled, to see how many places could >>> not be optimized. >>> >>> * I've also reorganized all the native code in hotspot/prims so that >>> we have a separate file for each scheme (and so that native Java >>> methods could be added where they really belong). This should also >>> help in the long run as it should make adding/removing a given scheme >>> easier. >>> >>> * I've also added a small test which tries to pass structs of >>> different sizes, but I will also work on a more complex test which >>> will stress-test all invocation modes in a more complete fashion. >>> With respect to testing, I've also done a fastdebug build and ran all >>> tests with that (as fastdebug catches way many more hotspot assertion >>> than the product version); everything passed. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8210757/ >>> >>> I'd like to thank Vladimir Ivanov for the prompt support whenever I >>> got stuck down the macro assembler rabbit hole :-) >>> >>> Cheers >>> Maurizio >>> >>> [1] - >>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002652.html >>> >>> >>> >>> >> > From maurizio.cimadamore at oracle.com Mon Oct 1 20:22:42 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 01 Oct 2018 20:22:42 +0000 Subject: hg: panama/dev: 8211281: Strenghten the logic for parsing header declarations Message-ID: <201810012022.w91KMhHM019601@aojmv0008.oracle.com> Changeset: 7d9623430d2f Author: mcimadamore Date: 2018-10-01 13:43 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/7d9623430d2f 8211281: Strenghten the logic for parsing header declarations Reviewed-by: sundar ! src/java.base/share/classes/jdk/internal/foreign/memory/DescriptorParser.java + test/jdk/java/foreign/TestHeaderDeclarations.java From vladimir.x.ivanov at oracle.com Mon Oct 1 20:50:39 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 1 Oct 2018 13:50:39 -0700 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> Message-ID: <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> Hi Ningsheng, >> Overall, I like how it shapes out. There are some aspects I'd like to clarify though. >> >> The name (*ScalableVector) is slightly misleading to me, but I'm fine with it. I >> interpret new shapes as representing vectors of maximally supported size at >> runtime without specifying the actual size. >> > > I am happy to change the name if you have some suggestion. The new shapes are representing current (SVE) hardware supported (max) vector register size, and the actual size is known at runtime. Yes, I'd like the names to clearly manifest it's the vector of maximum size available at runtime. Maybe *MaxVector, but I'm not too happy with it as well. >> New shapes don't interoperate well with existing ones, so unless you change >> how vector shapes are checked (==), at runtime scalable and fixed shape variants >> shouldn't meet. That leads to the next question: how do you expect vector >> shape changing operation working (resize(), rebracket(), cast()) with new variants? >> > > Those vector changing operations are in my TODO list. The scalable shapes are actually fixed length shape during runtime, so I think it is possible to implement those operations. But I am still don't quite understand the motivation and use cases of those vector shape changing APIs. Could you please help to explain a bit? There are 4 methods which change vector shape: resize/rebracket/reshape and cast. (1) Vector.resize() changes only vector length (either shrinking or widening) without touching element types: Int64Vector <-> Int128Vector <-> Int256Vector <-> Int512Vector Javadoc for Shape.resize() says [2]: * The lane elements of the input vector are copied without * modification to the resulting vector, but those lane elements, before * copying, may be truncated if the vector length is greater than this * species length, or appended to with default element values if the * vector length is less than this species length. (2) Vector.rebracket() changes only vector element type leaving vector size intact Byte256Vector <-> Short256Vector <-> Int256Vector <-> Long256Vector Javadoc says [3]: * The underlying bits of the input vector are copied without * modification to the resulting vector. (3) Vector.reshape generalizes resize() & rebracket() and enables arbitrary conversions between vector shapes: Byte64Vector <-> ... <-> Double512Vector * The underlying bits of the input vector are copied to the resulting * vector without modification, but those bits, before copying, may be * truncated if the vector bit size is greater than this species bit * size, or appended to with zero bits if the vector bit size is less * than this species bit size. (4) Vector.cast() allows arbitrary casts between vector shapes Byte64Vector <-> ... <-> Double512Vector Javadoc for Shape.cast() says [4]: * For each input vector lane up to the length of the input vector or * this species, which ever is the minimum, and where {@code N} is the * vector lane index, the element at index {@code N} of primitive type * {@code F} is converted, according to primitive conversion rules * specified by the Java Language Specification, to a value of primitive * type {@code E} and placed into the resulting vector at lane index * {@code N}. If this species length is greater than the input * vector length then the default primitive value is placed into * subsequent lanes of the resulting vector. Right now, resize(), rebracket(), and cast() are intrinsified on x86 while reshape() is not. So, my question boils down to: how vector shape checks are expected to work on *ScalableVectors in presence of operations which change vector size. For example, IntScalableVector.rebracket() => LongScalableVector which is fine, but ISV.resize() => ISV is what I'm concerned about and existing checks aren't enough for *ScalableVectors unless you check their length at runtime. >>> We are working on SVE support on OpenJDK, and current Vector API's intrinsics >> can really help us on our SVE backend work. We have an initial prototype which >> adds SVE backend and updates a bit for current register allocator to support >> scalable length vector types. Our WIP SVE backend shows that this scalable >> vector proposal works fine with current Vector API intrinsics. We would like to >> collect your comments about this scalable vector patch so that we can move >> forward for the SVE backend support. I notice that Vladimir is also thinking about >> alternative loop shapes, that's really helpful for SVE! We will also take a look at >> that further. >> >> It's very encouraging to hear existing intrinsics generalize well to SVE. Looking >> forward to seeing the results of SVE backend work. Feel free to share your pain >> points while implementing it. > > Thanks! We will also evaluate the Arm NEON implementation and performance for current Vector API. Looking forward to the results! Best regards, Vladimir Ivanov [1] Vector resize(Species species); ... * Transforms this vector to a vector of the given species shape {@code T}, * where this vector's element type {@code E} is preserved. ... Vector rebracket(Species species); ... * Transforms this vector to a vector of the given species element type * {@code F}, where this vector's shape {@code S} is preserved. ... Vector reshape(Species species); ... * Transforms this vector to a vector of the given species shape {@code T} * and element type {@code F}. ... Vector cast(Species species); ... * Converts this vector to a vector of the given species shape {@code T} and * element type {@code F}. ... [2] http://hg.openjdk.java.net/panama/dev/file/e8f06cc3fe82/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#l1226 [3] http://hg.openjdk.java.net/panama/dev/file/e8f06cc3fe82/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#l1193 [4] http://hg.openjdk.java.net/panama/dev/file/e8f06cc3fe82/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java#l1253 From shravya.rukmannagari at intel.com Mon Oct 1 22:09:21 2018 From: shravya.rukmannagari at intel.com (shravya.rukmannagari at intel.com) Date: Mon, 01 Oct 2018 22:09:21 +0000 Subject: hg: panama/dev: manual merge with default Message-ID: <201810012209.w91M9MhW005469@aojmv0008.oracle.com> Changeset: 8e78636737f8 Author: srukmannagar Date: 2018-10-01 15:05 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/8e78636737f8 manual merge with default ! make/autoconf/toolchain.m4 ! make/common/NativeCompilation.gmk ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad - src/hotspot/share/classfile/compactHashtable.inline.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/runtime/globals.hpp - src/java.base/macosx/native/libjli/java_md_macosx.c - test/jdk/com/sun/jdi/RedefineException.sh - test/jdk/com/sun/jdi/RedefineFinal.sh - test/jdk/com/sun/jdi/RedefineIntConstantToLong.sh - test/jdk/com/sun/jdi/RedefineMulti.sh - test/jdk/com/sun/jdi/RedefinePop.sh - test/jdk/com/sun/jdi/RedefineStep.sh - test/jdk/com/sun/jdi/RedefineTTYLineNumber.sh - test/jdk/com/sun/jdi/StringConvertTest.sh - test/jdk/com/sun/jdi/WatchFramePop.sh - test/jdk/lib/testlibrary/jdk/testlibrary/Asserts.java From maurizio.cimadamore at oracle.com Mon Oct 1 22:12:16 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 01 Oct 2018 22:12:16 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810012212.w91MCHc4008756@aojmv0008.oracle.com> Changeset: 831901ad8062 Author: mcimadamore Date: 2018-10-02 00:14 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/831901ad8062 Automatic merge with vectorIntrinsics ! make/RunTests.gmk ! make/autoconf/basics.m4 ! make/autoconf/spec.gmk.in ! src/hotspot/cpu/x86/macroAssembler_x86.hpp - src/hotspot/share/classfile/compactHashtable.inline.hpp - src/java.base/macosx/native/libjli/java_md_macosx.c ! test/jdk/TEST.groups - test/jdk/com/sun/jdi/RedefineException.sh - test/jdk/com/sun/jdi/RedefineFinal.sh - test/jdk/com/sun/jdi/RedefineIntConstantToLong.sh - test/jdk/com/sun/jdi/RedefineMulti.sh - test/jdk/com/sun/jdi/RedefinePop.sh - test/jdk/com/sun/jdi/RedefineStep.sh - test/jdk/com/sun/jdi/RedefineTTYLineNumber.sh - test/jdk/com/sun/jdi/StringConvertTest.sh - test/jdk/com/sun/jdi/WatchFramePop.sh - test/jdk/lib/testlibrary/jdk/testlibrary/Asserts.java From maurizio.cimadamore at oracle.com Mon Oct 1 22:12:34 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 01 Oct 2018 22:12:34 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810012212.w91MCY4s009192@aojmv0008.oracle.com> Changeset: 300accd57122 Author: mcimadamore Date: 2018-10-02 00:14 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/300accd57122 Automatic merge with foreign ! src/hotspot/cpu/x86/macroAssembler_x86.hpp From shravya.rukmannagari at intel.com Mon Oct 1 23:43:37 2018 From: shravya.rukmannagari at intel.com (shravya.rukmannagari at intel.com) Date: Mon, 01 Oct 2018 23:43:37 +0000 Subject: hg: panama/dev: VectorAPI shift and gather Generation Changes Message-ID: <201810012343.w91NhcQX022573@aojmv0008.oracle.com> Changeset: 9d5b8130187b Author: srukmannagar Date: 2018-10-01 16:36 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9d5b8130187b VectorAPI shift and gather Generation Changes ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh From maurizio.cimadamore at oracle.com Mon Oct 1 23:47:00 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 01 Oct 2018 23:47:00 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810012347.w91Nl1PW024353@aojmv0008.oracle.com> Changeset: 1f9d7cfcffdf Author: mcimadamore Date: 2018-10-02 01:49 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/1f9d7cfcffdf Automatic merge with vectorIntrinsics From maurizio.cimadamore at oracle.com Tue Oct 2 11:04:59 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 02 Oct 2018 11:04:59 +0000 Subject: hg: panama/dev: 8210757: Add binder support for direct native invocation strategy Message-ID: <201810021105.w92B50pS007828@aojmv0008.oracle.com> Changeset: ddd72eb903e5 Author: mcimadamore Date: 2018-10-02 12:04 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/ddd72eb903e5 8210757: Add binder support for direct native invocation strategy Reviewed-by: sundar, hjen, vlivanov + src/hotspot/cpu/x86/directUpcallHandler_x86.cpp + src/hotspot/cpu/x86/foreign_globals_x86.cpp + src/hotspot/cpu/x86/foreign_globals_x86.hpp - src/hotspot/cpu/x86/nativeInvoker_x86.cpp + src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp + src/hotspot/cpu/x86/universalUpcallHandler_x86.cpp + src/hotspot/share/prims/directNativeInvoker.cpp + src/hotspot/share/prims/directUpcallHandler.cpp + src/hotspot/share/prims/directUpcallHandler.hpp - src/hotspot/share/prims/nativeInvoker.cpp - src/hotspot/share/prims/nativeInvoker.hpp ! src/hotspot/share/prims/nativeLookup.cpp + src/hotspot/share/prims/universalNativeInvoker.cpp + src/hotspot/share/prims/universalNativeInvoker.hpp + src/hotspot/share/prims/universalUpcallHandler.cpp + src/hotspot/share/prims/universalUpcallHandler.hpp + src/hotspot/share/prims/upcallHandler.cpp ! src/hotspot/share/runtime/init.cpp ! src/java.base/share/classes/jdk/internal/foreign/BinderClassGenerator.java ! src/java.base/share/classes/jdk/internal/foreign/CallbackImplGenerator.java ! src/java.base/share/classes/jdk/internal/foreign/HeaderImplGenerator.java ! src/java.base/share/classes/jdk/internal/foreign/LayoutResolver.java - src/java.base/share/classes/jdk/internal/foreign/NativeInvoker.java ! src/java.base/share/classes/jdk/internal/foreign/ScopeImpl.java - src/java.base/share/classes/jdk/internal/foreign/UpcallHandler.java ! src/java.base/share/classes/jdk/internal/foreign/Util.java + src/java.base/share/classes/jdk/internal/foreign/invokers/DirectNativeInvoker.java + src/java.base/share/classes/jdk/internal/foreign/invokers/DirectSignatureShuffler.java + src/java.base/share/classes/jdk/internal/foreign/invokers/DirectUpcallHandler.java + src/java.base/share/classes/jdk/internal/foreign/invokers/NativeInvoker.java + src/java.base/share/classes/jdk/internal/foreign/invokers/UniversalNativeInvoker.java + src/java.base/share/classes/jdk/internal/foreign/invokers/UniversalUpcallHandler.java + src/java.base/share/classes/jdk/internal/foreign/invokers/UpcallHandler.java + src/java.base/share/classes/jdk/internal/foreign/invokers/VarargsInvoker.java ! src/java.base/share/classes/jdk/internal/foreign/memory/BoundedPointer.java ! src/java.base/share/classes/jdk/internal/foreign/memory/CallbackImpl.java + test/jdk/java/foreign/RegisterStructTest.java + test/jdk/java/foreign/libRegisterStruct.c From maurizio.cimadamore at oracle.com Tue Oct 2 11:06:52 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 02 Oct 2018 11:06:52 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810021106.w92B6qNw008763@aojmv0008.oracle.com> Changeset: b8533bf2b837 Author: mcimadamore Date: 2018-10-02 13:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b8533bf2b837 Automatic merge with foreign - src/hotspot/cpu/x86/nativeInvoker_x86.cpp - src/hotspot/share/prims/nativeInvoker.cpp - src/hotspot/share/prims/nativeInvoker.hpp - src/java.base/share/classes/jdk/internal/foreign/NativeInvoker.java - src/java.base/share/classes/jdk/internal/foreign/UpcallHandler.java From maurizio.cimadamore at oracle.com Tue Oct 2 11:07:55 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 2 Oct 2018 12:07:55 +0100 Subject: [foreign] RFR 8210757: Add binder support for direct native invocation strategy In-Reply-To: <1b86c7c5-45d2-71c5-5768-11caa3b6fb8c@oracle.com> References: <3e40cafe-df17-2569-8886-1b2142eb416c@oracle.com> <1b86c7c5-45d2-71c5-5768-11caa3b6fb8c@oracle.com> Message-ID: <3b2af9f6-7662-d1f3-ad00-ea74fbdc8a20@oracle.com> Pushed - thx everybody for the reviews! P.S. after a chat with Mandy, I decided to add the @Stable annotation to CallbackImplGenerator. It seems like the situation w.r.t. @Stable and VM anon class is as follows: the VM will not treat VM anon class fields as @Stable magically, but the VM will allow the @Stable annotation to be used even in VM anon classes that have a lookup class that belongs to a module other than java.base - in a way these classes are 'priviliged' and the set of tricks available at disposal is bigger. Maurizio On 01/10/18 19:21, Vladimir Ivanov wrote: > Looks very good, Maurizio! > > Best regards, > Vladimir Ivanov > > On 28/09/2018 04:19, Maurizio Cimadamore wrote: >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8210757_v2/ >> >> Maurizio >> >> >> On 28/09/18 12:19, Maurizio Cimadamore wrote: >>> This is an updated version of the direct invocation scheme support. >>> Very close to the last one, but there are some minor >>> refactorings/improvements: >>> >>> 1) Added a @Stable annotation in DirectNativeInvoker's MH field >>> 2) box/unbox routine used by the UniversalXYZ strategies have been >>> moved from NativeInvoker to UniversalNativeInvoker >>> 3) I revamped the logic which detects whether fastpath is applicable >>> - now we create the calling sequence first, and we use that to check >>> whether we can fast path it. Some internal benchmark have shown that >>> with a large number of symbols, we were doing a lot of work because >>> we were trying the fastpath always and then, in case of exception >>> fallback to slow path; in such cases we would create calling >>> sequence twice. This new technique might also be more friendly >>> w.r.t. Windows and other ABIs. >>> >>> I'd really like to move ahead with this (as this RFR has been out >>> for quite a while now) - if there's no other comments I'll go ahead. >>> >>> Maurizio >>> >>> >>> On 14/09/18 19:04, Maurizio Cimadamore wrote: >>>> Hi, >>>> as mentioned in [1], this patch adds binder support for the so >>>> called 'direct' invocation scheme, which allows for greater native >>>> invocation downcall/upcall performances by means of specialized >>>> adapters. The core idea, also described in [1], is to define >>>> adapters of the kind: >>>> >>>> invokeNative_V_DDDDD >>>> invokeNative_V_JDDDD >>>> invokeNative_V_JJDDD >>>> invokeNative_V_JJJDD >>>> invokeNative_V_JJJJD >>>> invokeNative_V_JJJJJ >>>> >>>> Where long arguments come before double arguments (and do this for >>>> each arity e.g. <=5). >>>> >>>> If all arguments are passed in register, then this reordering >>>> doesn't affect behavior, and greatly limits the number of >>>> permutations to be supported/generated. >>>> >>>> The downcall part (java to native) is relative straightforward: the >>>> directNativeInvoker.cpp file defines a bunch of native entry >>>> points, one per shape, which cast the input address to a function >>>> pointer of the desired shape, and then call it: >>>> >>>> jlong NI_invokeNative_J_JD(JNIEnv *env, jobject _unused, jlong >>>> addr, jlong arg0, jdouble arg1) { >>>> ??? return ((jlong (*)(jlong, jdouble))addr)(arg0, arg1); >>>> } >>>> >>>> The upcall business is a little trickier: first, if we are only to >>>> optimize upcalls where argument passing happens in registers, then >>>> it's crucial to note that by the time we get into the assembly >>>> stub, all the registers will have been populated by the native code >>>> to contain the right arguments in the right places. So we can avoid >>>> all the shuffling in the assembly adapter and simply jump onto a C >>>> function that looks like this: >>>> >>>> long specialized_upcall_helper_J(long l0, long l1, long l2, long l3, >>>> ????????????????????????????????????? double d0, double d1, double >>>> d2, double d3, >>>> ?????????????????????????????????????? unsigned int mask, jobject >>>> rec) { ... } >>>> >>>> Note here that the first 8 arguments are just longs and doubles, >>>> and those will be expected to be in registers, according to the >>>> System V ABI. (In windows, the situation will be a bit different as >>>> less integer registers are available, so this will need some work >>>> there). >>>> >>>> So, to recap, the assembly upcall stub simply 'append' the receiver >>>> object and a 'signature mask' in the last two available C registers >>>> and then jump onto the helper function. The helper function will >>>> find all the desired arguments in the right places - there will be, >>>> in the general case, some unused arguments, but that's fine, after >>>> all it didn't cost anything to us to load them in the first place! >>>> >>>> Note that we have three helper variants, one for each return type { >>>> long, double, void }. This is required as we need the C helper to >>>> return a value of the right type which will generate the right >>>> assembly sequence to store the result in the right register (either >>>> integer or MMX). >>>> >>>> So, with three helpers we can support all the shapes with up to 8 >>>> arguments. On the Java side we have, of course, to define a >>>> specialized entry point for each shape. >>>> >>>> All the magic for adapting method handle to and from the >>>> specialized adapters happen in the DirectSignatureShuffler class; >>>> this class is responsible for adapting each argument e.g. from Java >>>> to native value, and then reordering the adapted method handle to >>>> match the order in which arguments are expected by the adapter >>>> (e.g. move all longs in front). The challenge was in having >>>> DirectSignatureShuffle to be fully symmetric - e.g. I did not want >>>> to have different code paths for upcalls and downcalls, so the code >>>> tries quite hard to be parametric in the shuffling direction >>>> (java->native or native->java) - which means that adapters will be >>>> applied in one way or in the inverse way depending on the shuffling >>>> direction (and as to whether we are adapting an argument or a >>>> return). Since method handle filters are composable, it all works >>>> out quite beautifully. >>>> >>>> Note that the resulting, adapted MH is stored in a @Stable field to >>>> tell the JIT to optimize the heck out of it (as if it were a static >>>> constant). >>>> >>>> This patch contains several other changes - which I discuss briefly >>>> below: >>>> >>>> * we need to setup a framework in which new invocation strategies >>>> can be plugged in - note that we now have essentially 4 cases: >>>> >>>> { NativeInvoker, UpcallHandler } x { Universal, Direct } >>>> >>>> When the code wants e.g. a NativeInvoker, it asks for one to the >>>> NativeInvoker::of factory (UpcallHandler work in a similar way); >>>> this factory will attempt to go down the fast path - if an error >>>> occurs when computing the fast path, the call will fallback to the >>>> universal (slow) path. >>>> >>>> Most of the changes you see in the Java code are associated to this >>>> refactoring - e.g. all clients of NativeInvoker/UpcallHandler >>>> should now go through the factory >>>> >>>> * CallbackImplGenerator had a major issue since the new factory for >>>> NativeInvoker wants to bind an address eagerly (this is required >>>> e.g. to be forward compatible with linkToNative backend); which >>>> means that at construction time we have to get the address of the >>>> callback, call the NativeInvoker factory and then stash the target >>>> method handle into a field of the anon callback class. Vlad tells >>>> me that fields of anon classes are always 'trusted' by the JIT, >>>> which means they should be treated as '@Stable' (note that I can't >>>> put a @Stable annotation there, since this code will be spinned in >>>> user-land). >>>> >>>> * There are a bunch of properties that can be set to either force >>>> slow path or force 'direct' path; in the latter case, if an error >>>> occurs when instantiating the direct wrapper, an exception is >>>> thrown. This mode is very useful for testing, and I indeed have >>>> tried to run all our tests with this flag enabled, to see how many >>>> places could not be optimized. >>>> >>>> * I've also reorganized all the native code in hotspot/prims so >>>> that we have a separate file for each scheme (and so that native >>>> Java methods could be added where they really belong). This should >>>> also help in the long run as it should make adding/removing a given >>>> scheme easier. >>>> >>>> * I've also added a small test which tries to pass structs of >>>> different sizes, but I will also work on a more complex test which >>>> will stress-test all invocation modes in a more complete fashion. >>>> With respect to testing, I've also done a fastdebug build and ran >>>> all tests with that (as fastdebug catches way many more hotspot >>>> assertion than the product version); everything passed. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8210757/ >>>> >>>> I'd like to thank Vladimir Ivanov for the prompt support whenever I >>>> got stuck down the macro assembler rabbit hole :-) >>>> >>>> Cheers >>>> Maurizio >>>> >>>> [1] - >>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002652.html >>>> >>>> >>>> >>>> >>> >> From sandhya.viswanathan at intel.com Tue Oct 2 16:50:42 2018 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Tue, 2 Oct 2018 16:50:42 +0000 Subject: [vectorInstrinsics] merge with upstream failed In-Reply-To: References: Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EF14D79@FMSMSX126.amr.corp.intel.com> Thanks Maurizio for bringing our attention to this. FYI, we completed the manual merge yesterday. Best Regards, Sandhya -----Original Message----- From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Maurizio Cimadamore Sent: Monday, October 01, 2018 6:26 AM To: 'panama-dev at openjdk.java.net' Subject: [vectorInstrinsics] merge with upstream failed Hi, the vectorIntrinsics branch failed to merge because of the following conflicts: U src/hotspot/cpu/x86/assembler_x86.cpp U src/hotspot/cpu/x86/macroAssembler_x86.cpp U src/hotspot/cpu/x86/vm_version_x86.hpp U src/hotspot/cpu/x86/x86.ad I tried to take a look but the changes look a bit too deep for me to handle the merge. Could please somebody from the vector team look at the conflicts? To start a merge: $ hg update vectorIntrinsics $ hg merge -r default $ hg commit -m 'manual merge with default' $ hg push Cheers Maurizio From maurizio.cimadamore at oracle.com Tue Oct 2 16:55:43 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 2 Oct 2018 17:55:43 +0100 Subject: [vectorInstrinsics] merge with upstream failed In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EF14D79@FMSMSX126.amr.corp.intel.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EF14D79@FMSMSX126.amr.corp.intel.com> Message-ID: <3b04dbc0-552d-8aa3-5d36-ec70bd0ad89b@oracle.com> On 02/10/18 17:50, Viswanathan, Sandhya wrote: > Thanks Maurizio for bringing our attention to this. FYI, we completed the manual merge yesterday. Thanks, I noted that our internal build systems went back to green! Cheers Maurizio > > Best Regards, > Sandhya > > > -----Original Message----- > From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Maurizio Cimadamore > Sent: Monday, October 01, 2018 6:26 AM > To: 'panama-dev at openjdk.java.net' > Subject: [vectorInstrinsics] merge with upstream failed > > Hi, > the vectorIntrinsics branch failed to merge because of the following > conflicts: > > U src/hotspot/cpu/x86/assembler_x86.cpp > U src/hotspot/cpu/x86/macroAssembler_x86.cpp > U src/hotspot/cpu/x86/vm_version_x86.hpp > U src/hotspot/cpu/x86/x86.ad > > I tried to take a look but the changes look a bit too deep for me to > handle the merge. Could please somebody from the vector team look at the > conflicts? > > To start a merge: > > $ hg update vectorIntrinsics > > $ hg merge -r default > > > > $ hg commit -m 'manual merge with default' > > $ hg push > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Tue Oct 2 17:44:44 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 2 Oct 2018 18:44:44 +0100 Subject: [foreign] RFR 8211397: consolidate parsing of indentifiers in DescriptorParser Message-ID: <8904220f-4c3f-da4b-6ebf-92362c9c56da@oracle.com> Hi, following the recent parser changes to improve parsing of header declarations, this is a followup patch which unifies the parsing logic of layout annotation names with the recently introduced logic for parsing header declaration names. A new test has been added to check the various case of good/bad annotation names. Webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8211397/ Cheers Maurizio From samuel.audet at gmail.com Wed Oct 3 03:57:07 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Wed, 3 Oct 2018 12:57:07 +0900 Subject: on usability In-Reply-To: References: <138140e4ab654e59fa538b5438fdee9d@xs4all.nl> <71d58dfa-4bf2-382a-9449-e726f291b1e9@oracle.com> <3e25bf4a-1a75-357f-be72-fd36cbd3cf15@gmail.com> <1dde768f-2067-de80-2655-a881ae78c771@oracle.com> <39381ab4-f888-f7e9-3764-59b5dba1eca9@gmail.com> Message-ID: <2dac614c-8927-14d6-3303-8760b8088b09@gmail.com> After discussing offline with John and Maurizio, I'd like to make a few additions to this thread. Although we need wrappers to make the interfaces more usable, those wrappers can eventually be generated at runtime, just like lambda expressions actually create classes dynamically. If we can make this part of the plan, that sounds good. Then we'd just need to make it all work to manage the native libraries, maybe using JavaCPP as reference since I'm not aware of any other serious attempt at packaging native libraries for multiple platforms. As for the layout definition language, I've learned that the idea comes from similar features found on other platforms such as Python's struct module, which does get used by most popular serialization methods out there (Protocol Buffers, FlatBuffers, Avro, etc): https://docs.python.org/2/library/struct.html But I still think it's an overly complicated way of representing a "struct"... Couldn't we just list the member variables with methods or properties that access memory directly as with Swift or Substrate VM? Maybe that could even be part of the value types from Valhalla? We could then leave the layouts out of the interfaces for native code. What do you think John? As for C++ templates, we could have say std::map. How could we map this with Panama layouts without any calls to native functions? It's basically just data, but the structure's definition is implementation dependent. Could be red-black trees, a hash table, an entirely custom method, etc, so it's not something that I think we can support with Panama layouts without actually executing the C++ bits. In any case, what I'm most interested in is the performance. JNI is already pretty fast, and tools such as JNR or JavaCPP have shown that it's possible to make it user friendly enough without any additional overhead. (Although given the popularity of JNA that's not something people typically care about all that much). Anyway, I'll be waiting for a version of "linkToNative" that we can start testing, try to modify JavaCPP to target the new API and classes, although I'm starting to get the feeling that the leap isn't going to be big enough for people to want to make the switch. After all, everyone will have to be supporting old versions of the JDK and Android for years to come... Samuel On 10/01/2018 02:29 PM, Samuel Audet wrote: > Hi, Jorn, Maurizio, > > I'm not talking about syntactic sugar, I'm fine with Java requiring > getters/setters and having an init() call somewhere. What I'm not OK > with is, just to call a native function, we have to call something like > Libraries.bind() every single time with the name of the class and the > path to the library, or save it somewhere in a field, and then what do > we do with it? How do we manage it across classes and modules? Why can't > the framework do that automatically for us? > > This is just one example of the usability problems that Panama isn't > solving over JNI, that yes Swift or GraalVM is solving, not with > wrappers, but at compile time as Maurizio points out. Panama could do > the same with an init() function if it decided not to go with vanilla > interfaces since the factory method pattern prevents this: You'll need > wrappers. > > Another usability problem is code that is hard to read, like for the > layouts, yes, which are neither easy to read nor write, I'm glad > Maurizio agrees, but there are no proposal to fix this because we're > committed to this approach as it's supposed to make things more > general... but they still won't work for C++ templates or computational > graphs! So, maybe everyone will want to use Truffle anyway? > > BTW, Swift does support offsetof(), here's the proposal status: > https://github.com/apple/swift-evolution/blob/master/proposals/0210-key-path-offset.md > > "Status: Implemented (Swift 4.2)": Open source at work! > > BTW2, the example from GraalVM that I gave isn't from Truffle, it's from > the "Substrate VM" codebase: It's completely unrelated. > > JNI is already very capable. As Maurizio points out in his reply, the > whole point of Panama is not to improve the capabilities of JNI, it's to > improve the *usability* and the *performance*, but after over 4 years of > work, I still do not see how it will be able to fulfill either goals! > Let's maybe work on "linkToNative" and get this shipped already to let > others work on things like jextract? That might be worth it, but it's > not happening. Priorities are elsewhere, although it's not clear to me > where exactly. > > You see, in my opinion, the problem with Panama vs others like GraalVM, > LLVM, or Swift is that the link with the community is missing. Decisions > are made purely on an internal basis with no communication with the > outside. If you Jorn like where Panama is going on a technical basis, > that's great, but I'm not, and probably others are not either, but there > is no forum to have a discussion about this. > > In any case, the Java community is a bit wider than OpenJDK, so maybe > one day Truffle will get integrated into the JDK before Panama gets > anywhere, or Substrate VM will "replace" HotSpot, since AOT is pretty > much required for platforms like iOS, Google might become interested in > using it for Android too, and everyone's already bundling the JRE with > their desktop apps these days anyway. > > Samuel > > On 09/26/2018 06:39 PM, Jorn Vernee wrote: >> The Swift example looks cool and I can say 2 things about that: >> >> 1.) Swift seems to have properties (i.e. syntactic sugar for getters >> and setter), so It's much easier to inject some code that accesses an >> underlying C struct instead of a backing field. I think at least for >> the time being, the Java equivalent would be getters and setters. But >> tbh I don't see that much usability problems with that, since it's >> more or less the same amount of characters to write: `myStruct.x = 10` >> vs. `myStruct.x$set(10)` (especially considering auto-completion). It >> just doesn't look as fancy. >> >> 2.) I guess jextract could generate an equivalent of the 2 `Init()` >> functions as well for generated structs, and that would be part of the >> 'civilisation layer' Maurizio mentioned. With current tech, it would >> probably either create and leak a scope internally, or you'd have to >> pass a scope. Maybe a long term solution could be something like using >> a default scope that is managed by the garbage collector. The >> generated struct would not have a tight life-cycle (GC lazily collects >> objects), but it would be easier to use. >> >> The Graal native access stuff uses truffle, i.e. it is baked into the >> interpreter. But the truffle interpreter is built to be very >> customizeable, so I think doing the same with the Hotspot interpreter >> would be far more difficult. But either way, the way Graal maps a C >> struct to an interface in that example looks pretty similar to what >> panama is doing to me. >> >> I think panama is making sane choices, and focusing on capability >> before usability. panama is just not as far along as the other >> projects you mention, and I think more usability (jextract >> civilization layer) and better performance (linkToNative backend) are >> yet to come. >> >> Jorn >> >> Samuel Audet schreef op 2018-09-26 03:14: >>> We can do a lot of wrapper magic in either Java or C++. JavaCPP >>> already does for JNI what Jorn is describing we could do for Panama: >>> https://github.com/bytedeco/javacpp-presets/tree/master/systems#the-srcmainjavatestavxjava-source-file >>> >>> >>> If we consider JNI to be "legacy", it makes a lot of sense to try and >>> do some acrobatics like that to support legacy systems, but why not >>> make the new hotness actually _usable_? Take a look at how Swift does >>> it: >>> https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift >>> >>> >>> Now that's what I call *usable*. Panama is very far from that level of >>> usability. And it's not because the Java language is somehow >>> handicapped. Check what the guys over at GraalVM are doing: >>> https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.tutorial/src/com/oracle/svm/tutorial/CInterfaceTutorial.java >>> >>> >>> It also features performance that's already apparently higher than JNI: >>> https://cornerwings.github.io/2018/07/graal-native-methods/ >>> >>> Why not do something user friendly like that in Panama's case as well? >>> What's the rationale to make it all in the end as complicated to use >>> as JNI? Maybe there's something I'm missing, so please point it out. >>> >>> Samuel >>> >>> >>> On 09/24/2018 10:37 PM, Maurizio Cimadamore wrote: >>>> Having a pre-extracted stdlib bundle is something we have considered >>>> - quoting from [1]: >>>> >>>> "Now, since most (all?) of the libraries out there are going to assume >>>> the availability of some 'standard library', let's also assume that >>>> some >>>> extracted artifact for such library is available and that jextract >>>> always knows how to find it - this is the equivalent of java.base for >>>> the module system, or java.lang for the Java import system. This >>>> addresses the bootstrapping issue." >>>> >>>> In time we'll get there, I don't see any real technical obstacles to >>>> get to your 'optimal' snippet. >>>> >>>> I think there are two aspects that I'd like to draw attention upon: >>>> >>>> 1) Magic does not come for free. E.g. it might "seem" that JNI has a >>>> more direct approach to calling native methods (ease of use issues >>>> aside). In reality it's just that the complexity of calling that >>>> native method, marshalling arguments, unmarshalling returns, dealing >>>> with native thread transitions and what's not has just been pushed >>>> under the JVM rug. So, yes, you can "just" call getpid - but the >>>> burden is on the VM. Now, the JNI support is already quite complex - >>>> I can't honestly imagine a sane way for the VM to support any given >>>> invocation scheme that a user might wish to see supported. This is >>>> why Panama is betting on Java code + layouts to do the lifting: that >>>> way the VM interface can be kept simple (which has significant >>>> payoffs - as the resulting code can be optimized much more - see the >>>> linkToNative experimental results in [2]). >>>> >>>> 2) As your example points out, while calling 'getpid' is something >>>> that seems 'easy' enough - 'puts' is already some other beast. It >>>> takes a pointer to some memory location where the string is stored. >>>> The JNI approach is to pass the Java string as is, and then do the >>>> wiring in native code. That is, there's no free lunch here - either >>>> you do the adaptation in Java, or you do it in native code (**). >>>> Panama gives you a rich enough API to do all such adaptations in >>>> Java, so that all native calls are... just native calls (again this >>>> means more regularity which means more performances). Having opaque >>>> native code snippets which do argument adaptation is not very >>>> optimal (and optimizable) for the JVM. With Panama you can create a >>>> good-looking API which internally uses pointers/scopes and delegates >>>> to the right native method - all done in Java. On top of that, our >>>> plans cover a so called 'civilization' layer (see [3]), by which >>>> users will be able to customize what comes out of jextract in order >>>> e.g. to tell that for 'puts' they really want a Java String argument >>>> and not a Pointer; again this will be done in a more general >>>> way, so that the binder will be pointed at a pair of functions which >>>> can be used to map the user provided data to and from native code. >>>> >>>> (**) for an example of how interfacing with standard libraries needs >>>> some kind of wrapping, even in JNI - look at [4]; this file is >>>> essentially a collection of system calls which are wrapped by some >>>> logic (e.g. to check errno, ...). I claim that there is something >>>> _fundamentally_ wrong with code like this, in that the native code >>>> is mixing two concerns: (i) performing the required native call and >>>> (ii) adjusting input/output/errors of the call in a way that is >>>> suitable to the corresponding Java API. Why shouldn't the Java API >>>> itself be in charge of doing (ii) ? >>>> >>>> Maurizio >>>> >>>> [1] - >>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-August/002560.html >>>> >>>> [2] - >>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002652.html >>>> [3] - >>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001537.html >>>> >>>> [4] - >>>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c#l314 >>>> On 24/09/18 13:34, Jorn Vernee wrote: >>>>> I agree with the usability point. In C++ it's as simple to call >>>>> puts as doing: >>>>> >>>>> ??? #include >>>>> >>>>> ??? int main() { >>>>> ??????? puts("Hello World!"); >>>>> ??? } >>>>> >>>>> And I think the optimal Java equivalent would be something like: >>>>> >>>>> ??? import static org.openjdk.stdio.*; >>>>> >>>>> ??? public class Main { >>>>> >>>>> ??????? public static void main(String[] args) { >>>>> ??????????? puts("Hello World!"); >>>>> ??????? } >>>>> >>>>> ??? } >>>>> >>>>> This can be facilitated by creating a 'singleton facade' for the >>>>> library interface like so: >>>>> >>>>> ??? public class stdio { >>>>> >>>>> ??????? private static final stdioImpl lib = >>>>> Libraries.bind(lookup(), stdioImpl.class); >>>>> >>>>> ??????? public static int puts (String message) { >>>>> ??????????? try(Scope scope = Scope.newNativeScope()) { >>>>> ??????????????? Pointer msg = scope.toCString(message); >>>>> ??????????????? return lib.puts(msg); >>>>> ??????????? } >>>>> ??????? } >>>>> >>>>> ??????? ... >>>>> ??? } >>>>> >>>>> Such a facade class could be shipped with the JDK or perhaps as an >>>>> artifact on maven central, or maybe it could be an additional >>>>> output of jextract. >>>>> >>>>> But there is only so much you can do automagically from the Java >>>>> side. When working from C/C++ you have the compiler filling in the >>>>> blanks. For instance, it automatically allocates storage for string >>>>> literals. Java does that as well for Java string literals `String s >>>>> = "Hello";`, but it can not do that for native strings, and you >>>>> have to use the Scope API to do that manually. In some cases, like >>>>> the above, you can write glue-code to make that automatic, but I >>>>> think at some point things become too complex for that, and there >>>>> will always be some usability barrier to interop. >>>>> >>>>> Jorn >>>>> >>>>> Samuel Audet schreef op 2018-09-24 13:38: >>>>>> FWIW, I think the factory method pattern should be reconsidered >>>>>> entirely. In C/C++, when we want to call say getpid(), we don't start >>>>>> loading stuff up before calling getpid(), we call getpid()! Why >>>>>> not do >>>>>> the same from Java? From a usability point of view, not loading stuff >>>>>> manually works fine for JavaCPP... >>>>>> >>>>>> Now, I know you're going to start taking about interfaces and what >>>>>> not. You said that you had plans to introduce an entirely new array >>>>>> type just to make it more friendly with vector instructions and >>>>>> native >>>>>> libraries. Why not start thinking about an "interface" that would be >>>>>> friendly to native libraries as well? Why stop at arrays? >>>>>> >>>>>> Samuel >>>>>> > From maurizio.cimadamore at oracle.com Wed Oct 3 09:19:22 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 3 Oct 2018 10:19:22 +0100 Subject: on usability In-Reply-To: <2dac614c-8927-14d6-3303-8760b8088b09@gmail.com> References: <138140e4ab654e59fa538b5438fdee9d@xs4all.nl> <71d58dfa-4bf2-382a-9449-e726f291b1e9@oracle.com> <3e25bf4a-1a75-357f-be72-fd36cbd3cf15@gmail.com> <1dde768f-2067-de80-2655-a881ae78c771@oracle.com> <39381ab4-f888-f7e9-3764-59b5dba1eca9@gmail.com> <2dac614c-8927-14d6-3303-8760b8088b09@gmail.com> Message-ID: On 03/10/18 04:57, Samuel Audet wrote: > After discussing offline with John and Maurizio, I'd like to make a > few additions to this thread. > > Although we need wrappers to make the interfaces more usable, those > wrappers can eventually be generated at runtime, just like lambda > expressions actually create classes dynamically. If we can make this > part of the plan, that sounds good. Then we'd just need to make it all > work to manage the native libraries, maybe using JavaCPP as reference > since I'm not aware of any other serious attempt at packaging native > libraries for multiple platforms. Yep - our current interface + annotations will eventually need to land on interface + annotation + code snippets which means we will need a story to package up the 'code' bits and load them accordingly (we are aware of the many limitations of System.loadXYZ which JavaCPP, among others, attempt to solve). > > As for the layout definition language, I've learned that the idea > comes from similar features found on other platforms such as Python's > struct module, which does get used by most popular serialization > methods out there (Protocol Buffers, FlatBuffers, Avro, etc): > ????https://docs.python.org/2/library/struct.html Few months ago I also put together a writeup which investigates the use cases of message protocols and their descriptions: http://mail.openjdk.java.net/pipermail/panama-dev/2018-February/000940.html Some of the stuff in there actively influenced the design - for instance, one might wonder as to why an 'address' in a Panama layout has an explicit size - and the reason is that we want to accommodate not just machine pointers, but also the near/far pointers encoding typically found in protocol schemas. > > But I still think it's an overly complicated way of representing a > "struct"... Couldn't we just list the member variables with methods or > properties that access memory directly as with Swift or Substrate VM? > Maybe that could even be part of the value types from Valhalla? We > could then leave the layouts out of the interfaces for native code. > What do you think John? > > As for C++ templates, we could have say std::map MyObject>. How could we map this with Panama layouts without any calls > to native functions? It's basically just data, but the structure's > definition is implementation dependent. Could be red-black trees, a > hash table, an entirely custom method, etc, so it's not something that > I think we can support with Panama layouts without actually executing > the C++ bits. To follow your example, yes, we could model the layout of a std::map (after all, this is a class which has some fields) but we must also note that the 'size' of some of these fields is data-dependent, which is not a problem dissimilar from what we find in message protocol - see variable encoding used e.g. by protobuf for varints. I call these 'dependent' layouts - e.g. where the _value_ of some field gives away the size of a subsequent field. Below is one of the most common forms of dependent layouts found in C/C++: int nelems; int arr[] To know how big 'arr' is, you have to look 'nelems' up (this pattern is in fact so common that C even attempted to capture it in its variable-length-array feature - VLA). The layout assumes that these two properties are entangled. If we sprinkle layouts with annotations which make this dependency manifest, then the binder can act on this and could interpret a layout looking up sizes in the dependent fields. Of course there are well-formedness rules at play here: the dependency must always go 'backwards' (although this is common in real code), otherwise the binder wouldn't know at which 'offset' to find the relevant info. (digression: in reality a typical hashmap implementation is not _that_ data dependent - typically a map is implemented as an array of buckets which is resized dynamically - so the map object will typically store a _pointer_ to such array - that is, the _shallow_ size of a map object is _fixed_ and can therefore be represented with the layout descriptions we have today) Your hashmap example is really the above example, but on steroids - not only you have variability because of sizes (e.g. how many buckets does the map have?) - but it is also variable in a _type_ (e.g. std::string/MyObject in your example). The layout descriptions allow for 'holes' that can be dynamically filled, and I think using something like this will be the key to solve both problems, although I can imagine that, when it comes to C++ template, capturing a template class with a single layout might be challenging, since changing the type might also insert/remove additional padding, depending on where the element to be replaced is. And then there's an even deeper question:? layout descriptions are a fine (albeit too complicated, for your tastes :-)) way to describe pure, transparent, data aggregates. But when you move on to deal with OO languages (such as C++), a layout of an object typically doesn't tell the full story. You still need to call a method of that class to perform a lookup and pull values out of the map - as the way that's done (and the layout is used) is, ultimately, implementation specific (after all, this is the concept known as _encapsulation_). That is, transparent data can be extracted efficiently using layouts - but data that is encapsulated behind object APIs need to be accessed using such APIs. In which case the layout is mostly a way to make sense of the structure of a C++ object, its size, etc. which is useful information when you need to allocate memory and/or dereference pointers. So, to sum up - even if we had an uber precise layout description for your map, our goal would NOT be to extract pieces of data (keys, values) using the layout. Doing so would be similar to attempting to extract the contents of a Java HashMap using Unsafe.getInt. You *could* do it (assuming you knew all the details about the object impl you are operating upon), but that would be totally unsafe and ultimately not what layouts are for. That said, you still need a way to define what is the 'basic' structure of such an hashmp (e.g. it could have an int for the size, a pointer to a list of buckets...) - so that you know how many byte must be allocated for one of these (empty) things, how much to offset a pointer to one of this things, ... - and _that's_ what layouts are used for. > In any case, what I'm most interested in is the performance. JNI is > already pretty fast, and tools such as JNR or JavaCPP have shown that > it's possible to make it user friendly enough without any additional > overhead. (Although given the popularity of JNA that's not something > people typically care about all that much). Anyway, I'll be waiting > for a version of "linkToNative" that we can start testing, try to > modify JavaCPP to target the new API and classes, although I'm > starting to get the feeling that the leap isn't going to be big enough > for people to want to make the switch. After all, everyone will have > to be supporting old versions of the JDK and Android for years to come... The definition of 'fast enough' depends wildly on the use case at hand. If you are invoking a single native method which is gonna sit there for hours doing complex computation., then the JNI overhead is irrelevant, no arguments about that. If you call functions whose implementation is more trivial then the JNI overhead pops up. That's what you see in the benchmark I shared few weeks ago. But there's a related point to make here: if native code and Java code live in separate silos, then it is relatively natural for people to be mindful of 'crossing' the JNI bridge, and try and come up with ways to limit the number of times they do that (e.g. by aggregating computation on the native side). But once we start lowering the barrier between Java and native, as Panama and JavaCPP (and other solutions) do, you quickly run into troubles; consider a very simple loop: for (...) { ?? doSomething() } If the method in the loop body is 100% Java, then you know that your code will take advantage of several JIT optimizations (inlining, loop unrolling, etc.). But say you now replace your loop body with a call to another method, which is defined in terms of native code; suddenly the JNI overhead pops up, as the JIT is no longer able to optimize your code as well as it did before. However, if the JIT knew that this were 'just a simple native call, no strings attached, no oops to worry about', then it would be possible to model the native call within the JIT itself, which leads you to a world where native code and jitted code cohexist and mutually benefit from each other. In other words, as the interaction between Java and native code becomes more complex (which is likely if we make it easy for people to 'switch' to native), you'll start finding issues that might not be fully manifest right now (unless you work in certain domains). As an example of that, few months ago we have done an internal port of the clang API using Panama (which is now committed as a Panama test) and found that the performances of both JNI and Panama code are completely dominated by the cost of making an upcall from native to Java - that's because clang is a compiler and compilers like visitors - and a visitor is, well, at its most fundamental core, a callback (in this case into Java code). So in the clang case you have a single native call (e.g. clang_visitChildren') which is making hundreds, thousands of upcalls into a Java visitor method. That's a real case and is ultimately how jextract works. So, reducing JNI overhead, and improving integration between native code and JIT in those cases could make a huge difference. Maurizio > > Samuel > > > On 10/01/2018 02:29 PM, Samuel Audet wrote: >> Hi, Jorn, Maurizio, >> >> I'm not talking about syntactic sugar, I'm fine with Java requiring >> getters/setters and having an init() call somewhere. What I'm not OK >> with is, just to call a native function, we have to call something >> like Libraries.bind() every single time with the name of the class >> and the path to the library, or save it somewhere in a field, and >> then what do we do with it? How do we manage it across classes and >> modules? Why can't the framework do that automatically for us? >> >> This is just one example of the usability problems that Panama isn't >> solving over JNI, that yes Swift or GraalVM is solving, not with >> wrappers, but at compile time as Maurizio points out. Panama could do >> the same with an init() function if it decided not to go with vanilla >> interfaces since the factory method pattern prevents this: You'll >> need wrappers. >> >> Another usability problem is code that is hard to read, like for the >> layouts, yes, which are neither easy to read nor write, I'm glad >> Maurizio agrees, but there are no proposal to fix this because we're >> committed to this approach as it's supposed to make things more >> general... but they still won't work for C++ templates or >> computational graphs! So, maybe everyone will want to use Truffle >> anyway? >> >> BTW, Swift does support offsetof(), here's the proposal status: >> https://github.com/apple/swift-evolution/blob/master/proposals/0210-key-path-offset.md >> >> "Status: Implemented (Swift 4.2)": Open source at work! >> >> BTW2, the example from GraalVM that I gave isn't from Truffle, it's >> from the "Substrate VM" codebase: It's completely unrelated. >> >> JNI is already very capable. As Maurizio points out in his reply, the >> whole point of Panama is not to improve the capabilities of JNI, it's >> to improve the *usability* and the *performance*, but after over 4 >> years of work, I still do not see how it will be able to fulfill >> either goals! Let's maybe work on "linkToNative" and get this shipped >> already to let others work on things like jextract? That might be >> worth it, but it's not happening. Priorities are elsewhere, although >> it's not clear to me where exactly. >> >> You see, in my opinion, the problem with Panama vs others like >> GraalVM, LLVM, or Swift is that the link with the community is >> missing. Decisions are made purely on an internal basis with no >> communication with the outside. If you Jorn like where Panama is >> going on a technical basis, that's great, but I'm not, and probably >> others are not either, but there is no forum to have a discussion >> about this. >> >> In any case, the Java community is a bit wider than OpenJDK, so maybe >> one day Truffle will get integrated into the JDK before Panama gets >> anywhere, or Substrate VM will "replace" HotSpot, since AOT is pretty >> much required for platforms like iOS, Google might become interested >> in using it for Android too, and everyone's already bundling the JRE >> with their desktop apps these days anyway. >> >> Samuel >> >> On 09/26/2018 06:39 PM, Jorn Vernee wrote: >>> The Swift example looks cool and I can say 2 things about that: >>> >>> 1.) Swift seems to have properties (i.e. syntactic sugar for getters >>> and setter), so It's much easier to inject some code that accesses >>> an underlying C struct instead of a backing field. I think at least >>> for the time being, the Java equivalent would be getters and >>> setters. But tbh I don't see that much usability problems with that, >>> since it's more or less the same amount of characters to write: >>> `myStruct.x = 10` vs. `myStruct.x$set(10)` (especially considering >>> auto-completion). It just doesn't look as fancy. >>> >>> 2.) I guess jextract could generate an equivalent of the 2 `Init()` >>> functions as well for generated structs, and that would be part of >>> the 'civilisation layer' Maurizio mentioned. With current tech, it >>> would probably either create and leak a scope internally, or you'd >>> have to pass a scope. Maybe a long term solution could be something >>> like using a default scope that is managed by the garbage collector. >>> The generated struct would not have a tight life-cycle (GC lazily >>> collects objects), but it would be easier to use. >>> >>> The Graal native access stuff uses truffle, i.e. it is baked into >>> the interpreter. But the truffle interpreter is built to be very >>> customizeable, so I think doing the same with the Hotspot >>> interpreter would be far more difficult. But either way, the way >>> Graal maps a C struct to an interface in that example looks pretty >>> similar to what panama is doing to me. >>> >>> I think panama is making sane choices, and focusing on capability >>> before usability. panama is just not as far along as the other >>> projects you mention, and I think more usability (jextract >>> civilization layer) and better performance (linkToNative backend) >>> are yet to come. >>> >>> Jorn >>> >>> Samuel Audet schreef op 2018-09-26 03:14: >>>> We can do a lot of wrapper magic in either Java or C++. JavaCPP >>>> already does for JNI what Jorn is describing we could do for Panama: >>>> https://github.com/bytedeco/javacpp-presets/tree/master/systems#the-srcmainjavatestavxjava-source-file >>>> >>>> >>>> If we consider JNI to be "legacy", it makes a lot of sense to try and >>>> do some acrobatics like that to support legacy systems, but why not >>>> make the new hotness actually _usable_? Take a look at how Swift does >>>> it: >>>> https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift >>>> >>>> >>>> Now that's what I call *usable*. Panama is very far from that level of >>>> usability. And it's not because the Java language is somehow >>>> handicapped. Check what the guys over at GraalVM are doing: >>>> https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.tutorial/src/com/oracle/svm/tutorial/CInterfaceTutorial.java >>>> >>>> >>>> It also features performance that's already apparently higher than >>>> JNI: >>>> https://cornerwings.github.io/2018/07/graal-native-methods/ >>>> >>>> Why not do something user friendly like that in Panama's case as well? >>>> What's the rationale to make it all in the end as complicated to use >>>> as JNI? Maybe there's something I'm missing, so please point it out. >>>> >>>> Samuel >>>> >>>> >>>> On 09/24/2018 10:37 PM, Maurizio Cimadamore wrote: >>>>> Having a pre-extracted stdlib bundle is something we have >>>>> considered - quoting from [1]: >>>>> >>>>> "Now, since most (all?) of the libraries out there are going to >>>>> assume >>>>> the availability of some 'standard library', let's also assume >>>>> that some >>>>> extracted artifact for such library is available and that jextract >>>>> always knows how to find it - this is the equivalent of java.base for >>>>> the module system, or java.lang for the Java import system. This >>>>> addresses the bootstrapping issue." >>>>> >>>>> In time we'll get there, I don't see any real technical obstacles >>>>> to get to your 'optimal' snippet. >>>>> >>>>> I think there are two aspects that I'd like to draw attention upon: >>>>> >>>>> 1) Magic does not come for free. E.g. it might "seem" that JNI has >>>>> a more direct approach to calling native methods (ease of use >>>>> issues aside). In reality it's just that the complexity of calling >>>>> that native method, marshalling arguments, unmarshalling returns, >>>>> dealing with native thread transitions and what's not has just >>>>> been pushed under the JVM rug. So, yes, you can "just" call getpid >>>>> - but the burden is on the VM. Now, the JNI support is already >>>>> quite complex - I can't honestly imagine a sane way for the VM to >>>>> support any given invocation scheme that a user might wish to see >>>>> supported. This is why Panama is betting on Java code + layouts to >>>>> do the lifting: that way the VM interface can be kept simple >>>>> (which has significant payoffs - as the resulting code can be >>>>> optimized much more - see the linkToNative experimental results in >>>>> [2]). >>>>> >>>>> 2) As your example points out, while calling 'getpid' is something >>>>> that seems 'easy' enough - 'puts' is already some other beast. It >>>>> takes a pointer to some memory location where the string is >>>>> stored. The JNI approach is to pass the Java string as is, and >>>>> then do the wiring in native code. That is, there's no free lunch >>>>> here - either you do the adaptation in Java, or you do it in >>>>> native code (**). Panama gives you a rich enough API to do all >>>>> such adaptations in Java, so that all native calls are... just >>>>> native calls (again this means more regularity which means more >>>>> performances). Having opaque native code snippets which do >>>>> argument adaptation is not very optimal (and optimizable) for the >>>>> JVM. With Panama you can create a good-looking API which >>>>> internally uses pointers/scopes and delegates to the right native >>>>> method - all done in Java. On top of that, our plans cover a so >>>>> called 'civilization' layer (see [3]), by which users will be able >>>>> to customize what comes out of jextract in order e.g. to tell that >>>>> for 'puts' they really want a Java String argument and not a >>>>> Pointer; again this will be done in a more general way, so >>>>> that the binder will be pointed at a pair of functions which can >>>>> be used to map the user provided data to and from native code. >>>>> >>>>> (**) for an example of how interfacing with standard libraries >>>>> needs some kind of wrapping, even in JNI - look at [4]; this file >>>>> is essentially a collection of system calls which are wrapped by >>>>> some logic (e.g. to check errno, ...). I claim that there is >>>>> something _fundamentally_ wrong with code like this, in that the >>>>> native code is mixing two concerns: (i) performing the required >>>>> native call and (ii) adjusting input/output/errors of the call in >>>>> a way that is suitable to the corresponding Java API. Why >>>>> shouldn't the Java API itself be in charge of doing (ii) ? >>>>> >>>>> Maurizio >>>>> >>>>> [1] - >>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-August/002560.html >>>>> >>>>> [2] - >>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002652.html >>>>> [3] - >>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001537.html >>>>> >>>>> [4] - >>>>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c#l314 >>>>> On 24/09/18 13:34, Jorn Vernee wrote: >>>>>> I agree with the usability point. In C++ it's as simple to call >>>>>> puts as doing: >>>>>> >>>>>> ??? #include >>>>>> >>>>>> ??? int main() { >>>>>> ??????? puts("Hello World!"); >>>>>> ??? } >>>>>> >>>>>> And I think the optimal Java equivalent would be something like: >>>>>> >>>>>> ??? import static org.openjdk.stdio.*; >>>>>> >>>>>> ??? public class Main { >>>>>> >>>>>> ??????? public static void main(String[] args) { >>>>>> ??????????? puts("Hello World!"); >>>>>> ??????? } >>>>>> >>>>>> ??? } >>>>>> >>>>>> This can be facilitated by creating a 'singleton facade' for the >>>>>> library interface like so: >>>>>> >>>>>> ??? public class stdio { >>>>>> >>>>>> ??????? private static final stdioImpl lib = >>>>>> Libraries.bind(lookup(), stdioImpl.class); >>>>>> >>>>>> ??????? public static int puts (String message) { >>>>>> ??????????? try(Scope scope = Scope.newNativeScope()) { >>>>>> ??????????????? Pointer msg = scope.toCString(message); >>>>>> ??????????????? return lib.puts(msg); >>>>>> ??????????? } >>>>>> ??????? } >>>>>> >>>>>> ??????? ... >>>>>> ??? } >>>>>> >>>>>> Such a facade class could be shipped with the JDK or perhaps as >>>>>> an artifact on maven central, or maybe it could be an additional >>>>>> output of jextract. >>>>>> >>>>>> But there is only so much you can do automagically from the Java >>>>>> side. When working from C/C++ you have the compiler filling in >>>>>> the blanks. For instance, it automatically allocates storage for >>>>>> string literals. Java does that as well for Java string literals >>>>>> `String s = "Hello";`, but it can not do that for native strings, >>>>>> and you have to use the Scope API to do that manually. In some >>>>>> cases, like the above, you can write glue-code to make that >>>>>> automatic, but I think at some point things become too complex >>>>>> for that, and there will always be some usability barrier to >>>>>> interop. >>>>>> >>>>>> Jorn >>>>>> >>>>>> Samuel Audet schreef op 2018-09-24 13:38: >>>>>>> FWIW, I think the factory method pattern should be reconsidered >>>>>>> entirely. In C/C++, when we want to call say getpid(), we don't >>>>>>> start >>>>>>> loading stuff up before calling getpid(), we call getpid()! Why >>>>>>> not do >>>>>>> the same from Java? From a usability point of view, not loading >>>>>>> stuff >>>>>>> manually works fine for JavaCPP... >>>>>>> >>>>>>> Now, I know you're going to start taking about interfaces and what >>>>>>> not. You said that you had plans to introduce an entirely new array >>>>>>> type just to make it more friendly with vector instructions and >>>>>>> native >>>>>>> libraries. Why not start thinking about an "interface" that >>>>>>> would be >>>>>>> friendly to native libraries as well? Why stop at arrays? >>>>>>> >>>>>>> Samuel >>>>>>> >> > From maurizio.cimadamore at oracle.com Wed Oct 3 09:22:00 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 3 Oct 2018 10:22:00 +0100 Subject: [vectorInstrinsics] merge with upstream failed In-Reply-To: <3b04dbc0-552d-8aa3-5d36-ec70bd0ad89b@oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EF14D79@FMSMSX126.amr.corp.intel.com> <3b04dbc0-552d-8aa3-5d36-ec70bd0ad89b@oracle.com> Message-ID: <1fef2eef-70a0-15a5-7851-7589c6864ed9@oracle.com> Hi, not sure if it's related but we have started to see failures in our internal builds: * For target jdk_modules_jdk.incubator.vector__the.jdk.incubator.vector_batch: /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java:39: error: Byte128Vector is not abstract and does not override abstract method aShiftR(int) in ByteVector final class Byte128Vector extends ByteVector { ^ /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java:39: error: Byte256Vector is not abstract and does not override abstract method aShiftR(int) in ByteVector final class Byte256Vector extends ByteVector { ^ /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java:39: error: Byte512Vector is not abstract and does not override abstract method aShiftR(int) in ByteVector final class Byte512Vector extends ByteVector { ^ /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java:39: error: Byte64Vector is not abstract and does not override abstract method aShiftR(int) in ByteVector final class Byte64Vector extends ByteVector { ^ ... (rest of output omitted) * All command lines available in /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/build/linux-x86_64-server-release/make-support/failure-logs. === End of repeated output === === Make failed targets repeated here === CompileJavaModules.gmk:594: recipe for target '/scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/build/linux-x86_64-server-release/jdk/modules/jdk.incubator.vector/_the.jdk.incubator.vector_batch' failed make/Main.gmk:199: recipe for target 'jdk.incubator.vector-java' failed Is this a known issue? Maurizio On 02/10/18 17:55, Maurizio Cimadamore wrote: > > > On 02/10/18 17:50, Viswanathan, Sandhya wrote: >> Thanks Maurizio for bringing our attention to this. FYI, we completed >> the manual merge yesterday. > Thanks, I noted that our internal build systems went back to green! > > Cheers > Maurizio >> >> Best Regards, >> Sandhya >> >> >> -----Original Message----- >> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On >> Behalf Of Maurizio Cimadamore >> Sent: Monday, October 01, 2018 6:26 AM >> To: 'panama-dev at openjdk.java.net' >> Subject: [vectorInstrinsics] merge with upstream failed >> >> Hi, >> the vectorIntrinsics branch failed to merge because of the following >> conflicts: >> >> U src/hotspot/cpu/x86/assembler_x86.cpp >> U src/hotspot/cpu/x86/macroAssembler_x86.cpp >> U src/hotspot/cpu/x86/vm_version_x86.hpp >> U src/hotspot/cpu/x86/x86.ad >> >> I tried to take a look but the changes look a bit too deep for me to >> handle the merge. Could please somebody from the vector team look at the >> conflicts? >> >> To start a merge: >> >> $ hg update vectorIntrinsics >> >> $ hg merge -r default >> >> >> >> $ hg commit -m 'manual merge with default' >> >> $ hg push >> >> Cheers >> Maurizio >> > From sandhya.viswanathan at intel.com Wed Oct 3 14:52:02 2018 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 3 Oct 2018 14:52:02 +0000 Subject: [vectorInstrinsics] merge with upstream failed In-Reply-To: <1fef2eef-70a0-15a5-7851-7589c6864ed9@oracle.com> References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EF14D79@FMSMSX126.amr.corp.intel.com> <3b04dbc0-552d-8aa3-5d36-ec70bd0ad89b@oracle.com> <1fef2eef-70a0-15a5-7851-7589c6864ed9@oracle.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B9EF154BB@FMSMSX126.amr.corp.intel.com> Hi Maurizio, Builds after manual merge was ok. This could be due to the last change-set: http://hg.openjdk.java.net/panama/dev/rev/9d5b8130187b We will take a look. Best Regards, Sandhya From: Maurizio Cimadamore [mailto:maurizio.cimadamore at oracle.com] Sent: Wednesday, October 03, 2018 2:22 AM To: Viswanathan, Sandhya ; 'panama-dev at openjdk.java.net' Subject: Re: [vectorInstrinsics] merge with upstream failed Hi, not sure if it's related but we have started to see failures in our internal builds: * For target jdk_modules_jdk.incubator.vector__the.jdk.incubator.vector_batch: /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java:39: error: Byte128Vector is not abstract and does not override abstract method aShiftR(int) in ByteVector final class Byte128Vector extends ByteVector { ^ /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java:39: error: Byte256Vector is not abstract and does not override abstract method aShiftR(int) in ByteVector final class Byte256Vector extends ByteVector { ^ /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java:39: error: Byte512Vector is not abstract and does not override abstract method aShiftR(int) in ByteVector final class Byte512Vector extends ByteVector { ^ /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java:39: error: Byte64Vector is not abstract and does not override abstract method aShiftR(int) in ByteVector final class Byte64Vector extends ByteVector { ^ ... (rest of output omitted) * All command lines available in /scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/build/linux-x86_64-server-release/make-support/failure-logs. === End of repeated output === === Make failed targets repeated here === CompileJavaModules.gmk:594: recipe for target '/scratch/langtools/workspace/workspace/panama-test/panama-branches/panama-vectorIntrinsics/panama/build/linux-x86_64-server-release/jdk/modules/jdk.incubator.vector/_the.jdk.incubator.vector_batch' failed make/Main.gmk:199: recipe for target 'jdk.incubator.vector-java' failed Is this a known issue? Maurizio On 02/10/18 17:55, Maurizio Cimadamore wrote: On 02/10/18 17:50, Viswanathan, Sandhya wrote: Thanks Maurizio for bringing our attention to this. FYI, we completed the manual merge yesterday. Thanks, I noted that our internal build systems went back to green! Cheers Maurizio Best Regards, Sandhya -----Original Message----- From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Maurizio Cimadamore Sent: Monday, October 01, 2018 6:26 AM To: 'panama-dev at openjdk.java.net' Subject: [vectorInstrinsics] merge with upstream failed Hi, the vectorIntrinsics branch failed to merge because of the following conflicts: U src/hotspot/cpu/x86/assembler_x86.cpp U src/hotspot/cpu/x86/macroAssembler_x86.cpp U src/hotspot/cpu/x86/vm_version_x86.hpp U src/hotspot/cpu/x86/x86.ad I tried to take a look but the changes look a bit too deep for me to handle the merge. Could please somebody from the vector team look at the conflicts? To start a merge: $ hg update vectorIntrinsics $ hg merge -r default $ hg commit -m 'manual merge with default' $ hg push Cheers Maurizio From maurizio.cimadamore at oracle.com Wed Oct 3 20:03:40 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 03 Oct 2018 20:03:40 +0000 Subject: hg: panama/dev: 120 new changesets Message-ID: <201810032003.w93K3n2j000987@aojmv0008.oracle.com> Changeset: 76a3e8be46e6 Author: epavlova Date: 2018-09-26 12:47 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/76a3e8be46e6 8199885: [Graal] org.graalvm.compiler.core.test.CountedLoopTest fails with "ControlFlowAnchor should never be cloned in the same graph" Reviewed-by: kvn ! test/hotspot/jtreg/ProblemList-graal.txt ! test/hotspot/jtreg/compiler/graalunit/CoreTest.java ! test/hotspot/jtreg/compiler/graalunit/TestPackages.txt Changeset: 4147b929ea72 Author: jjg Date: 2018-09-26 14:54 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/4147b929ea72 8211180: SourceLauncherTest.java fails in JDK12 CI on Win* Reviewed-by: mchung, darcy ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: 9d9ab30af97d Author: jjg Date: 2018-09-26 15:14 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9d9ab30af97d 8210555: create --source --target synonyms for -source -target Reviewed-by: hannesw ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Start.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolOption.java ! test/langtools/jdk/javadoc/tool/api/basic/IsSupportedOptionTest.java ! test/langtools/jdk/javadoc/tool/sourceOption/SourceOption.java ! test/langtools/tools/javac/options/IsSupportedOptionTest.java - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java ! test/langtools/tools/javadoc/sourceOption/SourceOption.java Changeset: 904c4e07cc22 Author: jjg Date: 2018-09-26 16:23 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/904c4e07cc22 8209963: source file mode for JVM should provide a hook to locate the source file Reviewed-by: darcy ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: c2b02e3af8ed Author: jwilhelm Date: 2018-09-27 01:25 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c2b02e3af8ed Added tag jdk-12+13 for changeset 511a9946f83e ! .hgtags Changeset: 1e7353bd1499 Author: ccheung Date: 2018-09-26 18:21 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1e7353bd1499 8202282: [TESTBUG] appcds TestCommon.makeCommandLineForAppCDS() can be removed Summary: removed the unnecessary makeCommandLineForAppCDS() method and its usage Reviewed-by: iklam, jiangli ! test/hotspot/jtreg/runtime/appcds/GraalWithLimitedMetaspace.java ! test/hotspot/jtreg/runtime/appcds/TestCommon.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java Changeset: 707e4291f685 Author: pmuthuswamy Date: 2018-09-27 10:10 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/707e4291f685 8202628: javadoc generates bad links in TestModules.java Reviewed-by: jjg ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java Changeset: e9d38b28380e Author: mdoerr Date: 2018-09-27 09:29 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/e9d38b28380e 8211097: aix: fix build after JDK-8210919 Reviewed-by: shade, mbaesken, erikj ! make/lib/CoreLibraries.gmk Changeset: eb3e72f181af Author: jlahoda Date: 2018-09-27 10:24 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/eb3e72f181af 8211102: Crash with -XDfind=lambda and -source 7 Summary: Disabling analyzers that cannot run in the given source level; lambdas in standalone positions should have erroneous type rather than the recovery type; avoiding crash in Flow for broken code. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/analyzer/AnalyzersCheckSourceLevel.java + test/langtools/tools/javac/analyzer/AnalyzersCheckSourceLevel.out + test/langtools/tools/javac/analyzer/T8211102.java + test/langtools/tools/javac/lambda/LambdaNoFuncIntfFlow.java + test/langtools/tools/javac/lambda/LambdaNoFuncIntfFlow.out + test/langtools/tools/javac/lambda/NoTargetLambda.java + test/langtools/tools/javac/lambda/NoTargetLambda.out Changeset: 293c2728644c Author: kevinw Date: 2018-09-26 06:28 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/293c2728644c 8211124: HotSpot update for vm_version.cpp to recognise updated VS2017 Reviewed-by: dholmes, lfoltan ! src/hotspot/share/runtime/vm_version.cpp Changeset: 11fd6c8188d9 Author: erikj Date: 2018-09-27 08:49 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/11fd6c8188d9 8211130: Change to Oracle Developer Studio 12.6 for building on Solaris at Oracle Reviewed-by: tbell, prr, ihse ! make/conf/jib-profiles.js ! make/devkit/createSolarisDevkit12.6.sh Changeset: 760ca4ba79ce Author: gadams Date: 2018-09-27 07:33 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/760ca4ba79ce 8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" Reviewed-by: cjplummer, jcbeyler ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/hs203t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/hs203t003.java Changeset: 3f5a55b6bad8 Author: psadhukhan Date: 2018-07-25 15:36 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/3f5a55b6bad8 8205535: Useless (or buggy) call to Math.round on int input Reviewed-by: jdv ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java Changeset: 36bc2044b15c Author: psadhukhan Date: 2018-08-01 11:02 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/36bc2044b15c 8203904: javax/swing/JSplitPane/4816114/bug4816114.java: The divider location is wrong Reviewed-by: serb, kaddepalli ! test/jdk/javax/swing/JSplitPane/4816114/bug4816114.java Changeset: f91e995f6d5c Author: prr Date: 2018-08-03 12:52 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f91e995f6d5c Merge - test/hotspot/gtest/utilities/utilitiesHelper.inline.hpp - test/hotspot/jtreg/applications/jcstress/acqrel/Test.java - test/hotspot/jtreg/applications/jcstress/atomicity/Test.java - test/hotspot/jtreg/applications/jcstress/copy/Test.java - test/hotspot/jtreg/applications/jcstress/fences/Test.java - test/hotspot/jtreg/applications/jcstress/memeffects/Test.java - test/hotspot/jtreg/applications/jcstress/other/Test.java - test/hotspot/jtreg/applications/jcstress/seqcst.sync/Test.java - test/hotspot/jtreg/applications/jcstress/seqcst.volatiles/Test.java - test/langtools/tools/javac/file/zip/8003512/LoadClassFromJava6CreatedJarTest.java - test/langtools/tools/javac/processing/environment/round/AnnotatedElementInfo.java Changeset: 5ade5b3a227e Author: serb Date: 2018-08-08 18:31 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/5ade5b3a227e 8208996: X11 icon window color handing bug Reviewed-by: serb Contributed-by: takiguc at linux.vnet.ibm.com ! src/java.desktop/unix/classes/sun/awt/X11/XIconWindow.java Changeset: cd7d2f9154fd Author: psadhukhan Date: 2018-08-09 11:01 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/cd7d2f9154fd 8204963: javax.swing.border.TitledBorder has a memory leak Reviewed-by: serb, kaddepalli ! src/java.desktop/share/classes/javax/swing/border/TitledBorder.java + test/jdk/javax/swing/border/TestTitledBorderLeak.java Changeset: a2f64e4e75ca Author: psadhukhan Date: 2018-08-10 12:36 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/a2f64e4e75ca 8209343: Test javax/swing/border/TestTitledBorderLeak.java should be marked as headful Reviewed-by: jdv ! test/jdk/javax/swing/border/TestTitledBorderLeak.java Changeset: 6f08e6011e7e Author: prr Date: 2018-08-14 12:11 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/6f08e6011e7e Merge - src/hotspot/share/gc/g1/g1SATBMarkQueueFilter.cpp - src/hotspot/share/gc/g1/g1SATBMarkQueueFilter.hpp - src/hotspot/share/runtime/simpleThresholdPolicy.cpp - src/hotspot/share/runtime/simpleThresholdPolicy.hpp - src/hotspot/share/runtime/simpleThresholdPolicy.inline.hpp - test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/share/transform/v2/MHSamTF.java - test/jdk/com/sun/jdi/ArrayLengthDumpTest.sh - test/jdk/com/sun/jdi/BreakpointWithFullGC.sh Changeset: 3ba3d39b91c7 Author: psadhukhan Date: 2018-08-16 11:15 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/3ba3d39b91c7 8202702: Clearing selection on JTable causes disappearance of a row Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java + test/jdk/javax/swing/JTable/TestClearSel.java Changeset: 8f12ff1c0555 Author: dmarkov Date: 2018-08-16 19:20 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/8f12ff1c0555 8130655: OS X: keyboard input in textfield is not possible if the window contained textfield is owned by EmbeddedFrame Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m + test/jdk/java/awt/Window/WindowOwnedByEmbeddedFrameTest/WindowOwnedByEmbeddedFrameTest.java Changeset: 4b492ccc0b71 Author: dmarkov Date: 2018-08-17 09:31 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/4b492ccc0b71 8205479: OS X: requestFocus() does not work properly for embedded frame Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java Changeset: 57fa2c1c98d4 Author: serb Date: 2018-08-23 23:12 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/57fa2c1c98d4 8209340: The code which avoids synthetic accessors has become outdated Reviewed-by: psadhukhan, kaddepalli ! src/java.desktop/macosx/classes/sun/font/CStrike.java ! src/java.desktop/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java Changeset: 4b2c1e154664 Author: serb Date: 2018-08-24 16:29 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/4b2c1e154664 8039082: [TEST_BUG] Test java/awt/dnd/BadSerializationTest/BadSerializationTest.java fails Reviewed-by: prr ! test/jdk/ProblemList.txt - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin + test/jdk/java/awt/dnd/BadSerializationTest/BadSerializationTest.java + test/jdk/java/awt/dnd/BadSerializationTest/badAction + test/jdk/java/awt/dnd/BadSerializationTest/good + test/jdk/java/awt/dnd/BadSerializationTest/noEvents + test/jdk/java/awt/dnd/BadSerializationTest/nullComponent + test/jdk/java/awt/dnd/BadSerializationTest/nullDragSource + test/jdk/java/awt/dnd/BadSerializationTest/nullOrigin Changeset: 451ec22b1a46 Author: alitvinov Date: 2018-08-27 18:29 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/451ec22b1a46 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object Reviewed-by: prr, psadhukhan ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java + test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java Changeset: 0e67fa2953e8 Author: prr Date: 2018-08-27 10:54 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/0e67fa2953e8 Merge - src/hotspot/share/gc/g1/ptrQueue.cpp - src/hotspot/share/gc/g1/ptrQueue.hpp - src/hotspot/share/gc/g1/satbMarkQueue.cpp - src/hotspot/share/gc/g1/satbMarkQueue.hpp ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64InstructionAttr.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64VectorAssembler.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/IntrinsificationPredicate.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/hotspot/NotOnDebug.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/vector/AMD64VectorLIRInstruction.java - test/hotspot/jtreg/gc/g1/TestStringSymbolTableStats.java - test/hotspot/jtreg/runtime/appcds/cacheObject/RangeNotWithinHeap.java ! test/jdk/ProblemList.txt - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libfreebl3.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libnspr4.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libnss3.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libnssckbi.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libnssdbm3.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libnssutil3.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libplc4.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libplds4.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libsoftokn3.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libsqlite3.dylib - test/jdk/sun/security/pkcs11/nss/lib/macosx-x86_64/libssl3.dylib - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.chk - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nss3.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.chk - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plc4.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plc4.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plds4.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plds4.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.chk - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/freebl3.chk - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nspr4.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nspr4.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nss3.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.chk - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plc4.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plc4.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plds4.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plds4.lib - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/softokn3.chk - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll - test/jdk/sun/security/pkcs11/nss/lib/windows-i586/ssl3.lib Changeset: 1c184eb382e8 Author: alans Date: 2018-08-31 18:05 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1c184eb382e8 8146310: [macosx] com.apple.eawt.Application.setDefaultMenuBar does not initialize screen menu bar Reviewed-by: serb ! src/java.desktop/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m + test/jdk/java/awt/MenuBar/TestNoScreenMenuBar.java Changeset: 992d04fb3c7e Author: psadhukhan Date: 2018-09-05 15:56 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/992d04fb3c7e 8202013: JEditorPane shows large HTML unordered list bullets 8201925: JEditorPane unordered list bullets look pixelated Reviewed-by: prr, pbansal ! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java + test/jdk/javax/swing/JEditorPane/TestHTMLBulletsSizeAndAliasing.java Changeset: 109a94379f63 Author: prr Date: 2018-09-05 10:17 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/109a94379f63 Merge - make/idea/template/build.xml - make/langtools/intellij/ant.xml - make/langtools/intellij/codeStyleSettings.xml - make/langtools/intellij/compiler.xml - make/langtools/intellij/copyright/langtools.xml - make/langtools/intellij/copyright/profiles_settings.xml - make/langtools/intellij/inspectionProfiles/langtools.xml - make/langtools/intellij/inspectionProfiles/profiles_settings.xml - make/langtools/intellij/langtools.iml - make/langtools/intellij/misc.xml - make/langtools/intellij/modules.xml - make/langtools/intellij/runConfigurations/javac.xml - make/langtools/intellij/runConfigurations/javadoc.xml - make/langtools/intellij/runConfigurations/javap.xml - make/langtools/intellij/runConfigurations/jshell.xml - make/langtools/intellij/runConfigurations/sjavac.xml - make/langtools/intellij/src/idea/LangtoolsIdeaAntLogger.java - make/langtools/intellij/vcs.xml - make/langtools/intellij/workspace.xml - src/hotspot/share/utilities/errorReporter.cpp - src/hotspot/share/utilities/errorReporter.hpp - src/hotspot/share/utilities/globalDefinitions_sparcWorks.hpp - test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.c - test/hotspot/jtreg/vmTestbase/gc/gctests/mallocWithGC1/libmallocWithGC1.c - test/hotspot/jtreg/vmTestbase/gc/gctests/mallocWithGC2/libmallocWithGC2.c - test/hotspot/jtreg/vmTestbase/gc/gctests/mallocWithGC3/libmallocWithGC3.c - test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC01/libnativeGC01.c - test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC02/libnativeGC02.c - test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC03/libnativeGC03.c - test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/agent00.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/agent01.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/agent02.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/agent03.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/libVirtualMachine07agent00.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/libVirtualMachine07agent01.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/libVirtualMachine07agent02.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/libVirtualMachine07agent03.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine09/agent00.c - test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine09/libVirtualMachine09agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn004/libforceEarlyReturn004a.c - test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn005/libforceEarlyReturn005a.c - test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/libforceEarlyReturn002a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps001/addcaps001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps001/libaddcaps001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps002/addcaps002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps002/libaddcaps002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps003/addcaps003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps003/libaddcaps003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload001/agentonload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload001/libagentonload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload002/agentonload002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload002/libagentonload002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload003/agentonload003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload003/libagentonload003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnUnload/agentonunload001/agentonunload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnUnload/agentonunload001/libagentonunload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Allocate/alloc001/liballoc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/attach002Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/libattach002Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/attach002aAgent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/libattach002aAgent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach008/attach008Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach008/libattach008Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach009/attach009Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach009/libattach009Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach012/attach012Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach012/libattach012Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach014/attach014Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach014/libattach014Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent01.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Target.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/libattach015Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/libattach015Agent01.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/libattach015Target.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/libattach020Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/libattach021Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/libattach022Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach037/attach037Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach037/libattach037Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach038/attach038Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach038/libattach038Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach039/attach039Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach039/libattach039Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach040/attach040Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach040/libattach040Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach041/attach041Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach041/libattach041Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach042/attach042Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach042/libattach042Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent01.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent02.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent03.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/libattach045Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/libattach045Agent01.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/libattach045Agent02.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/libattach045Agent03.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach046/attach046Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach046/libattach046Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach050/attach050Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach050/libattach050Agent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/sharedAgents/libsimpleAgent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/sharedAgents/simpleAgent00.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/breakpoint001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/libbreakpoint001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk001/classfloadhk001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk001/libclassfloadhk001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk002/classfloadhk002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk002/libclassfloadhk002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk003/classfloadhk003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk003/libclassfloadhk003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk004/classfloadhk004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk004/libclassfloadhk004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk005/classfloadhk005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk005/libclassfloadhk005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk006/classfloadhk006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk006/libclassfloadhk006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk007/classfloadhk007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk007/libclassfloadhk007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk008/classfloadhk008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk008/libclassfloadhk008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk009/classfloadhk009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk009/libclassfloadhk009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassLoad/classload001/classload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassLoad/classload001/libclassload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassPrepare/classprep001/classprep001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassPrepare/classprep001/libclassprep001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk001/clrbrk001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk001/libclrbrk001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk002/clrbrk002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk002/libclrbrk002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk005/clrbrk005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk005/libclrbrk005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw001/clrfldw001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw001/libclrfldw001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw002/clrfldw002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw002/libclrfldw002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw001/clrfmodw001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw001/libclrfmodw001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw002/clrfmodw002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw002/libclrfmodw002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodLoad/compmethload001/compmethload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodLoad/compmethload001/libcompmethload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/compmethunload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/libcompmethunload001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon001/crrawmon001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon001/libcrrawmon001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon002/crrawmon002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon002/libcrrawmon002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DataDumpRequest/datadumpreq001/datadumpreq001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DataDumpRequest/datadumpreq001/libdatadumpreq001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Deallocate/dealloc001/dealloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Deallocate/dealloc001/libdealloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon001/drrawmon001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon001/libdrrawmon001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon003/drrawmon003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon003/libdrrawmon003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon004/drrawmon004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon004/libdrrawmon004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv001/disposeenv001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv001/libdisposeenv001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv002/disposeenv002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv002/libdisposeenv002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DynamicCodeGenerated/dyncodgen001/dyncodgen001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/DynamicCodeGenerated/dyncodgen001/libdyncodgen001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Exception/exception001/exception001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/Exception/exception001/libexception001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ExceptionCatch/excatch001/excatch001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ExceptionCatch/excatch001/libexcatch001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc001/fieldacc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc001/libfieldacc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc002/fieldacc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc002/libfieldacc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc003/fieldacc003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc003/libfieldacc003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc004/fieldacc004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc004/libfieldacc004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldModification/fieldmod001/fieldmod001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldModification/fieldmod001/libfieldmod001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldModification/fieldmod002/fieldmod002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldModification/fieldmod002/libfieldmod002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceEarlyReturn/ForceEarlyReturn001/libForceEarlyReturn001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc001/forcegc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc001/libforcegc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc002/forcegc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc002/libforcegc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FramePop/framepop001/framepop001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FramePop/framepop001/libframepop001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FramePop/framepop002/framepop002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/FramePop/framepop002/libframepop002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionFinish/gcfinish001/gcfinish001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionFinish/gcfinish001/libgcfinish001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart001/gcstart001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart001/libgcstart001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart002/gcstart002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart002/libgcstart002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GenerateEvents/genevents001/genevents001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GenerateEvents/genevents001/libgenevents001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/allthr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr001/liballthr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr002/allthr002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAllThreads/allthr002/liballthr002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetArgumentsSize/argsize001/argsize001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetArgumentsSize/argsize001/libargsize001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetArgumentsSize/argsize002/argsize002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetArgumentsSize/argsize002/libargsize002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAvailableProcessors/getavailproc001/getavailproc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAvailableProcessors/getavailproc001/libgetavailproc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes001/bytecodes001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes001/libbytecodes001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes002/bytecodes002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes002/libbytecodes002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes003/bytecodes003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes003/libbytecodes003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps001/getcaps001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps001/libgetcaps001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps002/getcaps002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps002/libgetcaps002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld005/getclfld005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld005/libgetclfld005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld006/getclfld006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld006/libgetclfld006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007/getclfld007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007/libgetclfld007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr001/getclsldr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr001/libgetclsldr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr002/getclsldr002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr002/libgetclsldr002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr003/getclsldr003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr003/libgetclsldr003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss001/clsldrclss001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss001/libclsldrclss001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/libclsldrclss002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd005/getclmthd005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd005/libgetclmthd005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd006/getclmthd006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd006/libgetclmthd006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd007/getclmthd007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd007/libgetclmthd007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf004/getclmdf004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf004/libgetclmdf004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf005/getclmdf005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf005/libgetclmdf005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf006/getclmdf006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf006/libgetclmdf006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf007/getclmdf007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf007/libgetclmdf007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig004/getclsig004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig004/libgetclsig004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig005/getclsig005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig005/libgetclsig005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig006/getclsig006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig006/libgetclsig006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat005/getclstat005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat005/libgetclstat005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat006/getclstat006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat006/libgetclstat006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat007/getclstat007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat007/libgetclstat007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentContendedMonitor/contmon001/contmon001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentContendedMonitor/contmon001/libcontmon001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentContendedMonitor/contmon002/contmon002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentContendedMonitor/contmon002/libcontmon002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentContendedMonitor/contmon003/contmon003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentContendedMonitor/contmon003/libcontmon003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/curthrcputime001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/libcurthrcputime001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTimerInfo/curthrtimerinfo001/curthrtimerinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTimerInfo/curthrtimerinfo001/libcurthrtimerinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnv/GetEnv001/GetEnv001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnv/GetEnv001/libGetEnv001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnvironmentLocalStorage/getenvstor001/getenvstor001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnvironmentLocalStorage/getenvstor001/libgetenvstor001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname001/geterrname001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname001/libgeterrname001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/geterrname002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/libgeterrname002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionEvents/extevents001/extevents001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionEvents/extevents001/libextevents001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionFunctions/extfuncs001/extfuncs001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionFunctions/extfuncs001/libextfuncs001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl001/getfldecl001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl001/libgetfldecl001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl002/getfldecl002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl002/libgetfldecl002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl004/getfldecl004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl004/libgetfldecl004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf003/getfldmdf003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf003/libgetfldmdf003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf004/getfldmdf004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf004/libgetfldmdf004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm003/getfldnm003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm003/libgetfldnm003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm004/getfldnm004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm004/libgetfldnm004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm005/getfldnm005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm005/libgetfldnm005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameCount/framecnt001/framecnt001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameCount/framecnt001/libframecnt001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameCount/framecnt002/framecnt002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameCount/framecnt002/libframecnt002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameCount/framecnt003/framecnt003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameCount/framecnt003/libframecnt003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameLocation/frameloc001/frameloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameLocation/frameloc001/libframeloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameLocation/frameloc002/frameloc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameLocation/frameloc002/libframeloc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameLocation/frameloc003/frameloc003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFrameLocation/frameloc003/libframeloc003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf005/getintrf005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf005/libgetintrf005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf006/getintrf006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf006/libgetintrf006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf007/getintrf007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf007/libgetintrf007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt001/getjlocfmt001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt001/libgetjlocfmt001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt002/getjlocfmt002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt002/libgetjlocfmt002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJNIFunctionTable/getjniftab001/getjniftab001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJNIFunctionTable/getjniftab001/libgetjniftab001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJNIFunctionTable/getjniftab002/getjniftab002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJNIFunctionTable/getjniftab002/libgetjniftab002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab001/liblinetab001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab001/linetab001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab002/liblinetab002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab002/linetab002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab003/liblinetab003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab003/linetab003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss001/libloadedclss001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss001/loadedclss001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss002/libloadedclss002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss002/loadedclss002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariable/getlocal001/getlocal001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariable/getlocal001/libgetlocal001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariable/getlocal002/getlocal002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariable/getlocal002/libgetlocal002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab001/liblocaltab001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab001/localtab001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab002/liblocaltab002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab002/localtab002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab003/liblocaltab003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab003/localtab003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab004/liblocaltab004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab004/localtab004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab005/liblocaltab005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab005/localtab005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMaxLocals/maxloc001/libmaxloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMaxLocals/maxloc001/maxloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMaxLocals/maxloc002/libmaxloc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMaxLocals/maxloc002/maxloc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls001/declcls001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls001/libdeclcls001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls002/declcls002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls002/libdeclcls002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls003/declcls003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls003/libdeclcls003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodLocation/methloc001/libmethloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodLocation/methloc001/methloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodLocation/methloc002/libmethloc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodLocation/methloc002/methloc002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/libmethmod001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/methmod001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod002/libmethmod002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod002/methmod002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname001/libmethname001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname001/methname001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname002/libmethname002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname002/methname002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname003/libmethname003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname003/methname003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectHashCode/objhashcode001/libobjhashcode001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectHashCode/objhashcode001/objhashcode001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/libobjmonusage001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage002/libobjmonusage002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage002/objmonusage002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/libobjmonusage003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/objmonusage003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004/libobjmonusage004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004/objmonusage004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage005/libobjmonusage005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage005/objmonusage005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/libobjmonusage006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/objmonusage006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectSize/objsize001/libobjsize001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectSize/objsize001/objsize001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectsWithTags/objwithtags001/libobjwithtags001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectsWithTags/objwithtags001/objwithtags001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf001/libownmoninf001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf001/ownmoninf001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf002/libownmoninf002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf002/ownmoninf002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf003/libownmoninf003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf003/ownmoninf003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase001/getphase001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase001/libgetphase001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase002/getphase002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase002/libgetphase002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPotentialCapabilities/getpotcaps001/getpotcaps001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPotentialCapabilities/getpotcaps001/libgetpotcaps001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex001/libsrcdebugex001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex001/srcdebugex001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex002/libsrcdebugex002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex002/srcdebugex002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex003/libsrcdebugex003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex003/srcdebugex003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn004/getsrcfn004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn004/libgetsrcfn004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn005/getsrcfn005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn005/libgetsrcfn005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn006/getsrcfn006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn006/libgetsrcfn006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr001/getstacktr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr001/libgetstacktr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr002/getstacktr002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr002/libgetstacktr002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr003/getstacktr003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr003/libgetstacktr003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr004/getstacktr004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr004/libgetstacktr004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr005/getstacktr005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr005/libgetstacktr005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr006/getstacktr006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr006/libgetstacktr006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr007/getstacktr007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr007/libgetstacktr007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr008/getstacktr008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr008/libgetstacktr008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr009/getstacktr009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr009/libgetstacktr009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops001/getsysprops001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops001/libgetsysprops001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops002/getsysprops002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops002/libgetsysprops002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop001/getsysprop001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop001/libgetsysprop001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop002/getsysprop002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop002/libgetsysprop002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTag/gettag001/gettag001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTag/gettag001/libgettag001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/libthrcputime001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/thrcputime001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/libthrcputime002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/thrcputime002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTimerInfo/thrtimerinfo001/libthrtimerinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTimerInfo/thrtimerinfo001/thrtimerinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/libgetthrdgrpchld001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupInfo/thrgrpinfo001/libthrgrpinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupInfo/thrgrpinfo001/thrgrpinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupInfo/thrgrpinfo002/libthrgrpinfo002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupInfo/thrgrpinfo002/thrgrpinfo002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/libthrinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/thrinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo002/libthrinfo002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo002/thrinfo002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadLocalStorage/getthrdstor001/getthrdstor001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadLocalStorage/getthrdstor001/libgetthrdstor001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat001/libthrstat001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat001/thrstat001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat002/libthrstat002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat002/thrstat002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat003/libthrstat003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat003/thrstat003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat004/libthrstat004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat004/thrstat004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat005/libthrstat005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat005/thrstat005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTime/gettime001/gettime001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTime/gettime001/libgettime001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTimerInfo/timerinfo001/libtimerinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTimerInfo/timerinfo001/timerinfo001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTopThreadGroups/topthrgrp001/libtopthrgrp001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTopThreadGroups/topthrgrp001/topthrgrp001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTopThreadGroups/topthrgrp002/libtopthrgrp002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTopThreadGroups/topthrgrp002/topthrgrp002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetVersionNumber/getvern001/getvern001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetVersionNumber/getvern001/libgetvern001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/intrpthrd001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/libintrpthrd001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd002/intrpthrd002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd002/libintrpthrd002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/intrpthrd003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/libintrpthrd003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsArrayClass/isarray004/isarray004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsArrayClass/isarray004/libisarray004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsArrayClass/isarray005/isarray005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsArrayClass/isarray005/libisarray005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin002/isfldsin002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin002/libisfldsin002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin003/isfldsin003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin003/libisfldsin003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsInterface/isintrf004/isintrf004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsInterface/isintrf004/libisintrf004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsInterface/isintrf005/isintrf005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsInterface/isintrf005/libisintrf005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodNative/isnative001/isnative001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodNative/isnative001/libisnative001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodNative/isnative002/isnative002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodNative/isnative002/libisnative002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodObsolete/isobsolete001/isobsolete001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodObsolete/isobsolete001/libisobsolete001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodSynthetic/issynth001/issynth001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodSynthetic/issynth001/libIsMethodSyntheticIssynth001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodSynthetic/issynth002/issynth002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodSynthetic/issynth002/libissynth002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap001/iterheap001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap001/libiterheap001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap002/iterheap002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap002/libiterheap002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap003/iterheap003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap003/libiterheap003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap004/iterheap004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap004/libiterheap004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap005/iterheap005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap005/libiterheap005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap006/iterheap006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap006/libiterheap006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/libiterheap007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls001/iterinstcls001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls001/libiterinstcls001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls002/iterinstcls002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls002/libiterinstcls002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls003/iterinstcls003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls003/libiterinstcls003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls004/iterinstcls004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls004/libiterinstcls004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls005/iterinstcls005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls005/libiterinstcls005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls006/iterinstcls006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls006/libiterinstcls006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls007/iterinstcls007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls007/libiterinstcls007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj001/iterobjreachobj001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj001/libiterobjreachobj001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/libiterobjreachobj002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj003/iterobjreachobj003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj003/libiterobjreachobj003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj004/iterobjreachobj004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj004/libiterobjreachobj004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj005/iterobjreachobj005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj005/libiterobjreachobj005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj001/iterreachobj001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj001/libiterreachobj001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj002/iterreachobj002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj002/libiterreachobj002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj003/iterreachobj003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj003/libiterreachobj003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj004/iterreachobj004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj004/libiterreachobj004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj005/iterreachobj005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj005/libiterreachobj005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/abort/Abort.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/abort/libAbort.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/callbacks/Callbacks.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/callbacks/libCallbacks.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/concrete-klass-filter/ConcreteKlassFilter.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/concrete-klass-filter/libConcreteKlassFilter.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/HeapFilter.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/libHeapFilter.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/non-concrete-klass-filter/NonConcreteKlassFilter.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/non-concrete-klass-filter/libNonConcreteKlassFilter.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MethodEntry/mentry001/libmentry001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MethodEntry/mentry001/mentry001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MethodEntry/mentry002/libmentry002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MethodEntry/mentry002/mentry002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MethodExit/mexit001/libmexit001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MethodExit/mexit001/mexit001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MethodExit/mexit002/libmexit002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MethodExit/mexit002/mexit002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorContendedEnter/mcontenter001/libmcontenter001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorContendedEnter/mcontenter001/mcontenter001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorContendedEntered/mcontentered001/libmcontentered001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorContendedEntered/mcontentered001/mcontentered001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorWait/monitorwait001/libmonitorwait001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorWait/monitorwait001/monitorwait001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorWaited/monitorwaited001/libmonitorwaited001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorWaited/monitorwaited001/monitorwaited001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind001/libnativemethbind001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind001/nativemethbind001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind002/libnativemethbind002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind002/nativemethbind002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind003/libnativemethbind003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind003/nativemethbind003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind004/libnativemethbind004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind004/nativemethbind004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop001/libnframepop001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop001/nframepop001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop002/libnframepop002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop002/nframepop002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop003/libnframepop003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop003/nframepop003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001/libobjfree001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001/objfree001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree002/libobjfree002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree002/objfree002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe001/libpopframe001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe001/popframe001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe002/libpopframe002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe002/popframe002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe003/libpopframe003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe003/popframe003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe004/libpopframe004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe004/popframe004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe005/libpopframe005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe005/popframe005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe006/libpopframe006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe006/popframe006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe007/libpopframe007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe007/popframe007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe008/libpopframe008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe008/popframe008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe009/libpopframe009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe009/popframe009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010/libpopframe010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010/popframe010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe011/libpopframe011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe011/popframe011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter001/librawmonenter001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter001/rawmonenter001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter002/librawmonenter002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter002/rawmonenter002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/librawmonenter003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/rawmonenter003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter004/librawmonenter004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter004/rawmonenter004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit001/librawmonexit001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit001/rawmonexit001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit002/librawmonexit002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit002/rawmonexit002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit003/librawmonexit003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit003/rawmonexit003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit005/librawmonexit005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit005/rawmonexit005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy001/librawmnntfy001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy001/rawmnntfy001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy002/librawmnntfy002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy002/rawmnntfy002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy003/librawmnntfy003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy003/rawmnntfy003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy004/librawmnntfy004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy004/rawmnntfy004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall001/librawmnntfyall001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall001/rawmnntfyall001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall002/librawmnntfyall002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall002/rawmnntfyall002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall003/librawmnntfyall003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall003/rawmnntfyall003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall004/librawmnntfyall004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall004/rawmnntfyall004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait001/librawmnwait001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait001/rawmnwait001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait002/librawmnwait002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait002/rawmnwait002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait003/librawmnwait003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait003/rawmnwait003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait004/librawmnwait004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait004/rawmnwait004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait005/librawmnwait005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait005/rawmnwait005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/libstressRedefine.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/stressRedefine.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass001/libredefclass001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass001/redefclass001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass002/libredefclass002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass002/redefclass002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass003/libredefclass003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass003/redefclass003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass004/libredefclass004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass004/redefclass004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass005/libredefclass005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass005/redefclass005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass006/libredefclass006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass006/redefclass006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass008/libredefclass008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass008/redefclass008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass009/libredefclass009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass009/redefclass009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass010/libredefclass010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass010/redefclass010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass011/libredefclass011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass011/redefclass011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass012/libredefclass012.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass012/redefclass012.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass013/libredefclass013.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass013/redefclass013.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass014/libredefclass014.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass014/redefclass014.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass015/libredefclass015.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass015/redefclass015.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass016/libredefclass016.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass016/redefclass016.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass017/libredefclass017.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass017/redefclass017.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass018/libredefclass018.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass018/redefclass018.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass019/libredefclass019.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass019/redefclass019.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass020/libredefclass020.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass020/redefclass020.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass021/libredefclass021.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass021/redefclass021.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass022/libredefclass022.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass022/redefclass022.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass023/libredefclass023.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass023/redefclass023.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass024/libredefclass024.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass024/redefclass024.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass025/libredefclass025.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass025/redefclass025.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass026/libredefclass026.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass026/redefclass026.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass027/libredefclass027.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass027/redefclass027.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass028/libredefclass028.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass028/redefclass028.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass029/libredefclass029.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass029/redefclass029.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass030/libredefclass030.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass030/redefclass030.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass031/libredefclass031.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass031/redefclass031.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps001/librelcaps001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps001/relcaps001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps002/librelcaps002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps002/relcaps002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/libresexhausted.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd001/libresumethrd001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd001/resumethrd001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd002/libresumethrd002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd002/resumethrd002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst001/libresumethrdlst001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst001/resumethrdlst001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst002/libresumethrdlst002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst002/resumethrdlst002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform002/libretransform002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform002/retransform002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform003/libretransform003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform003/retransform003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform004/libretransform004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform004/retransform004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/agentthr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/libagentthr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr002/agentthr002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr002/libagentthr002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr003/agentthr003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr003/libagentthr003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk002/libsetbrk002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk002/setbrk002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk003/libsetbrk003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk003/setbrk003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk005/libsetbrk005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk005/setbrk005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk007/libsetbrk007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk007/setbrk007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk008/libsetbrk008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk008/setbrk008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor001/libsetenvstor001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor001/setenvstor001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor002/libsetenvstor002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor002/setenvstor002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor003/libsetenvstor003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor003/setenvstor003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb001/libsetevntcallb001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb001/setevntcallb001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb002/libsetevntcallb002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb002/setevntcallb002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb003/libsetevntcallb003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb003/setevntcallb003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/libsetnotif001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/setnotif001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetExtensionEventCallback/setextevent001/libsetextevent001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetExtensionEventCallback/setextevent001/setextevent001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/libsetfldw001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/setfldw001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw002/libsetfldw002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw002/setfldw002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw003/libsetfldw003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw003/setfldw003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw004/libsetfldw004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw004/setfldw004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw005/libsetfldw005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw005/setfldw005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw006/libsetfldw006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw006/setfldw006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/libsetfmodw001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/setfmodw001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw002/libsetfmodw002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw002/setfmodw002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw003/libsetfmodw003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw003/setfmodw003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw004/libsetfmodw004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw004/setfmodw004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw005/libsetfmodw005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw005/setfmodw005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw006/libsetfmodw006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw006/setfmodw006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetJNIFunctionTable/setjniftab001/libsetjniftab001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetJNIFunctionTable/setjniftab001/setjniftab001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetJNIFunctionTable/setjniftab002/libsetjniftab002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetJNIFunctionTable/setjniftab002/setjniftab002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001/libsetlocal001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001/setlocal001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal002/libsetlocal002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal002/setlocal002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal003/libsetlocal003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal003/setlocal003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal004/libsetlocal004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal004/setlocal004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix001/SetNativeMethodPrefix001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix001/libSetNativeMethodPrefix001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/SetNativeMethodPrefix002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/SetNativeMethodPrefix002Main.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/libSetNativeMethodPrefix002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/libSetNativeMethodPrefix002Main.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop002/libsetsysprop002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop002/setsysprop002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop003/libsetsysprop003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop003/setsysprop003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetTag/settag001/libsettag001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetTag/settag001/settag001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor001/libsetthrdstor001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor001/setthrdstor001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor002/libsetthrdstor002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor002/setthrdstor002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor003/libsetthrdstor003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor003/setthrdstor003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag001/libsetvrbflag001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag001/setvrbflag001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/libsetvrbflag002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/setvrbflag002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep001/libsinglestep001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep001/singlestep001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep002/libsinglestep002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep002/singlestep002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep003/libsinglestep003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep003/singlestep003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd006/libstopthrd006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd006/stopthrd006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd007/libstopthrd007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd007/stopthrd007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd001/libsuspendthrd001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd001/suspendthrd001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd002/libsuspendthrd002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd002/suspendthrd002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/libsuspendthrd003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst001/libsuspendthrdlst001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst001/suspendthrdlst001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst002/libsuspendthrdlst002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst002/suspendthrdlst002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadEnd/threadend001/libthreadend001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadEnd/threadend001/threadend001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadEnd/threadend002/libthreadend002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadEnd/threadend002/threadend002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart001/libthreadstart001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart001/threadstart001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/libthreadstart002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart003/libthreadstart003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart003/threadstart003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMDeath/vmdeath001/libvmdeath001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMDeath/vmdeath001/vmdeath001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMInit/vminit001/libvminit001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMInit/vminit001/vminit001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMObjectAlloc/vmobjalloc001/libvmobjalloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMObjectAlloc/vmobjalloc001/vmobjalloc001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP01/ap01t001/ap01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP01/ap01t001/libap01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP02/ap02t001/ap02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP02/ap02t001/libap02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP03/ap03t001/ap03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP03/ap03t001/libap03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/ap04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/libap04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/ap04t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/libap04t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/libap04t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t001/ap05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t001/libap05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t002/ap05t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t002/libap05t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/libap06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t001/ap07t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t001/libap07t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t002/ap07t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t002/libap07t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP09/ap09t001/ap09t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP09/ap09t001/libap09t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/ap10t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/libap10t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/ap11t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/libap11t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/ap12t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/libap12t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/bi01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/libbi01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t002/bi01t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t002/libbi01t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001/bi02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001/libbi02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t002/bi02t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t002/libbi02t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t001/bi03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t001/libbi03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t002/bi03t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t002/libbi03t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/bi04t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/libbi04t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t001/cm01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t001/libcm01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t002/cm01t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t002/libcm01t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t003/cm01t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t003/libcm01t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t004/cm01t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t004/libcm01t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t005/cm01t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t005/libcm01t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t006/cm01t006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t006/libcm01t006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t007/cm01t007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t007/libcm01t007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t008/cm01t008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t008/libcm01t008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t009/cm01t009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t009/libcm01t009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t010/cm01t010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t010/libcm01t010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t011/cm01t011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t011/libcm01t011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t012/cm01t012.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t012/libcm01t012.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t013/cm01t013.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t013/libcm01t013.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t014/cm01t014.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t014/libcm01t014.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t015/cm01t015.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t015/libcm01t015.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t016/cm01t016.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t016/libcm01t016.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t017/cm01t017.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t017/libcm01t017.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t018/cm01t018.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t018/libcm01t018.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t019/cm01t019.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t019/libcm01t019.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t020/cm01t020.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t020/libcm01t020.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t021/cm01t021.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t021/libcm01t021.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/cm02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/libcm02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/cm03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/libcm03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/libtc01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/tc01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/libtc02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/tc02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/libtc03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/libtc03t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/libtc04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/libtc05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t001/em01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t001/libem01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/em01t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/libem01t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t001/em02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t001/libem02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t002/em02t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t002/libem02t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/em02t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/libem02t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t004/em02t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t004/libem02t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/em02t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/libem02t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/em02t006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/libem02t006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t007/em02t007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t007/libem02t007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t008/em02t008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t008/libem02t008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t009/em02t009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t009/libem02t009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t010/em02t010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t010/libem02t010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t011/em02t011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t011/libem02t011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012/em02t012.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012/libem02t012.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/libem04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t001/em05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t001/libem05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t002/em05t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t002/libem05t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/libem06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t001/em07t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t001/libem07t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/em07t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/libem07t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/ex03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/libex03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF01/gf01t001/gf01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF01/gf01t001/libgf01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF04/gf04t001/gf04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF04/gf04t001/libgf04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF06/gf06t001/gf06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF06/gf06t001/libgf06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t001/gf08t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t001/libgf08t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t002/gf08t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t002/libgf08t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t003/gf08t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t003/libgf08t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS103/hs103t002/hs103t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS103/hs103t002/libhs103t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t001/hs104t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t001/libhs104t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t002/hs104t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t002/libhs104t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t001/hs201t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t001/libhs201t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/libhs201t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/libhs201t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t001/hs202t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t001/libhs202t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/libhs202t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t001/hs203t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t001/libhs203t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t002/hs203t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t002/libhs203t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/hs203t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/libhs203t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/libhs203t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/libhs204t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t002/hs204t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t002/libhs204t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/libhs204t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t004/hs204t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t004/libhs204t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/libhs301t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t002/hs301t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t002/libhs301t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t003/hs301t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t003/libhs301t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004/hs301t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004/libhs301t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t005/hs301t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t005/libhs301t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t001/hs302t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t001/libhs302t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t002/hs302t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t002/libhs302t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t003/hs302t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t003/libhs302t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t004/hs302t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t004/libhs302t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t005/hs302t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t005/libhs302t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t006/hs302t006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t006/libhs302t006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t007/hs302t007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t007/libhs302t007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t008/hs302t008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t008/libhs302t008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t009/hs302t009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t009/libhs302t009.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t010/hs302t010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t010/libhs302t010.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t011/hs302t011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t011/libhs302t011.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t012/hs302t012.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t012/libhs302t012.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/libji01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t001/ji03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t001/libji03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t002/ji03t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t002/libji03t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/ji03t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/libji03t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t004/ji03t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t004/libji03t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/libji05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI06/ji06t001/ji06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI06/ji06t001/libji06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA01/ma01t001/libma01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA01/ma01t001/libma01t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA01/ma01t001/ma01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA01/ma01t001/ma01t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/libma02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/libma02t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/ma02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/ma02t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/libma03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/libma03t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/ma03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/ma03t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/libma04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/libma04t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/ma04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/ma04t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/libma04t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/libma04t002a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/libma04t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/libma04t003a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/ma04t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/ma04t003a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/libma05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/libma05t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/ma05t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/ma05t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/libma06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/libma06t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/ma06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/ma06t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/libma07t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/libma07t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/ma07t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/ma07t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/libma08t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/libma08t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/ma08t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/ma08t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/libma10t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/libma10t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/libma10t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/libma10t002a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/ma10t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/ma10t002a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/libma10t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/libma10t003a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/ma10t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/ma10t003a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/libma10t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/libma10t004a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/ma10t004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/ma10t004a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/libma10t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/libma10t005a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/ma10t005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/ma10t005a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/libma10t006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/libma10t006a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/libma10t007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/libma10t007a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/ma10t007.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/ma10t007a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/libma10t008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/libma10t008a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/ma10t008.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/ma10t008a.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t001/libsp01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t001/sp01t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/libsp01t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/sp01t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/libsp01t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/sp01t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t001/libsp02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t001/sp02t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t002/libsp02t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t002/sp02t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t003/libsp02t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t003/sp02t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/libsp03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/sp03t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/libsp03t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/sp03t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/libsp04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/sp04t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/libsp04t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/sp04t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t002/libsp05t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t002/sp05t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/libsp05t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t001/libsp06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t001/sp06t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t002/libsp06t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t002/sp06t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/libsp06t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/sp06t003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t001/libsp07t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t001/sp07t001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/libsp07t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/sp07t002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/followref001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/libfollowref001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/followref002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/libfollowref002.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/followref004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/libfollowref004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/followref005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/libfollowref005.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/libfollowref006.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/earlyretbase.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/libearlyretbase.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretfp/earlyretfp.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretfp/libearlyretfp.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/libearlyretint.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretlong/earlyretlong.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretlong/libearlyretlong.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretobj/earlyretobj.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretobj/libearlyretobj.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretstr/earlyretstr.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretstr/libearlyretstr.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretvoid/earlyretvoid.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretvoid/libearlyretvoid.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/getallstktr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/libgetallstktr001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetConstantPool/getcpool001/getcpool001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetConstantPool/getcpool001/libgetcpool001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLineNumberTable/linetab004/liblinetab004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLineNumberTable/linetab004/linetab004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLocalVariable/getlocal003/getlocal003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLocalVariable/getlocal003/libgetlocal003.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLocalVariable/getlocal004/getlocal004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLocalVariable/getlocal004/libgetlocal004.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic/issynth001/issynth001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic/issynth001/libIsSyntheticIssynth001.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/libMethodBind.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/OnUnload/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/OnUnload/JvmtiTest/libOnUnload.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/StackTrace/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/StackTrace/JvmtiTest/libStackTrace.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/agentthr/agentthr.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/agentthr/libagentthr.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/clsldrclss00x/clsldrclss00x.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/clsldrclss00x/libclsldrclss00x.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/events/redefineCFLH/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/events/redefineCFLH/JvmtiTest/libredefineCFLH.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/extmech/extmech.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/extmech/libextmech.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/AddToBootstrapClassLoaderSearch/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/AddToBootstrapClassLoaderSearch/JvmtiTest/libAddToBootstrapClassLoaderSearch.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/Dispose/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/Dispose/JvmtiTest/libDispose.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/ForceGarbageCollection/gc/gc.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/ForceGarbageCollection/gc/libgc.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/environment/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/environment/JvmtiTest/libenvironment.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest/libnosuspendMonitorInfo.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendStackTrace/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendStackTrace/JvmtiTest/libnosuspendStackTrace.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/librawmonitor.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/rawmonitor.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/heapref/heapref.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/heapref/libheapref.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/refignore/librefignore.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/refignore/refignore.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/setNullVMInit/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/setNullVMInit/JvmtiTest/libsetNullVMInit.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/timers/JvmtiTest/JvmtiTest.c - test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/timers/JvmtiTest/libtimers.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/StackTraceController.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/libStackTraceController.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/libThreadController.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/Deadlock.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/LockingThreads.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/RecursiveMonitoringThread.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/libDeadlock.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/libLockingThreads.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/libNativeBlockedThread.c - test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/libRecursiveMonitoringThread.c - test/hotspot/jtreg/vmTestbase/nsk/share/JVMDITools.c - test/hotspot/jtreg/vmTestbase/nsk/share/JVMTIagent.c - test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/BooleanArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ByteArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/CharArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/DoubleArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/FloatArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/IntArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/LongArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ShortArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/StringCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libBooleanArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libByteArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libCharArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libDoubleArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libFloatArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libIntArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libLongArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libShortArrayCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libStringCriticalLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNILocalRefLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIRefLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIWeakGlobalRefLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIGlobalRefLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNILocalRefLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIRefLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIWeakGlobalRefLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jvmti/JVMTIAllocLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jvmti/libJVMTIAllocLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/malloc/MallocLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/malloc/libMallocLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/jdi/MonitorEnterExecutor.c - test/hotspot/jtreg/vmTestbase/nsk/share/jdi/libMonitorEnterExecutor.c - test/hotspot/jtreg/vmTestbase/nsk/share/jni/JNIreferences.c - test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.c - test/hotspot/jtreg/vmTestbase/nsk/share/jni/libJNIreferences.c - test/hotspot/jtreg/vmTestbase/nsk/share/jpda/libNativeMethodsTestThread.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch_agent.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToBootstrapClassLoaderSearch/libbootclssearch_agent.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToSystemClassLoaderSearch/libsystemclssearch_agent.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToSystemClassLoaderSearch/systemclssearch_agent.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_tools.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/libHotSwap.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/unit/Heap.c - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/unit/libHeap.c - test/hotspot/jtreg/vmTestbase/nsk/share/locks/JNIMonitorLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/locks/LockingThread.c - test/hotspot/jtreg/vmTestbase/nsk/share/locks/libJNIMonitorLocker.c - test/hotspot/jtreg/vmTestbase/nsk/share/locks/libLockingThread.c - test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.c - test/hotspot/jtreg/vmTestbase/nsk/share/native/native_utils.c - test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.c - test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_mutex.c - test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.c - test/hotspot/jtreg/vmTestbase/nsk/stress/jni/gclocker/libgcl001.c - test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress001.c - test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress002.c - test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress003.c - test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress004.c - test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress005.c - test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress006.c - test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress007.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace003.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace004.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace005.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace006.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace008.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace009.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace011.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace012.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace014.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/libstrace015.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace003.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace004.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace005.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace006.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace008.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace009.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace011.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace012.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace014.c - test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace015.c - test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/libLTTest.c - test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/share/IndyRedefineClass.c - test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/share/libIndyRedefineClass.c - test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/libstepBreakPopReturn.c - test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/stepBreakPopReturn.c - test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/libnativeAndMH.c - test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/nativeAndMH.c - test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.c - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/libredefineClasses.c - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/redefineClasses.c - test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.c - test/hotspot/jtreg/vmTestbase/vm/share/libProcessUtils.c ! test/jdk/ProblemList.txt - test/jdk/com/sun/jdi/CatchAllTest.sh - test/jdk/com/sun/jdi/CatchCaughtTest.sh - test/jdk/com/sun/jdi/CommandCommentDelimiter.sh - test/jdk/com/sun/jdi/DeoptimizeWalk.sh - test/jdk/com/sun/jdi/EvalArgs.sh - test/jdk/com/sun/jdi/EvalArraysAsList.sh - test/jdk/com/sun/jdi/EvalInterfaceStatic.sh - test/jdk/com/sun/jdi/GetLocalVariables3Test.sh - test/jdk/com/sun/jdi/GetLocalVariables4Test.sh - test/jdk/com/sun/jdi/JdbExprTest.sh - test/jdk/com/sun/jdi/JdbMethodExitTest.sh - test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.sh - test/jdk/lib/testlibrary/jdk/testlibrary/JcmdBase.java - test/jdk/lib/testlibrary/jdk/testlibrary/OSInfo.java - test/jdk/lib/testlibrary/jdk/testlibrary/ProcessThread.java - test/jdk/lib/testlibrary/jdk/testlibrary/TestThread.java - test/jdk/lib/testlibrary/jdk/testlibrary/XRun.java - test/langtools/tools/javac/diags/examples/NeitherConditionalSubtype.java Changeset: dcf301c53d23 Author: serb Date: 2018-09-08 12:32 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/dcf301c53d23 8207150: Clip.isRunning() may return true after Clip.stop() was called Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java ! test/jdk/ProblemList.txt + test/jdk/javax/sound/sampled/Clip/ClipIsRunningAfterStop.java Changeset: 9f912f45d6aa Author: prr Date: 2018-09-09 11:19 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9f912f45d6aa 8210384: SunLayoutEngine.isAAT() font is expensive on MacOS Reviewed-by: dmarkov, kaddepalli ! src/java.desktop/share/classes/sun/font/SunLayoutEngine.java Changeset: 26a17d160081 Author: serb Date: 2018-09-09 19:07 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/26a17d160081 8205537: Drop of sun.applet package Reviewed-by: prr - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! test/jdk/java/lang/SecurityManager/CheckPackageAccess.java ! test/jdk/javax/swing/UIDefaults/6795356/TableTest.java ! test/jdk/sun/misc/URLClassPath/ClassnameCharTest.java Changeset: 372cbac1a862 Author: vagarwal Date: 2018-09-12 11:51 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/372cbac1a862 8210052: Enable testing for all the available look and feels in SwingSet3 demo tests Reviewed-by: shurailine, serb ! test/jdk/sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java ! test/jdk/sanity/client/SwingSet/src/ButtonDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ComboBoxDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ListDemoTest.java ! test/jdk/sanity/client/SwingSet/src/OptionPaneDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ProgressBarDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ScrollPaneDemoTest.java ! test/jdk/sanity/client/SwingSet/src/SpinnerDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TabbedPaneDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TableDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ToggleButtonDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TreeDemoTest.java Changeset: 16c6d8d35fd7 Author: prr Date: 2018-09-13 10:54 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/16c6d8d35fd7 Merge - make/jdk/src/classes/build/tools/hasher/Hasher.java - make/jdk/src/classes/build/tools/jarreorder/JarReorder.java - make/mapfiles/libjsig/mapfile-vers-solaris - src/java.desktop/windows/native/common/awt_makecube.cpp - test/hotspot/jtreg/vmTestbase/nsk/share/test/timeoutwatchdog/TimeoutHandler.java - test/hotspot/jtreg/vmTestbase/nsk/share/test/timeoutwatchdog/TimeoutWatchdog.java - test/hotspot/jtreg/vmTestbase/vm/share/gc/TriggerUnloadingByFillingHeap.java - test/hotspot/jtreg/vmTestbase/vm/share/vmstresser/CompileAndDeoptimize.java - test/hotspot/jtreg/vmTestbase/vm/share/vmstresser/MetaspaceStresser.java - test/jdk/com/sun/jdi/JdbArgTest.sh - test/jdk/com/sun/jdi/JdbLockTest.sh - test/jdk/com/sun/jdi/JdbMissStep.sh - test/jdk/com/sun/jdi/JdbVarargsTest.sh - test/jdk/com/sun/jdi/MixedSuspendTest.sh - test/jdk/com/sun/jdi/NotAField.sh - test/jdk/com/sun/jdi/NullLocalVariable.sh - test/jdk/com/sun/jdi/Redefine-g.sh - test/jdk/com/sun/jdi/RedefineAbstractClass.sh - test/jdk/com/sun/jdi/RedefineAddPrivateMethod.sh - test/jdk/com/sun/jdi/RedefineAnnotation.sh - test/jdk/com/sun/jdi/RedefineChangeClassOrder.sh - test/jdk/com/sun/jdi/RedefineClasses.sh - test/jdk/com/sun/jdi/RedefineClearBreakpoint.sh - test/jdk/com/sun/jdi/RedefineImplementor.sh - test/jdk/java/util/zip/ZipFile/deletetempjar.sh - test/jdk/javax/naming/module/basic.sh - test/jdk/lib/testlibrary/jdk/testlibrary/JDKToolFinder.java - test/jdk/lib/testlibrary/jdk/testlibrary/JDKToolLauncher.java - test/jdk/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java - test/jdk/lib/testlibrary/jdk/testlibrary/OutputBuffer.java - test/jdk/lib/testlibrary/jdk/testlibrary/ProcessTools.java - test/jdk/lib/testlibrary/jdk/testlibrary/StreamPumper.java Changeset: 16a0f33a5052 Author: prr Date: 2018-09-13 11:31 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/16a0f33a5052 7017058: Malayalam glyph substitution is failing for Malayalam with Windows Kartika font. 8191130: Sinhala text rendering problem with C+VIRAMA+ZWJ+RA/YA+V 8195836: opentype:Bengali: "Khanda Ta" shaping issue with U+09A4 TA, U+09CD virama, U+200D ZWJ Reviewed-by: serb, psadhukhan ! src/java.desktop/share/classes/sun/font/CMap.java + test/jdk/java/awt/font/GlyphVector/ZWJLigatureTest.java Changeset: cfbfa216f3c0 Author: mhalder Date: 2018-09-14 17:53 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/cfbfa216f3c0 8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut Reviewed-by: dmarkov, kaddepalli ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/jdk/java/awt/Frame/CycleThroughFrameTest/CycleThroughFrameTest.java Changeset: 2eb91a0167e8 Author: prr Date: 2018-09-15 14:03 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/2eb91a0167e8 8210766: Remove obsolete qualified export sun.net.www to java.desktop Reviewed-by: mchung ! src/java.base/share/classes/module-info.java Changeset: e06054185a18 Author: prr Date: 2018-09-17 09:36 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/e06054185a18 Merge - make/mapfiles/libjsound/mapfile-vers - make/mapfiles/libjvm_db/mapfile-vers - make/mapfiles/libjvm_dtrace/mapfile-vers - src/java.base/windows/conf/tzmappings - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/NewArrayStub.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/NewInstanceStub.java - test/jdk/java/util/ServiceLoader/basic/basic.sh - test/jdk/lib/testlibrary/jdk/testlibrary/Utils.java Changeset: c88fd713b51c Author: psadhukhan Date: 2018-09-18 18:12 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/c88fd713b51c 8191178: [macos] Problem with input of yen symbol Reviewed-by: dmarkov, mhalder ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m Changeset: d96a607e9594 Author: serb Date: 2018-09-18 18:32 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/d96a607e9594 8170937: Swing apps are slow if displaying from a remote source to many local displays Reviewed-by: prr, aivanov ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java ! test/jdk/java/awt/Mixing/AWT_Mixing/FrameBorderCounter.java ! test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Changeset: 0e514f1549b4 Author: serb Date: 2018-09-22 20:31 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/0e514f1549b4 8210692: The "com.sun.awt.SecurityWarning" class can be dropped Reviewed-by: prr, mullan, mchung ! src/java.base/share/lib/security/default.policy - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java ! test/jdk/TEST.ROOT ! test/jdk/TEST.groups - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties ! test/jdk/java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java Changeset: a642a0efc36d Author: prr Date: 2018-09-24 10:59 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/a642a0efc36d Merge - src/hotspot/share/classfile/compactHashtable.inline.hpp - src/java.base/macosx/native/libjli/java_md_macosx.c ! test/jdk/ProblemList.txt - test/jdk/com/sun/jdi/RedefineException.sh - test/jdk/com/sun/jdi/RedefineFinal.sh - test/jdk/com/sun/jdi/RedefineIntConstantToLong.sh - test/jdk/com/sun/jdi/RedefineMulti.sh - test/jdk/com/sun/jdi/RedefinePop.sh - test/jdk/com/sun/jdi/RedefineStep.sh - test/jdk/com/sun/jdi/RedefineTTYLineNumber.sh - test/jdk/com/sun/jdi/StringConvertTest.sh - test/jdk/com/sun/jdi/WatchFramePop.sh - test/jdk/lib/testlibrary/jdk/testlibrary/Asserts.java Changeset: f2d6750f5c10 Author: prr Date: 2018-09-24 11:46 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f2d6750f5c10 8210866: Remove HPKeysym.h from JDK sources Reviewed-by: serb, dmarkov ! src/java.desktop/unix/legal/xwindows.md - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h ! src/java.desktop/unix/native/libawt_xawt/xawt/XWindow.c Changeset: c38095007004 Author: prr Date: 2018-09-24 11:49 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c38095007004 8209548: Unused and incorrect calls to FT_Get_Char_Index Reviewed-by: psadhukhan, kaddepalli ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: 4ec74929fbfe Author: lbourges Date: 2018-09-24 21:23 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/4ec74929fbfe 8210335: Clipping problems with complex affine transforms: negative scaling factors or small scaling factors Summary: fixed clipping rectangle to take into account the inverse transform (scale/shear) Reviewed-by: prr, serb ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/DRendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/DStroker.java ! src/java.desktop/share/classes/sun/java2d/marlin/DTransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinConst.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/RendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java ! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Version.java + test/jdk/sun/java2d/marlin/ScaleClipTest.java Changeset: 111af7a30c74 Author: prr Date: 2018-09-25 14:38 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/111af7a30c74 8211125: backout fix for 8210880 which was pushed under another ID Reviewed-by: serb ! src/java.desktop/unix/legal/xwindows.md + src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h ! src/java.desktop/unix/native/libawt_xawt/xawt/XWindow.c Changeset: 5b500c6d19d3 Author: prr Date: 2018-09-25 14:44 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/5b500c6d19d3 8210880: Remove HPKeysym.h from JDK sources Reviewed-by: serb, dmarkov ! src/java.desktop/unix/legal/xwindows.md - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h ! src/java.desktop/unix/native/libawt_xawt/xawt/XWindow.c Changeset: 54937a08689b Author: serb Date: 2018-09-25 17:58 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/54937a08689b 8210286: Drop of sun.awt.HToolkit class Reviewed-by: dmarkov, prr ! src/java.desktop/share/classes/java/awt/GraphicsEnvironment.java - src/java.desktop/share/classes/sun/awt/HToolkit.java Changeset: c3fc25df8f5a Author: alitvinov Date: 2018-09-26 18:36 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/c3fc25df8f5a 8211165: License header is absent in a few J2Ddemo source code files Reviewed-by: prr, iris ! src/demo/share/jfc/J2Ddemo/java2d/DemoInstVarsAccessor.java ! src/demo/share/jfc/J2Ddemo/java2d/DemoInstVarsAccessorImplBase.java Changeset: d3e0d57cd3ff Author: prr Date: 2018-09-27 10:49 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/d3e0d57cd3ff Merge ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java Changeset: afb3c0884bf1 Author: prr Date: 2018-09-27 11:39 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/afb3c0884bf1 Merge Changeset: dade6dd87bb4 Author: jlaskey Date: 2018-09-27 15:47 -0300 URL: http://hg.openjdk.java.net/panama/dev/rev/dade6dd87bb4 8211080: RawStringLiteralLangAPI.java test times out by default Reviewed-by: jjg ! test/langtools/tools/javac/RawStringLiteralLangAPI.java Changeset: 0f7d0bb6cfe2 Author: jcbeyler Date: 2018-09-27 15:56 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/0f7d0bb6cfe2 8211036: Remove the NSK_STUB macros from vmTestbase for non jvmti Summary: Remove the NSK_STUB macros from code outside of the jvmti subfolder Reviewed-by: iignatyev, amenkov, dholmes ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/StackTraceController.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/Deadlock.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/LockingThreads.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/RecursiveMonitoringThread.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/JVMTIagent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/README ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/README ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/nsk_strace.h ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace006.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/nativeAndMH.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/redefineClasses.cpp Changeset: 1d12935177ed Author: mbaesken Date: 2018-09-28 09:20 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/1d12935177ed 8210964: add more ld preloading related info to hs_error file on Linux Reviewed-by: clanger, stuefe ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp Changeset: 5e9c922eafbc Author: mbaesken Date: 2018-09-27 15:37 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/5e9c922eafbc 8211149: fix potential memleak in getJavaIDFromLangID after failing SetupI18nProps call [windows] Reviewed-by: naoto, lucy ! src/java.base/windows/native/libjava/java_props_md.c Changeset: 28085dba5d9a Author: jjiang Date: 2018-09-28 15:42 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/28085dba5d9a 8209546: Make sun/security/tools/keytool/autotest.sh to support macosx Summary: Refactor autotest.sh to java test and remove standard.sh Reviewed-by: weijun ! test/jdk/ProblemList.txt ! test/jdk/sun/security/pkcs11/PKCS11Test.java ! test/jdk/sun/security/tools/keytool/KeyToolTest.java + test/jdk/sun/security/tools/keytool/NssTest.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh Changeset: c573d2633417 Author: rkennke Date: 2018-09-28 10:57 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c573d2633417 8211269: Make declaration of Allocation protected in MemAllocator Reviewed-by: shade ! src/hotspot/share/gc/shared/memAllocator.hpp Changeset: 7bd8d6b011c9 Author: sballal Date: 2018-09-28 14:31 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/7bd8d6b011c9 8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Reviewed-by: dholmes, jgeorge ! test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java ! test/hotspot/jtreg/serviceability/sa/TestJmapCore.java Changeset: 2d980757fd07 Author: chegar Date: 2018-09-28 12:47 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/2d980757fd07 8211092: test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java fails intermittently when cleaning up Reviewed-by: dfuchs ! test/jdk/ProblemList.txt ! test/jdk/sun/net/www/http/HttpClient/MultiThreadTest.java Changeset: 5ba442f14818 Author: avoitylov Date: 2018-09-28 15:39 +0300 URL: http://hg.openjdk.java.net/panama/dev/rev/5ba442f14818 8211212: ARM: -Werror=switch build failure Reviewed-by: shade ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp Changeset: 2a1e47af3c6b Author: mbaesken Date: 2018-09-27 17:13 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/2a1e47af3c6b 8211208: make AllocateHeapAt an unsupported option on AIX Reviewed-by: shade, tschatzl ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/gc/TestAllocateHeapAt.java ! test/hotspot/jtreg/gc/TestAllocateHeapAtError.java ! test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java ! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithAllocateHeapAt.java Changeset: a1c24d06e2b5 Author: dl Date: 2018-09-28 08:45 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/a1c24d06e2b5 8210971: Add exception handling methods to CompletionStage and CompletableFuture Reviewed-by: martin, chegar ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/CompletionStage.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java Changeset: 1239bfca87f8 Author: dl Date: 2018-09-28 08:45 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1239bfca87f8 8207003: Miscellaneous changes imported from jsr166 CVS 2018-09 Reviewed-by: martin, chegar ! test/jdk/java/util/Collections/EmptyNavigableSet.java ! test/jdk/java/util/PriorityQueue/AddNonComparable.java ! test/jdk/java/util/concurrent/tck/AbstractQueuedSynchronizerTest.java ! test/jdk/java/util/concurrent/tck/CountedCompleterTest.java ! test/jdk/java/util/concurrent/tck/DelayQueueTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinPool8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinTask8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java ! test/jdk/java/util/concurrent/tck/FutureTaskTest.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/RecursiveActionTest.java ! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java ! test/jdk/java/util/concurrent/tck/ReentrantLockTest.java ! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java Changeset: e374b0383035 Author: shade Date: 2018-09-28 18:28 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/e374b0383035 8211272: x86_32 build failures after JDK-8210764 (Update avx512 implementation) Reviewed-by: rkennke, kvn ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp Changeset: 3aac38c47955 Author: shade Date: 2018-09-28 18:28 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/3aac38c47955 8211274: x86_32 build failures after JDK-8211029 (Have a common set of enabled warnings for all native libraries) Reviewed-by: dholmes, tschatzl ! src/hotspot/cpu/x86/jniFastGetField_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp Changeset: d82660ddd75c Author: shade Date: 2018-09-28 18:28 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d82660ddd75c 8211268: Disable unsupported GCs for Zero Reviewed-by: sgehwolf, erikj ! make/autoconf/hotspot.m4 Changeset: d38cb687d631 Author: dtitov Date: 2018-09-28 12:04 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/d38cb687d631 8163083: SocketListeningConnector does not allow invocations with port 0 Reviewed-by: sspitsyn, amenkov, gadams, jcbeyler ! src/jdk.jdi/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/GenericListeningConnector.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketListeningConnector.java + test/jdk/com/sun/jdi/connect/WildcardPortSupport.java Changeset: f1f7ff620f83 Author: gadams Date: 2018-09-28 14:31 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/f1f7ff620f83 8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again Reviewed-by: cjplummer, amenkov ! test/hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java Changeset: 2712735bc434 Author: jcbeyler Date: 2018-09-28 13:01 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/2712735bc434 8210842: Handle JNIGlobalRefLocker.cpp Summary: Add checking for JNI calls via a new ExceptionCheckingJniEnv Reviewed-by: sspitsyn, amenkov, dholmes, mikael ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIGlobalRefLocker.cpp + test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp + test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp Changeset: 53a4760e9fcc Author: henryjen Date: 2018-09-28 13:15 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/53a4760e9fcc 8210810: Escaped character at specific position in argument file is not handled properly Reviewed-by: alanb Contributed-by: Bo Zhang ! src/java.base/share/native/libjli/args.c ! test/jdk/tools/launcher/ArgFileSyntax.java Changeset: db0c3952de52 Author: coleenp Date: 2018-09-28 16:07 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/db0c3952de52 8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate files Reviewed-by: iklam, stuefe ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/classLoaderData.inline.hpp + src/hotspot/share/classfile/classLoaderDataGraph.cpp + src/hotspot/share/classfile/classLoaderDataGraph.hpp + src/hotspot/share/classfile/classLoaderDataGraph.inline.hpp ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/classfile/classLoaderStats.cpp ! src/hotspot/share/classfile/loaderConstraints.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp ! src/hotspot/share/gc/g1/g1FullGCMarkTask.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/parallel/pcTasks.cpp ! src/hotspot/share/gc/parallel/psMarkSweep.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psTasks.cpp ! src/hotspot/share/gc/serial/genMarkSweep.cpp ! src/hotspot/share/gc/shared/cardTableRS.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/parallelCleaning.hpp ! src/hotspot/share/gc/z/zRootsIterator.cpp ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/saveRestore.cpp ! src/hotspot/share/jfr/periodic/jfrModuleEvent.cpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/klassVtable.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/biasedLocking.cpp ! src/hotspot/share/runtime/compilationPolicy.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/memprofiler.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/heapDumper.cpp ! src/hotspot/share/services/memBaseline.cpp Changeset: bb1d5dd64897 Author: mikael Date: 2018-09-28 14:11 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/bb1d5dd64897 8211176: Initialize ObjectMonitor eagerly Reviewed-by: dholmes, adinn, redestad ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: 540c1a848dd8 Author: mikael Date: 2018-09-28 14:53 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/540c1a848dd8 8211291: Backout JDK-8210842 Handle JNIGlobalRefLocker.cpp Reviewed-by: kbarrett, iignatyev, jcbeyler ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIGlobalRefLocker.cpp - test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp - test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp Changeset: 628909466216 Author: jiangli Date: 2018-10-01 00:52 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/628909466216 8210926: vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/TestDescription.java failed with JVMTI_ERROR_INVALID_CLASS in CDS mode Summary: Reset InstanceKlass _init_state to 'allocated' before writing out shared classes at dump time. Reviewed-by: dholmes, coleenp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 8f0f7f2ae20b Author: aph Date: 2018-09-26 18:11 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/8f0f7f2ae20b 8211170: AArch64: Warnings in C1 and template interpreter Reviewed-by: adinn ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Changeset: d034d46065fb Author: aph Date: 2018-10-01 09:56 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/d034d46065fb Merge - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java - src/java.desktop/share/classes/sun/awt/HToolkit.java - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java Changeset: 358a3b99198a Author: aph Date: 2018-09-20 18:29 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/358a3b99198a 8210972: Add comment text to C1 patching code Reviewed-by: kvn ! src/hotspot/share/c1/c1_Runtime1.cpp Changeset: 2a2a78bd1fc3 Author: lucy Date: 2018-10-01 12:07 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/2a2a78bd1fc3 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) Reviewed-by: shade, simonis ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/assembler_s390.cpp ! src/hotspot/cpu/s390/assembler_s390.hpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp Changeset: 933b0abb2211 Author: rkennke Date: 2018-10-01 16:34 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/933b0abb2211 8211241: Missing obj equals in TemplateTable::fast_aldc Reviewed-by: dcubed, coleenp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp Changeset: 5bdf60cd0ed0 Author: shade Date: 2018-10-01 16:41 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/5bdf60cd0ed0 8211239: Build fails without JFR: empty JFR events signatures mismatch Reviewed-by: mgronlun, dholmes ! make/src/classes/build/tools/jfr/GenerateJfrFiles.java Changeset: 02421ca2cc85 Author: rkennke Date: 2018-10-01 17:47 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/02421ca2cc85 8211071: unpack.cpp fails to compile with statement has no effect [-Werror=unused-value] Reviewed-by: ihse, clanger ! src/jdk.pack/share/native/common-unpack/unpack.cpp Changeset: 7cbb77546f87 Author: aph Date: 2018-10-01 12:29 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/7cbb77546f87 8211333: AArch64: Fix another build failure after JDK-8211029 Reviewed-by: shade, aph Contributed-by: pengfei.li at arm.com ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: 26810c5fe290 Author: aph Date: 2018-10-01 12:30 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/26810c5fe290 Merge Changeset: 67619141f027 Author: lancea Date: 2018-10-01 13:05 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/67619141f027 8211295: DriverManager.getConnection fails when called from com.sun.rowset.JdbcRowSetImpl Reviewed-by: mchung, alanb ! src/java.sql/share/classes/java/sql/DriverManager.java ! test/jdk/java/sql/testng/util/StubConnection.java + test/jdk/javax/sql/testng/test/rowset/jdbcrowset/JdbcRowSetDriverManagerTest.java Changeset: 2f1698b6db15 Author: simonis Date: 2018-10-01 19:08 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/2f1698b6db15 8211328: Different declaration and definition of ClassLoaderData::classes_do() leads to build failures Reviewed-by: dcubed, coleenp ! src/hotspot/share/classfile/classLoaderData.hpp Changeset: c5b97602cd4b Author: rkennke Date: 2018-10-01 20:23 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c5b97602cd4b 8211129: compiler/whitebox/ForceNMethodSweepTest.java fails after JDK-8132849 Reviewed-by: eosterlund, thartmann ! src/hotspot/share/runtime/sweeper.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 94b9b7a09001 Author: ccheung Date: 2018-10-01 11:36 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/94b9b7a09001 8211278: Update ProblemList Reviewed-by: iklam ! test/jdk/ProblemList-Xcomp.txt Changeset: 390f529f4f22 Author: kvn Date: 2018-10-01 11:54 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/390f529f4f22 8211251: Default mask register for avx512 instructions Summary: Encode AVX 512 instructions as unmasked instruction where mask register is not specified. Reviewed-by: kvn Contributed-by: sandhya.viswanathan at intel.com ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp Changeset: a8862960c19f Author: iignatyev Date: 2018-10-01 14:54 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/a8862960c19f 8211171: move JarUtils to top-level testlibrary Reviewed-by: alanb ! test/hotspot/jtreg/runtime/Dictionary/ProtectionDomainCacheTest.java - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java ! test/jdk/java/io/FilePermission/ReadFileOnPath.java ! test/jdk/java/io/Serializable/packageAccess/PackageAccessTest.java ! test/jdk/java/io/Serializable/resolveClass/consTest/ConsTest.java ! test/jdk/java/io/Serializable/resolveClass/consTest/SetupJar.java ! test/jdk/java/io/Serializable/resolveClass/deserializeButton/DeserializeButtonTest.java ! test/jdk/java/io/Serializable/superclassDataLoss/SuperclassDataLossTest.java ! test/jdk/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java ! test/jdk/java/lang/ClassLoader/getResource/automaticmodules/Driver.java ! test/jdk/java/lang/ClassLoader/securityManager/ClassLoaderTest.java ! test/jdk/java/lang/Package/IsCompatibleWithDriver.java ! test/jdk/java/lang/Package/PackageFromManifest.java ! test/jdk/java/lang/instrument/executableJAR/ExecJarWithAgent.java ! test/jdk/java/lang/module/AutomaticModulesTest.java ! test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java ! test/jdk/java/lang/module/MultiReleaseJarTest.java ! test/jdk/java/lang/module/customfs/ModulesInCustomFileSystem.java ! test/jdk/java/net/URLClassLoader/closetest/CloseTest.java ! test/jdk/java/net/URLClassLoader/closetest/GetResourceAsStream.java ! test/jdk/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/jdk/java/nio/channels/AsynchronousChannelGroup/SetupJar.java ! test/jdk/java/nio/charset/spi/CharsetProviderBasicTest.java ! test/jdk/java/nio/charset/spi/SetupJar.java ! test/jdk/java/rmi/module/ModuleTest.java ! test/jdk/java/security/Provider/SecurityProviderModularTest.java ! test/jdk/java/util/ServiceLoader/ModulesTest.java ! test/jdk/java/util/ServiceLoader/basic/ServiceLoaderBasicTest.java ! test/jdk/javax/security/auth/login/modules/JaasModularClientTest.java ! test/jdk/javax/security/auth/login/modules/JaasModularDefaultHandlerTest.java ! test/jdk/jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java - test/jdk/lib/testlibrary/JarUtils.java ! test/jdk/sun/net/www/protocol/jar/jarbug/TestDriver.java ! test/jdk/tools/jlink/basic/BasicTest.java ! test/jdk/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java ! test/jdk/tools/launcher/modules/addreads/AddReadsTest.java ! test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java ! test/jdk/tools/launcher/modules/patch/basic/PatchTest.java ! test/jdk/tools/launcher/modules/patch/basic/PatchTestWarningError.java ! test/jdk/tools/launcher/modules/validate/ValidateModulesTest.java ! test/lib/jdk/test/lib/util/JarUtils.java Changeset: 4756af2308a1 Author: manc Date: 2018-10-01 20:16 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/4756af2308a1 8210716: Detailed GC logging request misses some Summary: Changed log tags from (heap, ergo) to (gc, ergo, heap). Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/parallel/adjoiningGenerations.cpp ! src/hotspot/share/gc/parallel/psMarkSweep.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 3241975b1830 Author: weijun Date: 2018-10-02 16:02 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/3241975b1830 8210821: Support dns_canonicalize_hostname in krb5.conf Reviewed-by: valeriep ! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java + test/jdk/sun/security/krb5/auto/DnsCanonicalizeHostname.java + test/jdk/sun/security/krb5/auto/dns_canonicalize_hostname.hosts Changeset: 191c2b7d7186 Author: chegar Date: 2018-10-02 09:05 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/191c2b7d7186 8211325: test/jdk/java/net/Socket/LingerTest.java fails with cleaning up Reviewed-by: dfuchs ! test/jdk/ProblemList.txt ! test/jdk/java/net/Socket/LingerTest.java Changeset: 48dec0c13bec Author: chegar Date: 2018-10-02 10:40 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/48dec0c13bec 8209454: [error-prone] TypeParameterUnusedInFormals in jdk.net Reviewed-by: dfuchs ! src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java Changeset: df8ae450fce3 Author: dfuchs Date: 2018-10-02 14:17 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/df8ae450fce3 8211349: Bad HTML in {@link} for HttpResponse.BodyHandlers.ofPublisher Summary: Fixed links by moving <> out of the link as was done elsewhere in the file. Reviewed-by: chegar ! src/java.net.http/share/classes/java/net/http/HttpResponse.java Changeset: 2a12a3865916 Author: roland Date: 2018-09-27 16:25 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/2a12a3865916 8211231: BarrierSetC1::generate_referent_check() confuses register allocator Reviewed-by: iveresov, kvn ! src/hotspot/share/gc/shared/c1/barrierSetC1.cpp Changeset: 2ef304ee001d Author: roland Date: 2018-09-28 10:42 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/2ef304ee001d 8210887: Tweak C2 gc api for arraycopy Reviewed-by: kvn, thartmann ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/arraycopynode.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp Changeset: 08c296fe9458 Author: cushon Date: 2018-10-01 21:14 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/08c296fe9458 8211057: Gensrc step CompileProperties generates unstable CompilerProperties output Reviewed-by: mcimadamore, vromero ! make/langtools/tools/propertiesparser/gen/ClassGenerator.java Changeset: c1db377f6300 Author: igerasim Date: 2018-10-02 10:19 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c1db377f6300 8200381: Typos in javadoc - missing verb "be" and alike Reviewed-by: lancea, darcy, wetmore ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java ! src/java.base/share/classes/java/nio/channels/Selector.java ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java ! src/java.base/share/classes/sun/security/provider/DSA.java ! src/java.base/share/classes/sun/security/provider/certpath/IndexedCollectionCertStore.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/x509/OCSPNoCheckExtension.java Changeset: c4010f88ea68 Author: amenkov Date: 2018-10-02 12:06 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c4010f88ea68 8203928: [Test] Convert non-JDB scaffolding serviceability shell script tests to java Reviewed-by: jcbeyler, cjplummer ! test/jdk/com/sun/jdi/ImmutableResourceTest.java - test/jdk/com/sun/jdi/ImmutableResourceTest.sh ! test/jdk/com/sun/jdi/JITDebug.java - test/jdk/com/sun/jdi/JITDebug.sh + test/jdk/com/sun/jdi/PrivateTransportTest.java - test/jdk/com/sun/jdi/PrivateTransportTest.sh ! test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.java - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh ! test/jdk/com/sun/jdi/redefine/RedefineTest.java - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh ! test/jdk/com/sun/jdi/redefineMethod/RedefineTest.java Changeset: 1bf7a2919e06 Author: amenkov Date: 2018-10-02 12:08 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1bf7a2919e06 8209332: [TEST] test/jdk/com/sun/jdi/CatchPatternTest.sh is incorrect Reviewed-by: jcbeyler, dtitov, cjplummer + test/jdk/com/sun/jdi/CatchPatternTest.java - test/jdk/com/sun/jdi/CatchPatternTest.sh Changeset: 7ac0ac1e57b6 Author: dholmes Date: 2018-10-02 17:12 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/7ac0ac1e57b6 8211175: Remove temporary clock initialization duplication Reviewed-by: rehn, mikael ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp Changeset: 6003e034cdd8 Author: iklam Date: 2018-10-02 14:32 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/6003e034cdd8 8209946: [TESTBUG] CDS tests should use "@run driver" Reviewed-by: ccheung, jiangli, mseledtsov ! test/hotspot/jtreg/runtime/SharedArchiveFile/ArchiveDoesNotExist.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/CdsSameObjectAlignment.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSharedDictionary.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/NonBootLoaderClasses.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedBaseAddress.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStrings.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsDedup.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsRunAuto.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/TestInterpreterMethodEntries.java ! test/hotspot/jtreg/runtime/appcds/AppendClasspath.java ! test/hotspot/jtreg/runtime/appcds/BootClassPathMismatch.java ! test/hotspot/jtreg/runtime/appcds/CDSandJFR.java ! test/hotspot/jtreg/runtime/appcds/CaseSensitiveClassPath.java ! test/hotspot/jtreg/runtime/appcds/ClassLoaderTest.java ! test/hotspot/jtreg/runtime/appcds/ClassPathAttr.java ! test/hotspot/jtreg/runtime/appcds/CommandLineFlagComboNegative.java ! test/hotspot/jtreg/runtime/appcds/DirClasspathTest.java ! test/hotspot/jtreg/runtime/appcds/DumpClassList.java ! test/hotspot/jtreg/runtime/appcds/ExtraSymbols.java ! test/hotspot/jtreg/runtime/appcds/FieldAnnotationsTest.java ! test/hotspot/jtreg/runtime/appcds/FreeUnusedMetadata.java ! test/hotspot/jtreg/runtime/appcds/HelloExtTest.java ! test/hotspot/jtreg/runtime/appcds/HelloTest.java ! test/hotspot/jtreg/runtime/appcds/IgnoreEmptyClassPaths.java ! test/hotspot/jtreg/runtime/appcds/JvmtiAddPath.java ! test/hotspot/jtreg/runtime/appcds/MissingSuperTest.java ! test/hotspot/jtreg/runtime/appcds/MoveJDKTest.java ! test/hotspot/jtreg/runtime/appcds/MultiProcessSharing.java ! test/hotspot/jtreg/runtime/appcds/OldClassTest.java ! test/hotspot/jtreg/runtime/appcds/PackageSealing.java ! test/hotspot/jtreg/runtime/appcds/ParallelLoad2.java ! test/hotspot/jtreg/runtime/appcds/ParallelLoadTest.java ! test/hotspot/jtreg/runtime/appcds/ProhibitedPackage.java ! test/hotspot/jtreg/runtime/appcds/ProtectionDomain.java ! test/hotspot/jtreg/runtime/appcds/RewriteBytecodesTest.java ! test/hotspot/jtreg/runtime/appcds/SharedPackages.java ! test/hotspot/jtreg/runtime/appcds/SignedJar.java ! test/hotspot/jtreg/runtime/appcds/SpecifySysLoaderProp.java ! test/hotspot/jtreg/runtime/appcds/TestWithProfiler.java ! test/hotspot/jtreg/runtime/appcds/TraceLongClasspath.java ! test/hotspot/jtreg/runtime/appcds/WideIloadTest.java ! test/hotspot/jtreg/runtime/appcds/WrongClasspath.java ! test/hotspot/jtreg/runtime/appcds/XShareAutoWithChangedJar.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedIntegerCacheTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleComboTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleCompareTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedMirrorTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferences.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/MirrorWithReferenceFieldsTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/OpenArchiveRegion.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/PrimitiveTypesTest.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassTest.java ! test/hotspot/jtreg/runtime/appcds/condy/CondyHelloTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatA.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatB.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatC.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatD.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatE.java ! test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom.java ! test/hotspot/jtreg/runtime/appcds/customLoader/LoaderSegregationTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestMultiFP.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestSingleFP.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ProhibitedPackageNamesTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/ProtectionDomain.java ! test/hotspot/jtreg/runtime/appcds/customLoader/SameNameInTwoLoadersTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnintendedLoadersTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnloadUnregisteredLoaderTest.java ! test/hotspot/jtreg/runtime/appcds/customLoader/UnsupportedPlatforms.java ! test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTest.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/CheckUnsupportedDumpingOptions.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/JigsawOptionsCombo.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/AppClassInCP.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/CustomPackage.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/MismatchedPatchModule.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchDir.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchJavaBase.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/Simple.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/SubClassOfPatchedClass.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/TwoJars.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/BootAppendTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddModules.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddOpens.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddReads.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ExportModule.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/JvmtiAddPath.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/MainModuleOnly.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/OverrideTests.java ! test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelLoadAndTransformTest.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java ! test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/ExerciseGC.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/FlagCombo.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/InternSharedString.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/InvalidFileFormat.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/LargePages.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/LockSharedStrings.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasicPlus.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsStress.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWbTest.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java Changeset: ad00713a0562 Author: mikael Date: 2018-10-02 15:01 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/ad00713a0562 8211364: Remove expired flags Reviewed-by: dholmes, egahlin ! src/hotspot/share/runtime/arguments.cpp ! test/hotspot/jtreg/runtime/CommandLine/ObsoleteFlagErrorMessage.java ! test/jdk/jdk/jfr/event/compiler/TestAllocInNewTLAB.java ! test/jdk/jdk/jfr/event/compiler/TestAllocOutsideTLAB.java ! test/jdk/jdk/jfr/event/oldobject/TestAllocationTime.java ! test/jdk/jdk/jfr/event/oldobject/TestLargeRootSet.java ! test/jdk/jdk/jfr/event/oldobject/TestLastKnownHeapUsage.java ! test/jdk/jdk/jfr/startupargs/TestOldObjectQueueSize.java Changeset: 266a89a5d1af Author: ccheung Date: 2018-10-02 20:52 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/266a89a5d1af 8211287: ClassPathTests.java fails due to "Unable to map MiscData shared space at required address." Summary: catch the InvocationTargetException and rethrow exception based on the cause Reviewed-by: jiangli, iklam ! test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java Changeset: c0d05cf1d19d Author: pkoppula Date: 2018-10-02 21:38 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/c0d05cf1d19d 8211107: LDAPS communication failure with jdk 1.8.0_181 Reviewed-by: chegar, coffeys, vtewari ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java Changeset: 7577686cc9bd Author: mikael Date: 2018-10-02 22:36 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/7577686cc9bd 8211350: Remove jprt support Reviewed-by: dholmes, erikj, mchung, alanb, jjg - make/Jprt.gmk ! make/Main.gmk ! make/conf/jib-profiles.js - make/jprt.properties ! src/hotspot/os/linux/os_linux.cpp ! test/TestCommon.gmk ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/jprt.config ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/com/sun/jdi/cds/CDSJDITest.java ! test/jdk/java/lang/String/CompactString/CompactString.java ! test/jdk/java/lang/StringBuffer/CompactStringBuffer.java ! test/jdk/java/lang/StringBuilder/CompactStringBuilder.java - test/jdk/jprt.config ! test/jdk/lib/security/CheckBlacklistedCerts.java ! test/jdk/tools/jimage/JImageTest.java ! test/jdk/tools/jlink/plugins/StringSharingPluginTest.java ! test/jdk/tools/jlink/plugins/StripDebugPluginTest.java ! test/jdk/tools/lib/tests/Helper.java ! test/jdk/tools/pack200/Pack200Test.java ! test/jdk/tools/pack200/TestExceptions.java ! test/langtools/Makefile Changeset: f7babf9d1592 Author: pmuthuswamy Date: 2018-10-03 11:43 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/f7babf9d1592 8208531: -javafx mode should be on by default when JavaFX is available Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java + test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFxMode.java Changeset: 84743156e780 Author: dholmes Date: 2018-10-03 03:41 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/84743156e780 8188764: Obsolete AssumeMP and then remove all support for non-MP builds Reviewed-by: mikael, mdoerr, bulasevich, eosterlund ! src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/compiledIC_arm.cpp ! src/hotspot/cpu/arm/jniFastGetField_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/compiledIC_ppc.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/compiledIC_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/sparc/compiledIC_sparc.cpp ! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp ! src/hotspot/cpu/sparc/macroAssembler_sparc.inline.hpp ! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp ! src/hotspot/cpu/sparc/templateInterpreterGenerator_sparc.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/compiledIC_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/jniFastGetField_x86_32.cpp ! src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp ! src/hotspot/os_cpu/bsd_x86/bsd_x86_32.s ! src/hotspot/os_cpu/linux_arm/orderAccess_linux_arm.hpp ! src/hotspot/share/c1/c1_CodeStubs.hpp ! src/hotspot/share/c1/c1_InstructionPrinter.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/shared/c1/barrierSetC1.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/os.hpp ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 9ce37fa2e179 Author: hseigel Date: 2018-10-03 09:46 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/9ce37fa2e179 8209138: Symbol constructor uses u1 as the element type of its name argument Summary: Maske u1 the type for Symbol values and add a function to return it as a char. Reviewed-by: dholmes, coleenp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciObjArrayKlass.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/ci/ciSymbol.cpp ! src/hotspot/share/ci/ciSymbol.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/verificationType.cpp ! src/hotspot/share/classfile/verificationType.hpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/prims/jvmtiTagMap.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/fieldType.cpp ! src/hotspot/share/runtime/fieldType.hpp ! src/hotspot/share/runtime/signature.cpp ! src/hotspot/share/runtime/signature.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/heapDumper.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/Field.java Changeset: 27b48d82272c Author: redestad Date: 2018-10-03 15:05 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/27b48d82272c 8211384: Obsolete -XX:+/-MonitorInUseLists option Reviewed-by: mikael, rkennke, shade, dcubed ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 7d036fb69443 Author: rraghavan Date: 2018-10-03 08:03 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/7d036fb69443 8211168: Solaris-X64 build failure with error nreg hides the same name in an outer scope Summary: Corrected nreg definition Reviewed-by: dcubed, kvn, shade ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: dac71e2465ca Author: akolarkunnu Date: 2018-10-01 18:03 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/dac71e2465ca 8211160: Handle different look and feels in JInternalFrameOperator Reviewed-by: serb Contributed-by: abdul.kolarkunnu at oracle.com ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/drivers/DefaultDriverInstaller.java + test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/drivers/windows/InternalFramePopupMenuDriver.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/JInternalFrameOperator.java ! test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/version_info Changeset: 0b36afd411ec Author: aph Date: 2018-10-03 17:29 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/0b36afd411ec 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean Reviewed-by: shade, alanb ! src/java.base/unix/native/libjava/Console_md.c Changeset: 8897e41b327c Author: aph Date: 2018-10-03 17:45 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/8897e41b327c Merge Changeset: be4614f04eb6 Author: shade Date: 2018-10-03 18:46 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/be4614f04eb6 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions) Reviewed-by: kvn ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp Changeset: 22ca7ba0c50c Author: gziemski Date: 2018-10-03 12:34 -0500 URL: http://hg.openjdk.java.net/panama/dev/rev/22ca7ba0c50c 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF Summary: Added ATTRIBUTE_PRINTF to JVMFlag::printError Reviewed-by: kbarrett, coleenp ! src/hotspot/share/gc/cms/jvmFlagConstraintsCMS.cpp ! src/hotspot/share/runtime/flags/jvmFlag.hpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp Changeset: 4236fa9582bb Author: kvn Date: 2018-10-03 10:38 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/4236fa9582bb 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI Summary: use default compile threshold for these tests Reviewed-by: thartmann ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/compiler/profiling/TestSpecTrapClassUnloading.java ! test/hotspot/jtreg/compiler/profiling/TestTypeProfiling.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass/Launcher.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java Changeset: 82dc590fa586 Author: gadams Date: 2018-10-03 07:41 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/82dc590fa586 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false Reviewed-by: cjplummer, amenkov ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java Changeset: b16820c2336d Author: poonam Date: 2018-10-03 19:30 +0000 URL: http://hg.openjdk.java.net/panama/dev/rev/b16820c2336d 8211150: G1 Full GC not purging code root memory and hence causing memory leak Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 6f04692c7d51 Author: sherman Date: 2018-10-03 12:54 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/6f04692c7d51 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative Reviewed-by: alanb, lancea ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipDirectoryStream.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! test/jdk/jdk/nio/zipfs/Basic.java From maurizio.cimadamore at oracle.com Wed Oct 3 20:06:52 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 03 Oct 2018 20:06:52 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810032006.w93K6rWa001884@aojmv0008.oracle.com> Changeset: 664a58833042 Author: mcimadamore Date: 2018-10-03 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/664a58833042 Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/java.base/share/classes/module-info.java - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java - src/java.desktop/share/classes/sun/awt/HToolkit.java - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java ! test/jdk/TEST.groups - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java From maurizio.cimadamore at oracle.com Wed Oct 3 20:07:11 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 03 Oct 2018 20:07:11 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810032007.w93K7CpG002213@aojmv0008.oracle.com> Changeset: 878071fd2bf6 Author: mcimadamore Date: 2018-10-03 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/878071fd2bf6 Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/java.base/share/classes/module-info.java - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java - src/java.desktop/share/classes/sun/awt/HToolkit.java - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java From maurizio.cimadamore at oracle.com Wed Oct 3 20:07:31 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 03 Oct 2018 20:07:31 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810032007.w93K7VQC002548@aojmv0008.oracle.com> Changeset: 43291ccb37f2 Author: mcimadamore Date: 2018-10-03 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/43291ccb37f2 Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java - src/java.desktop/share/classes/sun/awt/HToolkit.java - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java From maurizio.cimadamore at oracle.com Wed Oct 3 20:07:50 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 03 Oct 2018 20:07:50 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810032007.w93K7o3A002932@aojmv0008.oracle.com> Changeset: 91826eefada1 Author: mcimadamore Date: 2018-10-03 22:10 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/91826eefada1 Automatic merge with default - make/Jprt.gmk - make/jprt.properties ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java - src/java.desktop/share/classes/sun/awt/HToolkit.java - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java From henry.jen at oracle.com Thu Oct 4 05:51:47 2018 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 3 Oct 2018 22:51:47 -0700 Subject: [foreign] RFR 8211397: consolidate parsing of indentifiers in DescriptorParser In-Reply-To: <8904220f-4c3f-da4b-6ebf-92362c9c56da@oracle.com> References: <8904220f-4c3f-da4b-6ebf-92362c9c56da@oracle.com> Message-ID: Looks fine. Cheers, Henry > On Oct 2, 2018, at 10:44 AM, Maurizio Cimadamore wrote: > > Hi, > following the recent parser changes to improve parsing of header declarations, this is a followup patch which unifies the parsing logic of layout annotation names with the recently introduced logic for parsing header declaration names. A new test has been added to check the various case of good/bad annotation names. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8211397/ > > Cheers > Maurizio > From sundararajan.athijegannathan at oracle.com Thu Oct 4 10:40:22 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 04 Oct 2018 16:10:22 +0530 Subject: [foreign] RFR 8211319: jextract fails to extract /usr/include/stdio.h on Linux Message-ID: <5BB5EE16.90306@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8211319 Webrev: http://cr.openjdk.java.net/~sundar/8211319/webrev.00/ Thanks, -Sundar From maurizio.cimadamore at oracle.com Thu Oct 4 10:46:14 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 4 Oct 2018 11:46:14 +0100 Subject: [foreign] RFR 8211319: jextract fails to extract /usr/include/stdio.h on Linux In-Reply-To: <5BB5EE16.90306@oracle.com> References: <5BB5EE16.90306@oracle.com> Message-ID: <462d5909-1161-4704-2b87-9ce5250ca6f0@oracle.com> Looks good as a temporary fixup. Ultimately, it seems that the underlying cause (as we have discussed) is in jextract attempting to artificially break up things at header boundaries, which results in dangling references. When jextract will work on a more holistic way (e.g. one artifact per extracted library), I believe we will be able to address this in the right way. In the meantime, this is ok. Thanks Maurizio On 04/10/18 11:40, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211319 > Webrev: http://cr.openjdk.java.net/~sundar/8211319/webrev.00/ > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 4 11:08:00 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 04 Oct 2018 11:08:00 +0000 Subject: hg: panama/dev: 8211319: jextract fails to extract /usr/include/stdio.h on Linux Message-ID: <201810041108.w94B80eN028933@aojmv0008.oracle.com> Changeset: faf350669b0e Author: sundar Date: 2018-10-04 03:52 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/faf350669b0e 8211319: jextract fails to extract /usr/include/stdio.h on Linux Reviewed-by: mcimadamore ! src/jdk.jextract/share/classes/com/sun/tools/jextract/TypedefHandler.java + test/jdk/com/sun/tools/jextract/stdio/StdioTest.java From sundararajan.athijegannathan at oracle.com Thu Oct 4 11:31:50 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 04 Oct 2018 17:01:50 +0530 Subject: [foreign RFR 8211713: jdk.jextract should avoid using java.base internal packages Message-ID: <5BB5FA26.1050602@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8211713 Webrev: http://cr.openjdk.java.net/~sundar/8211713/webrev.00/ Thanks, -Sundar From maurizio.cimadamore at oracle.com Thu Oct 4 12:36:01 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 4 Oct 2018 13:36:01 +0100 Subject: [foreign RFR 8211713: jdk.jextract should avoid using java.base internal packages In-Reply-To: <5BB5FA26.1050602@oracle.com> References: <5BB5FA26.1050602@oracle.com> Message-ID: I think that as a temporary measure, what you did is ok. (btw, I believe that Types shouldn't even be in the binder, and that the binder should only rely on NativeTypes) That said, I think that moving forward it'd be nice if instead of using predefined layouts we relied on clang to tell us the size of the type (even if it's a primitive) and build a layout from there (and then pick a suitable carrier depending on that size). In other words, I see the current code as a temporary measure until we get more portability, so I'm ok with it (for now). Maurizio On 04/10/18 12:31, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211713 > Webrev: http://cr.openjdk.java.net/~sundar/8211713/webrev.00/ > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 4 12:39:41 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 04 Oct 2018 12:39:41 +0000 Subject: hg: panama/dev: 8211713: jdk.jextract should avoid using java.base internal packages Message-ID: <201810041239.w94CdgTB013623@aojmv0008.oracle.com> Changeset: 959864359151 Author: sundar Date: 2018-10-04 18:18 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/959864359151 8211713: jdk.jextract should avoid using java.base internal packages Reviewed-by: mcimadamore ! src/java.base/share/classes/module-info.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/AsmCodeFactory.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/Context.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/Utils.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/tree/LayoutUtils.java From maurizio.cimadamore at oracle.com Thu Oct 4 16:39:17 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 4 Oct 2018 17:39:17 +0100 Subject: [foreign] RFR 8211722: Add comprehensive ABI test for downcalls Message-ID: <3fcb9dbf-bbe6-1cf4-d40b-6d571533e13d@oracle.com> Hi, since we are now supporting multiple invocation schemes (for both upcalls and downcalls) I thought it would be a good idea to start testing the ABI code more in depth. I have created a generator which creates an header/C file with aroun 2K different functions in it, each of which is a specific permutation of a fixes set of parameter types. Example: void f_PI_V_(void* p0, int p1) ; void f_PF_V_(void* p0, float p1) ; void f_PP_V_(void* p0, void* p1) ; The implementation of these functions (in the C file) is derived in a simple way: * if the function is void, body is empty * otherwise, it is assumed that the function will return its first parameter For struct parameters the generator also generates several combinations of struct fields, to make sure that everything works correctly - here an example of the structs defined: struct S_II { int p0; int p1; }; struct S_IF { int p0; float p1; }; struct S_IP { int p0; void* p1; }; To keep the number of combination under control, I had to limit the function arity to 3, and the struct field arity to 2. Otherwise the extracted @NativeHeader had a declaration string which was too big to fit in the constant pool (!!). The test extracts the header, loads the extracted classes and binds them. Then it uses reflection to call every single function in the header. This means that for every function to be called, the test will have to synthesize some parameter values to be passed to the function. In addition to all this, the test also verifies that, if a non-void function is called, the function call returns a value that is equal to the first argument passed. Needless to say, this test uncovered several issues which have been fixed as part of this patch: * The universal invoker doesn't like empty structs; there were several crashes, as no 'binding' was generated from them. Looking at the System V ABI it's not even 100% clear what should happen in case of an empty struct passed by value, but after inspecting output of clang/gcc it seems evident that empty structs are simply skipped (e.g. they do not take any register, which makes sense). So, to support this, I had to add support for empty structs in the classing sequence builder, and then special case UniversalInvoker::boxValue and UniversalInvoker::unboxValue, accordingly (to avoid touching pointers whose layout is void). * There was another issue in UniversalInvoker: when a function returned a struct by value using multi-register return,? the register values were not copied in the correct order into the resulting struct. To fix this I had to tweak CallingSequence to add 'offsets' for return types and fix the code in UniversalInvoker::invoke to compute the offset into the return register array correctly (the code was erroneously computing the offset using ArgumentBinding::getOffset). * The direct invocation scheme was also broken when mixed long and floating point parameters were passed; more specifically, the nativeMethodType signature was not normalized (e.g. put into a form where longs came first then followed by doubles) and as a result we failed to lookup the right method handle trampoline. I have fixed the direct shuffler in a more general way - now a nativeMethodType is always 'normalized' and additionally I tweaked the way in which method handle permutations were computed, as I realized that the permutation step has to be applied at different steps depending on whether we are inside an upcall or a downcall (and with different method type targets too). The resulting code passes the new ABI test (and all other tests too of course); note that the new ABI test is ran two times: once w/o any invocation scheme parameter (meaning NativeInvoker is free to chose fast path if it wants) and another which force the universal scheme. This should provide maximum coverage for both schemes. I will work separately on a similar approach to test upcalls (but I think it's better to split given that this one is already biggie). Webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8211722/ Cheers Maurizio From maurizio.cimadamore at oracle.com Thu Oct 4 16:48:13 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 04 Oct 2018 16:48:13 +0000 Subject: hg: panama/dev: 8211397: consolidate parsing of indentifiers in DescriptorParser Message-ID: <201810041648.w94GmETX019513@aojmv0008.oracle.com> Changeset: 261dc079d72f Author: mcimadamore Date: 2018-10-04 17:47 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/261dc079d72f 8211397: consolidate parsing of indentifiers in DescriptorParser Reviewed-by: hjen ! src/java.base/share/classes/jdk/internal/foreign/memory/DescriptorParser.java + test/jdk/java/foreign/TestAnnotations.java From shravya.rukmannagari at intel.com Thu Oct 4 21:35:29 2018 From: shravya.rukmannagari at intel.com (shravya.rukmannagari at intel.com) Date: Thu, 04 Oct 2018 21:35:29 +0000 Subject: hg: panama/dev: Build Fix for VectorAPI Shift Message-ID: <201810042135.w94LZTtd029477@aojmv0008.oracle.com> Changeset: 8b07f151b38a Author: srukmannagar Date: 2018-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/8b07f151b38a Build Fix for VectorAPI Shift ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template From maurizio.cimadamore at oracle.com Thu Oct 4 21:37:05 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 04 Oct 2018 21:37:05 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810042137.w94Lb5nI000349@aojmv0008.oracle.com> Changeset: aeb27f154bea Author: mcimadamore Date: 2018-10-04 23:39 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/aeb27f154bea Automatic merge with vectorIntrinsics From shravya.rukmannagari at intel.com Fri Oct 5 00:26:26 2018 From: shravya.rukmannagari at intel.com (shravya.rukmannagari at intel.com) Date: Fri, 05 Oct 2018 00:26:26 +0000 Subject: hg: panama/dev: manual merge with default Message-ID: <201810050026.w950QRJ6017085@aojmv0008.oracle.com> Changeset: 61e5462eea6f Author: srukmannagar Date: 2018-10-04 09:06 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/61e5462eea6f manual merge with default - make/Jprt.gmk - make/jprt.properties ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/module-info.java - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java - src/java.desktop/share/classes/sun/awt/HToolkit.java - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java From maurizio.cimadamore at oracle.com Fri Oct 5 00:32:08 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 05 Oct 2018 00:32:08 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810050032.w950W8vn020593@aojmv0008.oracle.com> Changeset: b75b2b0a7832 Author: mcimadamore Date: 2018-10-05 02:34 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b75b2b0a7832 Automatic merge with vectorIntrinsics - make/Jprt.gmk - make/jprt.properties ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/prims/nativeLookup.cpp ! src/java.base/share/classes/module-info.java - src/java.desktop/share/classes/com/sun/awt/SecurityWarning.java - src/java.desktop/share/classes/sun/applet/AppletClassLoader.java - src/java.desktop/share/classes/sun/applet/AppletSecurity.java - src/java.desktop/share/classes/sun/applet/AppletThreadGroup.java - src/java.desktop/share/classes/sun/awt/HToolkit.java - src/java.desktop/unix/native/libawt_xawt/awt/HPkeysym.h - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java ! test/jdk/TEST.groups - test/jdk/com/sun/awt/SecurityWarning/CustomSecurityManager.java - test/jdk/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java - test/jdk/com/sun/awt/TEST.properties - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/jdk/java/awt/dnd/BadSerializaionTest/badAction - test/jdk/java/awt/dnd/BadSerializaionTest/good - test/jdk/java/awt/dnd/BadSerializaionTest/noEvents - test/jdk/java/awt/dnd/BadSerializaionTest/nullComponent - test/jdk/java/awt/dnd/BadSerializaionTest/nullDragSource - test/jdk/java/awt/dnd/BadSerializaionTest/nullOrigin - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh - test/langtools/tools/javadoc/api/basic/IsSupportedOptionTest.java From maurizio.cimadamore at oracle.com Fri Oct 5 00:32:25 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 05 Oct 2018 00:32:25 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810050032.w950WQKd020903@aojmv0008.oracle.com> Changeset: 04ce3009afc1 Author: mcimadamore Date: 2018-10-05 02:34 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/04ce3009afc1 Automatic merge with foreign ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/java.base/share/classes/module-info.java From shravya.rukmannagari at intel.com Fri Oct 5 01:25:44 2018 From: shravya.rukmannagari at intel.com (shravya.rukmannagari at intel.com) Date: Fri, 05 Oct 2018 01:25:44 +0000 Subject: hg: panama/dev: Shift, Gather, Scatter API and Test Changes for VectorAPI Message-ID: <201810050125.w951Pjeq014391@aojmv0008.oracle.com> Changeset: 65e8fe3ef0ce Author: srukmannagar Date: 2018-10-04 10:06 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/65e8fe3ef0ce Shift, Gather, Scatter API and Test Changes for VectorAPI ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/gen-template.sh ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-op.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template From maurizio.cimadamore at oracle.com Fri Oct 5 01:32:00 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 05 Oct 2018 01:32:00 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810050132.w951W1Jv018237@aojmv0008.oracle.com> Changeset: 2fbd466d32ee Author: mcimadamore Date: 2018-10-05 03:34 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/2fbd466d32ee Automatic merge with vectorIntrinsics From maurizio.cimadamore at oracle.com Fri Oct 5 13:47:47 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 5 Oct 2018 14:47:47 +0100 Subject: [foreign] RFR 8211722: Add comprehensive ABI test for downcalls In-Reply-To: <3fcb9dbf-bbe6-1cf4-d40b-6d571533e13d@oracle.com> References: <3fcb9dbf-bbe6-1cf4-d40b-6d571533e13d@oracle.com> Message-ID: <416ef0b0-2551-2ca2-568b-683e9108e49f@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8211722_v2 This new version adds testing for upcalls too. When writing the new upcall tests I realized that the downcall test was defeated (at least parts of it) by the O3 optimizations used when compiling the test libraries. As a result some of the library test code was not executed (as GCC could see that the body had no effect). Turns out there was a biggie issue with DIrectNativeInvoker/UpcallHandler: while it is safe to erase all integral values to 'long', it is not safe to erase all floating points to 'double' (as the representation of float and double is different, so accessing lowest 32 bits of the MMX register doesn't make sense and yields wrong value). So, this patch also disables direct approach when used with 'floats'. I also found a way to significantly up the numbers of checks carried out - now the generators break up the generated functions into chunks: f0_F f0_P ... f0_S f1_F f1_P ... f1_S Then, the test uses a bunch of regex filter to tell jextract not to extract everything at once. This way we can make sure that we can always split the test in a suitable way so that jextract will be ok. This allowed me to test with 3 parameters and 3 struct fields, which allows us to test structs that are 'too big' to fit in registers (e.g. passed in memory). I also added both 'double' and 'float' to the kind of struct field/parameter type that can be generated (in the last patch only 'float' was used). Please give it a try on Mac, as the generated c file use some pragmas to make sure optimizations are disabled. I used that in combination with #ifdef to avoid warnings about unrecognized pragmas, but better to double check. Cheers Maurizio On 04/10/18 17:39, Maurizio Cimadamore wrote: > Hi, > since we are now supporting multiple invocation schemes (for both > upcalls and downcalls) I thought it would be a good idea to start > testing the ABI code more in depth. I have created a generator which > creates an header/C file with aroun 2K different functions in it, each > of which is a specific permutation of a fixes set of parameter types. > Example: > > void f_PI_V_(void* p0, int p1) ; > void f_PF_V_(void* p0, float p1) ; > void f_PP_V_(void* p0, void* p1) ; > > The implementation of these functions (in the C file) is derived in a > simple way: > > * if the function is void, body is empty > * otherwise, it is assumed that the function will return its first > parameter > > For struct parameters the generator also generates several > combinations of struct fields, to make sure that everything works > correctly - here an example of the structs defined: > > struct S_II { int p0; int p1; }; > struct S_IF { int p0; float p1; }; > struct S_IP { int p0; void* p1; }; > > To keep the number of combination under control, I had to limit the > function arity to 3, and the struct field arity to 2. Otherwise the > extracted @NativeHeader had a declaration string which was too big to > fit in the constant pool (!!). > > The test extracts the header, loads the extracted classes and binds > them. Then it uses reflection to call every single function in the > header. This means that for every function to be called, the test will > have to synthesize some parameter values to be passed to the function. > In addition to all this, the test also verifies that, if a non-void > function is called, the function call returns a value that is equal to > the first argument passed. > > Needless to say, this test uncovered several issues which have been > fixed as part of this patch: > > * The universal invoker doesn't like empty structs; there were several > crashes, as no 'binding' was generated from them. Looking at the > System V ABI it's not even 100% clear what should happen in case of an > empty struct passed by value, but after inspecting output of clang/gcc > it seems evident that empty structs are simply skipped (e.g. they do > not take any register, which makes sense). So, to support this, I had > to add support for empty structs in the classing sequence builder, and > then special case UniversalInvoker::boxValue and > UniversalInvoker::unboxValue, accordingly (to avoid touching pointers > whose layout is void). > > * There was another issue in UniversalInvoker: when a function > returned a struct by value using multi-register return,? the register > values were not copied in the correct order into the resulting struct. > To fix this I had to tweak CallingSequence to add 'offsets' for return > types and fix the code in UniversalInvoker::invoke to compute the > offset into the return register array correctly (the code was > erroneously computing the offset using ArgumentBinding::getOffset). > > * The direct invocation scheme was also broken when mixed long and > floating point parameters were passed; more specifically, the > nativeMethodType signature was not normalized (e.g. put into a form > where longs came first then followed by doubles) and as a result we > failed to lookup the right method handle trampoline. I have fixed the > direct shuffler in a more general way - now a nativeMethodType is > always 'normalized' and additionally I tweaked the way in which method > handle permutations were computed, as I realized that the permutation > step has to be applied at different steps depending on whether we are > inside an upcall or a downcall (and with different method type targets > too). > > The resulting code passes the new ABI test (and all other tests too of > course); note that the new ABI test is ran two times: once w/o any > invocation scheme parameter (meaning NativeInvoker is free to chose > fast path if it wants) and another which force the universal scheme. > This should provide maximum coverage for both schemes. > > I will work separately on a similar approach to test upcalls (but I > think it's better to split given that this one is already biggie). > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8211722/ > > Cheers > Maurizio > > > From shravya.rukmannagari at intel.com Sat Oct 6 00:58:54 2018 From: shravya.rukmannagari at intel.com (shravya.rukmannagari at intel.com) Date: Sat, 06 Oct 2018 00:58:54 +0000 Subject: hg: panama/dev: VectorAPI Cleanup Message-ID: <201810060058.w960wsq0000686@aojmv0008.oracle.com> Changeset: 59ab423b2e46 Author: srukmannagar Date: 2018-10-05 09:39 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/59ab423b2e46 VectorAPI Cleanup ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVectorHelper.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVectorHelper.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Shapes.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorIntrinsics.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorHelper.java.template From maurizio.cimadamore at oracle.com Sat Oct 6 01:02:00 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 06 Oct 2018 01:02:00 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810060102.w96121QP002054@aojmv0008.oracle.com> Changeset: fb472bd7471e Author: mcimadamore Date: 2018-10-06 03:04 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/fb472bd7471e Automatic merge with vectorIntrinsics From samuel.audet at gmail.com Sat Oct 6 03:22:18 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Sat, 6 Oct 2018 12:22:18 +0900 Subject: on usability In-Reply-To: References: <138140e4ab654e59fa538b5438fdee9d@xs4all.nl> <71d58dfa-4bf2-382a-9449-e726f291b1e9@oracle.com> <3e25bf4a-1a75-357f-be72-fd36cbd3cf15@gmail.com> <1dde768f-2067-de80-2655-a881ae78c771@oracle.com> <39381ab4-f888-f7e9-3764-59b5dba1eca9@gmail.com> <2dac614c-8927-14d6-3303-8760b8088b09@gmail.com> Message-ID: Before I forget, thanks for your time discussing this, John and Maurizio! With regards to layouts, "ultimately not what layouts are for" -> You said it, that's exactly what concerns me here. They are not an answer to the bridge with C/C++ and, in my opinion, their complexity isn't helping people trying to do that. If they could be abstracted away somehow though, I would be fine with that. Yes, speeding things up like callbacks is a necessary condition for progress, but not a sufficient condition. We all know that Dvorak is better than QWERTY, at least for the English language, but people either just go with QWERTY to stay standard, or basically learn both. Dvorak doesn't work all that well in other languages, so the advantages are not clear cut and the status quo remains. That's what I think will happen here. We'll have the majority of users continue with JNI/JNA, and some doing both (to support older versions of the JDK and Android), for very specific uses cases like your visitor pattern of Clang. But it doesn't generalize to C++ templates, which are there for encapsulation, sure, but everything happens **inline** with C++ templates. How many times faster will a pure C++ implementation of your for loop just accessing a std::map be vs doing that in Java with JNI vs Panama linkToNative? That's what I want to know, and I think the pure C++ implementation will still be an order of magnitude faster than the hybrid Panama approach. Anyway, it's all speculations at this point, so before we can continue this discussion, we'll need some numbers! BTW, I'm particularly interested in this kind of use case: http://ceres-solver.org/nnls_tutorial.html#hello-world JavaCPP already supports that just fine, but JNI callbacks are little slow. Can Panama make it less than 2 times slower than a pure C++ implementation? If that's not possible, I feel it would be wise to plan a clear path from Panama to GraalVM, Truffle, and Sulong to be "future proof". Right now, it's not clear to me how Panama relates. Samuel On 10/03/2018 06:19 PM, Maurizio Cimadamore wrote: > > > On 03/10/18 04:57, Samuel Audet wrote: >> After discussing offline with John and Maurizio, I'd like to make a >> few additions to this thread. >> >> Although we need wrappers to make the interfaces more usable, those >> wrappers can eventually be generated at runtime, just like lambda >> expressions actually create classes dynamically. If we can make this >> part of the plan, that sounds good. Then we'd just need to make it all >> work to manage the native libraries, maybe using JavaCPP as reference >> since I'm not aware of any other serious attempt at packaging native >> libraries for multiple platforms. > Yep - our current interface + annotations will eventually need to land > on interface + annotation + code snippets which means we will need a > story to package up the 'code' bits and load them accordingly (we are > aware of the many limitations of System.loadXYZ which JavaCPP, among > others, attempt to solve). >> >> As for the layout definition language, I've learned that the idea >> comes from similar features found on other platforms such as Python's >> struct module, which does get used by most popular serialization >> methods out there (Protocol Buffers, FlatBuffers, Avro, etc): >> ????https://docs.python.org/2/library/struct.html > Few months ago I also put together a writeup which investigates the use > cases of message protocols and their descriptions: > > http://mail.openjdk.java.net/pipermail/panama-dev/2018-February/000940.html > > Some of the stuff in there actively influenced the design - for > instance, one might wonder as to why an 'address' in a Panama layout has > an explicit size - and the reason is that we want to accommodate not > just machine pointers, but also the near/far pointers encoding typically > found in protocol schemas. >> >> But I still think it's an overly complicated way of representing a >> "struct"... Couldn't we just list the member variables with methods or >> properties that access memory directly as with Swift or Substrate VM? >> Maybe that could even be part of the value types from Valhalla? We >> could then leave the layouts out of the interfaces for native code. >> What do you think John? >> >> As for C++ templates, we could have say std::map> MyObject>. How could we map this with Panama layouts without any calls >> to native functions? It's basically just data, but the structure's >> definition is implementation dependent. Could be red-black trees, a >> hash table, an entirely custom method, etc, so it's not something that >> I think we can support with Panama layouts without actually executing >> the C++ bits. > To follow your example, yes, we could model the layout of a > std::map (after all, this is a class which has > some fields) but we must also note that the 'size' of some of these > fields is data-dependent, which is not a problem dissimilar from what we > find in message protocol - see variable encoding used e.g. by protobuf > for varints. I call these 'dependent' layouts - e.g. where the _value_ > of some field gives away the size of a subsequent field. Below is one of > the most common forms of dependent layouts found in C/C++: > > int nelems; > int arr[] > > To know how big 'arr' is, you have to look 'nelems' up (this pattern is > in fact so common that C even attempted to capture it in its > variable-length-array feature - VLA). The layout assumes that these two > properties are entangled. If we sprinkle layouts with annotations which > make this dependency manifest, then the binder can act on this and could > interpret a layout looking up sizes in the dependent fields. Of course > there are well-formedness rules at play here: the dependency must always > go 'backwards' (although this is common in real code), otherwise the > binder wouldn't know at which 'offset' to find the relevant info. > > (digression: in reality a typical hashmap implementation is not _that_ > data dependent - typically a map is implemented as an array of buckets > which is resized dynamically - so the map object will typically store a > _pointer_ to such array - that is, the _shallow_ size of a map object is > _fixed_ and can therefore be represented with the layout descriptions we > have today) > > Your hashmap example is really the above example, but on steroids - not > only you have variability because of sizes (e.g. how many buckets does > the map have?) - but it is also variable in a _type_ (e.g. > std::string/MyObject in your example). The layout descriptions allow for > 'holes' that can be dynamically filled, and I think using something like > this will be the key to solve both problems, although I can imagine > that, when it comes to C++ template, capturing a template class with a > single layout might be challenging, since changing the type might also > insert/remove additional padding, depending on where the element to be > replaced is. > > And then there's an even deeper question:? layout descriptions are a > fine (albeit too complicated, for your tastes :-)) way to describe pure, > transparent, data aggregates. But when you move on to deal with OO > languages (such as C++), a layout of an object typically doesn't tell > the full story. You still need to call a method of that class to perform > a lookup and pull values out of the map - as the way that's done (and > the layout is used) is, ultimately, implementation specific (after all, > this is the concept known as _encapsulation_). That is, transparent data > can be extracted efficiently using layouts - but data that is > encapsulated behind object APIs need to be accessed using such APIs. In > which case the layout is mostly a way to make sense of the structure of > a C++ object, its size, etc. which is useful information when you need > to allocate memory and/or dereference pointers. > > So, to sum up - even if we had an uber precise layout description for > your map, our goal would NOT be to extract pieces of data (keys, values) > using the layout. Doing so would be similar to attempting to extract the > contents of a Java HashMap using Unsafe.getInt. You *could* do it > (assuming you knew all the details about the object impl you are > operating upon), but that would be totally unsafe and ultimately not > what layouts are for. That said, you still need a way to define what is > the 'basic' structure of such an hashmp (e.g. it could have an int for > the size, a pointer to a list of buckets...) - so that you know how many > byte must be allocated for one of these (empty) things, how much to > offset a pointer to one of this things, ... - and _that's_ what layouts > are used for. >> In any case, what I'm most interested in is the performance. JNI is >> already pretty fast, and tools such as JNR or JavaCPP have shown that >> it's possible to make it user friendly enough without any additional >> overhead. (Although given the popularity of JNA that's not something >> people typically care about all that much). Anyway, I'll be waiting >> for a version of "linkToNative" that we can start testing, try to >> modify JavaCPP to target the new API and classes, although I'm >> starting to get the feeling that the leap isn't going to be big enough >> for people to want to make the switch. After all, everyone will have >> to be supporting old versions of the JDK and Android for years to come... > The definition of 'fast enough' depends wildly on the use case at hand. > If you are invoking a single native method which is gonna sit there for > hours doing complex computation., then the JNI overhead is irrelevant, > no arguments about that. > > If you call functions whose implementation is more trivial then the JNI > overhead pops up. That's what you see in the benchmark I shared few > weeks ago. But there's a related point to make here: if native code and > Java code live in separate silos, then it is relatively natural for > people to be mindful of 'crossing' the JNI bridge, and try and come up > with ways to limit the number of times they do that (e.g. by aggregating > computation on the native side). > > But once we start lowering the barrier between Java and native, as > Panama and JavaCPP (and other solutions) do, you quickly run into > troubles; consider a very simple loop: > > for (...) { > ?? doSomething() > } > > If the method in the loop body is 100% Java, then you know that your > code will take advantage of several JIT optimizations (inlining, loop > unrolling, etc.). But say you now replace your loop body with a call to > another method, which is defined in terms of native code; suddenly the > JNI overhead pops up, as the JIT is no longer able to optimize your code > as well as it did before. However, if the JIT knew that this were 'just > a simple native call, no strings attached, no oops to worry about', then > it would be possible to model the native call within the JIT itself, > which leads you to a world where native code and jitted code cohexist > and mutually benefit from each other. > > In other words, as the interaction between Java and native code becomes > more complex (which is likely if we make it easy for people to 'switch' > to native), you'll start finding issues that might not be fully manifest > right now (unless you work in certain domains). As an example of that, > few months ago we have done an internal port of the clang API using > Panama (which is now committed as a Panama test) and found that the > performances of both JNI and Panama code are completely dominated by the > cost of making an upcall from native to Java - that's because clang is a > compiler and compilers like visitors - and a visitor is, well, at its > most fundamental core, a callback (in this case into Java code). So in > the clang case you have a single native call (e.g. clang_visitChildren') > which is making hundreds, thousands of upcalls into a Java visitor > method. That's a real case and is ultimately how jextract works. > > So, reducing JNI overhead, and improving integration between native code > and JIT in those cases could make a huge difference. > > Maurizio >> >> Samuel >> >> >> On 10/01/2018 02:29 PM, Samuel Audet wrote: >>> Hi, Jorn, Maurizio, >>> >>> I'm not talking about syntactic sugar, I'm fine with Java requiring >>> getters/setters and having an init() call somewhere. What I'm not OK >>> with is, just to call a native function, we have to call something >>> like Libraries.bind() every single time with the name of the class >>> and the path to the library, or save it somewhere in a field, and >>> then what do we do with it? How do we manage it across classes and >>> modules? Why can't the framework do that automatically for us? >>> >>> This is just one example of the usability problems that Panama isn't >>> solving over JNI, that yes Swift or GraalVM is solving, not with >>> wrappers, but at compile time as Maurizio points out. Panama could do >>> the same with an init() function if it decided not to go with vanilla >>> interfaces since the factory method pattern prevents this: You'll >>> need wrappers. >>> >>> Another usability problem is code that is hard to read, like for the >>> layouts, yes, which are neither easy to read nor write, I'm glad >>> Maurizio agrees, but there are no proposal to fix this because we're >>> committed to this approach as it's supposed to make things more >>> general... but they still won't work for C++ templates or >>> computational graphs! So, maybe everyone will want to use Truffle >>> anyway? >>> >>> BTW, Swift does support offsetof(), here's the proposal status: >>> https://github.com/apple/swift-evolution/blob/master/proposals/0210-key-path-offset.md >>> >>> "Status: Implemented (Swift 4.2)": Open source at work! >>> >>> BTW2, the example from GraalVM that I gave isn't from Truffle, it's >>> from the "Substrate VM" codebase: It's completely unrelated. >>> >>> JNI is already very capable. As Maurizio points out in his reply, the >>> whole point of Panama is not to improve the capabilities of JNI, it's >>> to improve the *usability* and the *performance*, but after over 4 >>> years of work, I still do not see how it will be able to fulfill >>> either goals! Let's maybe work on "linkToNative" and get this shipped >>> already to let others work on things like jextract? That might be >>> worth it, but it's not happening. Priorities are elsewhere, although >>> it's not clear to me where exactly. >>> >>> You see, in my opinion, the problem with Panama vs others like >>> GraalVM, LLVM, or Swift is that the link with the community is >>> missing. Decisions are made purely on an internal basis with no >>> communication with the outside. If you Jorn like where Panama is >>> going on a technical basis, that's great, but I'm not, and probably >>> others are not either, but there is no forum to have a discussion >>> about this. >>> >>> In any case, the Java community is a bit wider than OpenJDK, so maybe >>> one day Truffle will get integrated into the JDK before Panama gets >>> anywhere, or Substrate VM will "replace" HotSpot, since AOT is pretty >>> much required for platforms like iOS, Google might become interested >>> in using it for Android too, and everyone's already bundling the JRE >>> with their desktop apps these days anyway. >>> >>> Samuel >>> >>> On 09/26/2018 06:39 PM, Jorn Vernee wrote: >>>> The Swift example looks cool and I can say 2 things about that: >>>> >>>> 1.) Swift seems to have properties (i.e. syntactic sugar for getters >>>> and setter), so It's much easier to inject some code that accesses >>>> an underlying C struct instead of a backing field. I think at least >>>> for the time being, the Java equivalent would be getters and >>>> setters. But tbh I don't see that much usability problems with that, >>>> since it's more or less the same amount of characters to write: >>>> `myStruct.x = 10` vs. `myStruct.x$set(10)` (especially considering >>>> auto-completion). It just doesn't look as fancy. >>>> >>>> 2.) I guess jextract could generate an equivalent of the 2 `Init()` >>>> functions as well for generated structs, and that would be part of >>>> the 'civilisation layer' Maurizio mentioned. With current tech, it >>>> would probably either create and leak a scope internally, or you'd >>>> have to pass a scope. Maybe a long term solution could be something >>>> like using a default scope that is managed by the garbage collector. >>>> The generated struct would not have a tight life-cycle (GC lazily >>>> collects objects), but it would be easier to use. >>>> >>>> The Graal native access stuff uses truffle, i.e. it is baked into >>>> the interpreter. But the truffle interpreter is built to be very >>>> customizeable, so I think doing the same with the Hotspot >>>> interpreter would be far more difficult. But either way, the way >>>> Graal maps a C struct to an interface in that example looks pretty >>>> similar to what panama is doing to me. >>>> >>>> I think panama is making sane choices, and focusing on capability >>>> before usability. panama is just not as far along as the other >>>> projects you mention, and I think more usability (jextract >>>> civilization layer) and better performance (linkToNative backend) >>>> are yet to come. >>>> >>>> Jorn >>>> >>>> Samuel Audet schreef op 2018-09-26 03:14: >>>>> We can do a lot of wrapper magic in either Java or C++. JavaCPP >>>>> already does for JNI what Jorn is describing we could do for Panama: >>>>> https://github.com/bytedeco/javacpp-presets/tree/master/systems#the-srcmainjavatestavxjava-source-file >>>>> >>>>> >>>>> If we consider JNI to be "legacy", it makes a lot of sense to try and >>>>> do some acrobatics like that to support legacy systems, but why not >>>>> make the new hotness actually _usable_? Take a look at how Swift does >>>>> it: >>>>> https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift >>>>> >>>>> >>>>> Now that's what I call *usable*. Panama is very far from that level of >>>>> usability. And it's not because the Java language is somehow >>>>> handicapped. Check what the guys over at GraalVM are doing: >>>>> https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.tutorial/src/com/oracle/svm/tutorial/CInterfaceTutorial.java >>>>> >>>>> >>>>> It also features performance that's already apparently higher than >>>>> JNI: >>>>> https://cornerwings.github.io/2018/07/graal-native-methods/ >>>>> >>>>> Why not do something user friendly like that in Panama's case as well? >>>>> What's the rationale to make it all in the end as complicated to use >>>>> as JNI? Maybe there's something I'm missing, so please point it out. >>>>> >>>>> Samuel >>>>> >>>>> >>>>> On 09/24/2018 10:37 PM, Maurizio Cimadamore wrote: >>>>>> Having a pre-extracted stdlib bundle is something we have >>>>>> considered - quoting from [1]: >>>>>> >>>>>> "Now, since most (all?) of the libraries out there are going to >>>>>> assume >>>>>> the availability of some 'standard library', let's also assume >>>>>> that some >>>>>> extracted artifact for such library is available and that jextract >>>>>> always knows how to find it - this is the equivalent of java.base for >>>>>> the module system, or java.lang for the Java import system. This >>>>>> addresses the bootstrapping issue." >>>>>> >>>>>> In time we'll get there, I don't see any real technical obstacles >>>>>> to get to your 'optimal' snippet. >>>>>> >>>>>> I think there are two aspects that I'd like to draw attention upon: >>>>>> >>>>>> 1) Magic does not come for free. E.g. it might "seem" that JNI has >>>>>> a more direct approach to calling native methods (ease of use >>>>>> issues aside). In reality it's just that the complexity of calling >>>>>> that native method, marshalling arguments, unmarshalling returns, >>>>>> dealing with native thread transitions and what's not has just >>>>>> been pushed under the JVM rug. So, yes, you can "just" call getpid >>>>>> - but the burden is on the VM. Now, the JNI support is already >>>>>> quite complex - I can't honestly imagine a sane way for the VM to >>>>>> support any given invocation scheme that a user might wish to see >>>>>> supported. This is why Panama is betting on Java code + layouts to >>>>>> do the lifting: that way the VM interface can be kept simple >>>>>> (which has significant payoffs - as the resulting code can be >>>>>> optimized much more - see the linkToNative experimental results in >>>>>> [2]). >>>>>> >>>>>> 2) As your example points out, while calling 'getpid' is something >>>>>> that seems 'easy' enough - 'puts' is already some other beast. It >>>>>> takes a pointer to some memory location where the string is >>>>>> stored. The JNI approach is to pass the Java string as is, and >>>>>> then do the wiring in native code. That is, there's no free lunch >>>>>> here - either you do the adaptation in Java, or you do it in >>>>>> native code (**). Panama gives you a rich enough API to do all >>>>>> such adaptations in Java, so that all native calls are... just >>>>>> native calls (again this means more regularity which means more >>>>>> performances). Having opaque native code snippets which do >>>>>> argument adaptation is not very optimal (and optimizable) for the >>>>>> JVM. With Panama you can create a good-looking API which >>>>>> internally uses pointers/scopes and delegates to the right native >>>>>> method - all done in Java. On top of that, our plans cover a so >>>>>> called 'civilization' layer (see [3]), by which users will be able >>>>>> to customize what comes out of jextract in order e.g. to tell that >>>>>> for 'puts' they really want a Java String argument and not a >>>>>> Pointer; again this will be done in a more general way, so >>>>>> that the binder will be pointed at a pair of functions which can >>>>>> be used to map the user provided data to and from native code. >>>>>> >>>>>> (**) for an example of how interfacing with standard libraries >>>>>> needs some kind of wrapping, even in JNI - look at [4]; this file >>>>>> is essentially a collection of system calls which are wrapped by >>>>>> some logic (e.g. to check errno, ...). I claim that there is >>>>>> something _fundamentally_ wrong with code like this, in that the >>>>>> native code is mixing two concerns: (i) performing the required >>>>>> native call and (ii) adjusting input/output/errors of the call in >>>>>> a way that is suitable to the corresponding Java API. Why >>>>>> shouldn't the Java API itself be in charge of doing (ii) ? >>>>>> >>>>>> Maurizio >>>>>> >>>>>> [1] - >>>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-August/002560.html >>>>>> >>>>>> [2] - >>>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-September/002652.html >>>>>> [3] - >>>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001537.html >>>>>> >>>>>> [4] - >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c#l314 >>>>>> On 24/09/18 13:34, Jorn Vernee wrote: >>>>>>> I agree with the usability point. In C++ it's as simple to call >>>>>>> puts as doing: >>>>>>> >>>>>>> ??? #include >>>>>>> >>>>>>> ??? int main() { >>>>>>> ??????? puts("Hello World!"); >>>>>>> ??? } >>>>>>> >>>>>>> And I think the optimal Java equivalent would be something like: >>>>>>> >>>>>>> ??? import static org.openjdk.stdio.*; >>>>>>> >>>>>>> ??? public class Main { >>>>>>> >>>>>>> ??????? public static void main(String[] args) { >>>>>>> ??????????? puts("Hello World!"); >>>>>>> ??????? } >>>>>>> >>>>>>> ??? } >>>>>>> >>>>>>> This can be facilitated by creating a 'singleton facade' for the >>>>>>> library interface like so: >>>>>>> >>>>>>> ??? public class stdio { >>>>>>> >>>>>>> ??????? private static final stdioImpl lib = >>>>>>> Libraries.bind(lookup(), stdioImpl.class); >>>>>>> >>>>>>> ??????? public static int puts (String message) { >>>>>>> ??????????? try(Scope scope = Scope.newNativeScope()) { >>>>>>> ??????????????? Pointer msg = scope.toCString(message); >>>>>>> ??????????????? return lib.puts(msg); >>>>>>> ??????????? } >>>>>>> ??????? } >>>>>>> >>>>>>> ??????? ... >>>>>>> ??? } >>>>>>> >>>>>>> Such a facade class could be shipped with the JDK or perhaps as >>>>>>> an artifact on maven central, or maybe it could be an additional >>>>>>> output of jextract. >>>>>>> >>>>>>> But there is only so much you can do automagically from the Java >>>>>>> side. When working from C/C++ you have the compiler filling in >>>>>>> the blanks. For instance, it automatically allocates storage for >>>>>>> string literals. Java does that as well for Java string literals >>>>>>> `String s = "Hello";`, but it can not do that for native strings, >>>>>>> and you have to use the Scope API to do that manually. In some >>>>>>> cases, like the above, you can write glue-code to make that >>>>>>> automatic, but I think at some point things become too complex >>>>>>> for that, and there will always be some usability barrier to >>>>>>> interop. >>>>>>> >>>>>>> Jorn >>>>>>> >>>>>>> Samuel Audet schreef op 2018-09-24 13:38: >>>>>>>> FWIW, I think the factory method pattern should be reconsidered >>>>>>>> entirely. In C/C++, when we want to call say getpid(), we don't >>>>>>>> start >>>>>>>> loading stuff up before calling getpid(), we call getpid()! Why >>>>>>>> not do >>>>>>>> the same from Java? From a usability point of view, not loading >>>>>>>> stuff >>>>>>>> manually works fine for JavaCPP... >>>>>>>> >>>>>>>> Now, I know you're going to start taking about interfaces and what >>>>>>>> not. You said that you had plans to introduce an entirely new array >>>>>>>> type just to make it more friendly with vector instructions and >>>>>>>> native >>>>>>>> libraries. Why not start thinking about an "interface" that >>>>>>>> would be >>>>>>>> friendly to native libraries as well? Why stop at arrays? >>>>>>>> >>>>>>>> Samuel >>>>>>>> From sundararajan.athijegannathan at oracle.com Mon Oct 8 12:19:36 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 08 Oct 2018 17:49:36 +0530 Subject: [foreign] RFR 8211722: Add comprehensive ABI test for downcalls Message-ID: <5BBB4B58.7030505@oracle.com> Response to -> http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002879.html I tested this patch on Mac. All tests pass. -Sundar From maurizio.cimadamore at oracle.com Mon Oct 8 12:18:08 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 8 Oct 2018 13:18:08 +0100 Subject: [foreign] RFR 8211722: Add comprehensive ABI test for downcalls In-Reply-To: <5BBB4B58.7030505@oracle.com> References: <5BBB4B58.7030505@oracle.com> Message-ID: <718b9129-9b52-49f1-b140-a0a243c6142f@oracle.com> Thanks, I'll go for it then Maurizio On 08/10/18 13:19, Sundararajan Athijegannathan wrote: > Response to -> > http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002879.html > I tested this patch on Mac. All tests pass. > > -Sundar > From maurizio.cimadamore at oracle.com Mon Oct 8 12:34:22 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 12:34:22 +0000 Subject: hg: panama/dev: 8211722: Add comprehensive ABI test for downcalls/upcalls Message-ID: <201810081234.w98CYNqf008394@aojmv0008.oracle.com> Changeset: 1887e484d777 Author: mcimadamore Date: 2018-10-04 17:44 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/1887e484d777 8211722: Add comprehensive ABI test for downcalls/upcalls Reviewed-by: sundar ! src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java ! src/java.base/share/classes/jdk/internal/foreign/abi/StorageClass.java ! src/java.base/share/classes/jdk/internal/foreign/abi/sysv/x64/CallingSequenceBuilderImpl.java ! src/java.base/share/classes/jdk/internal/foreign/invokers/DirectSignatureShuffler.java ! src/java.base/share/classes/jdk/internal/foreign/invokers/UniversalNativeInvoker.java + test/jdk/com/sun/tools/jextract/TestDowncall.java + test/jdk/com/sun/tools/jextract/TestDowncallGenerator.java + test/jdk/com/sun/tools/jextract/TestUpcall.java + test/jdk/com/sun/tools/jextract/TestUpcallGenerator.java + test/jdk/com/sun/tools/jextract/libTestDowncall.c + test/jdk/com/sun/tools/jextract/libTestDowncall.h + test/jdk/com/sun/tools/jextract/libTestUpcall.c + test/jdk/com/sun/tools/jextract/libTestUpcall.h From maurizio.cimadamore at oracle.com Mon Oct 8 12:37:04 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 08 Oct 2018 12:37:04 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810081237.w98Cb5Tu009413@aojmv0008.oracle.com> Changeset: db992c2acfe1 Author: mcimadamore Date: 2018-10-08 14:39 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/db992c2acfe1 Automatic merge with foreign From Ningsheng.Jian at arm.com Tue Oct 9 06:56:59 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Tue, 9 Oct 2018 06:56:59 +0000 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> Message-ID: Hi Vladimir, Thanks for your comments! > >> Overall, I like how it shapes out. There are some aspects I'd like to clarify > though. > >> > >> The name (*ScalableVector) is slightly misleading to me, but I'm fine > >> with it. I interpret new shapes as representing vectors of maximally > >> supported size at runtime without specifying the actual size. > >> > > > > I am happy to change the name if you have some suggestion. The new shapes > are representing current (SVE) hardware supported (max) vector register size, > and the actual size is known at runtime. > > Yes, I'd like the names to clearly manifest it's the vector of maximum size > available at runtime. Maybe *MaxVector, but I'm not too happy with it as well. > OK, but I think Max could not imply the point of one shape to fit multiple sizes. I was thinking about VL (variable length), but finally used current name to align with SVE (Scalable Vector Extension). > >> New shapes don't interoperate well with existing ones, so unless you > >> change how vector shapes are checked (==), at runtime scalable and > >> fixed shape variants shouldn't meet. That leads to the next question: > >> how do you expect vector shape changing operation working (resize(), > rebracket(), cast()) with new variants? > >> > > > > Those vector changing operations are in my TODO list. The scalable shapes are > actually fixed length shape during runtime, so I think it is possible to implement > those operations. But I am still don't quite understand the motivation and use > cases of those vector shape changing APIs. Could you please help to explain a > bit? > > There are 4 methods which change vector shape: resize/rebracket/reshape and > cast. > > (1) Vector.resize() changes only vector length (either shrinking or > widening) without touching element types: > Int64Vector <-> Int128Vector <-> Int256Vector <-> Int512Vector > > Javadoc for Shape.resize() says [2]: > * The lane elements of the input vector are copied without > * modification to the resulting vector, but those lane elements, before > * copying, may be truncated if the vector length is greater than this > * species length, or appended to with default element values if the > * vector length is less than this species length. > > > (2) Vector.rebracket() changes only vector element type leaving vector size > intact > Byte256Vector <-> Short256Vector <-> Int256Vector <-> Long256Vector > > Javadoc says [3]: > * The underlying bits of the input vector are copied without > * modification to the resulting vector. > > > (3) Vector.reshape generalizes resize() & rebracket() and enables arbitrary > conversions between vector shapes: > Byte64Vector <-> ... <-> Double512Vector > * The underlying bits of the input vector are copied to the resulting > * vector without modification, but those bits, before copying, may be > * truncated if the vector bit size is greater than this species bit > * size, or appended to with zero bits if the vector bit size is less > * than this species bit size. > > > (4) Vector.cast() allows arbitrary casts between vector shapes > Byte64Vector <-> ... <-> Double512Vector > > Javadoc for Shape.cast() says [4]: > * For each input vector lane up to the length of the input vector or > * this species, which ever is the minimum, and where {@code N} is the > * vector lane index, the element at index {@code N} of primitive type > * {@code F} is converted, according to primitive conversion rules > * specified by the Java Language Specification, to a value of primitive > * type {@code E} and placed into the resulting vector at lane index > * {@code N}. If this species length is greater than the input > * vector length then the default primitive value is placed into > * subsequent lanes of the resulting vector. > > Right now, resize(), rebracket(), and cast() are intrinsified on x86 > while reshape() is not. > > > So, my question boils down to: how vector shape checks are expected to > work on *ScalableVectors in presence of operations which change vector size. > > For example, IntScalableVector.rebracket() => LongScalableVector which > is fine, but ISV.resize() => ISV is what I'm concerned about and > existing checks aren't enough for *ScalableVectors unless you check > their length at runtime. > Thanks for the detailed explanation. So, which checks do you mean here? Do you mean this [1]? I find that current Java implementations already has some runtime length checks. One thing we need to consider is the ambiguity between existing sizes and scalable size. Current VectorIntrinsics.reinterpret() just tries to get the shape from size (library_call.cpp:get_exact_klass_for_vector_box) instead of getting the real class from input argument, which will lead to ClassCastException. Maybe that can be fixed by adding real klass type to the reinterpret function. [1] http://hg.openjdk.java.net/panama/dev/file/e8f06cc3fe82/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java#l1513 Thanks, Ningsheng From maurizio.cimadamore at oracle.com Tue Oct 9 10:33:05 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Oct 2018 11:33:05 +0100 Subject: [foreign] RFR 8211924: Tweak Panama/foreign build to be friendly with automated build and test Message-ID: Hi, this patch (contributed by Erik Joelsson) tweaks the Panama/foreign build to be friendly with our automated build and test infra. As it can be seen a step has been added to build the relevant clang libraries on systems such as Linux - which were failing to build when using the supplied devkit. Webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8211924/ Cheers Maurizio From sundararajan.athijegannathan at oracle.com Tue Oct 9 10:52:27 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 09 Oct 2018 16:22:27 +0530 Subject: [foreign] RFR 8211924: Tweak Panama/foreign build to be friendly with automated build and test In-Reply-To: References: Message-ID: <5BBC886B.8040107@oracle.com> Looks good. I built & tested "jdk_foreign" on Mac and Linux. Builds are fine. All jdk_foreign tests pass. Thanks, -Sundar On 09/10/18, 4:03 PM, Maurizio Cimadamore wrote: > Hi, > this patch (contributed by Erik Joelsson) tweaks the Panama/foreign > build to be friendly with our automated build and test infra. As it > can be seen a step has been added to build the relevant clang > libraries on systems such as Linux - which were failing to build when > using the supplied devkit. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8211924/ > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Tue Oct 9 10:47:31 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 09 Oct 2018 10:47:31 +0000 Subject: hg: panama/dev: 8211924: Tweak Panama/foreign build to be friendly with automated build and test Message-ID: <201810091047.w99AlVwR009465@aojmv0008.oracle.com> Changeset: 63a77030bcfa Author: mcimadamore Date: 2018-10-09 11:47 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/63a77030bcfa 8211924: Tweak Panama/foreign build to be friendly with automated build and test Reviewed-by: sundar Contributed-by: erikj ! make/RunTests.gmk ! make/autoconf/lib-clang.m4 ! make/common/Modules.gmk ! make/conf/jib-profiles.js ! make/copy/Copy-jdk.jextract.gmk + make/devkit/createLibclangBundle.sh ! make/lib/Lib-jdk.internal.clang.gmk From maurizio.cimadamore at oracle.com Tue Oct 9 10:47:35 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Oct 2018 11:47:35 +0100 Subject: [foreign] RFR 8211924: Tweak Panama/foreign build to be friendly with automated build and test In-Reply-To: <5BBC886B.8040107@oracle.com> References: <5BBC886B.8040107@oracle.com> Message-ID: Pushed, thanks Maurizio On 09/10/18 11:52, Sundararajan Athijegannathan wrote: > Looks good. > > I built & tested "jdk_foreign" on Mac and Linux. Builds are fine. All > jdk_foreign tests pass. > > Thanks, > -Sundar > > On 09/10/18, 4:03 PM, Maurizio Cimadamore wrote: >> Hi, >> this patch (contributed by Erik Joelsson) tweaks the Panama/foreign >> build to be friendly with our automated build and test infra. As it >> can be seen a step has been added to build the relevant clang >> libraries on systems such as Linux - which were failing to build when >> using the supplied devkit. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8211924/ >> >> Cheers >> Maurizio >> From maurizio.cimadamore at oracle.com Tue Oct 9 10:52:49 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 09 Oct 2018 10:52:49 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810091052.w99AqnXE011233@aojmv0008.oracle.com> Changeset: 4664d815e902 Author: mcimadamore Date: 2018-10-09 12:54 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/4664d815e902 Automatic merge with foreign ! make/common/Modules.gmk From maurizio.cimadamore at oracle.com Tue Oct 9 12:31:55 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Oct 2018 13:31:55 +0100 Subject: [foreign] RFR 8211925: Remove jdk.internal.clang from list of upgradeable modules Message-ID: Hi, while ago, to get the Jextract-FFI test working we added (as a short term measure) jdk.internal.clang and jdk.jextract to th elist of upgradeable modules. Itis now time to revert that, since this is causing issues with tier1 tests in jdk_lang group. This pathc reverts that change and, instead, uses --patch-module to achieve same effect. Webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8211925/ Cheers Maurizio From sundararajan.athijegannathan at oracle.com Tue Oct 9 12:59:37 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 09 Oct 2018 18:29:37 +0530 Subject: [foreign] RFR 8211925: Remove jdk.internal.clang from list of upgradeable modules In-Reply-To: References: Message-ID: <5BBCA639.9080006@oracle.com> Looks good. PS. Tested this patch on Linux and Mac. All jdk_lang tests ran fine. -Sunda On 09/10/18, 6:01 PM, Maurizio Cimadamore wrote: > Hi, > while ago, to get the Jextract-FFI test working we added (as a short > term measure) jdk.internal.clang and jdk.jextract to th elist of > upgradeable modules. Itis now time to revert that, since this is > causing issues with tier1 tests in jdk_lang group. This pathc reverts > that change and, instead, uses --patch-module to achieve same effect. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8211925/ > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Tue Oct 9 12:54:14 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 09 Oct 2018 12:54:14 +0000 Subject: hg: panama/dev: 8211925: Remove jdk.internal.clang from list of upgradeable modules Message-ID: <201810091254.w99CsExR005175@aojmv0008.oracle.com> Changeset: 3fc8bbd10061 Author: mcimadamore Date: 2018-10-09 13:53 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/3fc8bbd10061 8211925: Remove jdk.internal.clang from list of upgradeable modules Reviewed-by: sundar ! make/common/Modules.gmk ! test/jdk/com/sun/tools/jextract/jclang-ffi/TestJextractFFI.java From maurizio.cimadamore at oracle.com Tue Oct 9 12:56:56 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 09 Oct 2018 12:56:56 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810091256.w99Cuug9008098@aojmv0008.oracle.com> Changeset: b88d0a4e927c Author: mcimadamore Date: 2018-10-09 14:59 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b88d0a4e927c Automatic merge with foreign ! make/common/Modules.gmk From sundararajan.athijegannathan at oracle.com Wed Oct 10 11:58:12 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 10 Oct 2018 17:28:12 +0530 Subject: [foreign] RFR 8212002: jdk.internal.org.objectweb.asm.util need not be qualified exported to jdk.jextract Message-ID: <5BBDE954.20807@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8212002 Webrev: http://cr.openjdk.java.net/~sundar/8212002/webrev.00/ Thanks -Sundar From maurizio.cimadamore at oracle.com Wed Oct 10 13:42:49 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Oct 2018 14:42:49 +0100 Subject: [foreign] RFR 8212002: jdk.internal.org.objectweb.asm.util need not be qualified exported to jdk.jextract In-Reply-To: <5BBDE954.20807@oracle.com> References: <5BBDE954.20807@oracle.com> Message-ID: Looks good Maurizio On 10/10/18 12:58, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212002 > > Webrev: http://cr.openjdk.java.net/~sundar/8212002/webrev.00/ > > Thanks > -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 10 14:10:40 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 10 Oct 2018 14:10:40 +0000 Subject: hg: panama/dev: 8212002: jdk.internal.org.objectweb.asm.util need not be qualified exported to jdk.jextract Message-ID: <201810101410.w9AEAfbP023628@aojmv0008.oracle.com> Changeset: 1785437bf461 Author: sundar Date: 2018-10-10 19:49 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/1785437bf461 8212002: jdk.internal.org.objectweb.asm.util need not be qualified exported to jdk.jextract Reviewed-by: mcimadamore ! src/java.base/share/classes/module-info.java From maurizio.cimadamore at oracle.com Wed Oct 10 14:12:02 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 10 Oct 2018 14:12:02 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810101412.w9AEC2TP025736@aojmv0008.oracle.com> Changeset: a7bc90d39432 Author: mcimadamore Date: 2018-10-10 16:14 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/a7bc90d39432 Automatic merge with foreign ! src/java.base/share/classes/module-info.java From sundararajan.athijegannathan at oracle.com Wed Oct 10 17:42:01 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 10 Oct 2018 23:12:01 +0530 Subject: [foreign] RFR Clean up TestJextractFFI.java module path, add reads Message-ID: <5BBE39E9.2060303@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8212013 Webrev: http://cr.openjdk.java.net/~sundar/8212013/webrev.00/ Thanks, -Sundar From maurizio.cimadamore at oracle.com Wed Oct 10 17:34:12 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Oct 2018 18:34:12 +0100 Subject: [foreign] RFR Clean up TestJextractFFI.java module path, add reads In-Reply-To: <5BBE39E9.2060303@oracle.com> References: <5BBE39E9.2060303@oracle.com> Message-ID: <6e97e55e-e43a-a6e3-79c2-1fcc65f4a08f@oracle.com> Looks good Maurizio On 10/10/18 18:42, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212013 > Webrev: http://cr.openjdk.java.net/~sundar/8212013/webrev.00/ > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 10 17:38:13 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 10 Oct 2018 17:38:13 +0000 Subject: hg: panama/dev: 8212013: Clean up TestJextractFFI.java module path, add reads Message-ID: <201810101738.w9AHcDVQ029822@aojmv0008.oracle.com> Changeset: 32fe756ce0a3 Author: sundar Date: 2018-10-10 23:17 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/32fe756ce0a3 8212013: Clean up TestJextractFFI.java module path, add reads Reviewed-by: mcimadamore ! test/jdk/com/sun/tools/jextract/jclang-ffi/TestJextractFFI.java From maurizio.cimadamore at oracle.com Wed Oct 10 17:42:00 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 10 Oct 2018 17:42:00 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810101742.w9AHg0YL003631@aojmv0008.oracle.com> Changeset: d7a44f62c093 Author: mcimadamore Date: 2018-10-10 19:44 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d7a44f62c093 Automatic merge with foreign From maurizio.cimadamore at oracle.com Wed Oct 10 20:03:44 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 10 Oct 2018 20:03:44 +0000 Subject: hg: panama/dev: 75 new changesets Message-ID: <201810102003.w9AK3o4S005511@aojmv0008.oracle.com> Changeset: 35511492cd6d Author: kvn Date: 2018-10-03 14:53 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/35511492cd6d 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError Summary: exclude this test from running with Java Graal Reviewed-by: iveresov ! test/hotspot/jtreg/compiler/uncommontrap/TestDeoptOOM.java Changeset: ef114f6afcf1 Author: jwilhelm Date: 2018-10-04 00:50 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/ef114f6afcf1 Added tag jdk-12+14 for changeset 8897e41b327c ! .hgtags Changeset: 8705c6d536c5 Author: jwilhelm Date: 2018-10-04 10:35 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/8705c6d536c5 Added tag jdk-12+14 for changeset 6f04692c7d51 ! .hgtags Changeset: 6f58ecdb060a Author: nishjain Date: 2018-10-04 17:25 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/6f58ecdb060a 8166138: DateTimeFormatter.ISO_INSTANT should handle offsets Reviewed-by: rriggs, scolebourne, naoto Contributed-by: pallavi.sonal at oracle.com ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/jdk/java/time/tck/java/time/format/TCKInstantPrinterParser.java Changeset: 92383597fa21 Author: rehn Date: 2018-10-04 14:03 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/92383597fa21 8210303: VM_HandshakeAllThreads fails assert with "failed: blocked and not walkable" Reviewed-by: dcubed, dholmes ! src/hotspot/share/runtime/handshake.cpp Changeset: 1aa9beac610e Author: mdoerr Date: 2018-10-04 16:39 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/1aa9beac610e 8210754: print_location is not reliable enough (printing register info) Reviewed-by: stuefe, coleenp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 821bfc24d750 Author: mchung Date: 2018-10-04 08:45 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/821bfc24d750 8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass Reviewed-by: alanb, egahlin ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/jdk/internal/reflect/ClassDefiner.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventClassBuilder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventHandlerCreator.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java ! test/hotspot/jtreg/compiler/jsr292/NonInlinedCall/RedefineTest.java ! test/hotspot/jtreg/compiler/unsafe/UnsafeGetConstantField.java ! test/hotspot/jtreg/runtime/Dictionary/CleanProtectionDomain.java Changeset: 9ea22a0f9540 Author: vromero Date: 2018-10-04 08:37 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9ea22a0f9540 8211148: var in implicit lambdas shouldn't be accepted for source < 11 Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + test/langtools/tools/javac/diags/examples/VarInImplicitLambda.java ! test/langtools/tools/javac/lambda/LambdaParserTest.java ! test/langtools/tools/javac/var_implicit_lambda/VarInImplicitLambdaNegTest01.java ! test/langtools/tools/javac/var_implicit_lambda/VarInImplicitLambdaNegTest01.out + test/langtools/tools/javac/var_implicit_lambda/VarInImplicitLambdaNegTest01_source10.out Changeset: d3424ddad792 Author: gdub Date: 2018-08-17 12:19 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d3424ddad792 8209136: [JVMCI] Make sure volatile fields are read as volatile during constant reflection. Reviewed-by: kvn ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java Changeset: 592dff6ac440 Author: erikj Date: 2018-10-04 09:43 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/592dff6ac440 8211677: Java resource copy and clean should use MakeTargetDir macro Reviewed-by: tbell, ihse ! make/common/JavaCompilation.gmk Changeset: d63efc278e93 Author: vromero Date: 2018-10-04 10:19 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/d63efc278e93 8210789: langtools/tools/javac/T8152616.java missing @modules Reviewed-by: jjg ! test/langtools/tools/javac/T8152616.java Changeset: 4c247dde38ed Author: mchung Date: 2018-10-04 13:02 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/4c247dde38ed 8206240: java.lang.Class.newInstance() is causing caller to leak Reviewed-by: alanb ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/ReflectAccess.java ! src/java.base/share/classes/jdk/internal/reflect/LangReflectAccess.java ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! test/jdk/java/lang/StackWalker/ReflectionFrames.java ! test/jdk/java/lang/reflect/callerCache/AccessTest.java ! test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java ! test/jdk/jdk/modules/open/Basic.java Changeset: 7b90af8664ca Author: naoto Date: 2018-10-04 14:12 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/7b90af8664ca 8211398: Square character support for the Japanese new era Reviewed-by: rriggs ! make/data/unicodedata/UnicodeData.txt ! src/java.base/share/classes/java/lang/Character.java ! test/jdk/java/lang/Character/Scripts.txt ! test/jdk/java/lang/Character/UnicodeData.txt ! test/jdk/java/lang/Character/charprop00.bin Changeset: 804792ce736f Author: rwestberg Date: 2018-10-05 07:54 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/804792ce736f 8210459: Add support for generating compile_commands.json Reviewed-by: erikj, ihse + make/CompileCommands.gmk ! make/Main.gmk ! make/ModuleWrapper.gmk ! make/common/JdkNativeCompilation.gmk ! make/common/NativeCompilation.gmk ! make/conf/jib-profiles.js ! make/hotspot/lib/CompileJvm.gmk ! make/launcher/Launcher-jdk.pack.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/Lib-jdk.accessibility.gmk ! make/lib/LibCommon.gmk + test/make/TestCompileCommands.gmk ! test/make/TestMake.gmk Changeset: d0c04d180a3b Author: michaelm Date: 2018-10-05 11:28 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/d0c04d180a3b 8211420: com.sun.net.httpserver.HttpServer returns Content-length header for 204 response code Reviewed-by: chegar ! src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java + test/jdk/com/sun/net/httpserver/bugs/B8211420.java Changeset: 257ae7e677c3 Author: hseigel Date: 2018-10-05 08:50 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/257ae7e677c3 8211438: [Testbug] runtime/XCheckJniJsig/XCheckJSig.java looks for libjsig in wrong location Summary: Remove the os_arch string and JRE path from the test. Also add JNIEXPORT to libjsig symbols so dlsym can find them Reviewed-by: dholmes, lfoltan ! src/java.base/unix/native/libjsig/jsig.c ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/XCheckJniJsig/XCheckJSig.java Changeset: e75f6076d391 Author: coleenp Date: 2018-10-05 09:15 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/e75f6076d391 8209889: RedefineStress tests crash Summary: Create CompileTaskWrapper before potential safepoint Reviewed-by: mdoerr, dlong ! src/hotspot/share/compiler/compileBroker.cpp Changeset: 286389b60292 Author: kbarrett Date: 2018-10-05 14:28 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/286389b60292 8211296: Remove HotSpot deprecation warning suppression for Mac/clang Summary: Removed deprecation warning suppression, fixed uses of deprecated functions. Reviewed-by: dholmes, mikael ! make/hotspot/lib/CompileJvm.gmk ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/share/utilities/globalDefinitions_gcc.hpp Changeset: 549bc49734e8 Author: jcbeyler Date: 2018-10-05 13:38 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/549bc49734e8 8211123: GC Metaspace printing after full gc Summary: Move GC printing to after usage is calculated Reviewed-by: tschatzl, stuefe Contributed-by: nijiaben at perfma.com, jcbeyler at google.com ! src/hotspot/share/gc/shared/genCollectedHeap.cpp + test/hotspot/jtreg/gc/logging/TestMetaSpaceLog.java + test/hotspot/jtreg/gc/logging/testcases.jar Changeset: 951d401ac00f Author: bpb Date: 2018-10-05 15:37 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/951d401ac00f 8211794: Remove jdk/java/nio/channels/Selector/RacyDeregister.java from problem list Reviewed-by: bchristi ! test/jdk/ProblemList.txt Changeset: ccfa71bacd6f Author: kvn Date: 2018-10-05 15:46 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/ccfa71bacd6f 8206963: [AOT] bug with multiple class loaders Summary: AOT should not support custom class loaders. Reviewed-by: dlong, iveresov ! src/hotspot/share/aot/aotCodeHeap.cpp Changeset: 57862a02bf4b Author: jiangli Date: 2018-10-05 18:56 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/57862a02bf4b 8202951: Implementation of JEP 341: Default CDS Archives 8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode tests 8209739: [TESTBUG] javax/imageio/plugins/png/ItxtUtf8Test.java fails with OutOfMemoryError when running in CDS mode Summary: Generate the default CDS archive at JDK build time. Reviewed-by: erikj, ihse, dholmes, iklam, ccheung, mseledtsov Contributed-by: erik.joelsson at oracle.com, jiangli.zhou at oracle.com, calvin.cheung at oracle.com ! make/Images.gmk ! make/autoconf/configure.ac ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in ! make/scripts/compare.sh ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! test/TestCommon.gmk - test/hotspot/jtreg/ProblemList-cds-mode.txt + test/hotspot/jtreg/ProblemList-non-cds-mode.txt + test/hotspot/jtreg/runtime/SharedArchiveFile/CheckDefaultArchiveFile.java + test/hotspot/jtreg/runtime/SharedArchiveFile/CheckSharingWithDefaultArchive.java ! test/hotspot/jtreg/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java ! test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java ! test/lib/jdk/test/lib/Platform.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: ecb72543c632 Author: rkennke Date: 2018-09-27 13:56 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/ecb72543c632 8211219: Type inconsistency in LIRGenerator::atomic_cmpxchg(..) Reviewed-by: eosterlund, iveresov ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp Changeset: 2f7a2e7c3221 Author: vaibhav Date: 2018-10-05 18:25 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/2f7a2e7c3221 8210376: [TESTBUG] @requires vm.cds should be replaced by @requires vm.cds.archived.java.heap and documentation is required for vm.gc==null Summary: @requires vm.cds should be replaced by @requires vm.cds.archived.java.heap and documentation is required for vm.gc==null Reviewed-by: iklam, jiangli Contributed-by: Vaibhav Choudhary ! test/hotspot/jtreg/runtime/appcds/CommandLineFlagCombo.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java ! test/hotspot/jtreg/runtime/appcds/cacheObject/OpenArchiveRegion.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions_noCompactStrings.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions_stringDedup.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java Changeset: d6aa9ea2405d Author: dnsimon Date: 2018-10-05 20:03 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d6aa9ea2405d 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation Reviewed-by: never, kvn, sspitsyn ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayKlass.cpp ! src/hotspot/share/oops/typeArrayKlass.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotHostForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java Changeset: c83bc5def0d4 Author: lancea Date: 2018-10-07 14:35 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/c83bc5def0d4 8211765: JarFile constructor throws undocumented exception Reviewed-by: lancea, sherman, alanb, chegar Contributed-by: Jaikiran Pai ! src/java.base/share/classes/java/util/zip/ZipFile.java ! test/jdk/java/util/jar/JarFile/Constructor.java Changeset: f697ba5b18d2 Author: weijun Date: 2018-10-08 13:25 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/f697ba5b18d2 8210395: Add doc to SecurityTools.java Reviewed-by: mullan ! test/lib/jdk/test/lib/SecurityTools.java ! test/lib/jdk/test/lib/util/JarUtils.java Changeset: 5d6d636cefff Author: roland Date: 2018-10-05 16:47 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/5d6d636cefff 8211776: 8210887 broke arraycopy optimization when ZGC is enabled Reviewed-by: kvn ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp Changeset: d2a6c3cbc110 Author: eosterlund Date: 2018-10-08 14:48 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d2a6c3cbc110 8211718: Supporting multiple concurrent OopStorage iterators Reviewed-by: pliden, kbarrett ! src/hotspot/share/gc/shared/oopStorage.cpp ! src/hotspot/share/gc/shared/oopStorage.hpp ! src/hotspot/share/gc/shared/oopStorageParState.hpp Changeset: 957de5be48bc Author: vromero Date: 2018-10-08 06:52 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/957de5be48bc 8209407: VerifyError is thrown for inner class with lambda Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java + test/langtools/tools/javac/lambda/T8209407/VerifierErrorInnerPlusLambda.java Changeset: 15a9f90aa00f Author: simonis Date: 2018-10-08 17:41 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/15a9f90aa00f 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS Reviewed-by: shade, goetz, mdoerr, iklam ! make/autoconf/hotspot.m4 ! make/autoconf/jdk-options.m4 Changeset: d8aebcc2d3ac Author: redestad Date: 2018-10-08 18:16 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d8aebcc2d3ac 8211860: Avoid reading security properties eagerly on Manifest class initialization Reviewed-by: mullan, alanb ! src/java.base/share/classes/java/util/jar/Manifest.java ! src/java.base/share/classes/sun/security/util/SecurityProperties.java Changeset: 54e8e34a7243 Author: chegar Date: 2018-10-08 18:29 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/54e8e34a7243 8211863: Problem list test/jdk/javax/naming/module/RunBasic.java Reviewed-by: lancea ! test/jdk/ProblemList.txt Changeset: ba67866e9c12 Author: gadams Date: 2018-10-08 07:18 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/ba67866e9c12 8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently Reviewed-by: cjplummer, dcubed ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java Changeset: 50dc6dd40e6a Author: jjg Date: 2018-10-08 11:14 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/50dc6dd40e6a 8211407: Bad links to non-existent entries on serialized-form page Reviewed-by: jlahoda ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/JavadocTool.java + test/langtools/jdk/javadoc/doclet/testSerialTag/TestSerialTag.java Changeset: 054a24c46812 Author: jcbeyler Date: 2018-10-08 13:54 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/054a24c46812 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* Summary: Remove the NSK_CPP_STUB macros Reviewed-by: amenkov, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps001/addcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps002/addcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps003/addcaps003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/attach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/attach002aAgent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach008/attach008Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach009/attach009Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach012/attach012Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach014/attach014Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Target.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach037/attach037Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach038/attach038Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach039/attach039Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach040/attach040Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach041/attach041Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach042/attach042Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent02.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent03.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach046/attach046Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/breakpoint001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk001/classfloadhk001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk002/classfloadhk002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk003/classfloadhk003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk004/classfloadhk004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk005/classfloadhk005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk006/classfloadhk006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk007/classfloadhk007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk008/classfloadhk008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk009/classfloadhk009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassLoad/classload001/classload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodLoad/compmethload001/compmethload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/compmethunload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DataDumpRequest/datadumpreq001/datadumpreq001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv001/disposeenv001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv002/disposeenv002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DynamicCodeGenerated/dyncodgen001/dyncodgen001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc001/forcegc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc002/forcegc002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionFinish/gcfinish001/gcfinish001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart001/gcstart001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart002/gcstart002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GenerateEvents/genevents001/genevents001.cpp Changeset: 0e6e0d584b47 Author: jcbeyler Date: 2018-10-08 13:56 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/0e6e0d584b47 8211131: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[G-I]* Summary: Remove the NSK_CPP_STUB macros Reviewed-by: amenkov, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAvailableProcessors/getavailproc001/getavailproc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps002/getcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig006/getclsig006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/curthrcputime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTimerInfo/curthrtimerinfo001/curthrtimerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnv/GetEnv001/GetEnv001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnvironmentLocalStorage/getenvstor001/getenvstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname001/geterrname001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/geterrname002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionEvents/extevents001/extevents001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionFunctions/extfuncs001/extfuncs001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm005/getfldnm005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt001/getjlocfmt001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt002/getjlocfmt002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss002/loadedclss002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab004/localtab004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab005/localtab005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname003/methname003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectHashCode/objhashcode001/objhashcode001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectSize/objsize001/objsize001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectsWithTags/objwithtags001/objwithtags001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase001/getphase001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase002/getphase002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPotentialCapabilities/getpotcaps001/getpotcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops001/getsysprops001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops002/getsysprops002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop001/getsysprop001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop002/getsysprop002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTag/gettag001/gettag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/thrcputime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/thrcputime002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTimerInfo/thrtimerinfo001/thrtimerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadLocalStorage/getthrdstor001/getthrdstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTime/gettime001/gettime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTimerInfo/timerinfo001/timerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/intrpthrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodObsolete/isobsolete001/isobsolete001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap001/iterheap001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap002/iterheap002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap003/iterheap003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap004/iterheap004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap005/iterheap005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap006/iterheap006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls001/iterinstcls001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls002/iterinstcls002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls003/iterinstcls003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls004/iterinstcls004.cpp Changeset: 2a85adf3c330 Author: sherman Date: 2018-10-08 14:14 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/2a85adf3c330 8211728: JarFile::versionedStream() does not filter META-INF resources in versioned stream Reviewed-by: alanb ! src/java.base/share/classes/java/util/jar/JarFile.java ! test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java Changeset: 7bc8b456e5ac Author: iklam Date: 2018-10-08 16:29 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/7bc8b456e5ac 8210388: Use hash table to store archived subgraph_info records Reviewed-by: jiangli ! src/hotspot/share/classfile/compactHashtable.cpp ! src/hotspot/share/classfile/compactHashtable.hpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/classfile/stringTable.hpp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/classfile/symbolTable.hpp ! src/hotspot/share/memory/heapShared.cpp ! src/hotspot/share/memory/heapShared.hpp ! src/hotspot/share/memory/metaspaceShared.cpp Changeset: 71495d579a65 Author: kbarrett Date: 2018-10-08 20:01 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/71495d579a65 8211804: Constant AO_UNUSED_MBZ uses left shift of negative value Summary: Use unsigned shift. Reviewed-by: alanb ! src/jdk.pack/share/native/common-unpack/constants.h Changeset: a986ec4ff214 Author: jcbeyler Date: 2018-10-08 19:44 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/a986ec4ff214 8211782: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[I-S]* Summary: Remove the NSK_CPP_STUB macros Reviewed-by: amenkov, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls005/iterinstcls005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls006/iterinstcls006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls007/iterinstcls007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj001/iterobjreachobj001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj003/iterobjreachobj003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj004/iterobjreachobj004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj005/iterobjreachobj005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj001/iterreachobj001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj002/iterreachobj002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj003/iterreachobj003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj004/iterreachobj004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj005/iterreachobj005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/abort/Abort.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/callbacks/Callbacks.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/concrete-klass-filter/ConcreteKlassFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/HeapFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/non-concrete-klass-filter/NonConcreteKlassFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorContendedEnter/mcontenter001/mcontenter001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorContendedEntered/mcontentered001/mcontentered001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorWait/monitorwait001/monitorwait001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/MonitorWaited/monitorwaited001/monitorwaited001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind001/nativemethbind001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind002/nativemethbind002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind003/nativemethbind003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeMethodBind/nativemethbind004/nativemethbind004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001/objfree001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree002/objfree002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe005/popframe005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass028/redefclass028.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass029/redefclass029.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass030/redefclass030.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps001/relcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps002/relcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd001/resumethrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd002/resumethrd002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst001/resumethrdlst001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst002/resumethrdlst002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform002/retransform002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform003/retransform003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform004/retransform004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP01/ap01t001/ap01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP02/ap02t001/ap02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP03/ap03t001/ap03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/ap04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/ap04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t001/ap05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t002/ap05t002.cpp Changeset: a42c378b6f01 Author: alanb Date: 2018-10-09 07:06 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/a42c378b6f01 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module Reviewed-by: mchung ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/jdk/internal/loader/Loader.java ! src/java.base/share/classes/jdk/internal/loader/LoaderPool.java + test/jdk/java/lang/ModuleLayer/automatic/AutomaticModulesTest.java + test/jdk/java/lang/ModuleLayer/automatic/src/alib/q/Lib.java + test/jdk/java/lang/ModuleLayer/automatic/src/m/module-info.java + test/jdk/java/lang/ModuleLayer/automatic/src/m/p/Main.java Changeset: 6ee9500fe653 Author: sgehwolf Date: 2018-10-02 17:17 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/6ee9500fe653 8211387: [Zero] atomic_copy64: Use ldrexd for atomic reads on ARMv7 Reviewed-by: dholmes, aph Contributed-by: Andrew Haley ! src/hotspot/os_cpu/linux_zero/os_linux_zero.hpp Changeset: e25291a90cba Author: chegar Date: 2018-10-09 11:44 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/e25291a90cba 8211920: Close server socket and cleanups in test/jdk/javax/naming/module/RunBasic.java Reviewed-by: dfuchs ! test/jdk/javax/naming/module/RunBasic.java ! test/jdk/javax/naming/module/src/test/test/ConnectWithAuthzId.java ! test/jdk/javax/naming/module/src/test/test/ConnectWithFoo.java ! test/jdk/javax/naming/module/src/test/test/ReadByUrl.java ! test/jdk/javax/naming/module/src/test/test/StoreFruit.java ! test/jdk/javax/naming/module/src/test/test/StoreObject.java ! test/jdk/javax/naming/module/src/test/test/StorePerson.java ! test/jdk/javax/naming/module/src/test/test/StoreRemote.java Changeset: 7ecbaece746f Author: chegar Date: 2018-10-09 13:31 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/7ecbaece746f 8211902: broken link in java.net.http.WebSocket.Builder Reviewed-by: alanb, dfuchs ! src/java.net.http/share/classes/java/net/http/WebSocket.java Changeset: e7703e429767 Author: redestad Date: 2018-10-09 14:30 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/e7703e429767 8211859: Avoid initializing AtomicBoolean from RandomAccessFile Reviewed-by: alanb ! src/java.base/share/classes/java/io/RandomAccessFile.java Changeset: 9f154d0a59f6 Author: ghaug Date: 2018-10-09 15:06 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/9f154d0a59f6 8211768: [s390] Implement JFR profiling Reviewed-by: simonis, mdoerr ! src/hotspot/cpu/s390/frame_s390.cpp ! src/hotspot/cpu/s390/frame_s390.hpp ! src/hotspot/cpu/s390/frame_s390.inline.hpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp Changeset: d24b89390f6c Author: goetz Date: 2018-10-09 16:03 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d24b89390f6c 8211856: [ppc, s390] ProblemList some failing tests. Reviewed-by: kvn, mdoerr ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: 2630d51656aa Author: gadams Date: 2018-10-08 14:57 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/2630d51656aa 8201603: MonitorContendedEnter failure in nsk/jvmti/scenarios/contention/TC02/tc02t001 Reviewed-by: cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001.java Changeset: 3e5687d7d6b5 Author: rkennke Date: 2018-10-05 23:45 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/3e5687d7d6b5 8211792: Fix misplaced BarrierSet forward declarations Reviewed-by: shade, zgu ! src/hotspot/share/interpreter/templateTable.hpp ! src/hotspot/share/oops/oop.hpp Changeset: 9d5df3eb5cc4 Author: amenkov Date: 2018-10-09 12:26 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9d5df3eb5cc4 8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test Reviewed-by: sspitsyn, jcbeyler + test/jdk/com/sun/jdi/DeferredStepTest.java - test/jdk/com/sun/jdi/DeferredStepTest.sh - test/jdk/com/sun/jdi/ShellScaffold.sh - test/jdk/com/sun/jdi/ZZZcleanup.sh Changeset: 3a2384b54b56 Author: chegar Date: 2018-10-09 20:32 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/3a2384b54b56 8211927: Add additional diagnostic information to java/net/BindException/Test.java Reviewed-by: dfuchs ! test/jdk/java/net/BindException/Test.java Changeset: 070186461dbb Author: sherman Date: 2018-10-09 12:36 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/070186461dbb 8211880: Broken links in java.util.jar Reviewed-by: alanb, mchung, martin ! src/java.base/share/classes/java/util/jar/Attributes.java Changeset: 8dbf1a13af49 Author: jiangli Date: 2018-10-09 15:58 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/8dbf1a13af49 8206009: Move CDS java heap object archiving code to heapShared.hpp and heapShared.cpp Summary: Restructure and cleanup java heap object archiving code. Reviewed-by: coleenp, iklam ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/heapShared.cpp ! src/hotspot/share/memory/heapShared.hpp ! src/hotspot/share/memory/heapShared.inline.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/metaspaceShared.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/prims/whitebox.cpp Changeset: f50685d7142d Author: jcbeyler Date: 2018-10-09 13:22 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f50685d7142d 8211905: Remove multiple casts for EM06 file Summary: Remove multiple casts for EM06 file Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp Changeset: 50ef71b6fd3d Author: gadams Date: 2018-10-09 07:33 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/50ef71b6fd3d 8211324: Link to java.lang.ThreadGroup in JDWP spec is broken Reviewed-by: sspitsyn, chegar, alanb ! make/data/jdwp/jdwp.spec Changeset: dea8a62cdfc3 Author: erikj Date: 2018-10-09 14:57 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/dea8a62cdfc3 8211724: Change mkdir -p to MakeDir macro where possible Reviewed-by: ihse, asemenyuk ! make/BuildStatic.gmk ! make/Bundles.gmk ! make/CopyInterimCLDRConverter.gmk ! make/CreateBuildJdkCopy.gmk ! make/GenerateModuleSummary.gmk ! make/GensrcModuleInfo.gmk ! make/MacBundles.gmk ! make/autoconf/basics.m4 ! make/common/JarArchive.gmk ! make/common/JavaCompilation.gmk ! make/common/Modules.gmk ! make/common/ZipArchive.gmk ! make/copy/Copy-java.base.gmk ! make/gendata/GendataFontConfig.gmk ! make/gendata/GendataHtml32dtd.gmk ! make/gendata/GendataTZDB.gmk ! make/gensrc/GensrcCLDR.gmk ! make/gensrc/GensrcCharsetCoder.gmk ! make/gensrc/GensrcCommonLangtools.gmk ! make/gensrc/GensrcLocaleData.gmk ! make/gensrc/GensrcModuleLoaderMap.gmk ! make/gensrc/GensrcProperties.gmk ! make/gensrc/GensrcSwing.gmk ! make/launcher/Launcher-java.base.gmk ! make/rmic/Rmic-java.management.rmi.gmk Changeset: 49a21be61dcd Author: dholmes Date: 2018-10-09 20:19 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/49a21be61dcd 8211065: Private method check in linkResolver is incorrect Reviewed-by: acorn, lfoltan ! src/hotspot/share/interpreter/linkResolver.cpp ! test/hotspot/jtreg/runtime/Nestmates/privateMethods/TestInvokeErrors.java + test/hotspot/jtreg/runtime/linkResolver/TestDeletedMethod.java + test/hotspot/jtreg/runtime/linkResolver/TestDeletedMethod_Sub.jcod + test/hotspot/jtreg/runtime/linkResolver/TestDeletedMethod_Super.jcod Changeset: 2e72562697bf Author: dholmes Date: 2018-10-09 20:38 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/2e72562697bf 8211394: CHECK_ must be used in the rhs of an assignment statement within a block Summary: replace "return foo(CHECK_X);" with "return foo(THREAD);" Reviewed-by: iklam, phh, stuefe, lfoltan ! src/hotspot/share/classfile/verificationType.cpp ! src/hotspot/share/classfile/verificationType.hpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceMirrorKlass.cpp ! src/hotspot/share/runtime/javaCalls.cpp ! src/hotspot/share/services/management.cpp ! src/hotspot/share/utilities/exceptions.hpp Changeset: 218b5b64f102 Author: dtitov Date: 2018-10-09 19:11 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/218b5b64f102 8193879: Java debugger hangs on method invocation Reviewed-by: sspitsyn, amenkov, gadams ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java + test/jdk/com/sun/jdi/MethodInvokeWithTraceOnTest.java ! test/jdk/com/sun/jdi/TestScaffold.java ! test/jdk/com/sun/jdi/lib/jdb/JdbTest.java Changeset: 3ecaae33241a Author: thartmann Date: 2018-10-10 08:36 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/3ecaae33241a 8211332: Space for stub routines (code_size2) is too small on new Skylake CPUs Summary: Increase code_size2 for new Skylake CPUs. Reviewed-by: kvn, stuefe, thartmann Contributed-by: ralf.schmelter at sap.com ! src/hotspot/cpu/x86/stubRoutines_x86.hpp Changeset: e4d72440d60e Author: rkennke Date: 2018-10-03 15:22 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/e4d72440d60e 8211279: Verify missing object equals barriers Reviewed-by: pliden, shade, zgu ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/gc/shared/barrierSet.hpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp ! src/hotspot/share/oops/access.hpp ! src/hotspot/share/oops/accessBackend.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oopsHierarchy.cpp ! src/hotspot/share/oops/oopsHierarchy.hpp Changeset: c4a39588a075 Author: rkennke Date: 2018-10-10 10:58 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c4a39588a075 8211270: GC abstraction to get real object and headers size Reviewed-by: shade, zgu, eosterlund ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/whitebox.cpp Changeset: 3be7d098f4a6 Author: mhorie Date: 2018-10-10 14:28 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/3be7d098f4a6 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default Reviewed-by: mdoerr, goetz ! src/hotspot/cpu/ppc/c2_globals_ppc.hpp Changeset: 1c8745e31fa3 Author: prappo Date: 2018-10-10 14:13 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/1c8745e31fa3 8212000: Verify exported symbols in java.base (libnet, libnio/ch) Reviewed-by: alanb, chegar ! src/java.base/share/native/libnet/net_util.h ! src/java.base/unix/native/libnet/net_util_md.c ! src/java.base/unix/native/libnio/ch/Net.c ! src/java.base/unix/native/libnio/ch/nio_util.h ! src/java.base/windows/native/libnet/net_util_md.c Changeset: 755b367c2134 Author: roland Date: 2018-09-28 14:24 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/755b367c2134 8211232: GraphKit::make_runtime_call() sometimes attaches wrong memory state to call Reviewed-by: kvn ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp Changeset: 40aa2d50d116 Author: weijun Date: 2018-10-10 22:13 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/40aa2d50d116 8211969: test/jdk/lib/security/CheckBlacklistedCerts.java searching for wrong paths Reviewed-by: mullan ! test/jdk/lib/security/CheckBlacklistedCerts.java Changeset: f8626bcc1698 Author: hseigel Date: 2018-10-10 10:18 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/f8626bcc1698 8207689: Remove perfCounter _load_instance_class_failCounter used by deleted flag UnsyncloadClass Summary: Delete the perfCounter Reviewed-by: lfoltan, acorn, dholmes ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp Changeset: b6eaf7b7cd7f Author: jcbeyler Date: 2018-10-10 08:26 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/b6eaf7b7cd7f 8211950: Deprecate the check if a JVMTI collector is present assertion Summary: Deprecate assertion that a collector is there; it is now a nop Reviewed-by: eosterlund, phh, pliden ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/runtime/threadHeapSampler.cpp ! src/hotspot/share/runtime/threadHeapSampler.hpp Changeset: 4a63197816ce Author: jjg Date: 2018-10-10 10:00 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/4a63197816ce 8211952: Broken links in java.time API Reviewed-by: lancea ! src/java.base/share/classes/java/time/Duration.java ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/LocalDate.java ! src/java.base/share/classes/java/time/LocalDateTime.java ! src/java.base/share/classes/java/time/LocalTime.java ! src/java.base/share/classes/java/time/MonthDay.java ! src/java.base/share/classes/java/time/OffsetDateTime.java ! src/java.base/share/classes/java/time/OffsetTime.java ! src/java.base/share/classes/java/time/Period.java ! src/java.base/share/classes/java/time/Ser.java ! src/java.base/share/classes/java/time/Year.java ! src/java.base/share/classes/java/time/YearMonth.java ! src/java.base/share/classes/java/time/ZoneId.java ! src/java.base/share/classes/java/time/ZoneOffset.java ! src/java.base/share/classes/java/time/ZoneRegion.java ! src/java.base/share/classes/java/time/ZonedDateTime.java ! src/java.base/share/classes/java/time/chrono/AbstractChronology.java ! src/java.base/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/java.base/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/java.base/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/java.base/share/classes/java/time/chrono/HijrahChronology.java ! src/java.base/share/classes/java/time/chrono/HijrahDate.java ! src/java.base/share/classes/java/time/chrono/IsoChronology.java ! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java ! src/java.base/share/classes/java/time/chrono/JapaneseDate.java ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java ! src/java.base/share/classes/java/time/chrono/MinguoChronology.java ! src/java.base/share/classes/java/time/chrono/MinguoDate.java ! src/java.base/share/classes/java/time/chrono/Ser.java ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/java.base/share/classes/java/time/zone/Ser.java ! src/java.base/share/classes/java/time/zone/ZoneOffsetTransition.java ! src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/java.base/share/classes/java/time/zone/ZoneRules.java Changeset: 5888ef300549 Author: darcy Date: 2018-10-10 10:28 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/5888ef300549 8058202: AnnotatedType implementations don't override toString(), equals(), hashCode() Reviewed-by: jfranck ! src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java + test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java Changeset: a2c72b476c9f Author: igerasim Date: 2018-10-10 10:56 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/a2c72b476c9f 8211396: Broken link in javadoc for private java.util.regex.Pattern#normalize() Reviewed-by: jjg, sherman ! src/java.base/share/classes/java/util/regex/Pattern.java Changeset: ca7ddf0a1d47 Author: jcbeyler Date: 2018-10-10 11:20 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/ca7ddf0a1d47 8211801: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[A-E] Summary: Remove the NSK_CPP_STUB macros Reviewed-by: amenkov, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t001/ap07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t002/ap07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP09/ap09t001/ap09t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/ap10t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/ap11t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/ap12t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/bi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t002/bi01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001/bi02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t002/bi02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t001/bi03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t002/bi03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/bi04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t001/cm01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t002/cm01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t003/cm01t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t004/cm01t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t005/cm01t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t006/cm01t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t007/cm01t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t008/cm01t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t009/cm01t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t010/cm01t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t011/cm01t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t012/cm01t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t013/cm01t013.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t014/cm01t014.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t015/cm01t015.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t016/cm01t016.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t017/cm01t017.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t018/cm01t018.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t019/cm01t019.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t020/cm01t020.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t021/cm01t021.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/cm02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/cm03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/tc01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/tc02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t001/em01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/em01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t001/em02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t002/em02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/em02t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t004/em02t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/em02t005.cpp Changeset: c99e4c010022 Author: ctornqvi Date: 2018-10-10 11:47 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c99e4c010022 8212008: Use of TREAT_EXIT_CODE_1_AS_0 hide problems with jtreg Java Reviewed-by: erikj ! test/hotspot/jtreg/Makefile ! test/jdk/Makefile Changeset: eb1ecdd3611e Author: mullan Date: 2018-10-10 15:23 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/eb1ecdd3611e 8211878: Bad/broken links in docs/api/java.xml.crypto/javax/xml/crypto/dsig/Reference.html Reviewed-by: jjg ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java From maurizio.cimadamore at oracle.com Wed Oct 10 20:06:46 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 10 Oct 2018 20:06:46 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810102006.w9AK6kYX006560@aojmv0008.oracle.com> Changeset: 4b087f3db236 Author: mcimadamore Date: 2018-10-10 22:08 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/4b087f3db236 Automatic merge with default ! make/autoconf/basics.m4 ! make/autoconf/spec.gmk.in ! make/common/Modules.gmk ! make/conf/jib-profiles.js - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/jdk/com/sun/jdi/DeferredStepTest.sh - test/jdk/com/sun/jdi/ShellScaffold.sh - test/jdk/com/sun/jdi/ZZZcleanup.sh From maurizio.cimadamore at oracle.com Wed Oct 10 20:07:06 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 10 Oct 2018 20:07:06 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810102007.w9AK76XN006849@aojmv0008.oracle.com> Changeset: fc1f8f0c3cb7 Author: mcimadamore Date: 2018-10-10 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/fc1f8f0c3cb7 Automatic merge with default - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/jdk/com/sun/jdi/DeferredStepTest.sh - test/jdk/com/sun/jdi/ShellScaffold.sh - test/jdk/com/sun/jdi/ZZZcleanup.sh From maurizio.cimadamore at oracle.com Wed Oct 10 20:07:26 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 10 Oct 2018 20:07:26 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810102007.w9AK7QiC007175@aojmv0008.oracle.com> Changeset: f3c81646437b Author: mcimadamore Date: 2018-10-10 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/f3c81646437b Automatic merge with default ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/jdk/com/sun/jdi/DeferredStepTest.sh - test/jdk/com/sun/jdi/ShellScaffold.sh - test/jdk/com/sun/jdi/ZZZcleanup.sh From maurizio.cimadamore at oracle.com Wed Oct 10 20:07:45 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 10 Oct 2018 20:07:45 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810102007.w9AK7jCB007619@aojmv0008.oracle.com> Changeset: f1b60618f556 Author: mcimadamore Date: 2018-10-10 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/f1b60618f556 Automatic merge with default ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/jdk/com/sun/jdi/DeferredStepTest.sh - test/jdk/com/sun/jdi/ShellScaffold.sh - test/jdk/com/sun/jdi/ZZZcleanup.sh From vladimir.x.ivanov at oracle.com Wed Oct 10 23:01:31 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 10 Oct 2018 16:01:31 -0700 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> Message-ID: <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> Ningsheng, >>>> The name (*ScalableVector) is slightly misleading to me, but I'm fine >>>> with it. I interpret new shapes as representing vectors of maximally >>>> supported size at runtime without specifying the actual size. >>>> >>> >>> I am happy to change the name if you have some suggestion. The new shapes >> are representing current (SVE) hardware supported (max) vector register size, >> and the actual size is known at runtime. >> >> Yes, I'd like the names to clearly manifest it's the vector of maximum size >> available at runtime. Maybe *MaxVector, but I'm not too happy with it as well. >> > > OK, but I think Max could not imply the point of one shape to fit multiple sizes. I was thinking about VL (variable length), but finally used current name to align with SVE (Scalable Vector Extension). My understanding from the patch you shared is that vector size is fixed across the run and is set to maximally supported [1] IMO "variable length" is misleading in a sense it may be erroneously interpreted as "vectors of that shape may be of different size at runtime", so user have to check for that. In that respect, "*Max*" clearly refers to *some* size (fixed across the run) without specifying what the actual size is, but user can query it at runtime. ... >> So, my question boils down to: how vector shape checks are expected to >> work on *ScalableVectors in presence of operations which change vector size. >> >> For example, IntScalableVector.rebracket() => LongScalableVector which >> is fine, but ISV.resize() => ISV is what I'm concerned about and >> existing checks aren't enough for *ScalableVectors unless you check >> their length at runtime. >> > > Thanks for the detailed explanation. So, which checks do you mean here? Do you mean this [1]? I find that current Java implementations already has some runtime length checks. One thing we need to consider is the ambiguity between existing sizes and scalable size. Current VectorIntrinsics.reinterpret() just tries to get the shape from size (library_call.cpp:get_exact_klass_for_vector_box) instead of getting the real class from input argument, which will lead to ClassCastException. Maybe that can be fixed by adding real klass type to the reinterpret function. The checks I referred to are the casts on vector shapes which are part of every vector operation (e.g., [2]), but they don't immediately relate to shape-changing operations. It seems I had some wrong assumptions when coming up with the examples. Sorry for the confusion. Taking those into account, here's my take on current state of vector shape changing operations w.r.t. SV shapes. There'll be 30 vector shapes in total (5 sizes x 6 element types): * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV * Short64V, ..., ShortSV ... * Double64V, Double128V, ... Double512V, DoubleSV Depending on hardware, SVs may alias with "explicitly sized" shapes (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). (1) Vector.rebracket(): works fine for SVs since vector size (in bits) stays the same: IntSV <-> LongSV <-> ... <-> DoubleSV. (2) Vector.resize(): SV->SV doesn't make sense and the operation should involve both SV and existing vector shapes: IntSV <-> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause problems and needs to be carefully handled to avoid 2 equivalent shapes to meet at runtime. Otherwise, vector shape checks I mentioned earlier should be changed. (3) Vector.cast(): SV->SV, SV<->64V/.../512V * size-preserving transformations (int <-> float): SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV; * widening casts (e.g., int->long) SV->SV/64V/...: truncate upper part of the vector, since SVs already represent widest vector shapes; 64V/...->SV: either truncated or filled with defaults depending on actual size * narrowing casts (e.g., long->int) SV->SV/64V/...: fill upper part of SV with defaults; 64V/...->SV: either truncated or filled with defaults depending on actual size Best regards, Vladimir Ivanov [1] final class IntScalableVector extends IntVector { static final IntScalableSpecies SPECIES = new IntScalableSpecies(); static final IntScalableVector ZERO = new IntScalableVector(); static final int LENGTH = SPECIES.length(); ... static final class IntScalableSpecies extends IntSpecies { static final int BIT_SIZE = Shapes.S_Scalable_BIT.bitSize(); static final int LENGTH = BIT_SIZE / Integer.SIZE; ... public static final SScalableBit S_Scalable_BIT = new SScalableBit(); public static final class SScalableBit extends Vector.Shape { @Override public int bitSize() { Unsafe u = Unsafe.getUnsafe(); return u.getMaxVectorSize(byte.class) * 8; } } [2] http://hg.openjdk.java.net/panama/dev/file/e8f06cc3fe82/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java#l327 From samuel.audet at gmail.com Thu Oct 11 01:18:19 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Thu, 11 Oct 2018 10:18:19 +0900 Subject: [foreign] some JMH benchmarks In-Reply-To: <26e88428-a2fc-5833-8433-ca394ef19f96@gmail.com> References: <03fd2280-50a7-7772-7100-317a199ecf78@oracle.com> <34d05b5e-cae7-a82e-5f7b-a84d904cc8b7@oracle.com> <106fc755-1f1a-1fba-5de2-03b0e21e9a86@oracle.com> <25be0579-eb55-65e7-b379-206b8713a687@gmail.com> <580516c9-0ef2-0ceb-7c8c-c67d6621c074@gmail.com> <55e13144-ad01-dd24-5081-864ebe8e7524@oracle.com> <26e88428-a2fc-5833-8433-ca394ef19f96@gmail.com> Message-ID: <36c98f68-edb2-18d1-5355-ebd8863a27d7@gmail.com> Hi, Maurizio, To get the ball going, I've updated my benchmark code with sorting examples: https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 With the usual 2-cores VM, Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz, Ubuntu 14.04, GCC 4.9, OpenJDK 8, I obtained the following: Benchmark Mode Cnt Score Error Units NativeBenchmark.expBenchmark thrpt 5 37684721.600 ? 1082945.216 ops/s NativeBenchmark.getpidBenchmark thrpt 5 97760579.697 ? 3559212.842 ops/s NativeBenchmark.callbackSortBenchmark thrpt 5 362762.157 ? 11992.584 ops/s NativeBenchmark.nativeSortBenchmark thrpt 5 7218834.171 ? 461245.346 ops/s NativeBenchmark.inlineSortBenchmark thrpt 5 17211735.752 ? 1032386.799 ops/s That seems to be consistent with the results you got with JNI on JDK 8: http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt https://bugs.openjdk.java.net/browse/JDK-8210975 Although my callbackSortBenchmark() seems a bit slower. JavaCPP doesn't currently support static methods for callback functions, which wouldn't be a problem to support, but for now that's probably where the small ~10% difference comes from. Anyway, what's important is that nativeSortBenchmark() is ~20 times faster than callbackSortBenchmark(), and inlineSortBenchmark() is ~47 times faster. In theory, how much faster can link2native make callbackSortBenchmark()? Given the results you provided for getpid(), I'm guessing maybe 3 or 4 times faster, which sounds good, but it's still a far cry from nativeSortBenchmark() and especially inlineSortBenchmark(). So, I get the impression that it is not possible to make it useful for this kind of use case. I would very much like to be proven wrong though. Samuel On 09/21/2018 09:51 AM, Samuel Audet wrote: > Sounds good, thanks for testing this and for filing the bug report! > > Samuel > > On 09/21/2018 03:14 AM, Maurizio Cimadamore wrote: >> Sorry for the delay in getting back at you. There's indeed something >> fishy going on here, and I have spotted a regression in JNI perf since >> JDK 11. This could be caused by update in compiler toolchain >> introduced in same version, but I have filed an issue for our hotspot >> team to investigate: >> >> https://bugs.openjdk.java.net/browse/JDK-8210975 >> >> In the context of this discussion, it's likely that the rtegression is >> affecting the numbers of both Panama (which is built on top of JNI at >> the moment) and the JNI benchmarks. >> >> Thanks >> Maurizio >> >> >> On 19/09/18 01:13, Samuel Audet wrote: >>> Thanks! You haven't mentioned the version of the JDK you're using >>> though. I'm starting to get the impression that JNI in newer versions >>> of OpenJDK will be slower... ? >>> >>> On 09/18/2018 07:03 PM, Maurizio Cimadamore wrote: >>>> These are the numbers I get >>>> >>>> Benchmark???????????????????????? Mode? Cnt???????? Score Error Units >>>> NativeBenchmark.expBenchmark???? thrpt??? 5? 30542590.094 ? >>>> 44126.434? ops/s >>>> NativeBenchmark.getpidBenchmark? thrpt??? 5? 61764677.092 ? >>>> 21102.236? ops/s >>>> >>>> They are in the same ballpark, but exp() is a bit faster; byw, I >>>> tried to repeat my benchmark with JNI exp() _and_ O3 and I've got >>>> very similar numbers (yesterday I did a very quick test and there >>>> was probably some other job running on the machine and brining down >>>> the figures a bit). >>>> >>>> But overall, the results in your bench seem to match what I got: exp >>>> is faster, pid is slower, the difference is mostly caused by O3. If >>>> no O3 is used, then the numbers should match what I included in my >>>> numbers (and getpid should be a bit faster). >>>> >>>> Maurizio >>>> >>>> >>>> On 18/09/18 05:48, Samuel Audet wrote: >>>>> Anyway, I've put online an updated version of my benchmark files here: >>>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >>>>> Just run "git clone" on the URL and run "mvn package" on the pom.xml. >>>>> >>>>> With the 2 virtual cores of an Intel(R) Xeon(R) CPU E5-2673 v4 @ >>>>> 2.30GHz running Ubuntu 14.04 on the cloud with GCC 4.9 and OpenJDK >>>>> 8, I get these numbers: >>>>> >>>>> Benchmark???????????????????????? Mode? Cnt????????? Score Error >>>>> ?Units >>>>> NativeBenchmark.expBenchmark???? thrpt?? 25?? 37460540.440 ? >>>>> 393299.974 ?ops/s >>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25? 100323188.451 ? >>>>> 1254197.449 ?ops/s >>>>> >>>>> While on my laptop, an Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz >>>>> running Fedora 27, GCC 7.3, and OpenJDK 9, I get the following: >>>>> >>>>> Benchmark???????????????????????? Mode? Cnt???????? Score Error Units >>>>> NativeBenchmark.expBenchmark???? thrpt?? 25? 50047147.099 ? >>>>> 924366.937 ops/s >>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25?? 4825508.193 ? >>>>> 21662.633 ops/s >>>>> >>>>> Now, it looks like getpid() is really slow on Fedora 27 for some >>>>> reason, but as Linus puts it, we should not be using that for >>>>> benchmarking: >>>>> https://yarchive.net/comp/linux/getpid_caching.html >>>>> >>>>> What do you get on your machines? >>>>> >>>>> Samuel >>>>> >>>>> >>>>> On 09/18/2018 12:58 AM, Maurizio Cimadamore wrote: >>>>>> For the records, here's what I get for all the three benchmarks if >>>>>> I compile the JNI code with -O3: >>>>>> >>>>>> Benchmark????????????????????????? Mode? Cnt Score Error Units >>>>>> PanamaBenchmark.testJNIExp??????? thrpt??? 5? 28575269.294 ? >>>>>> 1907726.710? ops/s >>>>>> PanamaBenchmark.testJNIJavaQsort? thrpt??? 5??? 372148.433 ? >>>>>> 27178.529? ops/s >>>>>> PanamaBenchmark.testJNIPid??????? thrpt??? 5? 59240069.011 ? >>>>>> 403881.697? ops/s >>>>>> >>>>>> The first and second benchmarks get faster and very close to the >>>>>> 'direct' optimization numbers in [1]. Surprisingly, the last >>>>>> benchmark (getpid) is quite slower. I've been able to reproduce >>>>>> across multiple runs; for that benchmark omitting O3 seems to be >>>>>> the achieve best results, not sure why. It starts of faster >>>>>> (around in the first couple of warmup iterations, but then it goes >>>>>> slower in all the other runs - presumably it interacts badly with >>>>>> the C2 generated code. For instance, this is a run with O3 enabled: >>>>>> >>>>>> # Run progress: 66.67% complete, ETA 00:01:40 >>>>>> # Fork: 1 of 1 >>>>>> # Warmup Iteration?? 1: 65182202.653 ops/s >>>>>> # Warmup Iteration?? 2: 64900639.094 ops/s >>>>>> # Warmup Iteration?? 3: 59314945.437 ops/s >>>>>> <--------------------------------- >>>>>> # Warmup Iteration?? 4: 59269007.877 ops/s >>>>>> # Warmup Iteration?? 5: 59239905.163 ops/s >>>>>> Iteration?? 1: 59300748.074 ops/s >>>>>> Iteration?? 2: 59249666.044 ops/s >>>>>> Iteration?? 3: 59268597.051 ops/s >>>>>> Iteration?? 4: 59322074.572 ops/s >>>>>> Iteration?? 5: 59059259.317 ops/s >>>>>> >>>>>> And this is a run with O3 disabled: >>>>>> >>>>>> # Run progress: 0.00% complete, ETA 00:01:40 >>>>>> # Fork: 1 of 1 >>>>>> # Warmup Iteration?? 1: 55882128.787 ops/s >>>>>> # Warmup Iteration?? 2: 53102361.751 ops/s >>>>>> # Warmup Iteration?? 3: 66964755.699 ops/s >>>>>> <--------------------------------- >>>>>> # Warmup Iteration?? 4: 66414428.355 ops/s >>>>>> # Warmup Iteration?? 5: 65328475.276 ops/s >>>>>> Iteration?? 1: 64229192.993 ops/s >>>>>> Iteration?? 2: 65191719.319 ops/s >>>>>> Iteration?? 3: 65352022.471 ops/s >>>>>> Iteration?? 4: 65152090.426 ops/s >>>>>> Iteration?? 5: 65320545.712 ops/s >>>>>> >>>>>> >>>>>> In both cases, the 3rd warmup execution sees a performance jump - >>>>>> with O3, the jump is backwards, w/o O3 the jump is forward, which >>>>>> is quite typical for a JMH benchmark as C2 optimization will start >>>>>> to kick in. >>>>>> >>>>>> For these reasons, I'm reluctant to update my benchmark numbers to >>>>>> reflect the O3 behavior (although I agree that, since the Hotspot >>>>>> code is compiled with that optimization it would make more sense >>>>>> to use that as a reference). >>>>>> >>>>>> Maurizio >>>>>> >>>>>> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt >>>>>> >>>>>> >>>>>> >>>>>> On 17/09/18 16:18, Maurizio Cimadamore wrote: >>>>>>> >>>>>>> >>>>>>> On 17/09/18 15:08, Samuel Audet wrote: >>>>>>>> Yes, the blackhole or the random number doesn't make any >>>>>>>> difference, but not calling gcc with -O3 does. Running the >>>>>>>> compiler with optimizations on is pretty common, but they are >>>>>>>> not enabled by default. >>>>>>> A bit better >>>>>>> >>>>>>> PanamaBenchmark.testMethod? thrpt??? 5? 28018170.076 ? >>>>>>> 8491668.248 ops/s >>>>>>> >>>>>>> But not much of a difference (I did not expected much, as the >>>>>>> body of the native method is extremely simple). >>>>>>> >>>>>>> Maurizio >>>>> >>>> >>> >> > From Ningsheng.Jian at arm.com Thu Oct 11 06:28:09 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Thu, 11 Oct 2018 06:28:09 +0000 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> Message-ID: Hi Vladimir, > > My understanding from the patch you shared is that vector size is fixed across > the run and is set to maximally supported [1] > > IMO "variable length" is misleading in a sense it may be erroneously interpreted > as "vectors of that shape may be of different size at runtime", so user have to > check for that. In that respect, "*Max*" > clearly refers to *some* size (fixed across the run) without specifying what the > actual size is, but user can query it at runtime. > Yes, it is fixed across different run in the same system. OK, I will leave it open for now. > ... > >> So, my question boils down to: how vector shape checks are expected > >> to work on *ScalableVectors in presence of operations which change vector > size. > >> > >> For example, IntScalableVector.rebracket() => LongScalableVector > >> which is fine, but ISV.resize() => ISV is what I'm concerned about > >> and existing checks aren't enough for *ScalableVectors unless you > >> check their length at runtime. > >> > > > > Thanks for the detailed explanation. So, which checks do you mean here? Do > you mean this [1]? I find that current Java implementations already has some > runtime length checks. One thing we need to consider is the ambiguity between > existing sizes and scalable size. Current VectorIntrinsics.reinterpret() just tries to > get the shape from size (library_call.cpp:get_exact_klass_for_vector_box) instead > of getting the real class from input argument, which will lead to > ClassCastException. Maybe that can be fixed by adding real klass type to the > reinterpret function. > > The checks I referred to are the casts on vector shapes which are part of every > vector operation (e.g., [2]), but they don't immediately relate to shape-changing > operations. > OK, but I would expect the normal operations between SV and other vectors are illegal, though they may have the same size, since users usually don't know the real size of SV. We should treat SV different from other vectors. > It seems I had some wrong assumptions when coming up with the examples. > Sorry for the confusion. Taking those into account, here's my take on current > state of vector shape changing operations w.r.t. SV shapes. > > There'll be 30 vector shapes in total (5 sizes x 6 element types): > * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV > * Short64V, ..., ShortSV > ... > * Double64V, Double128V, ... Double512V, DoubleSV > > Depending on hardware, SVs may alias with "explicitly sized" shapes (e.g., IntSV is > equivalent to Int512V on AVX512 capable H/W). > > (1) Vector.rebracket(): works fine for SVs since vector size (in bits) stays the same: > IntSV <-> LongSV <-> ... <-> DoubleSV. > > (2) Vector.resize(): SV->SV doesn't make sense and the operation should involve > both SV and existing vector shapes: IntSV <-> Int64V/Int128V/.../Int512V. The > ambiguity you mention can cause problems and needs to be carefully handled to > avoid 2 equivalent shapes to meet at runtime. Otherwise, vector shape checks I > mentioned earlier should be changed. > Yes, we will try to address this issue carefully in the follow-up webrev. > (3) Vector.cast(): SV->SV, SV<->64V/.../512V > * size-preserving transformations (int <-> float): > SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV; > > * widening casts (e.g., int->long) > SV->SV/64V/...: truncate upper part of the vector, since SVs already > represent widest vector shapes; > 64V/...->SV: either truncated or filled with defaults depending on actual size > > * narrowing casts (e.g., long->int) > SV->SV/64V/...: fill upper part of SV with defaults; > 64V/...->SV: either truncated or filled with defaults depending on actual size > Thanks, Ningsheng From maurizio.cimadamore at oracle.com Thu Oct 11 07:59:47 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Oct 2018 08:59:47 +0100 Subject: [foreign] some JMH benchmarks In-Reply-To: <36c98f68-edb2-18d1-5355-ebd8863a27d7@gmail.com> References: <03fd2280-50a7-7772-7100-317a199ecf78@oracle.com> <34d05b5e-cae7-a82e-5f7b-a84d904cc8b7@oracle.com> <106fc755-1f1a-1fba-5de2-03b0e21e9a86@oracle.com> <25be0579-eb55-65e7-b379-206b8713a687@gmail.com> <580516c9-0ef2-0ceb-7c8c-c67d6621c074@gmail.com> <55e13144-ad01-dd24-5081-864ebe8e7524@oracle.com> <26e88428-a2fc-5833-8433-ca394ef19f96@gmail.com> <36c98f68-edb2-18d1-5355-ebd8863a27d7@gmail.com> Message-ID: <82880be5-488a-a628-6778-713bee76b0a7@oracle.com> Thanks for the numbers - we are aware of the performance difference between pure native callback case (your nativeSortBench) vs. JNI callback one (callbackSortBench); The cost you are seeing there is multiplied, as the compare function is repeatedly called by the qsort logic (not just once as in getpid). E.g. if qsort calls the compare function 5 times, the cost you see is ~5x of the cost for doing a single upcall. On top of that, the cost for doing an upcall is higher than the one for doing a downcall; as I was playing with the hotspot code the other day, I noted that Java calling conventions are arranged in such a way so that making a JNI call can generally be achieved with no argument shuffling (e.g. java register arg # = c register arg # + 1). That is, the downcall JNI bridge can simply insert the JNIEnv parameter in the first C register, and jump - which makes for a very quick adaptation overhead, even in the absence of C2 optimizations. This choice of course pays for downcalls, but when you walk through the details of implementing effective upcall support, it's easy to note how that's working against you: when doing an upcall you have to shift all registers? up by one position before being able to call the Java code, which makes for a more cumbersome shuffling code. I think fixing mismatches like these would go a long way in making performances more symmetric between upcalls and downcalls, but of course that's mostly speculation at this point. Maurizio On 11/10/18 02:18, Samuel Audet wrote: > Hi, Maurizio, > > To get the ball going, I've updated my benchmark code with sorting > examples: > https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 > > With the usual 2-cores VM, Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz, > Ubuntu 14.04, GCC 4.9, OpenJDK 8, I obtained the following: > Benchmark?????????????????????????????? Mode? Cnt???????? Score Error? > Units > NativeBenchmark.expBenchmark?????????? thrpt??? 5? 37684721.600 ? > 1082945.216? ops/s > NativeBenchmark.getpidBenchmark??????? thrpt??? 5? 97760579.697 ? > 3559212.842? ops/s > NativeBenchmark.callbackSortBenchmark? thrpt??? 5??? 362762.157 ? > 11992.584? ops/s > NativeBenchmark.nativeSortBenchmark??? thrpt??? 5?? 7218834.171 ? > 461245.346? ops/s > NativeBenchmark.inlineSortBenchmark??? thrpt??? 5? 17211735.752 ? > 1032386.799? ops/s > > That seems to be consistent with the results you got with JNI on JDK 8: > ??? http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt > ??? https://bugs.openjdk.java.net/browse/JDK-8210975 > Although my callbackSortBenchmark() seems a bit slower. JavaCPP > doesn't currently support static methods for callback functions, which > wouldn't be a problem to support, but for now that's probably where > the small ~10% difference comes from. > > Anyway, what's important is that nativeSortBenchmark() is ~20 times > faster than callbackSortBenchmark(), and inlineSortBenchmark() is ~47 > times faster. > > In theory, how much faster can link2native make > callbackSortBenchmark()? Given the results you provided for getpid(), > I'm guessing maybe 3 or 4 times faster, which sounds good, but it's > still a far cry from nativeSortBenchmark() and especially > inlineSortBenchmark(). So, I get the impression that it is not > possible to make it useful for this kind of use case. I would very > much like to be proven wrong though. > > Samuel > > On 09/21/2018 09:51 AM, Samuel Audet wrote: >> Sounds good, thanks for testing this and for filing the bug report! >> >> Samuel >> >> On 09/21/2018 03:14 AM, Maurizio Cimadamore wrote: >>> Sorry for the delay in getting back at you. There's indeed something >>> fishy going on here, and I have spotted a regression in JNI perf >>> since JDK 11. This could be caused by update in compiler toolchain >>> introduced in same version, but I have filed an issue for our >>> hotspot team to investigate: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8210975 >>> >>> In the context of this discussion, it's likely that the rtegression >>> is affecting the numbers of both Panama (which is built on top of >>> JNI at the moment) and the JNI benchmarks. >>> >>> Thanks >>> Maurizio >>> >>> >>> On 19/09/18 01:13, Samuel Audet wrote: >>>> Thanks! You haven't mentioned the version of the JDK you're using >>>> though. I'm starting to get the impression that JNI in newer >>>> versions of OpenJDK will be slower... ? >>>> >>>> On 09/18/2018 07:03 PM, Maurizio Cimadamore wrote: >>>>> These are the numbers I get >>>>> >>>>> Benchmark???????????????????????? Mode? Cnt???????? Score Error Units >>>>> NativeBenchmark.expBenchmark???? thrpt??? 5? 30542590.094 ? >>>>> 44126.434? ops/s >>>>> NativeBenchmark.getpidBenchmark? thrpt??? 5? 61764677.092 ? >>>>> 21102.236? ops/s >>>>> >>>>> They are in the same ballpark, but exp() is a bit faster; byw, I >>>>> tried to repeat my benchmark with JNI exp() _and_ O3 and I've got >>>>> very similar numbers (yesterday I did a very quick test and there >>>>> was probably some other job running on the machine and brining >>>>> down the figures a bit). >>>>> >>>>> But overall, the results in your bench seem to match what I got: >>>>> exp is faster, pid is slower, the difference is mostly caused by >>>>> O3. If no O3 is used, then the numbers should match what I >>>>> included in my numbers (and getpid should be a bit faster). >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> On 18/09/18 05:48, Samuel Audet wrote: >>>>>> Anyway, I've put online an updated version of my benchmark files >>>>>> here: >>>>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >>>>>> Just run "git clone" on the URL and run "mvn package" on the >>>>>> pom.xml. >>>>>> >>>>>> With the 2 virtual cores of an Intel(R) Xeon(R) CPU E5-2673 v4 @ >>>>>> 2.30GHz running Ubuntu 14.04 on the cloud with GCC 4.9 and >>>>>> OpenJDK 8, I get these numbers: >>>>>> >>>>>> Benchmark???????????????????????? Mode? Cnt Score Error ?Units >>>>>> NativeBenchmark.expBenchmark???? thrpt?? 25 37460540.440 ? >>>>>> 393299.974 ?ops/s >>>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25 100323188.451 ? >>>>>> 1254197.449 ?ops/s >>>>>> >>>>>> While on my laptop, an Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz >>>>>> running Fedora 27, GCC 7.3, and OpenJDK 9, I get the following: >>>>>> >>>>>> Benchmark???????????????????????? Mode? Cnt Score Error Units >>>>>> NativeBenchmark.expBenchmark???? thrpt?? 25 50047147.099 ? >>>>>> 924366.937 ops/s >>>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25 4825508.193 ? >>>>>> 21662.633 ops/s >>>>>> >>>>>> Now, it looks like getpid() is really slow on Fedora 27 for some >>>>>> reason, but as Linus puts it, we should not be using that for >>>>>> benchmarking: >>>>>> https://yarchive.net/comp/linux/getpid_caching.html >>>>>> >>>>>> What do you get on your machines? >>>>>> >>>>>> Samuel >>>>>> >>>>>> >>>>>> On 09/18/2018 12:58 AM, Maurizio Cimadamore wrote: >>>>>>> For the records, here's what I get for all the three benchmarks >>>>>>> if I compile the JNI code with -O3: >>>>>>> >>>>>>> Benchmark????????????????????????? Mode? Cnt Score Error Units >>>>>>> PanamaBenchmark.testJNIExp??????? thrpt??? 5 28575269.294 ? >>>>>>> 1907726.710? ops/s >>>>>>> PanamaBenchmark.testJNIJavaQsort? thrpt??? 5 372148.433 ? >>>>>>> 27178.529? ops/s >>>>>>> PanamaBenchmark.testJNIPid??????? thrpt??? 5 59240069.011 ? >>>>>>> 403881.697? ops/s >>>>>>> >>>>>>> The first and second benchmarks get faster and very close to the >>>>>>> 'direct' optimization numbers in [1]. Surprisingly, the last >>>>>>> benchmark (getpid) is quite slower. I've been able to reproduce >>>>>>> across multiple runs; for that benchmark omitting O3 seems to be >>>>>>> the achieve best results, not sure why. It starts of faster >>>>>>> (around in the first couple of warmup iterations, but then it >>>>>>> goes slower in all the other runs - presumably it interacts >>>>>>> badly with the C2 generated code. For instance, this is a run >>>>>>> with O3 enabled: >>>>>>> >>>>>>> # Run progress: 66.67% complete, ETA 00:01:40 >>>>>>> # Fork: 1 of 1 >>>>>>> # Warmup Iteration?? 1: 65182202.653 ops/s >>>>>>> # Warmup Iteration?? 2: 64900639.094 ops/s >>>>>>> # Warmup Iteration?? 3: 59314945.437 ops/s >>>>>>> <--------------------------------- >>>>>>> # Warmup Iteration?? 4: 59269007.877 ops/s >>>>>>> # Warmup Iteration?? 5: 59239905.163 ops/s >>>>>>> Iteration?? 1: 59300748.074 ops/s >>>>>>> Iteration?? 2: 59249666.044 ops/s >>>>>>> Iteration?? 3: 59268597.051 ops/s >>>>>>> Iteration?? 4: 59322074.572 ops/s >>>>>>> Iteration?? 5: 59059259.317 ops/s >>>>>>> >>>>>>> And this is a run with O3 disabled: >>>>>>> >>>>>>> # Run progress: 0.00% complete, ETA 00:01:40 >>>>>>> # Fork: 1 of 1 >>>>>>> # Warmup Iteration?? 1: 55882128.787 ops/s >>>>>>> # Warmup Iteration?? 2: 53102361.751 ops/s >>>>>>> # Warmup Iteration?? 3: 66964755.699 ops/s >>>>>>> <--------------------------------- >>>>>>> # Warmup Iteration?? 4: 66414428.355 ops/s >>>>>>> # Warmup Iteration?? 5: 65328475.276 ops/s >>>>>>> Iteration?? 1: 64229192.993 ops/s >>>>>>> Iteration?? 2: 65191719.319 ops/s >>>>>>> Iteration?? 3: 65352022.471 ops/s >>>>>>> Iteration?? 4: 65152090.426 ops/s >>>>>>> Iteration?? 5: 65320545.712 ops/s >>>>>>> >>>>>>> >>>>>>> In both cases, the 3rd warmup execution sees a performance jump >>>>>>> - with O3, the jump is backwards, w/o O3 the jump is forward, >>>>>>> which is quite typical for a JMH benchmark as C2 optimization >>>>>>> will start to kick in. >>>>>>> >>>>>>> For these reasons, I'm reluctant to update my benchmark numbers >>>>>>> to reflect the O3 behavior (although I agree that, since the >>>>>>> Hotspot code is compiled with that optimization it would make >>>>>>> more sense to use that as a reference). >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> [1] - >>>>>>> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 17/09/18 16:18, Maurizio Cimadamore wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 17/09/18 15:08, Samuel Audet wrote: >>>>>>>>> Yes, the blackhole or the random number doesn't make any >>>>>>>>> difference, but not calling gcc with -O3 does. Running the >>>>>>>>> compiler with optimizations on is pretty common, but they are >>>>>>>>> not enabled by default. >>>>>>>> A bit better >>>>>>>> >>>>>>>> PanamaBenchmark.testMethod? thrpt??? 5? 28018170.076 ? >>>>>>>> 8491668.248 ops/s >>>>>>>> >>>>>>>> But not much of a difference (I did not expected much, as the >>>>>>>> body of the native method is extremely simple). >>>>>>>> >>>>>>>> Maurizio >>>>>> >>>>> >>>> >>> >> > From maurizio.cimadamore at oracle.com Thu Oct 11 15:02:08 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Oct 2018 16:02:08 +0100 Subject: [foreign] RFR 8212049: Improve jextract usability Message-ID: Hi, quoting from the JBS issue: "There are some low hanging fruits that could significantly improve usability of jextract: 1) auto excluding symbols not found with -l/-L 2) inferring rpath from -L/-l (e.g. -rpath:auto) 3) applying same header settings (e.g. rpath) to ALL headers being extracted, not just the explicitly provided ones 4) treat headers in the same folders as a 'unit' (even if in system folders), and ignore dependencies outside this unit (3) and (4) are particularly important because right now we tend to have many subtle asymmetries between different header files being generated, depending on whether they are explicit/implicit and whether they live in system folders or not. This makes the jextract behaviour particularly hard to grasp." This patch fixes all 1-4 (and additionally fixes a crash when libraries could not be loaded by the symbol checker enabled with -l and -L). I've added (with help of Sundar many thanks!) tests for (1), (2), and (3) (and the crash issue). I also have test for (4), although is probably a bit limited (but better than nothing): I simply check that when extracting an header that depends on we don't end up generating artifacts for stdio too. Webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ You might want to check any existing local tests you might have to make sure nothing is broken by these cha Maurizio From sundararajan.athijegannathan at oracle.com Thu Oct 11 15:37:14 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 11 Oct 2018 21:07:14 +0530 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: References: Message-ID: <5BBF6E2A.1060102@oracle.com> All tests pass on Mac. Questions: * Do we need some escaped name for "auto"? something that can't occur in file system normally? Is the debug print leftover or help for debugging test? (JtregJextract driver) + System.err.println(jextrOpts); -Sundar On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: > Hi, > quoting from the JBS issue: > > "There are some low hanging fruits that could significantly improve > usability of jextract: > > 1) auto excluding symbols not found with -l/-L > 2) inferring rpath from -L/-l (e.g. -rpath:auto) > 3) applying same header settings (e.g. rpath) to ALL headers being > extracted, not just the explicitly provided ones > 4) treat headers in the same folders as a 'unit' (even if in system > folders), and ignore dependencies outside this unit > > (3) and (4) are particularly important because right now we tend to > have many subtle asymmetries between different header files being > generated, depending on whether they are explicit/implicit and whether > they live in system folders or not. This makes the jextract behaviour > particularly hard to grasp." > > This patch fixes all 1-4 (and additionally fixes a crash when > libraries could not be loaded by the symbol checker enabled with -l > and -L). > > I've added (with help of Sundar many thanks!) tests for (1), (2), and > (3) (and the crash issue). I also have test for (4), although is > probably a bit limited (but better than nothing): I simply check that > when extracting an header that depends on we don't end up > generating artifacts for stdio too. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ > > You might want to check any existing local tests you might have to > make sure nothing is broken by these cha > > Maurizio > > From maurizio.cimadamore at oracle.com Thu Oct 11 15:32:42 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Oct 2018 16:32:42 +0100 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: <5BBF6E2A.1060102@oracle.com> References: <5BBF6E2A.1060102@oracle.com> Message-ID: On 11/10/18 16:37, Sundararajan Athijegannathan wrote: > > All tests pass on Mac. Questions: > > * Do we need some escaped name for "auto"? something that can't occur > in file system normally? What about using a new flag - e.g. rpath:auto This is a new option, but shares same radix. Or we could have something completely different: --infer-rpath Suggestions? > > Is the debug print leftover or help for debugging test? (JtregJextract > driver) > > +??????? System.err.println(jextrOpts); Whoops Maurizio > > > -Sundar > > > On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: >> Hi, >> quoting from the JBS issue: >> >> "There are some low hanging fruits that could significantly improve >> usability of jextract: >> >> 1) auto excluding symbols not found with -l/-L >> 2) inferring rpath from -L/-l (e.g. -rpath:auto) >> 3) applying same header settings (e.g. rpath) to ALL headers being >> extracted, not just the explicitly provided ones >> 4) treat headers in the same folders as a 'unit' (even if in system >> folders), and ignore dependencies outside this unit >> >> (3) and (4) are particularly important because right now we tend to >> have many subtle asymmetries between different header files being >> generated, depending on whether they are explicit/implicit and >> whether they live in system folders or not. This makes the jextract >> behaviour particularly hard to grasp." >> >> This patch fixes all 1-4 (and additionally fixes a crash when >> libraries could not be loaded by the symbol checker enabled with -l >> and -L). >> >> I've added (with help of Sundar many thanks!) tests for (1), (2), and >> (3) (and the crash issue). I also have test for (4), although is >> probably a bit limited (but better than nothing): I simply check that >> when extracting an header that depends on we don't end up >> generating artifacts for stdio too. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ >> >> You might want to check any existing local tests you might have to >> make sure nothing is broken by these cha >> >> Maurizio >> >> From henry.jen at oracle.com Thu Oct 11 15:35:27 2018 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 11 Oct 2018 08:35:27 -0700 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: <5BBF6E2A.1060102@oracle.com> References: <5BBF6E2A.1060102@oracle.com> Message-ID: <4A6B6796-4C02-49E3-A2F5-DCA96828F865@oracle.com> It?s good, with a nitpick. I prefer to have separate option to infer rpath instead of ?rpath=auto. It?s just a matter not to impost unnecessary limitation. Who knows if user like to have a folder named auto. Cheers, Henry > On Oct 11, 2018, at 8:37 AM, Sundararajan Athijegannathan wrote: > > > All tests pass on Mac. Questions: > > * Do we need some escaped name for "auto"? something that can't occur in file system normally? > > Is the debug print leftover or help for debugging test? (JtregJextract driver) > > + System.err.println(jextrOpts); > > > -Sundar > > > On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: >> Hi, >> quoting from the JBS issue: >> >> "There are some low hanging fruits that could significantly improve usability of jextract: >> >> 1) auto excluding symbols not found with -l/-L >> 2) inferring rpath from -L/-l (e.g. -rpath:auto) >> 3) applying same header settings (e.g. rpath) to ALL headers being extracted, not just the explicitly provided ones >> 4) treat headers in the same folders as a 'unit' (even if in system folders), and ignore dependencies outside this unit >> >> (3) and (4) are particularly important because right now we tend to have many subtle asymmetries between different header files being generated, depending on whether they are explicit/implicit and whether they live in system folders or not. This makes the jextract behaviour particularly hard to grasp." >> >> This patch fixes all 1-4 (and additionally fixes a crash when libraries could not be loaded by the symbol checker enabled with -l and -L). >> >> I've added (with help of Sundar many thanks!) tests for (1), (2), and (3) (and the crash issue). I also have test for (4), although is probably a bit limited (but better than nothing): I simply check that when extracting an header that depends on we don't end up generating artifacts for stdio too. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ >> >> You might want to check any existing local tests you might have to make sure nothing is broken by these cha >> >> Maurizio >> >> From sundararajan.athijegannathan at oracle.com Thu Oct 11 15:59:19 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 11 Oct 2018 21:29:19 +0530 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: References: <5BBF6E2A.1060102@oracle.com> Message-ID: <5BBF7357.6090409@oracle.com> I like --infer-rpath. Clean and tells exactly what it does. -Sundar On 11/10/18, 9:02 PM, Maurizio Cimadamore wrote: > > > On 11/10/18 16:37, Sundararajan Athijegannathan wrote: >> >> All tests pass on Mac. Questions: >> >> * Do we need some escaped name for "auto"? something that can't occur >> in file system normally? > What about using a new flag - e.g. > > rpath:auto > > This is a new option, but shares same radix. > > Or we could have something completely different: > > --infer-rpath > > Suggestions? >> >> Is the debug print leftover or help for debugging test? >> (JtregJextract driver) >> >> + System.err.println(jextrOpts); > Whoops > > Maurizio >> >> >> -Sundar >> >> >> On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: >>> Hi, >>> quoting from the JBS issue: >>> >>> "There are some low hanging fruits that could significantly improve >>> usability of jextract: >>> >>> 1) auto excluding symbols not found with -l/-L >>> 2) inferring rpath from -L/-l (e.g. -rpath:auto) >>> 3) applying same header settings (e.g. rpath) to ALL headers being >>> extracted, not just the explicitly provided ones >>> 4) treat headers in the same folders as a 'unit' (even if in system >>> folders), and ignore dependencies outside this unit >>> >>> (3) and (4) are particularly important because right now we tend to >>> have many subtle asymmetries between different header files being >>> generated, depending on whether they are explicit/implicit and >>> whether they live in system folders or not. This makes the jextract >>> behaviour particularly hard to grasp." >>> >>> This patch fixes all 1-4 (and additionally fixes a crash when >>> libraries could not be loaded by the symbol checker enabled with -l >>> and -L). >>> >>> I've added (with help of Sundar many thanks!) tests for (1), (2), >>> and (3) (and the crash issue). I also have test for (4), although is >>> probably a bit limited (but better than nothing): I simply check >>> that when extracting an header that depends on we don't >>> end up generating artifacts for stdio too. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ >>> >>> You might want to check any existing local tests you might have to >>> make sure nothing is broken by these cha >>> >>> Maurizio >>> >>> > From maurizio.cimadamore at oracle.com Thu Oct 11 16:01:05 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Oct 2018 17:01:05 +0100 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: <4A6B6796-4C02-49E3-A2F5-DCA96828F865@oracle.com> References: <5BBF6E2A.1060102@oracle.com> <4A6B6796-4C02-49E3-A2F5-DCA96828F865@oracle.com> Message-ID: <5fe30491-9bb0-3783-df0a-9956be613810@oracle.com> Does the --infer-rpath option address your conern? Maurizio On 11/10/18 16:35, Henry Jen wrote: > It?s good, with a nitpick. I prefer to have separate option to infer rpath instead of ?rpath=auto. It?s just a matter not to impost unnecessary limitation. Who knows if user like to have a folder named auto. > > Cheers, > Henry > > >> On Oct 11, 2018, at 8:37 AM, Sundararajan Athijegannathan wrote: >> >> >> All tests pass on Mac. Questions: >> >> * Do we need some escaped name for "auto"? something that can't occur in file system normally? >> >> Is the debug print leftover or help for debugging test? (JtregJextract driver) >> >> + System.err.println(jextrOpts); >> >> >> -Sundar >> >> >> On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: >>> Hi, >>> quoting from the JBS issue: >>> >>> "There are some low hanging fruits that could significantly improve usability of jextract: >>> >>> 1) auto excluding symbols not found with -l/-L >>> 2) inferring rpath from -L/-l (e.g. -rpath:auto) >>> 3) applying same header settings (e.g. rpath) to ALL headers being extracted, not just the explicitly provided ones >>> 4) treat headers in the same folders as a 'unit' (even if in system folders), and ignore dependencies outside this unit >>> >>> (3) and (4) are particularly important because right now we tend to have many subtle asymmetries between different header files being generated, depending on whether they are explicit/implicit and whether they live in system folders or not. This makes the jextract behaviour particularly hard to grasp." >>> >>> This patch fixes all 1-4 (and additionally fixes a crash when libraries could not be loaded by the symbol checker enabled with -l and -L). >>> >>> I've added (with help of Sundar many thanks!) tests for (1), (2), and (3) (and the crash issue). I also have test for (4), although is probably a bit limited (but better than nothing): I simply check that when extracting an header that depends on we don't end up generating artifacts for stdio too. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ >>> >>> You might want to check any existing local tests you might have to make sure nothing is broken by these cha >>> >>> Maurizio >>> >>> From maurizio.cimadamore at oracle.com Thu Oct 11 16:11:51 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Oct 2018 17:11:51 +0100 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: <5BBF7357.6090409@oracle.com> References: <5BBF6E2A.1060102@oracle.com> <5BBF7357.6090409@oracle.com> Message-ID: <1f6d0f03-e02d-b529-3afe-8fe9efda2f27@oracle.com> New webrev http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v4/ Replaces '-rpath auto' with '-infer-rpath' Maurizio On 11/10/18 16:59, Sundararajan Athijegannathan wrote: > I like --infer-rpath. Clean and tells exactly what it does. > > -Sundar > > On 11/10/18, 9:02 PM, Maurizio Cimadamore wrote: >> >> >> On 11/10/18 16:37, Sundararajan Athijegannathan wrote: >>> >>> All tests pass on Mac. Questions: >>> >>> * Do we need some escaped name for "auto"? something that can't >>> occur in file system normally? >> What about using a new flag - e.g. >> >> rpath:auto >> >> This is a new option, but shares same radix. >> >> Or we could have something completely different: >> >> --infer-rpath >> >> Suggestions? >>> >>> Is the debug print leftover or help for debugging test? >>> (JtregJextract driver) >>> >>> +??????? System.err.println(jextrOpts); >> Whoops >> >> Maurizio >>> >>> >>> -Sundar >>> >>> >>> On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: >>>> Hi, >>>> quoting from the JBS issue: >>>> >>>> "There are some low hanging fruits that could significantly improve >>>> usability of jextract: >>>> >>>> 1) auto excluding symbols not found with -l/-L >>>> 2) inferring rpath from -L/-l (e.g. -rpath:auto) >>>> 3) applying same header settings (e.g. rpath) to ALL headers being >>>> extracted, not just the explicitly provided ones >>>> 4) treat headers in the same folders as a 'unit' (even if in system >>>> folders), and ignore dependencies outside this unit >>>> >>>> (3) and (4) are particularly important because right now we tend to >>>> have many subtle asymmetries between different header files being >>>> generated, depending on whether they are explicit/implicit and >>>> whether they live in system folders or not. This makes the jextract >>>> behaviour particularly hard to grasp." >>>> >>>> This patch fixes all 1-4 (and additionally fixes a crash when >>>> libraries could not be loaded by the symbol checker enabled with -l >>>> and -L). >>>> >>>> I've added (with help of Sundar many thanks!) tests for (1), (2), >>>> and (3) (and the crash issue). I also have test for (4), although >>>> is probably a bit limited (but better than nothing): I simply check >>>> that when extracting an header that depends on we don't >>>> end up generating artifacts for stdio too. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ >>>> >>>> You might want to check any existing local tests you might have to >>>> make sure nothing is broken by these cha >>>> >>>> Maurizio >>>> >>>> >> From sundararajan.athijegannathan at oracle.com Thu Oct 11 16:41:07 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 11 Oct 2018 22:11:07 +0530 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: <1f6d0f03-e02d-b529-3afe-8fe9efda2f27@oracle.com> References: <5BBF6E2A.1060102@oracle.com> <5BBF7357.6090409@oracle.com> <1f6d0f03-e02d-b529-3afe-8fe9efda2f27@oracle.com> Message-ID: <5BBF7D23.5000807@oracle.com> Looks good -Sundar On 11/10/18, 9:41 PM, Maurizio Cimadamore wrote: > New webrev > > http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v4/ > > Replaces '-rpath auto' with '-infer-rpath' > > Maurizio > > > On 11/10/18 16:59, Sundararajan Athijegannathan wrote: >> I like --infer-rpath. Clean and tells exactly what it does. >> >> -Sundar >> >> On 11/10/18, 9:02 PM, Maurizio Cimadamore wrote: >>> >>> >>> On 11/10/18 16:37, Sundararajan Athijegannathan wrote: >>>> >>>> All tests pass on Mac. Questions: >>>> >>>> * Do we need some escaped name for "auto"? something that can't >>>> occur in file system normally? >>> What about using a new flag - e.g. >>> >>> rpath:auto >>> >>> This is a new option, but shares same radix. >>> >>> Or we could have something completely different: >>> >>> --infer-rpath >>> >>> Suggestions? >>>> >>>> Is the debug print leftover or help for debugging test? >>>> (JtregJextract driver) >>>> >>>> + System.err.println(jextrOpts); >>> Whoops >>> >>> Maurizio >>>> >>>> >>>> -Sundar >>>> >>>> >>>> On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> quoting from the JBS issue: >>>>> >>>>> "There are some low hanging fruits that could significantly >>>>> improve usability of jextract: >>>>> >>>>> 1) auto excluding symbols not found with -l/-L >>>>> 2) inferring rpath from -L/-l (e.g. -rpath:auto) >>>>> 3) applying same header settings (e.g. rpath) to ALL headers being >>>>> extracted, not just the explicitly provided ones >>>>> 4) treat headers in the same folders as a 'unit' (even if in >>>>> system folders), and ignore dependencies outside this unit >>>>> >>>>> (3) and (4) are particularly important because right now we tend >>>>> to have many subtle asymmetries between different header files >>>>> being generated, depending on whether they are explicit/implicit >>>>> and whether they live in system folders or not. This makes the >>>>> jextract behaviour particularly hard to grasp." >>>>> >>>>> This patch fixes all 1-4 (and additionally fixes a crash when >>>>> libraries could not be loaded by the symbol checker enabled with >>>>> -l and -L). >>>>> >>>>> I've added (with help of Sundar many thanks!) tests for (1), (2), >>>>> and (3) (and the crash issue). I also have test for (4), although >>>>> is probably a bit limited (but better than nothing): I simply >>>>> check that when extracting an header that depends on we >>>>> don't end up generating artifacts for stdio too. >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ >>>>> >>>>> You might want to check any existing local tests you might have to >>>>> make sure nothing is broken by these cha >>>>> >>>>> Maurizio >>>>> >>>>> >>> > From henry.jen at oracle.com Thu Oct 11 16:37:14 2018 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 11 Oct 2018 09:37:14 -0700 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: <5fe30491-9bb0-3783-df0a-9956be613810@oracle.com> References: <5BBF6E2A.1060102@oracle.com> <4A6B6796-4C02-49E3-A2F5-DCA96828F865@oracle.com> <5fe30491-9bb0-3783-df0a-9956be613810@oracle.com> Message-ID: <9CB979B6-7A94-4962-92C1-E293C120FFFC@oracle.com> Absolutely, didn?t see Sundar already mentioned it. Regarding to system header, the comment still said exclude system headers. As the code now include system headers in the same package(i.e extra headers included by the main header in the same folder or subfolder), you probably want to remove that comment at line Contex.javat:367. Other than that, +1 for the patch. For sake of continuing development regarding include, your approach works nicely if the package is in a self-contained folder, like /usr/include/python. It was like that before, but that would blur the boundary if the source header file is directly put in somewhere like /usr/include. I sent out a patch to enable include system headers explicitly, and throw NoSuchMethodException at runtime for missing symbols. http://mail.openjdk.java.net/pipermail/panama-dev/2018-August/002425.html With your patch, symbol checker will exclude missing symbols, which is good. However, we probably still need the binder in case -l is not used during extract to enable symbol checker. Cheers, Henry > On Oct 11, 2018, at 9:01 AM, Maurizio Cimadamore wrote: > > Does the --infer-rpath option address your conern? > > Maurizio > > > On 11/10/18 16:35, Henry Jen wrote: >> It?s good, with a nitpick. I prefer to have separate option to infer rpath instead of ?rpath=auto. It?s just a matter not to impost unnecessary limitation. Who knows if user like to have a folder named auto. >> >> Cheers, >> Henry >> >> >>> On Oct 11, 2018, at 8:37 AM, Sundararajan Athijegannathan wrote: >>> >>> >>> All tests pass on Mac. Questions: >>> >>> * Do we need some escaped name for "auto"? something that can't occur in file system normally? >>> >>> Is the debug print leftover or help for debugging test? (JtregJextract driver) >>> >>> + System.err.println(jextrOpts); >>> >>> >>> -Sundar >>> >>> >>> On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: >>>> Hi, >>>> quoting from the JBS issue: >>>> >>>> "There are some low hanging fruits that could significantly improve usability of jextract: >>>> >>>> 1) auto excluding symbols not found with -l/-L >>>> 2) inferring rpath from -L/-l (e.g. -rpath:auto) >>>> 3) applying same header settings (e.g. rpath) to ALL headers being extracted, not just the explicitly provided ones >>>> 4) treat headers in the same folders as a 'unit' (even if in system folders), and ignore dependencies outside this unit >>>> >>>> (3) and (4) are particularly important because right now we tend to have many subtle asymmetries between different header files being generated, depending on whether they are explicit/implicit and whether they live in system folders or not. This makes the jextract behaviour particularly hard to grasp." >>>> >>>> This patch fixes all 1-4 (and additionally fixes a crash when libraries could not be loaded by the symbol checker enabled with -l and -L). >>>> >>>> I've added (with help of Sundar many thanks!) tests for (1), (2), and (3) (and the crash issue). I also have test for (4), although is probably a bit limited (but better than nothing): I simply check that when extracting an header that depends on we don't end up generating artifacts for stdio too. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ >>>> >>>> You might want to check any existing local tests you might have to make sure nothing is broken by these cha >>>> >>>> Maurizio >>>> >>>> > From maurizio.cimadamore at oracle.com Thu Oct 11 16:42:24 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Oct 2018 17:42:24 +0100 Subject: [foreign] RFR 8212049: Improve jextract usability In-Reply-To: <9CB979B6-7A94-4962-92C1-E293C120FFFC@oracle.com> References: <5BBF6E2A.1060102@oracle.com> <4A6B6796-4C02-49E3-A2F5-DCA96828F865@oracle.com> <5fe30491-9bb0-3783-df0a-9956be613810@oracle.com> <9CB979B6-7A94-4962-92C1-E293C120FFFC@oracle.com> Message-ID: <19a2362e-1a11-1c9d-08a3-dab7fb3cd9a1@oracle.com> On 11/10/18 17:37, Henry Jen wrote: > Absolutely, didn?t see Sundar already mentioned it. > > Regarding to system header, the comment still said exclude system headers. As the code now include system headers in the same package(i.e extra headers included by the main header in the same folder or subfolder), you probably want to remove that comment at line Contex.javat:367. > > Other than that, +1 for the patch. I'll fix that on the fly and commit. Thanks. > > For sake of continuing development regarding include, your approach works nicely if the package is in a self-contained folder, like /usr/include/python. It was like that before, but that would blur the boundary if the source header file is directly put in somewhere like /usr/include. > > I sent out a patch to enable include system headers explicitly, and throw NoSuchMethodException at runtime for missing symbols. > http://mail.openjdk.java.net/pipermail/panama-dev/2018-August/002425.html I'm sympathetic to your use case - I believe what you want in that case is not 'don't follow system headers', but don't follow _period_. E.g. don't follow dependencies (and check hard if there are missing symbols in the extracted artifact). I'm less sympathetic with the binder fixing up missing stuff - if a symbol _for which there's a declaration in the header anno_ is missing I believe we should fail; there's enough indication of the intention that the symbol needs to be part of the interface. Maurizio > > With your patch, symbol checker will exclude missing symbols, which is good. However, we probably still need the binder in case -l is not used during extract to enable symbol checker. > > Cheers, > Henry > >> On Oct 11, 2018, at 9:01 AM, Maurizio Cimadamore wrote: >> >> Does the --infer-rpath option address your conern? >> >> Maurizio >> >> >> On 11/10/18 16:35, Henry Jen wrote: >>> It?s good, with a nitpick. I prefer to have separate option to infer rpath instead of ?rpath=auto. It?s just a matter not to impost unnecessary limitation. Who knows if user like to have a folder named auto. >>> >>> Cheers, >>> Henry >>> >>> >>>> On Oct 11, 2018, at 8:37 AM, Sundararajan Athijegannathan wrote: >>>> >>>> >>>> All tests pass on Mac. Questions: >>>> >>>> * Do we need some escaped name for "auto"? something that can't occur in file system normally? >>>> >>>> Is the debug print leftover or help for debugging test? (JtregJextract driver) >>>> >>>> + System.err.println(jextrOpts); >>>> >>>> >>>> -Sundar >>>> >>>> >>>> On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> quoting from the JBS issue: >>>>> >>>>> "There are some low hanging fruits that could significantly improve usability of jextract: >>>>> >>>>> 1) auto excluding symbols not found with -l/-L >>>>> 2) inferring rpath from -L/-l (e.g. -rpath:auto) >>>>> 3) applying same header settings (e.g. rpath) to ALL headers being extracted, not just the explicitly provided ones >>>>> 4) treat headers in the same folders as a 'unit' (even if in system folders), and ignore dependencies outside this unit >>>>> >>>>> (3) and (4) are particularly important because right now we tend to have many subtle asymmetries between different header files being generated, depending on whether they are explicit/implicit and whether they live in system folders or not. This makes the jextract behaviour particularly hard to grasp." >>>>> >>>>> This patch fixes all 1-4 (and additionally fixes a crash when libraries could not be loaded by the symbol checker enabled with -l and -L). >>>>> >>>>> I've added (with help of Sundar many thanks!) tests for (1), (2), and (3) (and the crash issue). I also have test for (4), although is probably a bit limited (but better than nothing): I simply check that when extracting an header that depends on we don't end up generating artifacts for stdio too. >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/ >>>>> >>>>> You might want to check any existing local tests you might have to make sure nothing is broken by these cha >>>>> >>>>> Maurizio >>>>> >>>>> From maurizio.cimadamore at oracle.com Thu Oct 11 16:45:58 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 11 Oct 2018 16:45:58 +0000 Subject: hg: panama/dev: 8212049: Improve jextract usability Message-ID: <201810111645.w9BGjwWF005133@aojmv0008.oracle.com> Changeset: 2d3127b5645c Author: mcimadamore Date: 2018-10-11 17:45 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/2d3127b5645c 8212049: Improve jextract usability Reviewed-by: sundar, hjen ! src/jdk.jextract/share/classes/com/sun/tools/jextract/Context.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/Main.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/resources/Messages.properties ! test/jdk/com/sun/tools/jextract/JextractToolProviderTest.java ! test/jdk/com/sun/tools/jextract/JtregJextract.java + test/jdk/com/sun/tools/jextract/missing/MissingSymbolTest.java + test/jdk/com/sun/tools/jextract/missing/libMissing.c + test/jdk/com/sun/tools/jextract/missing/missing.h + test/jdk/com/sun/tools/jextract/rpath/RpathTest.java + test/jdk/com/sun/tools/jextract/rpath/bar.h + test/jdk/com/sun/tools/jextract/rpath/foo.h + test/jdk/com/sun/tools/jextract/systemHeaders/SystemHeadersTest.java + test/jdk/com/sun/tools/jextract/systemHeaders/foo.h From maurizio.cimadamore at oracle.com Thu Oct 11 17:35:57 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Oct 2018 18:35:57 +0100 Subject: [foreign] RFR 8212061: Fix jextract command line errors and crashes Message-ID: <6aff48f9-e088-5fc9-fb4d-6207f7603e24@oracle.com> This patch fixes two further problems with the jextract tool: 1) jextract will attempt to generate a jarfile where the extracted header is - if that is a system header, this leads to permission issues (e.g. cannot write to xyz) 2) If some option is used but no actual header file is specified, jextract crashes with exception (1) has been addressed by using working dir, which should lead to more predictable behavior. (2) has been fixed by checking for absence of input files, and issuing an error if that happens. Webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8212061/ Cheers Maurizio From henry.jen at oracle.com Thu Oct 11 19:25:58 2018 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 11 Oct 2018 12:25:58 -0700 Subject: [foreign] RFR 8212061: Fix jextract command line errors and crashes In-Reply-To: <6aff48f9-e088-5fc9-fb4d-6207f7603e24@oracle.com> References: <6aff48f9-e088-5fc9-fb4d-6207f7603e24@oracle.com> Message-ID: <8D26619D-9315-463E-A54E-A7AF2379C838@oracle.com> Looks good. This is same behavior as javac. Cheers, Henry > On Oct 11, 2018, at 10:35 AM, Maurizio Cimadamore wrote: > > This patch fixes two further problems with the jextract tool: > > 1) jextract will attempt to generate a jarfile where the extracted header is - if that is a system header, this leads to permission issues (e.g. cannot write to xyz) > 2) If some option is used but no actual header file is specified, jextract crashes with exception > > > (1) has been addressed by using working dir, which should lead to more predictable behavior. (2) has been fixed by checking for absence of input files, and issuing an error if that happens. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8212061/ > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Thu Oct 11 22:44:02 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 11 Oct 2018 22:44:02 +0000 Subject: hg: panama/dev: 8212061: Fix jextract command line errors and crashes Message-ID: <201810112244.w9BMi3Ua005281@aojmv0008.oracle.com> Changeset: c8daf579cc92 Author: mcimadamore Date: 2018-10-11 23:43 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/c8daf579cc92 8212061: Fix jextract command line errors and crashes Reviewed-by: hjen ! src/jdk.jextract/share/classes/com/sun/tools/jextract/Main.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/resources/Messages.properties ! test/jdk/com/sun/tools/jextract/JextractToolProviderTest.java + test/jdk/com/sun/tools/jextract/defaultOutput/TestDefaultOutput.java + test/jdk/com/sun/tools/jextract/defaultOutput/foo/foo.h From sundararajan.athijegannathan at oracle.com Fri Oct 12 02:39:27 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 12 Oct 2018 08:09:27 +0530 Subject: [foreign] RFR 8212061: Fix jextract command line errors and crashes In-Reply-To: <8D26619D-9315-463E-A54E-A7AF2379C838@oracle.com> References: <6aff48f9-e088-5fc9-fb4d-6207f7603e24@oracle.com> <8D26619D-9315-463E-A54E-A7AF2379C838@oracle.com> Message-ID: <5BC0095F.5010204@oracle.com> Am I missing something? javac produces .class on the same dir where .java was found - in other words, javac's behaviour is similar jextract (before this patch). -Sundar On 12/10/18, 12:55 AM, Henry Jen wrote: > Looks good. This is same behavior as javac. > > Cheers, > Henry > > >> On Oct 11, 2018, at 10:35 AM, Maurizio Cimadamore wrote: >> >> This patch fixes two further problems with the jextract tool: >> >> 1) jextract will attempt to generate a jarfile where the extracted header is - if that is a system header, this leads to permission issues (e.g. cannot write to xyz) >> 2) If some option is used but no actual header file is specified, jextract crashes with exception >> >> >> (1) has been addressed by using working dir, which should lead to more predictable behavior. (2) has been fixed by checking for absence of input files, and issuing an error if that happens. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8212061/ >> >> Cheers >> Maurizio >> From henry.jen at oracle.com Fri Oct 12 02:31:49 2018 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 11 Oct 2018 19:31:49 -0700 Subject: [foreign] RFR 8212061: Fix jextract command line errors and crashes In-Reply-To: <5BC0095F.5010204@oracle.com> References: <6aff48f9-e088-5fc9-fb4d-6207f7603e24@oracle.com> <8D26619D-9315-463E-A54E-A7AF2379C838@oracle.com> <5BC0095F.5010204@oracle.com> Message-ID: <8EE08609-1C0A-4ACD-B94A-2919E8D1BF8A@oracle.com> Sorry I was not clear, I meant the behavior with out input file. Was wondering why not print usage. Cheers, Henry > On Oct 11, 2018, at 7:39 PM, Sundararajan Athijegannathan wrote: > > Am I missing something? javac produces .class on the same dir where .java was found - in other words, javac's behaviour is similar jextract (before this patch). > > -Sundar > > On 12/10/18, 12:55 AM, Henry Jen wrote: >> Looks good. This is same behavior as javac. >> >> Cheers, >> Henry >> >> >>> On Oct 11, 2018, at 10:35 AM, Maurizio Cimadamore wrote: >>> >>> This patch fixes two further problems with the jextract tool: >>> >>> 1) jextract will attempt to generate a jarfile where the extracted header is - if that is a system header, this leads to permission issues (e.g. cannot write to xyz) >>> 2) If some option is used but no actual header file is specified, jextract crashes with exception >>> >>> >>> (1) has been addressed by using working dir, which should lead to more predictable behavior. (2) has been fixed by checking for absence of input files, and issuing an error if that happens. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8212061/ >>> >>> Cheers >>> Maurizio >>> From sundararajan.athijegannathan at oracle.com Fri Oct 12 02:43:48 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 12 Oct 2018 08:13:48 +0530 Subject: [foreign] RFR 8212061: Fix jextract command line errors and crashes In-Reply-To: <8EE08609-1C0A-4ACD-B94A-2919E8D1BF8A@oracle.com> References: <6aff48f9-e088-5fc9-fb4d-6207f7603e24@oracle.com> <8D26619D-9315-463E-A54E-A7AF2379C838@oracle.com> <5BC0095F.5010204@oracle.com> <8EE08609-1C0A-4ACD-B94A-2919E8D1BF8A@oracle.com> Message-ID: <5BC00A64.1070905@oracle.com> okay. I agree on error for lack of input files. -Sundar On 12/10/18, 8:01 AM, Henry Jen wrote: > Sorry I was not clear, I meant the behavior with out input file. Was wondering why not print usage. > > Cheers, > Henry > >> On Oct 11, 2018, at 7:39 PM, Sundararajan Athijegannathan wrote: >> >> Am I missing something? javac produces .class on the same dir where .java was found - in other words, javac's behaviour is similar jextract (before this patch). >> >> -Sundar >> >> On 12/10/18, 12:55 AM, Henry Jen wrote: >>> Looks good. This is same behavior as javac. >>> >>> Cheers, >>> Henry >>> >>> >>>> On Oct 11, 2018, at 10:35 AM, Maurizio Cimadamore wrote: >>>> >>>> This patch fixes two further problems with the jextract tool: >>>> >>>> 1) jextract will attempt to generate a jarfile where the extracted header is - if that is a system header, this leads to permission issues (e.g. cannot write to xyz) >>>> 2) If some option is used but no actual header file is specified, jextract crashes with exception >>>> >>>> >>>> (1) has been addressed by using working dir, which should lead to more predictable behavior. (2) has been fixed by checking for absence of input files, and issuing an error if that happens. >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8212061/ >>>> >>>> Cheers >>>> Maurizio >>>> From vladimir.x.ivanov at oracle.com Fri Oct 12 03:18:16 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Oct 2018 20:18:16 -0700 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> Message-ID: <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> >>>> So, my question boils down to: how vector shape checks are expected >>>> to work on *ScalableVectors in presence of operations which change vector >> size. >>>> >>>> For example, IntScalableVector.rebracket() => LongScalableVector >>>> which is fine, but ISV.resize() => ISV is what I'm concerned about >>>> and existing checks aren't enough for *ScalableVectors unless you >>>> check their length at runtime. >>> >>> Thanks for the detailed explanation. So, which checks do you mean here? Do >> you mean this [1]? I find that current Java implementations already has some >> runtime length checks. One thing we need to consider is the ambiguity between >> existing sizes and scalable size. Current VectorIntrinsics.reinterpret() just tries to >> get the shape from size (library_call.cpp:get_exact_klass_for_vector_box) instead >> of getting the real class from input argument, which will lead to >> ClassCastException. Maybe that can be fixed by adding real klass type to the >> reinterpret function. >> >> The checks I referred to are the casts on vector shapes which are part of every >> vector operation (e.g., [2]), but they don't immediately relate to shape-changing >> operations. >> > > OK, but I would expect the normal operations between SV and other vectors are illegal, though they may have the same size, since users usually don't know the real size of SV. We should treat SV different from other vectors. Yes, the checks currently in place effectively forbid mixing vectors of different shapes. But API allows to reshape/cast vectors to arbitrary shapes and that may cause problems if equivalent shapes meet at runtime. Since concrete vector shapes aren't part of API, I believe it is possible to exclude duplicating shapes at runtime. For example, SVs can be used as a substitute for *512V shapes on 512-bit SVE or AVX512-capable hardware. It seems current JDK-JVM interface (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), but it would be very interesting to hear your experience. API allows to query vectors of smaller/larger sizes than hardware natively supports and implementation has to support that (even if performance suffers). It means SV shapes can coexist at runtime with existing shapes (*64V/.../*512V) and casts/reshapes between all those shapes should work. Best regards, Vladimir Ivanov >> It seems I had some wrong assumptions when coming up with the examples. >> Sorry for the confusion. Taking those into account, here's my take on current >> state of vector shape changing operations w.r.t. SV shapes. >> >> There'll be 30 vector shapes in total (5 sizes x 6 element types): >> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV >> * Short64V, ..., ShortSV >> ... >> * Double64V, Double128V, ... Double512V, DoubleSV >> >> Depending on hardware, SVs may alias with "explicitly sized" shapes (e.g., IntSV is >> equivalent to Int512V on AVX512 capable H/W). >> >> (1) Vector.rebracket(): works fine for SVs since vector size (in bits) stays the same: >> IntSV <-> LongSV <-> ... <-> DoubleSV. >> >> (2) Vector.resize(): SV->SV doesn't make sense and the operation should involve >> both SV and existing vector shapes: IntSV <-> Int64V/Int128V/.../Int512V. The >> ambiguity you mention can cause problems and needs to be carefully handled to >> avoid 2 equivalent shapes to meet at runtime. Otherwise, vector shape checks I >> mentioned earlier should be changed. >> > > Yes, we will try to address this issue carefully in the follow-up webrev. > >> (3) Vector.cast(): SV->SV, SV<->64V/.../512V >> * size-preserving transformations (int <-> float): >> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV; >> >> * widening casts (e.g., int->long) >> SV->SV/64V/...: truncate upper part of the vector, since SVs already >> represent widest vector shapes; >> 64V/...->SV: either truncated or filled with defaults depending on actual size >> >> * narrowing casts (e.g., long->int) >> SV->SV/64V/...: fill upper part of SV with defaults; >> 64V/...->SV: either truncated or filled with defaults depending on actual size >> > > Thanks, > Ningsheng > From jean-philippe.halimi at intel.com Fri Oct 12 18:38:31 2018 From: jean-philippe.halimi at intel.com (jean-philippe.halimi at intel.com) Date: Fri, 12 Oct 2018 18:38:31 +0000 Subject: hg: panama/dev: Fix SVML Windows build issues Message-ID: <201810121838.w9CIcVWD026375@aojmv0008.oracle.com> Changeset: 151d891dca7f Author: jphalimi Date: 2018-10-12 11:37 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/151d891dca7f Fix SVML Windows build issues ! src/hotspot/os_cpu/windows_x86/globals_vectorApiSupport_windows.hpp ! src/hotspot/share/utilities/globalDefinitions_vecApi.hpp From maurizio.cimadamore at oracle.com Fri Oct 12 18:42:15 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 12 Oct 2018 18:42:15 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810121842.w9CIgGYJ000256@aojmv0008.oracle.com> Changeset: 0f484474fe79 Author: mcimadamore Date: 2018-10-12 20:44 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/0f484474fe79 Automatic merge with vectorIntrinsics From vivek.r.deshpande at intel.com Sat Oct 13 00:15:06 2018 From: vivek.r.deshpande at intel.com (vivek.r.deshpande at intel.com) Date: Sat, 13 Oct 2018 00:15:06 +0000 Subject: hg: panama/dev: fix vpermb encoding Message-ID: <201810130015.w9D0F7RG025197@aojmv0008.oracle.com> Changeset: 1909b6cc6c93 Author: vdeshpande Date: 2018-10-12 17:12 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1909b6cc6c93 fix vpermb encoding ! src/hotspot/cpu/x86/assembler_x86.cpp From maurizio.cimadamore at oracle.com Sat Oct 13 00:17:02 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 13 Oct 2018 00:17:02 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810130017.w9D0H3mW026077@aojmv0008.oracle.com> Changeset: 978a9f569754 Author: mcimadamore Date: 2018-10-13 02:19 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/978a9f569754 Automatic merge with vectorIntrinsics From maurizio.cimadamore at oracle.com Mon Oct 15 13:00:09 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Oct 2018 13:00:09 +0000 Subject: hg: panama/dev: Add support for CDS in java_lang_invoke_NativeEntryPoint Message-ID: <201810151300.w9FD09tk009206@aojmv0008.oracle.com> Changeset: 73e08761cda9 Author: mcimadamore Date: 2018-10-15 13:59 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/73e08761cda9 Add support for CDS in java_lang_invoke_NativeEntryPoint ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp From maurizio.cimadamore at oracle.com Mon Oct 15 14:05:25 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Oct 2018 14:05:25 +0000 Subject: hg: panama/dev: manual merge with default Message-ID: <201810151405.w9FE5Pw6016727@aojmv0008.oracle.com> Changeset: 4529f4a02e31 Author: mcimadamore Date: 2018-10-15 15:05 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/4529f4a02e31 manual merge with default ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/jdk/com/sun/jdi/DeferredStepTest.sh - test/jdk/com/sun/jdi/ShellScaffold.sh - test/jdk/com/sun/jdi/ZZZcleanup.sh From maurizio.cimadamore at oracle.com Mon Oct 15 14:07:20 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Oct 2018 14:07:20 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810151407.w9FE7KiY017851@aojmv0008.oracle.com> Changeset: b4d93b0c27fe Author: mcimadamore Date: 2018-10-15 16:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b4d93b0c27fe Automatic merge with vectorIntrinsics ! make/autoconf/basics.m4 ! make/autoconf/spec.gmk.in ! make/common/Modules.gmk ! make/conf/jib-profiles.js - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/jdk/com/sun/jdi/DeferredStepTest.sh - test/jdk/com/sun/jdi/ShellScaffold.sh - test/jdk/com/sun/jdi/ZZZcleanup.sh From maurizio.cimadamore at oracle.com Mon Oct 15 14:07:38 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Oct 2018 14:07:38 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810151407.w9FE7c2M018257@aojmv0008.oracle.com> Changeset: 2a40c53d796d Author: mcimadamore Date: 2018-10-15 16:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/2a40c53d796d Automatic merge with foreign ! make/common/Modules.gmk From maurizio.cimadamore at oracle.com Mon Oct 15 14:19:33 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Oct 2018 15:19:33 +0100 Subject: [foreign] RFR 8212182: HelpFlagsTest fails because of lack of jextract support Message-ID: Hi, this patch fixes a test failure due to the lack of a profile for the jextract tool. (another option to fix this would be to exclude jextract from the test entirely...) Webrev: http://cr.openjdk.java.net/~mcimadamore/panama/8212182/ Cheers Maurizio From sundararajan.athijegannathan at oracle.com Mon Oct 15 14:40:45 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 15 Oct 2018 20:10:45 +0530 Subject: [foreign] RFR 8212182: HelpFlagsTest fails because of lack of jextract support In-Reply-To: References: Message-ID: <5BC4A6ED.801@oracle.com> Looks good. PS. Tested it on Mac. It works fine. -Sundar On 15/10/18, 7:49 PM, Maurizio Cimadamore wrote: > Hi, > this patch fixes a test failure due to the lack of a profile for the > jextract tool. > > (another option to fix this would be to exclude jextract from the test > entirely...) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/panama/8212182/ > > Cheers > Maurizio > > From maurizio.cimadamore at oracle.com Mon Oct 15 15:30:24 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Oct 2018 15:30:24 +0000 Subject: hg: panama/dev: 8212182: HelpFlagsTest fails because of lack of jextract support Message-ID: <201810151530.w9FFUPk8004541@aojmv0008.oracle.com> Changeset: 63093f898b50 Author: mcimadamore Date: 2018-10-15 16:29 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/63093f898b50 8212182: HelpFlagsTest fails because of lack of jextract support Reviewed-by: sundar ! test/jdk/tools/launcher/HelpFlagsTest.java From maurizio.cimadamore at oracle.com Mon Oct 15 15:32:04 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 15 Oct 2018 15:32:04 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810151532.w9FFW4BP005594@aojmv0008.oracle.com> Changeset: c1ee01a70af0 Author: mcimadamore Date: 2018-10-15 17:34 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c1ee01a70af0 Automatic merge with foreign From samuel.audet at gmail.com Tue Oct 16 07:24:11 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Tue, 16 Oct 2018 16:24:11 +0900 Subject: [foreign] some JMH benchmarks In-Reply-To: <82880be5-488a-a628-6778-713bee76b0a7@oracle.com> References: <03fd2280-50a7-7772-7100-317a199ecf78@oracle.com> <34d05b5e-cae7-a82e-5f7b-a84d904cc8b7@oracle.com> <106fc755-1f1a-1fba-5de2-03b0e21e9a86@oracle.com> <25be0579-eb55-65e7-b379-206b8713a687@gmail.com> <580516c9-0ef2-0ceb-7c8c-c67d6621c074@gmail.com> <55e13144-ad01-dd24-5081-864ebe8e7524@oracle.com> <26e88428-a2fc-5833-8433-ca394ef19f96@gmail.com> <36c98f68-edb2-18d1-5355-ebd8863a27d7@gmail.com> <82880be5-488a-a628-6778-713bee76b0a7@oracle.com> Message-ID: I see, thanks for the explanation about the internals! I was aware of the performance issue with callbacks and what quicksort entails, but not about what happens in HotSpot. Given that Panama is doing away with the mandatory arguments for JNI, would it make sense to make the Java ABI match the native ABI, at least for methods that interact with native code? I'm sure it would hurt JNI, but we could provide a VM option to let users decide on a per application basis. What do you think? BTW, I've updated my benchmarks to get some numbers for std::map: https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 It's not as bad as I thought it was, or put another way, std::map is a lot of slower than I thought it was, even slower than java.util.HashMap, so even JNI is kind of usable in this case: NativeBenchmark.sumBenchmark thrpt 5 550427.311 ? 12725.331 ops/s NativeBenchmark.nativeSumBenchmark thrpt 5 1371863.410 ? 44171.140 ops/s NativeBenchmark.javaSumBenchmark thrpt 5 1977540.009 ? 58851.055 ops/s For reference, that's still with 2-cores VM, Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz, Ubuntu 14.04, GCC 4.9, OpenJDK 8. Samuel On 10/11/2018 04:59 PM, Maurizio Cimadamore wrote: > Thanks for the numbers - we are aware of the performance difference > between pure native callback case (your nativeSortBench) vs. JNI > callback one (callbackSortBench); The cost you are seeing there is > multiplied, as the compare function is repeatedly called by the qsort > logic (not just once as in getpid). E.g. if qsort calls the compare > function 5 times, the cost you see is ~5x of the cost for doing a single > upcall. > > On top of that, the cost for doing an upcall is higher than the one for > doing a downcall; as I was playing with the hotspot code the other day, > I noted that Java calling conventions are arranged in such a way so that > making a JNI call can generally be achieved with no argument shuffling > (e.g. java register arg # = c register arg # + 1). That is, the downcall > JNI bridge can simply insert the JNIEnv parameter in the first C > register, and jump - which makes for a very quick adaptation overhead, > even in the absence of C2 optimizations. > > This choice of course pays for downcalls, but when you walk through the > details of implementing effective upcall support, it's easy to note how > that's working against you: when doing an upcall you have to shift all > registers? up by one position before being able to call the Java code, > which makes for a more cumbersome shuffling code. > > I think fixing mismatches like these would go a long way in making > performances more symmetric between upcalls and downcalls, but of course > that's mostly speculation at this point. > > Maurizio > > > On 11/10/18 02:18, Samuel Audet wrote: >> Hi, Maurizio, >> >> To get the ball going, I've updated my benchmark code with sorting >> examples: >> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >> >> With the usual 2-cores VM, Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz, >> Ubuntu 14.04, GCC 4.9, OpenJDK 8, I obtained the following: >> Benchmark?????????????????????????????? Mode? Cnt???????? Score Error >> Units >> NativeBenchmark.expBenchmark?????????? thrpt??? 5? 37684721.600 ? >> 1082945.216? ops/s >> NativeBenchmark.getpidBenchmark??????? thrpt??? 5? 97760579.697 ? >> 3559212.842? ops/s >> NativeBenchmark.callbackSortBenchmark? thrpt??? 5??? 362762.157 ? >> 11992.584? ops/s >> NativeBenchmark.nativeSortBenchmark??? thrpt??? 5?? 7218834.171 ? >> 461245.346? ops/s >> NativeBenchmark.inlineSortBenchmark??? thrpt??? 5? 17211735.752 ? >> 1032386.799? ops/s >> >> That seems to be consistent with the results you got with JNI on JDK 8: >> ??? http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt >> ??? https://bugs.openjdk.java.net/browse/JDK-8210975 >> Although my callbackSortBenchmark() seems a bit slower. JavaCPP >> doesn't currently support static methods for callback functions, which >> wouldn't be a problem to support, but for now that's probably where >> the small ~10% difference comes from. >> >> Anyway, what's important is that nativeSortBenchmark() is ~20 times >> faster than callbackSortBenchmark(), and inlineSortBenchmark() is ~47 >> times faster. >> >> In theory, how much faster can link2native make >> callbackSortBenchmark()? Given the results you provided for getpid(), >> I'm guessing maybe 3 or 4 times faster, which sounds good, but it's >> still a far cry from nativeSortBenchmark() and especially >> inlineSortBenchmark(). So, I get the impression that it is not >> possible to make it useful for this kind of use case. I would very >> much like to be proven wrong though. >> >> Samuel >> >> On 09/21/2018 09:51 AM, Samuel Audet wrote: >>> Sounds good, thanks for testing this and for filing the bug report! >>> >>> Samuel >>> >>> On 09/21/2018 03:14 AM, Maurizio Cimadamore wrote: >>>> Sorry for the delay in getting back at you. There's indeed something >>>> fishy going on here, and I have spotted a regression in JNI perf >>>> since JDK 11. This could be caused by update in compiler toolchain >>>> introduced in same version, but I have filed an issue for our >>>> hotspot team to investigate: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8210975 >>>> >>>> In the context of this discussion, it's likely that the rtegression >>>> is affecting the numbers of both Panama (which is built on top of >>>> JNI at the moment) and the JNI benchmarks. >>>> >>>> Thanks >>>> Maurizio >>>> >>>> >>>> On 19/09/18 01:13, Samuel Audet wrote: >>>>> Thanks! You haven't mentioned the version of the JDK you're using >>>>> though. I'm starting to get the impression that JNI in newer >>>>> versions of OpenJDK will be slower... ? >>>>> >>>>> On 09/18/2018 07:03 PM, Maurizio Cimadamore wrote: >>>>>> These are the numbers I get >>>>>> >>>>>> Benchmark???????????????????????? Mode? Cnt???????? Score Error Units >>>>>> NativeBenchmark.expBenchmark???? thrpt??? 5? 30542590.094 ? >>>>>> 44126.434? ops/s >>>>>> NativeBenchmark.getpidBenchmark? thrpt??? 5? 61764677.092 ? >>>>>> 21102.236? ops/s >>>>>> >>>>>> They are in the same ballpark, but exp() is a bit faster; byw, I >>>>>> tried to repeat my benchmark with JNI exp() _and_ O3 and I've got >>>>>> very similar numbers (yesterday I did a very quick test and there >>>>>> was probably some other job running on the machine and brining >>>>>> down the figures a bit). >>>>>> >>>>>> But overall, the results in your bench seem to match what I got: >>>>>> exp is faster, pid is slower, the difference is mostly caused by >>>>>> O3. If no O3 is used, then the numbers should match what I >>>>>> included in my numbers (and getpid should be a bit faster). >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 18/09/18 05:48, Samuel Audet wrote: >>>>>>> Anyway, I've put online an updated version of my benchmark files >>>>>>> here: >>>>>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >>>>>>> Just run "git clone" on the URL and run "mvn package" on the >>>>>>> pom.xml. >>>>>>> >>>>>>> With the 2 virtual cores of an Intel(R) Xeon(R) CPU E5-2673 v4 @ >>>>>>> 2.30GHz running Ubuntu 14.04 on the cloud with GCC 4.9 and >>>>>>> OpenJDK 8, I get these numbers: >>>>>>> >>>>>>> Benchmark???????????????????????? Mode? Cnt Score Error ?Units >>>>>>> NativeBenchmark.expBenchmark???? thrpt?? 25 37460540.440 ? >>>>>>> 393299.974 ?ops/s >>>>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25 100323188.451 ? >>>>>>> 1254197.449 ?ops/s >>>>>>> >>>>>>> While on my laptop, an Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz >>>>>>> running Fedora 27, GCC 7.3, and OpenJDK 9, I get the following: >>>>>>> >>>>>>> Benchmark???????????????????????? Mode? Cnt Score Error Units >>>>>>> NativeBenchmark.expBenchmark???? thrpt?? 25 50047147.099 ? >>>>>>> 924366.937 ops/s >>>>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25 4825508.193 ? >>>>>>> 21662.633 ops/s >>>>>>> >>>>>>> Now, it looks like getpid() is really slow on Fedora 27 for some >>>>>>> reason, but as Linus puts it, we should not be using that for >>>>>>> benchmarking: >>>>>>> https://yarchive.net/comp/linux/getpid_caching.html >>>>>>> >>>>>>> What do you get on your machines? >>>>>>> >>>>>>> Samuel >>>>>>> >>>>>>> >>>>>>> On 09/18/2018 12:58 AM, Maurizio Cimadamore wrote: >>>>>>>> For the records, here's what I get for all the three benchmarks >>>>>>>> if I compile the JNI code with -O3: >>>>>>>> >>>>>>>> Benchmark????????????????????????? Mode? Cnt Score Error Units >>>>>>>> PanamaBenchmark.testJNIExp??????? thrpt??? 5 28575269.294 ? >>>>>>>> 1907726.710? ops/s >>>>>>>> PanamaBenchmark.testJNIJavaQsort? thrpt??? 5 372148.433 ? >>>>>>>> 27178.529? ops/s >>>>>>>> PanamaBenchmark.testJNIPid??????? thrpt??? 5 59240069.011 ? >>>>>>>> 403881.697? ops/s >>>>>>>> >>>>>>>> The first and second benchmarks get faster and very close to the >>>>>>>> 'direct' optimization numbers in [1]. Surprisingly, the last >>>>>>>> benchmark (getpid) is quite slower. I've been able to reproduce >>>>>>>> across multiple runs; for that benchmark omitting O3 seems to be >>>>>>>> the achieve best results, not sure why. It starts of faster >>>>>>>> (around in the first couple of warmup iterations, but then it >>>>>>>> goes slower in all the other runs - presumably it interacts >>>>>>>> badly with the C2 generated code. For instance, this is a run >>>>>>>> with O3 enabled: >>>>>>>> >>>>>>>> # Run progress: 66.67% complete, ETA 00:01:40 >>>>>>>> # Fork: 1 of 1 >>>>>>>> # Warmup Iteration?? 1: 65182202.653 ops/s >>>>>>>> # Warmup Iteration?? 2: 64900639.094 ops/s >>>>>>>> # Warmup Iteration?? 3: 59314945.437 ops/s >>>>>>>> <--------------------------------- >>>>>>>> # Warmup Iteration?? 4: 59269007.877 ops/s >>>>>>>> # Warmup Iteration?? 5: 59239905.163 ops/s >>>>>>>> Iteration?? 1: 59300748.074 ops/s >>>>>>>> Iteration?? 2: 59249666.044 ops/s >>>>>>>> Iteration?? 3: 59268597.051 ops/s >>>>>>>> Iteration?? 4: 59322074.572 ops/s >>>>>>>> Iteration?? 5: 59059259.317 ops/s >>>>>>>> >>>>>>>> And this is a run with O3 disabled: >>>>>>>> >>>>>>>> # Run progress: 0.00% complete, ETA 00:01:40 >>>>>>>> # Fork: 1 of 1 >>>>>>>> # Warmup Iteration?? 1: 55882128.787 ops/s >>>>>>>> # Warmup Iteration?? 2: 53102361.751 ops/s >>>>>>>> # Warmup Iteration?? 3: 66964755.699 ops/s >>>>>>>> <--------------------------------- >>>>>>>> # Warmup Iteration?? 4: 66414428.355 ops/s >>>>>>>> # Warmup Iteration?? 5: 65328475.276 ops/s >>>>>>>> Iteration?? 1: 64229192.993 ops/s >>>>>>>> Iteration?? 2: 65191719.319 ops/s >>>>>>>> Iteration?? 3: 65352022.471 ops/s >>>>>>>> Iteration?? 4: 65152090.426 ops/s >>>>>>>> Iteration?? 5: 65320545.712 ops/s >>>>>>>> >>>>>>>> >>>>>>>> In both cases, the 3rd warmup execution sees a performance jump >>>>>>>> - with O3, the jump is backwards, w/o O3 the jump is forward, >>>>>>>> which is quite typical for a JMH benchmark as C2 optimization >>>>>>>> will start to kick in. >>>>>>>> >>>>>>>> For these reasons, I'm reluctant to update my benchmark numbers >>>>>>>> to reflect the O3 behavior (although I agree that, since the >>>>>>>> Hotspot code is compiled with that optimization it would make >>>>>>>> more sense to use that as a reference). >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> [1] - >>>>>>>> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt >>>>>>>> >>>>>>>> >>>>>>>> From maurizio.cimadamore at oracle.com Tue Oct 16 07:36:41 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 16 Oct 2018 08:36:41 +0100 Subject: [foreign] some JMH benchmarks In-Reply-To: References: <03fd2280-50a7-7772-7100-317a199ecf78@oracle.com> <34d05b5e-cae7-a82e-5f7b-a84d904cc8b7@oracle.com> <106fc755-1f1a-1fba-5de2-03b0e21e9a86@oracle.com> <25be0579-eb55-65e7-b379-206b8713a687@gmail.com> <580516c9-0ef2-0ceb-7c8c-c67d6621c074@gmail.com> <55e13144-ad01-dd24-5081-864ebe8e7524@oracle.com> <26e88428-a2fc-5833-8433-ca394ef19f96@gmail.com> <36c98f68-edb2-18d1-5355-ebd8863a27d7@gmail.com> <82880be5-488a-a628-6778-713bee76b0a7@oracle.com> Message-ID: <37a1c3a8-d1c7-6bac-05e5-370fbd0343b8@oracle.com> On 16/10/18 08:24, Samuel Audet wrote: > I see, thanks for the explanation about the internals! I was aware of > the performance issue with callbacks and what quicksort entails, but > not about what happens in HotSpot. > > Given that Panama is doing away with the mandatory arguments for JNI, > would it make sense to make the Java ABI match the native ABI, at > least for methods that interact with native code? I'm sure it would > hurt JNI, but we could provide a VM option to let users decide on a > per application basis. What do you think? Thanks for the extra numbers. As for changing calling conventions, I'm not sure is feasible (but speaking with my "I'm not a JIT/hotspot expert hat on" ;-) ). As you say, JNI performance could suffer, but most importantly, hotspot has already to maintain a matrix of { interpreted, compiled } x { interpreted, compiled } - e.g. the source/target method could be already compiled by the JIT or not; so adding an extra compiled mode with different calling conventions would mean supporting 6 adaptation flavors (ignoring the 3 trivial identity ones) instead of just 2 - so that would be significant cost for the JVM to swallow. Maurizio > > BTW, I've updated my benchmarks to get some numbers for std::map: > https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 > > It's not as bad as I thought it was, or put another way, std::map is a > lot of slower than I thought it was, even slower than > java.util.HashMap, so even JNI is kind of usable in this case: > NativeBenchmark.sumBenchmark?????????? thrpt??? 5??? 550427.311 ? > 12725.331? ops/s > NativeBenchmark.nativeSumBenchmark???? thrpt??? 5?? 1371863.410 ? > 44171.140? ops/s > NativeBenchmark.javaSumBenchmark?????? thrpt??? 5?? 1977540.009 ? > 58851.055? ops/s > > For reference, that's still with 2-cores VM, Intel(R) Xeon(R) CPU > E5-2673 v4 @ 2.30GHz, Ubuntu 14.04, GCC 4.9, OpenJDK 8. > > Samuel > > On 10/11/2018 04:59 PM, Maurizio Cimadamore wrote: >> Thanks for the numbers - we are aware of the performance difference >> between pure native callback case (your nativeSortBench) vs. JNI >> callback one (callbackSortBench); The cost you are seeing there is >> multiplied, as the compare function is repeatedly called by the qsort >> logic (not just once as in getpid). E.g. if qsort calls the compare >> function 5 times, the cost you see is ~5x of the cost for doing a >> single upcall. >> >> On top of that, the cost for doing an upcall is higher than the one >> for doing a downcall; as I was playing with the hotspot code the >> other day, I noted that Java calling conventions are arranged in such >> a way so that making a JNI call can generally be achieved with no >> argument shuffling (e.g. java register arg # = c register arg # + 1). >> That is, the downcall JNI bridge can simply insert the JNIEnv >> parameter in the first C register, and jump - which makes for a very >> quick adaptation overhead, even in the absence of C2 optimizations. >> >> This choice of course pays for downcalls, but when you walk through >> the details of implementing effective upcall support, it's easy to >> note how that's working against you: when doing an upcall you have to >> shift all registers? up by one position before being able to call the >> Java code, which makes for a more cumbersome shuffling code. >> >> I think fixing mismatches like these would go a long way in making >> performances more symmetric between upcalls and downcalls, but of >> course that's mostly speculation at this point. >> >> Maurizio >> >> >> On 11/10/18 02:18, Samuel Audet wrote: >>> Hi, Maurizio, >>> >>> To get the ball going, I've updated my benchmark code with sorting >>> examples: >>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >>> >>> With the usual 2-cores VM, Intel(R) Xeon(R) CPU E5-2673 v4 @ >>> 2.30GHz, Ubuntu 14.04, GCC 4.9, OpenJDK 8, I obtained the following: >>> Benchmark?????????????????????????????? Mode? Cnt Score Error Units >>> NativeBenchmark.expBenchmark?????????? thrpt??? 5 37684721.600 ? >>> 1082945.216? ops/s >>> NativeBenchmark.getpidBenchmark??????? thrpt??? 5 97760579.697 ? >>> 3559212.842? ops/s >>> NativeBenchmark.callbackSortBenchmark? thrpt??? 5 362762.157 ? >>> 11992.584? ops/s >>> NativeBenchmark.nativeSortBenchmark??? thrpt??? 5 7218834.171 ? >>> 461245.346? ops/s >>> NativeBenchmark.inlineSortBenchmark??? thrpt??? 5 17211735.752 ? >>> 1032386.799? ops/s >>> >>> That seems to be consistent with the results you got with JNI on JDK 8: >>> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt >>> ??? https://bugs.openjdk.java.net/browse/JDK-8210975 >>> Although my callbackSortBenchmark() seems a bit slower. JavaCPP >>> doesn't currently support static methods for callback functions, >>> which wouldn't be a problem to support, but for now that's probably >>> where the small ~10% difference comes from. >>> >>> Anyway, what's important is that nativeSortBenchmark() is ~20 times >>> faster than callbackSortBenchmark(), and inlineSortBenchmark() is >>> ~47 times faster. >>> >>> In theory, how much faster can link2native make >>> callbackSortBenchmark()? Given the results you provided for >>> getpid(), I'm guessing maybe 3 or 4 times faster, which sounds good, >>> but it's still a far cry from nativeSortBenchmark() and especially >>> inlineSortBenchmark(). So, I get the impression that it is not >>> possible to make it useful for this kind of use case. I would very >>> much like to be proven wrong though. >>> >>> Samuel >>> >>> On 09/21/2018 09:51 AM, Samuel Audet wrote: >>>> Sounds good, thanks for testing this and for filing the bug report! >>>> >>>> Samuel >>>> >>>> On 09/21/2018 03:14 AM, Maurizio Cimadamore wrote: >>>>> Sorry for the delay in getting back at you. There's indeed >>>>> something fishy going on here, and I have spotted a regression in >>>>> JNI perf since JDK 11. This could be caused by update in compiler >>>>> toolchain introduced in same version, but I have filed an issue >>>>> for our hotspot team to investigate: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8210975 >>>>> >>>>> In the context of this discussion, it's likely that the >>>>> rtegression is affecting the numbers of both Panama (which is >>>>> built on top of JNI at the moment) and the JNI benchmarks. >>>>> >>>>> Thanks >>>>> Maurizio >>>>> >>>>> >>>>> On 19/09/18 01:13, Samuel Audet wrote: >>>>>> Thanks! You haven't mentioned the version of the JDK you're using >>>>>> though. I'm starting to get the impression that JNI in newer >>>>>> versions of OpenJDK will be slower... ? >>>>>> >>>>>> On 09/18/2018 07:03 PM, Maurizio Cimadamore wrote: >>>>>>> These are the numbers I get >>>>>>> >>>>>>> Benchmark???????????????????????? Mode? Cnt Score Error Units >>>>>>> NativeBenchmark.expBenchmark???? thrpt??? 5 30542590.094 ? >>>>>>> 44126.434? ops/s >>>>>>> NativeBenchmark.getpidBenchmark? thrpt??? 5 61764677.092 ? >>>>>>> 21102.236? ops/s >>>>>>> >>>>>>> They are in the same ballpark, but exp() is a bit faster; byw, I >>>>>>> tried to repeat my benchmark with JNI exp() _and_ O3 and I've >>>>>>> got very similar numbers (yesterday I did a very quick test and >>>>>>> there was probably some other job running on the machine and >>>>>>> brining down the figures a bit). >>>>>>> >>>>>>> But overall, the results in your bench seem to match what I got: >>>>>>> exp is faster, pid is slower, the difference is mostly caused by >>>>>>> O3. If no O3 is used, then the numbers should match what I >>>>>>> included in my numbers (and getpid should be a bit faster). >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> >>>>>>> On 18/09/18 05:48, Samuel Audet wrote: >>>>>>>> Anyway, I've put online an updated version of my benchmark >>>>>>>> files here: >>>>>>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >>>>>>>> Just run "git clone" on the URL and run "mvn package" on the >>>>>>>> pom.xml. >>>>>>>> >>>>>>>> With the 2 virtual cores of an Intel(R) Xeon(R) CPU E5-2673 v4 >>>>>>>> @ 2.30GHz running Ubuntu 14.04 on the cloud with GCC 4.9 and >>>>>>>> OpenJDK 8, I get these numbers: >>>>>>>> >>>>>>>> Benchmark???????????????????????? Mode? Cnt Score Error ?Units >>>>>>>> NativeBenchmark.expBenchmark???? thrpt?? 25 37460540.440 ? >>>>>>>> 393299.974 ?ops/s >>>>>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25 100323188.451 ? >>>>>>>> 1254197.449 ?ops/s >>>>>>>> >>>>>>>> While on my laptop, an Intel(R) Core(TM) i7-7700HQ CPU @ >>>>>>>> 2.80GHz running Fedora 27, GCC 7.3, and OpenJDK 9, I get the >>>>>>>> following: >>>>>>>> >>>>>>>> Benchmark???????????????????????? Mode? Cnt Score Error Units >>>>>>>> NativeBenchmark.expBenchmark???? thrpt?? 25 50047147.099 ? >>>>>>>> 924366.937 ops/s >>>>>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25 4825508.193 ? >>>>>>>> 21662.633 ops/s >>>>>>>> >>>>>>>> Now, it looks like getpid() is really slow on Fedora 27 for >>>>>>>> some reason, but as Linus puts it, we should not be using that >>>>>>>> for benchmarking: >>>>>>>> https://yarchive.net/comp/linux/getpid_caching.html >>>>>>>> >>>>>>>> What do you get on your machines? >>>>>>>> >>>>>>>> Samuel >>>>>>>> >>>>>>>> >>>>>>>> On 09/18/2018 12:58 AM, Maurizio Cimadamore wrote: >>>>>>>>> For the records, here's what I get for all the three >>>>>>>>> benchmarks if I compile the JNI code with -O3: >>>>>>>>> >>>>>>>>> Benchmark????????????????????????? Mode? Cnt Score Error Units >>>>>>>>> PanamaBenchmark.testJNIExp??????? thrpt??? 5 28575269.294 ? >>>>>>>>> 1907726.710? ops/s >>>>>>>>> PanamaBenchmark.testJNIJavaQsort? thrpt??? 5 372148.433 ? >>>>>>>>> 27178.529? ops/s >>>>>>>>> PanamaBenchmark.testJNIPid??????? thrpt??? 5 59240069.011 ? >>>>>>>>> 403881.697? ops/s >>>>>>>>> >>>>>>>>> The first and second benchmarks get faster and very close to >>>>>>>>> the 'direct' optimization numbers in [1]. Surprisingly, the >>>>>>>>> last benchmark (getpid) is quite slower. I've been able to >>>>>>>>> reproduce across multiple runs; for that benchmark omitting O3 >>>>>>>>> seems to be the achieve best results, not sure why. It starts >>>>>>>>> of faster (around in the first couple of warmup iterations, >>>>>>>>> but then it goes slower in all the other runs - presumably it >>>>>>>>> interacts badly with the C2 generated code. For instance, this >>>>>>>>> is a run with O3 enabled: >>>>>>>>> >>>>>>>>> # Run progress: 66.67% complete, ETA 00:01:40 >>>>>>>>> # Fork: 1 of 1 >>>>>>>>> # Warmup Iteration?? 1: 65182202.653 ops/s >>>>>>>>> # Warmup Iteration?? 2: 64900639.094 ops/s >>>>>>>>> # Warmup Iteration?? 3: 59314945.437 ops/s >>>>>>>>> <--------------------------------- >>>>>>>>> # Warmup Iteration?? 4: 59269007.877 ops/s >>>>>>>>> # Warmup Iteration?? 5: 59239905.163 ops/s >>>>>>>>> Iteration?? 1: 59300748.074 ops/s >>>>>>>>> Iteration?? 2: 59249666.044 ops/s >>>>>>>>> Iteration?? 3: 59268597.051 ops/s >>>>>>>>> Iteration?? 4: 59322074.572 ops/s >>>>>>>>> Iteration?? 5: 59059259.317 ops/s >>>>>>>>> >>>>>>>>> And this is a run with O3 disabled: >>>>>>>>> >>>>>>>>> # Run progress: 0.00% complete, ETA 00:01:40 >>>>>>>>> # Fork: 1 of 1 >>>>>>>>> # Warmup Iteration?? 1: 55882128.787 ops/s >>>>>>>>> # Warmup Iteration?? 2: 53102361.751 ops/s >>>>>>>>> # Warmup Iteration?? 3: 66964755.699 ops/s >>>>>>>>> <--------------------------------- >>>>>>>>> # Warmup Iteration?? 4: 66414428.355 ops/s >>>>>>>>> # Warmup Iteration?? 5: 65328475.276 ops/s >>>>>>>>> Iteration?? 1: 64229192.993 ops/s >>>>>>>>> Iteration?? 2: 65191719.319 ops/s >>>>>>>>> Iteration?? 3: 65352022.471 ops/s >>>>>>>>> Iteration?? 4: 65152090.426 ops/s >>>>>>>>> Iteration?? 5: 65320545.712 ops/s >>>>>>>>> >>>>>>>>> >>>>>>>>> In both cases, the 3rd warmup execution sees a performance >>>>>>>>> jump - with O3, the jump is backwards, w/o O3 the jump is >>>>>>>>> forward, which is quite typical for a JMH benchmark as C2 >>>>>>>>> optimization will start to kick in. >>>>>>>>> >>>>>>>>> For these reasons, I'm reluctant to update my benchmark >>>>>>>>> numbers to reflect the O3 behavior (although I agree that, >>>>>>>>> since the Hotspot code is compiled with that optimization it >>>>>>>>> would make more sense to use that as a reference). >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> [1] - >>>>>>>>> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> From samuel.audet at gmail.com Tue Oct 16 11:12:27 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Tue, 16 Oct 2018 20:12:27 +0900 Subject: [foreign] some JMH benchmarks In-Reply-To: <37a1c3a8-d1c7-6bac-05e5-370fbd0343b8@oracle.com> References: <03fd2280-50a7-7772-7100-317a199ecf78@oracle.com> <34d05b5e-cae7-a82e-5f7b-a84d904cc8b7@oracle.com> <106fc755-1f1a-1fba-5de2-03b0e21e9a86@oracle.com> <25be0579-eb55-65e7-b379-206b8713a687@gmail.com> <580516c9-0ef2-0ceb-7c8c-c67d6621c074@gmail.com> <55e13144-ad01-dd24-5081-864ebe8e7524@oracle.com> <26e88428-a2fc-5833-8433-ca394ef19f96@gmail.com> <36c98f68-edb2-18d1-5355-ebd8863a27d7@gmail.com> <82880be5-488a-a628-6778-713bee76b0a7@oracle.com> <37a1c3a8-d1c7-6bac-05e5-370fbd0343b8@oracle.com> Message-ID: Hum, I think I'm beginning to understand the motivation behind GraalVM... On 10/16/2018 04:36 PM, Maurizio Cimadamore wrote: > On 16/10/18 08:24, Samuel Audet wrote: >> I see, thanks for the explanation about the internals! I was aware of >> the performance issue with callbacks and what quicksort entails, but >> not about what happens in HotSpot. >> >> Given that Panama is doing away with the mandatory arguments for JNI, >> would it make sense to make the Java ABI match the native ABI, at >> least for methods that interact with native code? I'm sure it would >> hurt JNI, but we could provide a VM option to let users decide on a >> per application basis. What do you think? > Thanks for the extra numbers. > > As for changing calling conventions, I'm not sure is feasible (but > speaking with my "I'm not a JIT/hotspot expert hat on" ;-) ). As you > say, JNI performance could suffer, but most importantly, hotspot has > already to maintain a matrix of { interpreted, compiled } x { > interpreted, compiled } - e.g. the source/target method could be already > compiled by the JIT or not; so adding an extra compiled mode with > different calling conventions would mean supporting 6 adaptation flavors > (ignoring the 3 trivial identity ones) instead of just 2 - so that would > be significant cost for the JVM to swallow. > > Maurizio >> >> BTW, I've updated my benchmarks to get some numbers for std::map: >> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >> >> It's not as bad as I thought it was, or put another way, std::map is a >> lot of slower than I thought it was, even slower than >> java.util.HashMap, so even JNI is kind of usable in this case: >> NativeBenchmark.sumBenchmark?????????? thrpt??? 5??? 550427.311 ? >> 12725.331? ops/s >> NativeBenchmark.nativeSumBenchmark???? thrpt??? 5?? 1371863.410 ? >> 44171.140? ops/s >> NativeBenchmark.javaSumBenchmark?????? thrpt??? 5?? 1977540.009 ? >> 58851.055? ops/s >> >> For reference, that's still with 2-cores VM, Intel(R) Xeon(R) CPU >> E5-2673 v4 @ 2.30GHz, Ubuntu 14.04, GCC 4.9, OpenJDK 8. >> >> Samuel >> >> On 10/11/2018 04:59 PM, Maurizio Cimadamore wrote: >>> Thanks for the numbers - we are aware of the performance difference >>> between pure native callback case (your nativeSortBench) vs. JNI >>> callback one (callbackSortBench); The cost you are seeing there is >>> multiplied, as the compare function is repeatedly called by the qsort >>> logic (not just once as in getpid). E.g. if qsort calls the compare >>> function 5 times, the cost you see is ~5x of the cost for doing a >>> single upcall. >>> >>> On top of that, the cost for doing an upcall is higher than the one >>> for doing a downcall; as I was playing with the hotspot code the >>> other day, I noted that Java calling conventions are arranged in such >>> a way so that making a JNI call can generally be achieved with no >>> argument shuffling (e.g. java register arg # = c register arg # + 1). >>> That is, the downcall JNI bridge can simply insert the JNIEnv >>> parameter in the first C register, and jump - which makes for a very >>> quick adaptation overhead, even in the absence of C2 optimizations. >>> >>> This choice of course pays for downcalls, but when you walk through >>> the details of implementing effective upcall support, it's easy to >>> note how that's working against you: when doing an upcall you have to >>> shift all registers? up by one position before being able to call the >>> Java code, which makes for a more cumbersome shuffling code. >>> >>> I think fixing mismatches like these would go a long way in making >>> performances more symmetric between upcalls and downcalls, but of >>> course that's mostly speculation at this point. >>> >>> Maurizio >>> >>> >>> On 11/10/18 02:18, Samuel Audet wrote: >>>> Hi, Maurizio, >>>> >>>> To get the ball going, I've updated my benchmark code with sorting >>>> examples: >>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >>>> >>>> With the usual 2-cores VM, Intel(R) Xeon(R) CPU E5-2673 v4 @ >>>> 2.30GHz, Ubuntu 14.04, GCC 4.9, OpenJDK 8, I obtained the following: >>>> Benchmark?????????????????????????????? Mode? Cnt Score Error Units >>>> NativeBenchmark.expBenchmark?????????? thrpt??? 5 37684721.600 ? >>>> 1082945.216? ops/s >>>> NativeBenchmark.getpidBenchmark??????? thrpt??? 5 97760579.697 ? >>>> 3559212.842? ops/s >>>> NativeBenchmark.callbackSortBenchmark? thrpt??? 5 362762.157 ? >>>> 11992.584? ops/s >>>> NativeBenchmark.nativeSortBenchmark??? thrpt??? 5 7218834.171 ? >>>> 461245.346? ops/s >>>> NativeBenchmark.inlineSortBenchmark??? thrpt??? 5 17211735.752 ? >>>> 1032386.799? ops/s >>>> >>>> That seems to be consistent with the results you got with JNI on JDK 8: >>>> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8210975 >>>> Although my callbackSortBenchmark() seems a bit slower. JavaCPP >>>> doesn't currently support static methods for callback functions, >>>> which wouldn't be a problem to support, but for now that's probably >>>> where the small ~10% difference comes from. >>>> >>>> Anyway, what's important is that nativeSortBenchmark() is ~20 times >>>> faster than callbackSortBenchmark(), and inlineSortBenchmark() is >>>> ~47 times faster. >>>> >>>> In theory, how much faster can link2native make >>>> callbackSortBenchmark()? Given the results you provided for >>>> getpid(), I'm guessing maybe 3 or 4 times faster, which sounds good, >>>> but it's still a far cry from nativeSortBenchmark() and especially >>>> inlineSortBenchmark(). So, I get the impression that it is not >>>> possible to make it useful for this kind of use case. I would very >>>> much like to be proven wrong though. >>>> >>>> Samuel >>>> >>>> On 09/21/2018 09:51 AM, Samuel Audet wrote: >>>>> Sounds good, thanks for testing this and for filing the bug report! >>>>> >>>>> Samuel >>>>> >>>>> On 09/21/2018 03:14 AM, Maurizio Cimadamore wrote: >>>>>> Sorry for the delay in getting back at you. There's indeed >>>>>> something fishy going on here, and I have spotted a regression in >>>>>> JNI perf since JDK 11. This could be caused by update in compiler >>>>>> toolchain introduced in same version, but I have filed an issue >>>>>> for our hotspot team to investigate: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8210975 >>>>>> >>>>>> In the context of this discussion, it's likely that the >>>>>> rtegression is affecting the numbers of both Panama (which is >>>>>> built on top of JNI at the moment) and the JNI benchmarks. >>>>>> >>>>>> Thanks >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 19/09/18 01:13, Samuel Audet wrote: >>>>>>> Thanks! You haven't mentioned the version of the JDK you're using >>>>>>> though. I'm starting to get the impression that JNI in newer >>>>>>> versions of OpenJDK will be slower... ? >>>>>>> >>>>>>> On 09/18/2018 07:03 PM, Maurizio Cimadamore wrote: >>>>>>>> These are the numbers I get >>>>>>>> >>>>>>>> Benchmark???????????????????????? Mode? Cnt Score Error Units >>>>>>>> NativeBenchmark.expBenchmark???? thrpt??? 5 30542590.094 ? >>>>>>>> 44126.434? ops/s >>>>>>>> NativeBenchmark.getpidBenchmark? thrpt??? 5 61764677.092 ? >>>>>>>> 21102.236? ops/s >>>>>>>> >>>>>>>> They are in the same ballpark, but exp() is a bit faster; byw, I >>>>>>>> tried to repeat my benchmark with JNI exp() _and_ O3 and I've >>>>>>>> got very similar numbers (yesterday I did a very quick test and >>>>>>>> there was probably some other job running on the machine and >>>>>>>> brining down the figures a bit). >>>>>>>> >>>>>>>> But overall, the results in your bench seem to match what I got: >>>>>>>> exp is faster, pid is slower, the difference is mostly caused by >>>>>>>> O3. If no O3 is used, then the numbers should match what I >>>>>>>> included in my numbers (and getpid should be a bit faster). >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> >>>>>>>> On 18/09/18 05:48, Samuel Audet wrote: >>>>>>>>> Anyway, I've put online an updated version of my benchmark >>>>>>>>> files here: >>>>>>>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69 >>>>>>>>> Just run "git clone" on the URL and run "mvn package" on the >>>>>>>>> pom.xml. >>>>>>>>> >>>>>>>>> With the 2 virtual cores of an Intel(R) Xeon(R) CPU E5-2673 v4 >>>>>>>>> @ 2.30GHz running Ubuntu 14.04 on the cloud with GCC 4.9 and >>>>>>>>> OpenJDK 8, I get these numbers: >>>>>>>>> >>>>>>>>> Benchmark???????????????????????? Mode? Cnt Score Error ?Units >>>>>>>>> NativeBenchmark.expBenchmark???? thrpt?? 25 37460540.440 ? >>>>>>>>> 393299.974 ?ops/s >>>>>>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25 100323188.451 ? >>>>>>>>> 1254197.449 ?ops/s >>>>>>>>> >>>>>>>>> While on my laptop, an Intel(R) Core(TM) i7-7700HQ CPU @ >>>>>>>>> 2.80GHz running Fedora 27, GCC 7.3, and OpenJDK 9, I get the >>>>>>>>> following: >>>>>>>>> >>>>>>>>> Benchmark???????????????????????? Mode? Cnt Score Error Units >>>>>>>>> NativeBenchmark.expBenchmark???? thrpt?? 25 50047147.099 ? >>>>>>>>> 924366.937 ops/s >>>>>>>>> NativeBenchmark.getpidBenchmark? thrpt?? 25 4825508.193 ? >>>>>>>>> 21662.633 ops/s >>>>>>>>> >>>>>>>>> Now, it looks like getpid() is really slow on Fedora 27 for >>>>>>>>> some reason, but as Linus puts it, we should not be using that >>>>>>>>> for benchmarking: >>>>>>>>> https://yarchive.net/comp/linux/getpid_caching.html >>>>>>>>> >>>>>>>>> What do you get on your machines? >>>>>>>>> >>>>>>>>> Samuel >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/18/2018 12:58 AM, Maurizio Cimadamore wrote: >>>>>>>>>> For the records, here's what I get for all the three >>>>>>>>>> benchmarks if I compile the JNI code with -O3: >>>>>>>>>> >>>>>>>>>> Benchmark????????????????????????? Mode? Cnt Score Error Units >>>>>>>>>> PanamaBenchmark.testJNIExp??????? thrpt??? 5 28575269.294 ? >>>>>>>>>> 1907726.710? ops/s >>>>>>>>>> PanamaBenchmark.testJNIJavaQsort? thrpt??? 5 372148.433 ? >>>>>>>>>> 27178.529? ops/s >>>>>>>>>> PanamaBenchmark.testJNIPid??????? thrpt??? 5 59240069.011 ? >>>>>>>>>> 403881.697? ops/s >>>>>>>>>> >>>>>>>>>> The first and second benchmarks get faster and very close to >>>>>>>>>> the 'direct' optimization numbers in [1]. Surprisingly, the >>>>>>>>>> last benchmark (getpid) is quite slower. I've been able to >>>>>>>>>> reproduce across multiple runs; for that benchmark omitting O3 >>>>>>>>>> seems to be the achieve best results, not sure why. It starts >>>>>>>>>> of faster (around in the first couple of warmup iterations, >>>>>>>>>> but then it goes slower in all the other runs - presumably it >>>>>>>>>> interacts badly with the C2 generated code. For instance, this >>>>>>>>>> is a run with O3 enabled: >>>>>>>>>> >>>>>>>>>> # Run progress: 66.67% complete, ETA 00:01:40 >>>>>>>>>> # Fork: 1 of 1 >>>>>>>>>> # Warmup Iteration?? 1: 65182202.653 ops/s >>>>>>>>>> # Warmup Iteration?? 2: 64900639.094 ops/s >>>>>>>>>> # Warmup Iteration?? 3: 59314945.437 ops/s >>>>>>>>>> <--------------------------------- >>>>>>>>>> # Warmup Iteration?? 4: 59269007.877 ops/s >>>>>>>>>> # Warmup Iteration?? 5: 59239905.163 ops/s >>>>>>>>>> Iteration?? 1: 59300748.074 ops/s >>>>>>>>>> Iteration?? 2: 59249666.044 ops/s >>>>>>>>>> Iteration?? 3: 59268597.051 ops/s >>>>>>>>>> Iteration?? 4: 59322074.572 ops/s >>>>>>>>>> Iteration?? 5: 59059259.317 ops/s >>>>>>>>>> >>>>>>>>>> And this is a run with O3 disabled: >>>>>>>>>> >>>>>>>>>> # Run progress: 0.00% complete, ETA 00:01:40 >>>>>>>>>> # Fork: 1 of 1 >>>>>>>>>> # Warmup Iteration?? 1: 55882128.787 ops/s >>>>>>>>>> # Warmup Iteration?? 2: 53102361.751 ops/s >>>>>>>>>> # Warmup Iteration?? 3: 66964755.699 ops/s >>>>>>>>>> <--------------------------------- >>>>>>>>>> # Warmup Iteration?? 4: 66414428.355 ops/s >>>>>>>>>> # Warmup Iteration?? 5: 65328475.276 ops/s >>>>>>>>>> Iteration?? 1: 64229192.993 ops/s >>>>>>>>>> Iteration?? 2: 65191719.319 ops/s >>>>>>>>>> Iteration?? 3: 65352022.471 ops/s >>>>>>>>>> Iteration?? 4: 65152090.426 ops/s >>>>>>>>>> Iteration?? 5: 65320545.712 ops/s >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In both cases, the 3rd warmup execution sees a performance >>>>>>>>>> jump - with O3, the jump is backwards, w/o O3 the jump is >>>>>>>>>> forward, which is quite typical for a JMH benchmark as C2 >>>>>>>>>> optimization will start to kick in. >>>>>>>>>> >>>>>>>>>> For these reasons, I'm reluctant to update my benchmark >>>>>>>>>> numbers to reflect the O3 behavior (although I agree that, >>>>>>>>>> since the Hotspot code is compiled with that optimization it >>>>>>>>>> would make more sense to use that as a reference). >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> [1] - >>>>>>>>>> http://cr.openjdk.java.net/~mcimadamore/panama/foreign-jmh.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > From jean-philippe.halimi at intel.com Wed Oct 17 00:34:26 2018 From: jean-philippe.halimi at intel.com (jean-philippe.halimi at intel.com) Date: Wed, 17 Oct 2018 00:34:26 +0000 Subject: hg: panama/dev: VectorAPI: disable SVML routines for KNL on Windows Message-ID: <201810170034.w9H0YRmL003805@aojmv0008.oracle.com> Changeset: a6e1c1fd5e27 Author: jphalimi Date: 2018-10-16 17:33 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 VectorAPI: disable SVML routines for KNL on Windows ! src/hotspot/share/opto/library_call.cpp From maurizio.cimadamore at oracle.com Wed Oct 17 00:37:21 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Oct 2018 00:37:21 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810170037.w9H0bMoJ005145@aojmv0008.oracle.com> Changeset: dd6ce725af02 Author: mcimadamore Date: 2018-10-17 02:39 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/dd6ce725af02 Automatic merge with vectorIntrinsics From sundararajan.athijegannathan at oracle.com Wed Oct 17 05:35:21 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 17 Oct 2018 11:05:21 +0530 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class Message-ID: <5BC6CA19.5000101@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 Webrev: http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html Thanks, -Sundar From maurizio.cimadamore at oracle.com Wed Oct 17 09:55:17 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 17 Oct 2018 10:55:17 +0100 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <5BC6CA19.5000101@oracle.com> References: <5BC6CA19.5000101@oracle.com> Message-ID: <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> I like it! Few questions/comments: * should it be enabled/disabled with explicit option * should the name of the statics class be customizable * I like the code organization - have you thought of pushing it further and make StaticForwarderGenerator a _subclass_ of AsmCodeFactory - each visitor could maybe delegate to super.visitXyz() first and then do its own bit? Then when you setup the pipeline, depending on what info is available on the context (e.g. presence of -l) you can decide whether to use a 'bare' ASMCodeFactory or the 'embellished' one. That should remove all the 'if staticFwd != null ...' sections from AsmCodeFactory. Maurizio On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 > Webrev: http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 17 12:37:16 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 17 Oct 2018 18:07:16 +0530 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> Message-ID: <5BC72CFC.9@oracle.com> On option: do we need an explicit option? given that one file extra and that too only when -l is specified. (too many options already? ;) ) On naming: we've derived automatic names elsewhere. I think we could revisit all naming options by another round - perhaps even java convention for header interface name. On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt class and extended it from AsmCodeFactory. visit methods now return Boolean to tell if the particular tree was handled or not. This is needed so that subclass can avoid the same tree if super class avoided it (for eg. function-like macros, repeated definitions..) Updated: http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html Thanks, -Sundar On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: > I like it! Few questions/comments: > > * should it be enabled/disabled with explicit option > * should the name of the statics class be customizable > * I like the code organization - have you thought of pushing it > further and make StaticForwarderGenerator a _subclass_ of > AsmCodeFactory - each visitor could maybe delegate to super.visitXyz() > first and then do its own bit? Then when you setup the pipeline, > depending on what info is available on the context (e.g. presence of > -l) you can decide whether to use a 'bare' ASMCodeFactory or the > 'embellished' one. That should remove all the 'if staticFwd != null > ...' sections from AsmCodeFactory. > > Maurizio > > > On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >> Webrev: http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >> >> Thanks, >> -Sundar From jbvernee at xs4all.nl Wed Oct 17 15:43:05 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Wed, 17 Oct 2018 17:43:05 +0200 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <5BC72CFC.9@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> Message-ID: Sundararajan Athijegannathan schreef op 2018-10-17 14:37: > On option: do we need an explicit option? given that one file extra > and that too only when -l is specified. (too many options already? ;) > ) Maybe having an option is nice, but have it be turned on by default? That way if someone really wanted to not generate the forwarder they could, and for the general use case they don't have to bother with setting an option every time. > On naming: we've derived automatic names elsewhere. I think we could > revisit all naming options by another round - perhaps even java > convention for header interface name. > > On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt class > and extended it from AsmCodeFactory. visit methods now return Boolean > to tell if the particular tree was handled or not. This is needed so > that subclass can avoid the same tree if super class avoided it (for > eg. function-like macros, repeated definitions..) I'm wondering if this runs into trouble later on when adding more code generation extensions/options. Let's say you add `foo` and `bar` options later on. You'd have to make an extension subclass for every combination of options (StaticFooBar, StaticFoo, StaticBar, FooBar, Static, Foo, Bar). Maybe you could have something like a `CodeFactory`, which consists of an `AsmCodeFactory` and a list of `CodeFactoryExt`, of which the static forwarder generator would be one. And have this kind of pattern: ``` @Override public Void visitVar(VarTree varTree, JType jt) { if(asmCodeFactory.visitVar(varTree, jt)) { for(CodeFactoryExt cfe : extensions) { cfe.visitVar(varTree, jt); } } return null; } ``` I think that also allows you to get rid of the if/else statements in the extension class. It's not really needed right now since there is only 1 extension, but it might be nice idea for the future. Jorn > Updated: > http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html > > Thanks, > -Sundar > > On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >> I like it! Few questions/comments: >> >> * should it be enabled/disabled with explicit option >> * should the name of the statics class be customizable >> * I like the code organization - have you thought of pushing it >> further and make StaticForwarderGenerator a _subclass_ of >> AsmCodeFactory - each visitor could maybe delegate to super.visitXyz() >> first and then do its own bit? Then when you setup the pipeline, >> depending on what info is available on the context (e.g. presence of >> -l) you can decide whether to use a 'bare' ASMCodeFactory or the >> 'embellished' one. That should remove all the 'if staticFwd != null >> ...' sections from AsmCodeFactory. >> >> Maurizio >> >> >> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>> Webrev: >>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>> >>> Thanks, >>> -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 17 16:25:18 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 17 Oct 2018 21:55:18 +0530 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> Message-ID: <5BC7626E.1020406@oracle.com> comments below.. On 17/10/18, 9:13 PM, Jorn Vernee wrote: > Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >> On option: do we need an explicit option? given that one file extra >> and that too only when -l is specified. (too many options already? ;) >> ) > > Maybe having an option is nice, but have it be turned on by default? > That way if someone really wanted to not generate the forwarder they > could, and for the general use case they don't have to bother with > setting an option every time. > okay. >> On naming: we've derived automatic names elsewhere. I think we could >> revisit all naming options by another round - perhaps even java >> convention for header interface name. >> >> On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt class >> and extended it from AsmCodeFactory. visit methods now return Boolean >> to tell if the particular tree was handled or not. This is needed so >> that subclass can avoid the same tree if super class avoided it (for >> eg. function-like macros, repeated definitions..) > > I'm wondering if this runs into trouble later on when adding more code > generation extensions/options. Let's say you add `foo` and `bar` > options later on. You'd have to make an extension subclass for every > combination of options (StaticFooBar, StaticFoo, StaticBar, FooBar, > Static, Foo, Bar). > > Maybe you could have something like a `CodeFactory`, which consists of > an `AsmCodeFactory` and a list of `CodeFactoryExt`, of which the > static forwarder generator would be one. And have this kind of pattern: > > ``` > @Override > public Void visitVar(VarTree varTree, JType jt) { > if(asmCodeFactory.visitVar(varTree, jt)) { > for(CodeFactoryExt cfe : extensions) { > cfe.visitVar(varTree, jt); > } > } > return null; > } > ``` > > I think that also allows you to get rid of the if/else statements in > the extension class. > > It's not really needed right now since there is only 1 extension, but > it might be nice idea for the future. Right. We don't want to go there yet - but yes, if we happened to add one more, we can revisit & refactor the code. -Sundar > > Jorn > >> Updated: http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >> >> Thanks, >> -Sundar >> >> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>> I like it! Few questions/comments: >>> >>> * should it be enabled/disabled with explicit option >>> * should the name of the statics class be customizable >>> * I like the code organization - have you thought of pushing it >>> further and make StaticForwarderGenerator a _subclass_ of >>> AsmCodeFactory - each visitor could maybe delegate to >>> super.visitXyz() first and then do its own bit? Then when you setup >>> the pipeline, depending on what info is available on the context >>> (e.g. presence of -l) you can decide whether to use a 'bare' >>> ASMCodeFactory or the 'embellished' one. That should remove all the >>> 'if staticFwd != null ...' sections from AsmCodeFactory. >>> >>> Maurizio >>> >>> >>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>> Please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>> Webrev: >>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>> >>>> Thanks, >>>> -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 17 17:35:28 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 17 Oct 2018 23:05:28 +0530 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <5BC7626E.1020406@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> Message-ID: <5BC772E0.3030706@oracle.com> Updated: http://cr.openjdk.java.net/~sundar/8212560/webrev.02/index.html Added --static-forwarder boolean option (default true) -Sundar On 17/10/18, 9:55 PM, Sundararajan Athijegannathan wrote: > > comments below.. > > On 17/10/18, 9:13 PM, Jorn Vernee wrote: >> Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >>> On option: do we need an explicit option? given that one file extra >>> and that too only when -l is specified. (too many options already? ;) >>> ) >> >> Maybe having an option is nice, but have it be turned on by default? >> That way if someone really wanted to not generate the forwarder they >> could, and for the general use case they don't have to bother with >> setting an option every time. >> > okay. > >>> On naming: we've derived automatic names elsewhere. I think we could >>> revisit all naming options by another round - perhaps even java >>> convention for header interface name. >>> >>> On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt class >>> and extended it from AsmCodeFactory. visit methods now return Boolean >>> to tell if the particular tree was handled or not. This is needed so >>> that subclass can avoid the same tree if super class avoided it (for >>> eg. function-like macros, repeated definitions..) >> >> I'm wondering if this runs into trouble later on when adding more >> code generation extensions/options. Let's say you add `foo` and `bar` >> options later on. You'd have to make an extension subclass for every >> combination of options (StaticFooBar, StaticFoo, StaticBar, FooBar, >> Static, Foo, Bar). >> >> Maybe you could have something like a `CodeFactory`, which consists >> of an `AsmCodeFactory` and a list of `CodeFactoryExt`, of which the >> static forwarder generator would be one. And have this kind of pattern: >> >> ``` >> @Override >> public Void visitVar(VarTree varTree, JType jt) { >> if(asmCodeFactory.visitVar(varTree, jt)) { >> for(CodeFactoryExt cfe : extensions) { >> cfe.visitVar(varTree, jt); >> } >> } >> return null; >> } >> ``` >> >> I think that also allows you to get rid of the if/else statements in >> the extension class. >> >> It's not really needed right now since there is only 1 extension, but >> it might be nice idea for the future. > > Right. We don't want to go there yet - but yes, if we happened to add > one more, we can revisit & refactor the code. > > -Sundar >> >> Jorn >> >>> Updated: >>> http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >>> >>> Thanks, >>> -Sundar >>> >>> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>>> I like it! Few questions/comments: >>>> >>>> * should it be enabled/disabled with explicit option >>>> * should the name of the statics class be customizable >>>> * I like the code organization - have you thought of pushing it >>>> further and make StaticForwarderGenerator a _subclass_ of >>>> AsmCodeFactory - each visitor could maybe delegate to >>>> super.visitXyz() first and then do its own bit? Then when you setup >>>> the pipeline, depending on what info is available on the context >>>> (e.g. presence of -l) you can decide whether to use a 'bare' >>>> ASMCodeFactory or the 'embellished' one. That should remove all the >>>> 'if staticFwd != null ...' sections from AsmCodeFactory. >>>> >>>> Maurizio >>>> >>>> >>>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>>> Please review. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>>> >>>>> Thanks, >>>>> -Sundar From john.r.rose at oracle.com Wed Oct 17 18:14:27 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 17 Oct 2018 11:14:27 -0700 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> Message-ID: <7A1C6288-DD18-4728-8927-6F5A21829950@oracle.com> On Oct 17, 2018, at 2:55 AM, Maurizio Cimadamore wrote: > > * should it be enabled/disabled with explicit option > * should the name of the statics class be customizable +1, +1; perhaps the method that is called to create the single instance should also be customizable. Then the whole static class is something that could be written by anybody; it's just a big delegation pattern. Less magic is better. ? John From maurizio.cimadamore at oracle.com Wed Oct 17 20:02:48 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Oct 2018 20:02:48 +0000 Subject: hg: panama/dev: 95 new changesets Message-ID: <201810172002.w9HK2uLZ014475@aojmv0008.oracle.com> Changeset: ec4f2762b234 Author: mullan Date: 2018-10-10 16:25 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/ec4f2762b234 8191053: Provide a mechanism to make system's security manager immutable Summary: Make System.setSecurityManager optional to support and add new disallow and allow options to the java.security.manager system property Reviewed-by: alanb, mchung, rriggs, smarks ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/System.java + test/jdk/java/lang/System/AllowSecurityManager.java Changeset: 26c3104c936d Author: akolarkunnu Date: 2018-10-05 05:03 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/26c3104c936d 8210055: Enable different look and feel tests in SwingSet3 demo tests Reviewed-by: serb Contributed-by: abdul.kolarkunnu at oracle.com ! test/jdk/sanity/client/SwingSet/src/DialogDemoTest.java ! test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java ! test/jdk/sanity/client/SwingSet/src/WindowDemoTest.java ! test/jdk/sanity/client/lib/Extensions/src/org/jemmy2ext/JemmyExt.java ! test/jdk/sanity/client/lib/SwingSet2/src/SwingSet2.java Changeset: fc52ccf451cd Author: mchung Date: 2018-10-10 15:19 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/fc52ccf451cd 8211921: AssertionError in MethodHandles$Lookup.defineClass Reviewed-by: alanb ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: a36ee8e96c1e Author: jwilhelm Date: 2018-10-11 00:43 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/a36ee8e96c1e Added tag jdk-12+15 for changeset f8626bcc1698 ! .hgtags Changeset: c7f7d824f2b6 Author: bpb Date: 2018-10-10 17:53 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c7f7d824f2b6 8152910: Get performance improvement with Stable annotation Reviewed-by: darcy Contributed-by: Peter Levart ! src/java.base/share/classes/java/math/BigInteger.java Changeset: 081aed66b645 Author: kbarrett Date: 2018-10-10 23:47 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/081aed66b645 8211962: Implicit narrowing in MacOSX java.desktop jsound Summary: Cast value to needed type. Reviewed-by: serb ! src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp Changeset: b698138cf69b Author: mbaesken Date: 2018-10-10 16:56 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b698138cf69b 8211929: hotspot/share/opto/parse2.cpp compile error with gcc 7.3.1 Reviewed-by: kvn, stuefe ! src/hotspot/share/opto/parse2.cpp Changeset: b25bfa10f52f Author: shade Date: 2018-10-11 10:42 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b25bfa10f52f 8212005: Epsilon elastic TLAB sizing may cause misalignment Reviewed-by: rkennke, tschatzl ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp + test/hotspot/jtreg/gc/epsilon/TestAlignment.java Changeset: 4cffba2df537 Author: roland Date: 2018-09-18 20:41 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/4cffba2df537 8210389: C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/compile.cpp + test/hotspot/jtreg/compiler/regalloc/VolatileLoadMemBarsOnlyUses.java Changeset: bbc90467f354 Author: roland Date: 2018-09-27 17:46 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/bbc90467f354 8211233: MemBarNode::trailing_membar() and MemBarNode::leading_membar() need to handle dying subgraphs better Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/memnode.cpp Changeset: b16ad2f2536a Author: chegar Date: 2018-10-11 13:40 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/b16ad2f2536a 8211922: Remove test/jdk/javax/naming/module/RunBasic.java from the ProblemList Reviewed-by: lancea ! test/jdk/ProblemList.txt Changeset: c459186b9584 Author: prappo Date: 2018-10-11 14:10 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/c459186b9584 8212001: Verify exported symbols in java.base (libjava) Reviewed-by: chegar ! src/java.base/share/native/libjava/io_util.c ! src/java.base/share/native/libjava/io_util.h ! src/java.base/windows/native/libjava/io_util_md.c ! src/java.base/windows/native/libjava/io_util_md.h ! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c Changeset: 7a1e2d7ac55a Author: hseigel Date: 2018-10-11 10:11 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/7a1e2d7ac55a 8079784: Unexpected IllegalAccessError when trying access InnerClasses attribute Summary: Prevent classes in the InnerClasses attribute from being loaded unless they are actually being accessed. Reviewed-by: dholmes, lfoltan ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/runtime/reflection.cpp + test/hotspot/jtreg/runtime/InnerClassesAttr/Base.java + test/hotspot/jtreg/runtime/InnerClassesAttr/Child.java + test/hotspot/jtreg/runtime/InnerClassesAttr/InnerClassesTest.jasm Changeset: 8419d77e3635 Author: hseigel Date: 2018-10-11 11:31 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/8419d77e3635 8211821: PrintStringTableStatistics crashes JVM Summary: During JVM exit, print the Symbol and String tables before current thread gets deleted. Reviewed-by: iklam, dholmes ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/thread.cpp + test/hotspot/jtreg/runtime/PrintStringTableStats/PrintStringTableStatsTest.java Changeset: c9e901ad4c8f Author: jcbeyler Date: 2018-10-11 09:30 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c9e901ad4c8f 8211432: [REDO] Handle JNIGlobalRefLocker.cpp Summary: Adding a JNI verification wrapper for tests Reviewed-by: amenkov, sspitsyn, phh ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIGlobalRefLocker.cpp + test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp + test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp Changeset: 896a556de423 Author: jcbeyler Date: 2018-10-11 12:41 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/896a556de423 8212025: Remove collector_present variable from ThreadHeapSampler Summary: Remove unused variable from ThreadHeapSampler Reviewed-by: tschatzl, pliden ! src/hotspot/share/runtime/threadHeapSampler.hpp Changeset: 62523934374c Author: rkennke Date: 2018-10-11 23:48 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/62523934374c 8212054: Boilerplate to bind oopDesc::equals_raw() to actual raw implementation Reviewed-by: shade, eosterlund ! src/hotspot/share/oops/accessBackend.hpp Changeset: 5fcf63f0d86c Author: kevinw Date: 2018-10-11 15:49 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/5fcf63f0d86c 8211714: Need to update vm_version.cpp to recognise VS2017 minor versions Reviewed-by: dholmes Contributed-by: muthusamy.chinnathambi at oracle.com ! src/hotspot/share/runtime/vm_version.cpp Changeset: 19f6b12df31a Author: mli Date: 2018-10-12 10:35 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/19f6b12df31a 8186610: move ModuleUtils to top-level testlibrary Reviewed-by: alanb, iignatyev ! test/jdk/java/lang/ModuleLayer/BasicLayerTest.java ! test/jdk/java/lang/ModuleLayer/LayerAndLoadersTest.java ! test/jdk/java/lang/ModuleLayer/LayerControllerTest.java ! test/jdk/java/lang/module/AutomaticModulesTest.java ! test/jdk/java/lang/module/ConfigurationTest.java - test/jdk/lib/testlibrary/ModuleTargetHelper.java - test/jdk/lib/testlibrary/ModuleUtils.java + test/jdk/tools/jlink/plugins/SystemModuleDescriptors/ModuleTargetHelper.java ! test/jdk/tools/jlink/plugins/SystemModuleDescriptors/SystemModulesTest.java ! test/jdk/tools/jlink/plugins/SystemModuleDescriptors/UserModuleTest.java + test/lib/jdk/test/lib/util/ModuleUtils.java Changeset: 4acfd9b6c2f9 Author: goetz Date: 2018-10-12 08:33 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/4acfd9b6c2f9 8211931: [ppc][testbug] runtime/jni/terminatedThread/TestTerminatedThread.java fails as threads don't terminate immediately Reviewed-by: dholmes, mdoerr ! test/hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java Changeset: 331fbd2db6b5 Author: vtewari Date: 2018-10-12 12:37 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/331fbd2db6b5 8189366: SocketInputStream.available() should check for eof Reviewed-by: chegar ! src/java.base/share/classes/java/net/SocketInputStream.java ! test/jdk/java/net/Socket/CloseAvailable.java Changeset: 537dbfcef4a7 Author: dholmes Date: 2018-10-12 03:51 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/537dbfcef4a7 8211046: Forced data dependencies serve no purpose on x86 Reviewed-by: eosterlund, rehn ! src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp Changeset: 76d526565453 Author: michaelm Date: 2018-10-12 11:12 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/76d526565453 8203850: java.net.http HTTP client should allow specifying Origin and Referer headers Reviewed-by: chegar, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/RequestBuilderTest.java ! test/jdk/java/net/httpclient/SpecialHeadersTest.java Changeset: 0c1e44da019c Author: rkennke Date: 2018-10-12 16:25 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/0c1e44da019c 8212053: A few more missing object equals barriers Reviewed-by: shade, zgu ! src/hotspot/share/oops/compressedOops.inline.hpp ! src/hotspot/share/runtime/vframe.cpp Changeset: 9c84227836d4 Author: sgehwolf Date: 2018-10-12 10:58 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/9c84227836d4 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 Summary: Only add RTC1 compile flag for slowdebug builds. Reviewed-by: mdoerr, erikj ! make/lib/Lib-jdk.hotspot.agent.gmk Changeset: 101c2b6eacbe Author: mchinnathamb Date: 2018-10-09 16:08 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/101c2b6eacbe 8027434: "-XX:OnOutOfMemoryError" uses fork instead of vfork Reviewed-by: dholmes, iklam ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/solaris/os_solaris.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/vmError.cpp Changeset: 65efb9c57fef Author: amenkov Date: 2018-10-12 10:08 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/65efb9c57fef 8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' Reviewed-by: sspitsyn, jcbeyler ! test/jdk/ProblemList.txt ! test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java ! test/jdk/com/sun/jdi/DoubleAgentTest.java ! test/lib/jdk/test/lib/apps/LingeredApp.java Changeset: 367b2cd49ec5 Author: lancea Date: 2018-10-12 14:16 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/367b2cd49ec5 8212045: Add back tests removed from HashesTest.java and AddExportsTest.java Reviewed-by: rriggs ! test/jdk/tools/jmod/hashes/HashesTest.java ! test/jdk/tools/launcher/modules/addexports/AddExportsTest.java + test/jdk/tools/launcher/modules/addexports/src/java.compiler/javax/annotation/processing/Generated.java + test/jdk/tools/launcher/modules/addexports/src/java.compiler/javax/tools/ToolsHelper.java + test/jdk/tools/launcher/modules/addexports/src/java.compiler/javax/tools/internal/Helper.java + test/jdk/tools/launcher/modules/addexports/src/java.compiler/module-info.java + test/jdk/tools/launcher/modules/addexports/src/m2/jdk/test2/Main.java + test/jdk/tools/launcher/modules/addexports/src/m2/module-info.java Changeset: 76c87b213fa0 Author: kbarrett Date: 2018-10-12 17:35 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/76c87b213fa0 8212023: Implicit narrowing in Solaris/sparc initializers Summary: Explicitly narrow or fix destination types. Reviewed-by: dholmes, tschatzl ! src/hotspot/cpu/sparc/nativeInst_sparc.cpp ! src/hotspot/os/solaris/os_solaris.cpp Changeset: f48838bdcc31 Author: xyin Date: 2018-10-15 09:34 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/f48838bdcc31 8187522: test/sun/net/ftp/FtpURLConnectionLeak.java timed out Reviewed-by: chegar, vtewari ! test/jdk/sun/net/ftp/FtpURLConnectionLeak.java ! test/jdk/sun/net/www/ftptest/FtpCommandHandler.java ! test/jdk/sun/net/www/ftptest/FtpServer.java Changeset: 3b8994cb4481 Author: jcbeyler Date: 2018-10-14 19:07 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/3b8994cb4481 8212082: Remove the NSK_CPP_STUB macros for remaining vmTestbase/jvmti/[sS]* Summary: Remove NSK_CPP_STUB macros from the tests Reviewed-by: amenkov, phh ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor001/setenvstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor002/setenvstor002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor003/setenvstor003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb001/setevntcallb001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb002/setevntcallb002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb003/setevntcallb003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetExtensionEventCallback/setextevent001/setextevent001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix001/SetNativeMethodPrefix001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/SetNativeMethodPrefix002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop002/setsysprop002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop003/setsysprop003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetTag/settag001/settag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor001/setthrdstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor002/setthrdstor002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor003/setthrdstor003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/ma08t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/ma08t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/ma10t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/ma10t002a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/ma10t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/ma10t003a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/ma10t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/ma10t004a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/ma10t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/ma10t005a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/ma10t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/ma10t007a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/ma10t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/ma10t008a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t001/sp01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/sp01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/sp01t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t001/sp02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t002/sp02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t003/sp02t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/sp03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/sp03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/sp04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/sp04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t002/sp05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t001/sp06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t002/sp06t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/sp06t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t001/sp07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/sp07t002.cpp Changeset: 9e6158f12068 Author: mdoerr Date: 2018-10-15 08:08 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/9e6158f12068 8211852: inspect stack during error reporting Reviewed-by: dholmes, goetz ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/utilities/vmError.cpp Changeset: f0340f0ea249 Author: pmuthuswamy Date: 2018-10-15 17:52 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/f0340f0ea249 8211957: Broken links to stylesheet in java.base/doc-files Reviewed-by: alanb ! src/java.base/share/classes/java/lang/doc-files/ValueBased.html ! src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html Changeset: a2edf32cd813 Author: lkorinth Date: 2018-10-12 12:10 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/a2edf32cd813 8201436: Replace oop_ps_push_contents with oop_iterate and closure Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psCardTable.cpp + src/hotspot/share/gc/parallel/psClosure.inline.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/parallel/psScavenge.inline.hpp ! src/hotspot/share/gc/parallel/psTasks.cpp ! src/hotspot/share/oops/instanceClassLoaderKlass.hpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/instanceRefKlass.hpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayKlass.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/typeArrayKlass.hpp Changeset: 49f627781c2a Author: lkorinth Date: 2018-10-12 12:13 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/49f627781c2a 8211446: Replace oop_pc_follow_contents with oop_iterate and closure Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/parallel/pcTasks.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/oops/instanceClassLoaderKlass.hpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/instanceRefKlass.hpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayKlass.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/typeArrayKlass.hpp Changeset: 88916200bdd7 Author: lkorinth Date: 2018-10-12 12:14 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/88916200bdd7 8211447: Replace oop_pc_update_pointers with oop_iterate and closure Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp ! src/hotspot/share/oops/instanceClassLoaderKlass.hpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/instanceRefKlass.hpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayKlass.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/typeArrayKlass.hpp Changeset: 84fe81feae26 Author: coffeys Date: 2018-10-15 14:42 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/84fe81feae26 8209862: CipherCore performance improvement Reviewed-by: apetcher, ascarpino Contributed-by: sergey.kuksenko at oracle.com, sean.coffey at oracle.com ! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java Changeset: 934969c63223 Author: jjiang Date: 2018-10-15 22:47 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/934969c63223 8211978: Move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary Summary: Move SimpleSSLContext.java and testkeys to test/lib/jdk/test/lib/net Reviewed-by: chegar ! test/jdk/com/sun/net/httpserver/SelCacheTest.java ! test/jdk/com/sun/net/httpserver/Test1.java ! test/jdk/com/sun/net/httpserver/Test12.java ! test/jdk/com/sun/net/httpserver/Test13.java ! test/jdk/com/sun/net/httpserver/Test6a.java ! test/jdk/com/sun/net/httpserver/Test7a.java ! test/jdk/com/sun/net/httpserver/Test8a.java ! test/jdk/com/sun/net/httpserver/Test9.java ! test/jdk/com/sun/net/httpserver/Test9a.java ! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java ! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTest.java ! test/jdk/java/net/URLPermission/URLTest.java ! test/jdk/java/net/httpclient/AbstractNoBody.java ! test/jdk/java/net/httpclient/AbstractThrowingPublishers.java ! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java ! test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java ! test/jdk/java/net/httpclient/AsFileDownloadTest.java ! test/jdk/java/net/httpclient/AsFileDownloadTest.policy ! test/jdk/java/net/httpclient/BasicRedirectTest.java ! test/jdk/java/net/httpclient/CancelledResponse.java ! test/jdk/java/net/httpclient/ConcurrentResponses.java ! test/jdk/java/net/httpclient/CookieHeaderTest.java ! test/jdk/java/net/httpclient/CustomRequestPublisher.java ! test/jdk/java/net/httpclient/CustomResponseSubscriber.java ! test/jdk/java/net/httpclient/DependentActionsTest.java ! test/jdk/java/net/httpclient/DependentPromiseActionsTest.java ! test/jdk/java/net/httpclient/DigestEchoClient.java ! test/jdk/java/net/httpclient/DigestEchoClientSSL.java ! test/jdk/java/net/httpclient/EchoHandler.java ! test/jdk/java/net/httpclient/EncodedCharsInURI.java ! test/jdk/java/net/httpclient/EscapedOctetsInURI.java ! test/jdk/java/net/httpclient/ExpectContinue.java ! test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java ! test/jdk/java/net/httpclient/FlowAdapterSubscriberTest.java ! test/jdk/java/net/httpclient/HeadTest.java ! test/jdk/java/net/httpclient/HttpClientBuilderTest.java ! test/jdk/java/net/httpclient/HttpEchoHandler.java ! test/jdk/java/net/httpclient/HttpsTunnelTest.java ! test/jdk/java/net/httpclient/ImmutableFlowItems.java ! test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java ! test/jdk/java/net/httpclient/InvalidSSLContextTest.java ! test/jdk/java/net/httpclient/InvalidSubscriptionRequest.java ! test/jdk/java/net/httpclient/LightWeightHttpServer.java ! test/jdk/java/net/httpclient/LineBodyHandlerTest.java ! test/jdk/java/net/httpclient/ManyRequests.java ! test/jdk/java/net/httpclient/ManyRequests2.java ! test/jdk/java/net/httpclient/ManyRequestsLegacy.java ! test/jdk/java/net/httpclient/MappingResponseSubscriber.java ! test/jdk/java/net/httpclient/MaxStreams.java ! test/jdk/java/net/httpclient/NoBodyPartOne.java ! test/jdk/java/net/httpclient/NoBodyPartTwo.java ! test/jdk/java/net/httpclient/NonAsciiCharsInURI.java ! test/jdk/java/net/httpclient/ProxyAuthDisabledSchemes.java ! test/jdk/java/net/httpclient/ProxyAuthDisabledSchemesSSL.java ! test/jdk/java/net/httpclient/ProxyTest.java ! test/jdk/java/net/httpclient/RedirectMethodChange.java ! test/jdk/java/net/httpclient/RedirectWithCookie.java ! test/jdk/java/net/httpclient/RequestBodyTest.java ! test/jdk/java/net/httpclient/RequestBodyTest.policy ! test/jdk/java/net/httpclient/ResponseBodyBeforeError.java ! test/jdk/java/net/httpclient/ResponsePublisher.java ! test/jdk/java/net/httpclient/RetryWithCookie.java ! test/jdk/java/net/httpclient/ServerCloseTest.java ! test/jdk/java/net/httpclient/ShortResponseBody.java ! test/jdk/java/net/httpclient/ShortResponseBodyWithRetry.java ! test/jdk/java/net/httpclient/SmokeTest.java ! test/jdk/java/net/httpclient/SpecialHeadersTest.java ! test/jdk/java/net/httpclient/SplitResponse.java ! test/jdk/java/net/httpclient/SplitResponseAsync.java ! test/jdk/java/net/httpclient/SplitResponseKeepAlive.java ! test/jdk/java/net/httpclient/SplitResponseKeepAliveAsync.java ! test/jdk/java/net/httpclient/SplitResponseSSL.java ! test/jdk/java/net/httpclient/SplitResponseSSLAsync.java ! test/jdk/java/net/httpclient/SplitResponseSSLKeepAlive.java ! test/jdk/java/net/httpclient/SplitResponseSSLKeepAliveAsync.java ! test/jdk/java/net/httpclient/StreamingBody.java ! test/jdk/java/net/httpclient/ThrowingPublishersCustomAfterCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersCustomBeforeCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersIOAfterCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersIOBeforeCancel.java ! test/jdk/java/net/httpclient/ThrowingPublishersInNextRequest.java ! test/jdk/java/net/httpclient/ThrowingPublishersInRequest.java ! test/jdk/java/net/httpclient/ThrowingPublishersInSubscribe.java ! test/jdk/java/net/httpclient/ThrowingPublishersSanity.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsInputStreamCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsInputStreamIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsLinesCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsLinesIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsStringCustom.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesAsStringIO.java ! test/jdk/java/net/httpclient/ThrowingPushPromisesSanity.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsInputStream.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsInputStreamAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsLines.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsLinesAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsString.java ! test/jdk/java/net/httpclient/ThrowingSubscribersAsStringAsync.java ! test/jdk/java/net/httpclient/ThrowingSubscribersSanity.java ! test/jdk/java/net/httpclient/TimeoutBasic.java ! test/jdk/java/net/httpclient/UnauthorizedTest.java ! test/jdk/java/net/httpclient/UnknownBodyLengthTest.java ! test/jdk/java/net/httpclient/dependent.policy ! test/jdk/java/net/httpclient/http2/BadHeadersTest.java ! test/jdk/java/net/httpclient/http2/BasicTest.java ! test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java ! test/jdk/java/net/httpclient/http2/ErrorTest.java ! test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java ! test/jdk/java/net/httpclient/http2/ImplicitPushCancel.java ! test/jdk/java/net/httpclient/http2/ProxyTest2.java ! test/jdk/java/net/httpclient/http2/RedirectTest.java ! test/jdk/java/net/httpclient/http2/ServerPush.java ! test/jdk/java/net/httpclient/http2/ServerPushWithDiffTypes.java ! test/jdk/java/net/httpclient/security/Driver.java ! test/jdk/java/net/httpclient/security/Security.java ! test/jdk/java/net/httpclient/websocket/WSHandshakeExceptionTest.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/AbstractSSLTubeTest.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java + test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java ! test/jdk/javax/net/ssl/HttpsURLConnection/Equals.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys ! test/jdk/sun/net/www/protocol/http/RedirectOnPost.java + test/lib/jdk/test/lib/net/SimpleSSLContext.java + test/lib/jdk/test/lib/net/testkeys Changeset: cb20bf10cfbd Author: zgu Date: 2018-10-15 11:53 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/cb20bf10cfbd 8212074: Add method to peek the remaining tasks in task queues Summary: Add methods for implementing new task termination protocol Reviewed-by: tschatzl, shade, rkennke ! src/hotspot/share/gc/shared/taskqueue.hpp Changeset: e5adee94d20d Author: naoto Date: 2018-10-15 09:35 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/e5adee94d20d 8211961: Broken link in java.util.Locale Reviewed-by: mchung ! src/java.base/share/classes/java/util/Locale.java Changeset: c64384f414bc Author: rkennke Date: 2018-10-10 23:05 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c64384f414bc 8211955: GC abstraction for LAB reserve Reviewed-by: pliden, shade ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/plab.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp Changeset: 28375a1de254 Author: erikj Date: 2018-10-15 11:36 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/28375a1de254 8212028: Use run-test makefile framework for testing in Oracle's Mach5 Reviewed-by: ihse ! make/Help.gmk ! make/RunTests.gmk ! make/RunTestsPrebuilt.gmk ! make/RunTestsPrebuiltSpec.gmk ! make/common/MakeBase.gmk ! make/conf/jib-profiles.js ! test/hotspot/jtreg/compiler/escapeAnalysis/TestArrayCopy.java ! test/hotspot/jtreg/compiler/graalunit/JttLangMathALTest.java ! test/hotspot/jtreg/compiler/graalunit/JttLangMathMZTest.java ! test/hotspot/jtreg/compiler/jsr292/ContinuousCallSiteTargetChange.java ! test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationApp.java ! test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/correctBootstrap/TestDescription.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/incorrectBootstrap/TestDescription.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/mh/TestDescription.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/mt/TestDescription.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/gc/createLotsOfMHConsts/Test.java ! test/jdk/tools/jimage/JImageExtractTest.java Changeset: 27df68106e57 Author: jiangli Date: 2018-10-15 15:21 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/27df68106e57 8211956: AppCDS crashes for some uses with JRuby Summary: Make sure FileMapInfo::verify_mapped_heap_regions only verifies 'num' of spaces. Reviewed-by: iklam ! src/hotspot/share/memory/filemap.cpp Changeset: c83ba72377fc Author: shade Date: 2018-10-15 22:30 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c83ba72377fc 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator Reviewed-by: rkennke, kbarrett, joehw ! src/java.xml/share/classes/com/sun/xml/internal/stream/util/ThreadLocalBufferAllocator.java Changeset: 1e0cdaf980f3 Author: akolarkunnu Date: 2018-10-11 07:22 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1e0cdaf980f3 8211139: Increase timeout value in all tests under jdk/sanity/client/SwingSet/src Reviewed-by: serb Contributed-by: abdul.kolarkunnu at oracle.com ! test/jdk/sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java ! test/jdk/sanity/client/SwingSet/src/ButtonDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ComboBoxDemoTest.java ! test/jdk/sanity/client/SwingSet/src/DialogDemoTest.java ! test/jdk/sanity/client/SwingSet/src/FrameDemoTest.java ! test/jdk/sanity/client/SwingSet/src/GridBagLayoutDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ListDemoTest.java ! test/jdk/sanity/client/SwingSet/src/OptionPaneDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ProgressBarDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ScrollPaneDemoTest.java ! test/jdk/sanity/client/SwingSet/src/SpinnerDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TabbedPaneDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TableDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TextFieldDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ToggleButtonDemoTest.java ! test/jdk/sanity/client/SwingSet/src/ToolTipDemoTest.java ! test/jdk/sanity/client/SwingSet/src/TreeDemoTest.java ! test/jdk/sanity/client/SwingSet/src/WindowDemoTest.java ! test/jdk/sanity/client/lib/Extensions/src/org/jemmy2ext/JemmyExt.java Changeset: b1526df0add2 Author: shurailine Date: 2018-10-15 13:44 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/b1526df0add2 Merge Changeset: e851c8ca30a7 Author: akolarkunnu Date: 2018-10-03 23:00 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/e851c8ca30a7 8209499: Create test for SwingSet EditorPaneDemo Reviewed-by: serb Contributed-by: abdul.kolarkunnu at oracle.com + test/jdk/sanity/client/SwingSet/src/EditorPaneDemoTest.java + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/EditorPaneDemo.java + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/CREDITS + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/ant.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/book.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/bug.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/bug2.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/crest.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/king.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/micro.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/Octavo/seaweed.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/ant.html + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/bug.html + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/editorpane/back.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/editorpane/forward.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/editorpane/header.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/index.html + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/king.html + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/preface.html + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/seaweed.html + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/book/title.html + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/resources/EditorPaneDemo.properties + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/editorpane/resources/images/EditorPaneDemo.gif Changeset: e9727e6b5fc1 Author: jcbeyler Date: 2018-10-15 14:16 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/e9727e6b5fc1 8211980: Remove ThreadHeapSampler enable/disable/enabled methods Summary: Remove methods from ThreadHeapSampler Reviewed-by: dholmes, phh ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/threadHeapSampler.cpp ! src/hotspot/share/runtime/threadHeapSampler.hpp Changeset: 04d4f1e4aff2 Author: jcbeyler Date: 2018-10-15 14:55 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/04d4f1e4aff2 8212083: Handle remaining gc/lock native code and fix two strings Summary: Migrate code to using wrapping JNI for exceptions Reviewed-by: phh, tschatzl ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/BooleanArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ByteArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/CharArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/DoubleArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/FloatArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/IntArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/LongArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ShortArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/StringCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libBooleanArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libByteArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libCharArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libDoubleArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libFloatArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libIntArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libLongArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libShortArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/libStringCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNILocalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIWeakGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNILocalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/libJNIWeakGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp Changeset: 1f4d86a504f2 Author: dholmes Date: 2018-10-15 21:02 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/1f4d86a504f2 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo Summary: ensure the target thread has reached wait() before inspecting it Reviewed-by: mchung, dfuchs, jcbeyler ! test/jdk/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Changeset: a35cc060f251 Author: weijun Date: 2018-10-16 09:19 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/a35cc060f251 8212165: JGSS: Fix cut/paste error in NativeUtil.c Reviewed-by: alanb, weijun Contributed-by: Viktor Dukhovni ! src/java.security.jgss/share/native/libj2gss/NativeUtil.c Changeset: 6a297371a9b4 Author: jjiang Date: 2018-10-16 10:16 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/6a297371a9b4 8211971: Move security/cacerts/VerifyCACerts.java and security/CheckBlacklistedCerts.java Summary: Move lib/security tests to sun/security/lib Reviewed-by: weijun - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java + test/jdk/sun/security/lib/CheckBlacklistedCerts.java + test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: b52336cdb42d Author: tschatzl Date: 2018-10-16 11:27 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b52336cdb42d 8210492: PLAB object promotion events report object sizes in words Summary: Properly scale values passed to the JFR event. Reviewed-by: phh, jcbeyler ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp Changeset: fea91995e077 Author: rwestberg Date: 2018-10-16 11:32 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/fea91995e077 8212004: Optional compile_commands.json field not compatible with older libclang Reviewed-by: erikj ! make/common/NativeCompilation.gmk Changeset: 059384474dde Author: dfuchs Date: 2018-10-16 12:38 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/059384474dde 8211960: broken links in java.util.logging Reviewed-by: mchung, chegar ! src/java.logging/share/classes/java/util/logging/SimpleFormatter.java Changeset: 5a2af44ecb83 Author: pliden Date: 2018-10-16 13:43 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/5a2af44ecb83 8212181: ZGC: Fix incorrect root iteration in ZHeapIterator Reviewed-by: eosterlund ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zHeapIterator.hpp Changeset: 3a168f782e80 Author: eosterlund Date: 2018-10-16 13:14 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/3a168f782e80 8210064: ZGC: Introduce ZConcurrentRootsIterator for scanning a subset of strong IN_NATIVE roots concurrently Reviewed-by: pliden, kbarrett ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zMark.cpp ! src/hotspot/share/gc/z/zMark.hpp ! src/hotspot/share/gc/z/zRootsIterator.cpp ! src/hotspot/share/gc/z/zRootsIterator.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: de6dc206a92b Author: eosterlund Date: 2018-10-16 13:16 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/de6dc206a92b 8210330: Make CLD claiming allow multiple claim bits Reviewed-by: pliden, coleenp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/gc/cms/cmsOopClosures.inline.hpp ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp ! src/hotspot/share/gc/g1/g1FullGCMarker.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1OopClosures.cpp ! src/hotspot/share/gc/g1/g1OopClosures.hpp ! src/hotspot/share/gc/g1/g1RootClosures.cpp ! src/hotspot/share/gc/g1/g1SharedClosures.hpp ! src/hotspot/share/gc/parallel/pcTasks.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/markSweep.cpp ! src/hotspot/share/gc/z/zRootsIterator.cpp ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/saveRestore.cpp ! src/hotspot/share/memory/iterator.cpp ! src/hotspot/share/memory/iterator.hpp ! src/hotspot/share/memory/iterator.inline.hpp Changeset: ca0c25e01c5b Author: eosterlund Date: 2018-10-16 13:18 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/ca0c25e01c5b 8210498: nmethod entry barriers Reviewed-by: kvn, pliden + src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp + src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp + src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp + src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp + src/hotspot/cpu/sparc/gc/shared/barrierSetNMethod_sparc.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp + src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/stubRoutines_x86_64.cpp ! src/hotspot/cpu/x86/x86_64.ad + src/hotspot/cpu/zero/gc/shared/barrierSetNMethod_zero.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/gc/epsilon/epsilonBarrierSet.cpp ! src/hotspot/share/gc/shared/barrierSet.hpp + src/hotspot/share/gc/shared/barrierSetNMethod.cpp + src/hotspot/share/gc/shared/barrierSetNMethod.hpp ! src/hotspot/share/gc/shared/modRefBarrierSet.hpp ! src/hotspot/share/gc/z/zBarrierSet.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp Changeset: ad6384355aa3 Author: thartmann Date: 2018-10-16 14:17 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/ad6384355aa3 8210215: C2 should optimize trichotomy calculations Summary: Ideal transformation to optimize trichotomic comparisons. Reviewed-by: kvn, jrose ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subnode.hpp + test/hotspot/jtreg/compiler/codegen/TestTrichotomyExpressions.java Changeset: f53671e05660 Author: hannesw Date: 2018-10-16 15:05 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/f53671e05660 8210683: Search result display order reversed for overloaded entries Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java Changeset: 89f3b013ab8f Author: bobv Date: 2018-10-16 09:54 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/89f3b013ab8f 8211740: [AOT] -XX:AOTLibrary doesn't accept windows path Reviewed-by: kvn, iignatyev ! src/hotspot/share/aot/aotLoader.cpp ! test/hotspot/jtreg/compiler/aot/cli/MultipleAOTLibraryTest.java Changeset: 032c1c1379ab Author: bobv Date: 2018-10-16 09:55 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/032c1c1379ab Merge - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys Changeset: 435467bce14e Author: bpb Date: 2018-10-16 07:49 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/435467bce14e 8212212: (bf) Incorrect path to stream preprocessor source in java.nio Buffer test scripts Reviewed-by: alanb ! test/jdk/java/nio/Buffer/genBasic.sh ! test/jdk/java/nio/Buffer/genCopyDirectMemory.sh ! test/jdk/java/nio/Buffer/genOrder.sh Changeset: 2d9f8845d0ae Author: hseigel Date: 2018-10-16 11:08 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/2d9f8845d0ae 7041262: VM_Version should be called instead of Abstract_VM_Version so that overriding works Summary: Change calls to Abstract_VM_Version methods to be calls to VM_Version methods. Reviewed-by: coleenp, kbarrett, dholmes ! src/hotspot/cpu/arm/vm_version_arm_32.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/gc/cms/cmsArguments.cpp ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/z/zInitialize.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/vm_version.hpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/services/runtimeService.cpp ! src/hotspot/share/utilities/vmError.cpp Changeset: 0edbbc64393c Author: rriggs Date: 2018-10-16 10:55 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/0edbbc64393c 8192939: Remove Finalize methods from FileInputStream and FileOutputStream Reviewed-by: alanb, iris, mchung ! src/java.base/share/classes/java/io/FileInputStream.java ! src/java.base/share/classes/java/io/FileOutputStream.java ! test/jdk/java/io/FileInputStream/UnreferencedFISClosesFd.java ! test/jdk/java/io/FileOutputStream/UnreferencedFOSClosesFd.java Changeset: f586d225bd0b Author: shade Date: 2018-10-16 17:43 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/f586d225bd0b 8212177: Epsilon alignment adjustments can overflow max TLAB size Reviewed-by: pliden, tschatzl ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp + test/hotspot/jtreg/gc/epsilon/TestMaxTLAB.java Changeset: af6fb2cb82ae Author: jnimeh Date: 2018-10-16 11:24 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/af6fb2cb82ae 8211866: TLS 1.3 CertificateRequest message sometimes offers disallowed signature algorithms Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/CertSignAlgsExtension.java ! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java Changeset: bfdf2926cebc Author: mchung Date: 2018-10-16 11:47 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/bfdf2926cebc 8212197: OpenDataException thrown when constructing CompositeData for StackTraceElement Reviewed-by: alanb ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! test/jdk/sun/management/StackTraceElementCompositeData/CompatibilityTest.java Changeset: 3b17277860e7 Author: jnimeh Date: 2018-10-16 12:05 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/3b17277860e7 8210989: RSASSA-PSS certificate cannot be selected for client auth on TLSv1.2 Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/CertificateRequest.java ! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java ! src/java.base/share/classes/sun/security/ssl/X509Authentication.java Changeset: a4d4c609d70c Author: dholmes Date: 2018-10-16 19:07 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/a4d4c609d70c 8211909: JDWP Transport Listener: dt_socket thread crash Reviewed-by: dcubed, dsamersoff ! src/hotspot/share/prims/jvmtiEnv.cpp Changeset: c31b6e1c4383 Author: weijun Date: 2018-03-08 14:04 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/c31b6e1c4383 8196897: Improve PRNG support Reviewed-by: valeriep, mullan, igerasim ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp Changeset: 1801fada294a Author: sherman Date: 2018-03-28 08:42 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1801fada294a 8197881: Better StringBuilder support Reviewed-by: rriggs ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java Changeset: 7593b9b8e8f2 Author: vtewari Date: 2018-03-30 08:37 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/7593b9b8e8f2 8199110: Address Internet Addresses Reviewed-by: chegar, rriggs, igerasim, skoivu, rhalade ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/NetworkInterface.java ! src/java.base/unix/native/libnet/NetworkInterface.c Changeset: f351c1a6c37a Author: sherman Date: 2018-04-04 13:55 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f351c1a6c37a 8199172: Improve jar attribute checks Reviewed-by: psandoz, alanb ! src/java.base/share/classes/java/util/jar/JarFile.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java ! test/jdk/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java Changeset: 42244a052fbb Author: weijun Date: 2018-04-17 15:55 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/42244a052fbb 8194534: Manifest better support Reviewed-by: mchung, igerasim ! src/java.base/share/classes/java/net/URLClassLoader.java ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/jar/JarVerifier.java ! src/java.base/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/java.base/share/classes/java/util/jar/Manifest.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilJarAccess.java ! test/lib/jdk/test/lib/util/JarUtils.java Changeset: 2de3d2f1df39 Author: apetcher Date: 2018-04-23 12:01 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/2de3d2f1df39 8201756: Improve cipher inputs Summary: Clarify spec of CipherInputStream in Javadoc comments Reviewed-by: ascarpino ! src/java.base/share/classes/javax/crypto/CipherInputStream.java Changeset: f1b6c4079be0 Author: prr Date: 2018-04-23 16:15 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f1b6c4079be0 8200648: Make midi code more sound Reviewed-by: serb, mschoene, rhalade ! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiIn.cpp ! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiOut.c ! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_Ports.c Changeset: 279174cb3a24 Author: hseigel Date: 2018-05-14 09:05 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/279174cb3a24 8199226: Improve field accesses Reviewed-by: acorn, ahgross, rhalade Contributed-by: harold.seigel at oracle.com ! src/hotspot/share/interpreter/linkResolver.cpp Changeset: 9d5b5f07af5a Author: sundar Date: 2018-05-18 13:34 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/9d5b5f07af5a 8202936: Improve script engine support Reviewed-by: jlaskey, ahgross, rhalade ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java Changeset: 27135de165ac Author: bchristi Date: 2018-05-29 10:27 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/27135de165ac 8195874: Improve jar specification adherence Summary: Also reviewed by Chris Ries Reviewed-by: alanb, mchung, rriggs ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java Changeset: 6c014b7762a2 Author: vtewari Date: 2018-06-08 15:56 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/6c014b7762a2 8199177: Enhance JNDI lookups Reviewed-by: michaelm, robm, skoivu, rhalade, chegar, rriggs, ahgross Contributed-by: vyom.tewari at oracle.com ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java Changeset: 391beb57ed65 Author: joehw Date: 2018-06-15 14:19 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/391beb57ed65 8204497: Better formatting of decimals Reviewed-by: rriggs, lancea, dfuchs, mschoene ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java Changeset: b1db57cfe6bd Author: igerasim Date: 2018-06-20 18:02 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/b1db57cfe6bd 8204667: Resources not freed on exception Reviewed-by: skoivu, chegar ! src/java.base/unix/native/libnet/NetworkInterface.c ! src/java.base/windows/native/libnet/NetworkInterface.c ! src/java.base/windows/native/libnet/NetworkInterface_winXP.c Changeset: 0c50240bf61d Author: kaddepalli Date: 2018-06-29 10:28 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/0c50240bf61d 8194546: Choosier FileManagers Reviewed-by: serb, prr, rhalade, skoivu ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java Changeset: ca48ad1b6e21 Author: michaelm Date: 2018-07-10 08:20 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/ca48ad1b6e21 8196902: Better HTTP Redirection Reviewed-by: dfuchs Contributed-by: chris.hegarty at oracle.com ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 2990f1e1c325 Author: apetcher Date: 2018-07-30 13:53 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/2990f1e1c325 8208209: Improve TLS connection stability again Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/ClientHello.java ! src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java Changeset: 0da586f1ed05 Author: weijun Date: 2018-08-08 08:05 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/0da586f1ed05 8208754: The fix for JDK-8194534 needs updates Reviewed-by: alanb, igerasim, rhalade, mullan ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/java.base/share/classes/java/util/jar/Manifest.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilJarAccess.java Changeset: f54dcfc5a5f8 Author: bchristi Date: 2018-10-05 15:12 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f54dcfc5a5f8 8211731: Reconsider default option for ClassPathURLCheck change done in JDK-8195874 Reviewed-by: alanb, mchung ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java Changeset: e4b9475b0508 Author: mli Date: 2018-10-17 16:37 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/e4b9475b0508 8210403: Refactor java.util.Locale:i18n shell tests to plain java tests Reviewed-by: naoto Contributed-by: ying.z.zhou at oracle.com ! test/jdk/java/util/Locale/LocaleCategory.java - test/jdk/java/util/Locale/LocaleCategory.sh - test/jdk/java/util/Locale/LocaleProviders.sh + test/jdk/java/util/Locale/LocaleProvidersRun.java + test/jdk/java/util/Locale/providersrc/spi/dest/META-INF/services/java.util.spi.TimeZoneNameProvider + test/jdk/java/util/Locale/providersrc/spi/src/tznp.java + test/jdk/java/util/Locale/providersrc/spi/src/tznp8013086.java Changeset: 8f93292c2a51 Author: pmuthuswamy Date: 2018-10-17 15:28 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/8f93292c2a51 8211901: javadoc generates broken links on deprecated items page Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java + test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverriddenDeprecatedMethods.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg1/BaseClass.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/pkg1/SubClass.java Changeset: c2672a0f233a Author: redestad Date: 2018-10-17 14:19 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c2672a0f233a 8212201: Classlist build tool should be built for the target JDK version Reviewed-by: erikj, ihse ! make/CompileToolsJdk.gmk ! make/GenerateLinkOptData.gmk Changeset: cba34f27d9ce Author: jjiang Date: 2018-10-17 22:06 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/cba34f27d9ce 8212562: To remove lib/security from test/jdk/TEST.groups Summary: Remove lib/security from test group jdk_security3 Reviewed-by: coffeys ! test/jdk/TEST.groups Changeset: 430e6421d503 Author: redestad Date: 2018-10-17 17:35 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/430e6421d503 8212597: Optimize String concatenation setup when using primitive operands Reviewed-by: shade ! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: 199658d1ef86 Author: shade Date: 2018-10-17 18:31 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/199658d1ef86 8212608: Minimal VM build failure after JDK-8210498 (nmethod entry barriers) Reviewed-by: eosterlund ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp From maurizio.cimadamore at oracle.com Wed Oct 17 20:06:51 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Oct 2018 20:06:51 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810172006.w9HK6qgS015722@aojmv0008.oracle.com> Changeset: 2ed6af9b4d5d Author: mcimadamore Date: 2018-10-17 22:08 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/2ed6af9b4d5d Automatic merge with default ! make/RunTests.gmk ! make/conf/jib-profiles.js ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/java.base/share/classes/java/lang/System.java ! test/jdk/TEST.groups - test/jdk/java/util/Locale/LocaleCategory.sh - test/jdk/java/util/Locale/LocaleProviders.sh - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java - test/jdk/lib/testlibrary/ModuleTargetHelper.java - test/jdk/lib/testlibrary/ModuleUtils.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys From maurizio.cimadamore at oracle.com Wed Oct 17 20:07:16 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Oct 2018 20:07:16 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810172007.w9HK7HPb016008@aojmv0008.oracle.com> Changeset: 652946cb0d76 Author: mcimadamore Date: 2018-10-17 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/652946cb0d76 Automatic merge with default - test/jdk/java/util/Locale/LocaleCategory.sh - test/jdk/java/util/Locale/LocaleProviders.sh - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java - test/jdk/lib/testlibrary/ModuleTargetHelper.java - test/jdk/lib/testlibrary/ModuleUtils.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys From maurizio.cimadamore at oracle.com Wed Oct 17 20:07:37 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Oct 2018 20:07:37 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810172007.w9HK7bCd016461@aojmv0008.oracle.com> Changeset: f26dc932ac08 Author: mcimadamore Date: 2018-10-17 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/f26dc932ac08 Automatic merge with default ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java - test/jdk/java/util/Locale/LocaleCategory.sh - test/jdk/java/util/Locale/LocaleProviders.sh - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java - test/jdk/lib/testlibrary/ModuleTargetHelper.java - test/jdk/lib/testlibrary/ModuleUtils.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys From maurizio.cimadamore at oracle.com Wed Oct 17 20:07:56 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 17 Oct 2018 20:07:56 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810172007.w9HK7v24016918@aojmv0008.oracle.com> Changeset: aefbd980fe7b Author: mcimadamore Date: 2018-10-17 22:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/aefbd980fe7b Automatic merge with default ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java - test/jdk/java/util/Locale/LocaleCategory.sh - test/jdk/java/util/Locale/LocaleProviders.sh - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java - test/jdk/lib/testlibrary/ModuleTargetHelper.java - test/jdk/lib/testlibrary/ModuleUtils.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys From samuel.audet at gmail.com Thu Oct 18 00:16:34 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Thu, 18 Oct 2018 09:16:34 +0900 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <5BC772E0.3030706@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> Message-ID: <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> That looks good, thanks Sundar! Though, eventually, it would be great to have those generated at runtime somehow, so that we don't need to start parsing stuff when we just need to call single functions, like we can do with JNA or JavaCPP, for example: https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69#file-nativebenchmark-java Samuel On 10/18/2018 02:35 AM, Sundararajan Athijegannathan wrote: > Updated: http://cr.openjdk.java.net/~sundar/8212560/webrev.02/index.html > > Added --static-forwarder boolean option (default true) > > -Sundar > > On 17/10/18, 9:55 PM, Sundararajan Athijegannathan wrote: >> >> comments below.. >> >> On 17/10/18, 9:13 PM, Jorn Vernee wrote: >>> Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >>>> On option: do we need an explicit option? given that one file extra >>>> and that too only when -l is specified. (too many options already? ;) >>>> ) >>> >>> Maybe having an option is nice, but have it be turned on by default? >>> That way if someone really wanted to not generate the forwarder they >>> could, and for the general use case they don't have to bother with >>> setting an option every time. >>> >> okay. >> >>>> On naming: we've derived automatic names elsewhere. I think we could >>>> revisit all naming options by another round - perhaps even java >>>> convention for header interface name. >>>> >>>> On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt class >>>> and extended it from AsmCodeFactory. visit methods now return Boolean >>>> to tell if the particular tree was handled or not. This is needed so >>>> that subclass can avoid the same tree if super class avoided it (for >>>> eg. function-like macros, repeated definitions..) >>> >>> I'm wondering if this runs into trouble later on when adding more >>> code generation extensions/options. Let's say you add `foo` and `bar` >>> options later on. You'd have to make an extension subclass for every >>> combination of options (StaticFooBar, StaticFoo, StaticBar, FooBar, >>> Static, Foo, Bar). >>> >>> Maybe you could have something like a `CodeFactory`, which consists >>> of an `AsmCodeFactory` and a list of `CodeFactoryExt`, of which the >>> static forwarder generator would be one. And have this kind of pattern: >>> >>> ``` >>> @Override >>> public Void visitVar(VarTree varTree, JType jt) { >>> ??? if(asmCodeFactory.visitVar(varTree, jt)) { >>> ??????? for(CodeFactoryExt cfe : extensions) { >>> ??????????? cfe.visitVar(varTree, jt); >>> ??????? } >>> ??? } >>> ??? return null; >>> } >>> ``` >>> >>> I think that also allows you to get rid of the if/else statements in >>> the extension class. >>> >>> It's not really needed right now since there is only 1 extension, but >>> it might be nice idea for the future. >> >> Right. We don't want to go there yet - but yes, if we happened to add >> one more, we can revisit & refactor the code. >> >> -Sundar >>> >>> Jorn >>> >>>> Updated: >>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >>>> >>>> Thanks, >>>> -Sundar >>>> >>>> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>>>> I like it! Few questions/comments: >>>>> >>>>> * should it be enabled/disabled with explicit option >>>>> * should the name of the statics class be customizable >>>>> * I like the code organization - have you thought of pushing it >>>>> further and make StaticForwarderGenerator a _subclass_ of >>>>> AsmCodeFactory - each visitor could maybe delegate to >>>>> super.visitXyz() first and then do its own bit? Then when you setup >>>>> the pipeline, depending on what info is available on the context >>>>> (e.g. presence of -l) you can decide whether to use a 'bare' >>>>> ASMCodeFactory or the 'embellished' one. That should remove all the >>>>> 'if staticFwd != null ...' sections from AsmCodeFactory. >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>>>> Please review. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>>>> >>>>>> Thanks, >>>>>> -Sundar From maurizio.cimadamore at oracle.com Thu Oct 18 00:56:09 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 17 Oct 2018 17:56:09 -0700 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <5BC72CFC.9@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> Message-ID: <3d928ad4-9904-46ea-ed36-32c3abd76c1e@oracle.com> On 17/10/2018 05:37, Sundararajan Athijegannathan wrote: > > On option: do we need an explicit option? given that one file extra > and that too only when -l is specified. (too many options already? ;) ) > > On naming: we've derived automatic names elsewhere. I think we could > revisit all naming options by another round - perhaps even java > convention for header interface name. While on the plane a good name scheme came to mind - why not call the static wrappers with the 'Lib' suffix (a la *nix) ? E.g. given an header: foo.h we could generate: foo.class (raw header) fooLib.class (static forwarder lib) > > On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt class > and extended it from AsmCodeFactory. visit methods now return Boolean > to tell if the particular tree was handled or not. This is needed so > that subclass can avoid the same tree if super class avoided it (for > eg. function-like macros, repeated definitions..) > > Updated: http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html Looks good! Maurizio > > Thanks, > -Sundar > > On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >> I like it! Few questions/comments: >> >> * should it be enabled/disabled with explicit option >> * should the name of the statics class be customizable >> * I like the code organization - have you thought of pushing it >> further and make StaticForwarderGenerator a _subclass_ of >> AsmCodeFactory - each visitor could maybe delegate to >> super.visitXyz() first and then do its own bit? Then when you setup >> the pipeline, depending on what info is available on the context >> (e.g. presence of -l) you can decide whether to use a 'bare' >> ASMCodeFactory or the 'embellished' one. That should remove all the >> 'if staticFwd != null ...' sections from AsmCodeFactory. >> >> Maurizio >> >> >> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>> Please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>> Webrev: http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>> >>> Thanks, >>> -Sundar From samuel.audet at gmail.com Thu Oct 18 02:02:53 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Thu, 18 Oct 2018 11:02:53 +0900 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> Message-ID: <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> And while we're at it, I think the runtime component could also take care of abstracting away the details of the layouts, so gettimeofday() could look something like this, again without having to parse anything for simple cases: @Struct interface Timeval { @SizeT long tv_sec(); Timeval tv_sec(long tv_sec); long tv_usec(); Timeval tv_usec(long tv_usec); } interface Dummy { int gettimeofday(Timeval tv, Pointer timezone); } import static Dummy.*; public static void main(String[] args) { InitMagicBindings(Dummy.class, Timeval.class); Timeval t = Timeval.create() gettimeofday(t, null); } } Now that would be awesome :) Samuel On 10/18/2018 09:16 AM, Samuel Audet wrote: > That looks good, thanks Sundar! Though, eventually, it would be great to > have those generated at runtime somehow, so that we don't need to start > parsing stuff when we just need to call single functions, like we can do > with JNA or JavaCPP, for example: > https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69#file-nativebenchmark-java > > > Samuel > > On 10/18/2018 02:35 AM, Sundararajan Athijegannathan wrote: >> Updated: http://cr.openjdk.java.net/~sundar/8212560/webrev.02/index.html >> >> Added --static-forwarder boolean option (default true) >> >> -Sundar >> >> On 17/10/18, 9:55 PM, Sundararajan Athijegannathan wrote: >>> >>> comments below.. >>> >>> On 17/10/18, 9:13 PM, Jorn Vernee wrote: >>>> Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >>>>> On option: do we need an explicit option? given that one file extra >>>>> and that too only when -l is specified. (too many options already? ;) >>>>> ) >>>> >>>> Maybe having an option is nice, but have it be turned on by default? >>>> That way if someone really wanted to not generate the forwarder they >>>> could, and for the general use case they don't have to bother with >>>> setting an option every time. >>>> >>> okay. >>> >>>>> On naming: we've derived automatic names elsewhere. I think we could >>>>> revisit all naming options by another round - perhaps even java >>>>> convention for header interface name. >>>>> >>>>> On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt class >>>>> and extended it from AsmCodeFactory. visit methods now return Boolean >>>>> to tell if the particular tree was handled or not. This is needed so >>>>> that subclass can avoid the same tree if super class avoided it (for >>>>> eg. function-like macros, repeated definitions..) >>>> >>>> I'm wondering if this runs into trouble later on when adding more >>>> code generation extensions/options. Let's say you add `foo` and >>>> `bar` options later on. You'd have to make an extension subclass for >>>> every combination of options (StaticFooBar, StaticFoo, StaticBar, >>>> FooBar, Static, Foo, Bar). >>>> >>>> Maybe you could have something like a `CodeFactory`, which consists >>>> of an `AsmCodeFactory` and a list of `CodeFactoryExt`, of which the >>>> static forwarder generator would be one. And have this kind of pattern: >>>> >>>> ``` >>>> @Override >>>> public Void visitVar(VarTree varTree, JType jt) { >>>> ??? if(asmCodeFactory.visitVar(varTree, jt)) { >>>> ??????? for(CodeFactoryExt cfe : extensions) { >>>> ??????????? cfe.visitVar(varTree, jt); >>>> ??????? } >>>> ??? } >>>> ??? return null; >>>> } >>>> ``` >>>> >>>> I think that also allows you to get rid of the if/else statements in >>>> the extension class. >>>> >>>> It's not really needed right now since there is only 1 extension, >>>> but it might be nice idea for the future. >>> >>> Right. We don't want to go there yet - but yes, if we happened to add >>> one more, we can revisit & refactor the code. >>> >>> -Sundar >>>> >>>> Jorn >>>> >>>>> Updated: >>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >>>>> >>>>> Thanks, >>>>> -Sundar >>>>> >>>>> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>>>>> I like it! Few questions/comments: >>>>>> >>>>>> * should it be enabled/disabled with explicit option >>>>>> * should the name of the statics class be customizable >>>>>> * I like the code organization - have you thought of pushing it >>>>>> further and make StaticForwarderGenerator a _subclass_ of >>>>>> AsmCodeFactory - each visitor could maybe delegate to >>>>>> super.visitXyz() first and then do its own bit? Then when you >>>>>> setup the pipeline, depending on what info is available on the >>>>>> context (e.g. presence of -l) you can decide whether to use a >>>>>> 'bare' ASMCodeFactory or the 'embellished' one. That should remove >>>>>> all the 'if staticFwd != null ...' sections from AsmCodeFactory. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>>>>> Please review. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>>>>> >>>>>>> Thanks, >>>>>>> -Sundar > From Yang.Zhang at arm.com Thu Oct 18 10:07:39 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Thu, 18 Oct 2018 10:07:39 +0000 Subject: [vector api] RFC: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Message-ID: Hi, I'm working on supporting vector api for aarch64 NEON. I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ Could you please help to review this? Regards, Yang From maurizio.cimadamore at oracle.com Thu Oct 18 14:45:45 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 18 Oct 2018 07:45:45 -0700 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> Message-ID: <0799c4df-7790-82af-d196-85d56463aa57@oracle.com> Hi Samuel, I'm really confused here; if the various annotated interfaces/artifacts are generated in a jar bundle by jextract, what is the problem with layout annotations? It's not like the user will see them? So, if you are concerned about usabilty (e.g. what the client see, as in your 'main' method) using a different kind of annotation won't change anything. If you are concerned with the (one time) runtime cost to parse the layout annotations, we have already covered how the best way to address that concern is by running jextract as a jlink at module install time (as we do for other similar tasks in the JDK build itself). That will create binding implementations for all the required interfaces _statically_ which should help with startup. Maurizio On 17/10/2018 19:02, Samuel Audet wrote: > And while we're at it, I think the runtime component could also take > care of abstracting away the details of the layouts, so gettimeofday() > could look something like this, again without having to parse anything > for simple cases: > > ??? @Struct > ??? interface Timeval { > ??????? @SizeT long tv_sec(); > ??????? Timeval tv_sec(long tv_sec); > > ??????? long tv_usec(); > ??????? Timeval tv_usec(long tv_usec); > ??? } > > ??? interface Dummy { > ??????? int gettimeofday(Timeval tv, Pointer timezone); > ??? } > > ??? import static Dummy.*; > > ??? public static void main(String[] args) { > ????InitMagicBindings(Dummy.class, Timeval.class); > ??????? Timeval t = Timeval.create() > ????gettimeofday(t, null); > ??? } > } > > Now that would be awesome :) > > Samuel > > On 10/18/2018 09:16 AM, Samuel Audet wrote: >> That looks good, thanks Sundar! Though, eventually, it would be great >> to have those generated at runtime somehow, so that we don't need to >> start parsing stuff when we just need to call single functions, like >> we can do with JNA or JavaCPP, for example: >> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69#file-nativebenchmark-java >> >> >> Samuel >> >> On 10/18/2018 02:35 AM, Sundararajan Athijegannathan wrote: >>> Updated: >>> http://cr.openjdk.java.net/~sundar/8212560/webrev.02/index.html >>> >>> Added --static-forwarder boolean option (default true) >>> >>> -Sundar >>> >>> On 17/10/18, 9:55 PM, Sundararajan Athijegannathan wrote: >>>> >>>> comments below.. >>>> >>>> On 17/10/18, 9:13 PM, Jorn Vernee wrote: >>>>> Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >>>>>> On option: do we need an explicit option? given that one file extra >>>>>> and that too only when -l is specified. (too many options >>>>>> already? ;) >>>>>> ) >>>>> >>>>> Maybe having an option is nice, but have it be turned on by >>>>> default? That way if someone really wanted to not generate the >>>>> forwarder they could, and for the general use case they don't have >>>>> to bother with setting an option every time. >>>>> >>>> okay. >>>> >>>>>> On naming: we've derived automatic names elsewhere. I think we could >>>>>> revisit all naming options by another round - perhaps even java >>>>>> convention for header interface name. >>>>>> >>>>>> On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt >>>>>> class >>>>>> and extended it from AsmCodeFactory. visit methods now return >>>>>> Boolean >>>>>> to tell if the particular tree was handled or not. This is needed so >>>>>> that subclass can avoid the same tree if super class avoided it (for >>>>>> eg. function-like macros, repeated definitions..) >>>>> >>>>> I'm wondering if this runs into trouble later on when adding more >>>>> code generation extensions/options. Let's say you add `foo` and >>>>> `bar` options later on. You'd have to make an extension subclass >>>>> for every combination of options (StaticFooBar, StaticFoo, >>>>> StaticBar, FooBar, Static, Foo, Bar). >>>>> >>>>> Maybe you could have something like a `CodeFactory`, which >>>>> consists of an `AsmCodeFactory` and a list of `CodeFactoryExt`, of >>>>> which the static forwarder generator would be one. And have this >>>>> kind of pattern: >>>>> >>>>> ``` >>>>> @Override >>>>> public Void visitVar(VarTree varTree, JType jt) { >>>>> ??? if(asmCodeFactory.visitVar(varTree, jt)) { >>>>> ??????? for(CodeFactoryExt cfe : extensions) { >>>>> ??????????? cfe.visitVar(varTree, jt); >>>>> ??????? } >>>>> ??? } >>>>> ??? return null; >>>>> } >>>>> ``` >>>>> >>>>> I think that also allows you to get rid of the if/else statements >>>>> in the extension class. >>>>> >>>>> It's not really needed right now since there is only 1 extension, >>>>> but it might be nice idea for the future. >>>> >>>> Right. We don't want to go there yet - but yes, if we happened to >>>> add one more, we can revisit & refactor the code. >>>> >>>> -Sundar >>>>> >>>>> Jorn >>>>> >>>>>> Updated: >>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >>>>>> >>>>>> Thanks, >>>>>> -Sundar >>>>>> >>>>>> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>>>>>> I like it! Few questions/comments: >>>>>>> >>>>>>> * should it be enabled/disabled with explicit option >>>>>>> * should the name of the statics class be customizable >>>>>>> * I like the code organization - have you thought of pushing it >>>>>>> further and make StaticForwarderGenerator a _subclass_ of >>>>>>> AsmCodeFactory - each visitor could maybe delegate to >>>>>>> super.visitXyz() first and then do its own bit? Then when you >>>>>>> setup the pipeline, depending on what info is available on the >>>>>>> context (e.g. presence of -l) you can decide whether to use a >>>>>>> 'bare' ASMCodeFactory or the 'embellished' one. That should >>>>>>> remove all the 'if staticFwd != null ...' sections from >>>>>>> AsmCodeFactory. >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> >>>>>>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>>>>>> Please review. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Sundar >> > From sundararajan.athijegannathan at oracle.com Thu Oct 18 16:08:30 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 18 Oct 2018 16:08:30 +0000 Subject: hg: panama/dev: 8212560: jextract should generate a static forwarder class Message-ID: <201810181608.w9IG8U6H016830@aojmv0008.oracle.com> Changeset: a43735f1fe86 Author: sundar Date: 2018-10-18 21:48 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/a43735f1fe86 8212560: jextract should generate a static forwarder class Reviewed-by: mcimadamore ! src/jdk.jextract/share/classes/com/sun/tools/jextract/AsmCodeFactory.java + src/jdk.jextract/share/classes/com/sun/tools/jextract/AsmCodeFactoryExt.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/Context.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/Main.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/resources/Messages.properties ! test/jdk/com/sun/tools/jextract/libproc/LibprocTest.java + test/jdk/com/sun/tools/jextract/staticForwarder/NoStaticForwarderTest.java + test/jdk/com/sun/tools/jextract/staticForwarder/StaticForwarderTest.java + test/jdk/com/sun/tools/jextract/staticForwarder/libUtils.c + test/jdk/com/sun/tools/jextract/staticForwarder/utils.h From Alejandro.MartinezVicente at arm.com Thu Oct 18 16:14:04 2018 From: Alejandro.MartinezVicente at arm.com (Alejandro Martinez Vicente) Date: Thu, 18 Oct 2018 16:14:04 +0000 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension Message-ID: (I just registered, so maybe this won't appear as a reply to the last message) Hi, The scalable shape is just a convenient way to avoid having to code the 16 vector lengths that SVE supports. We should always return a concrete VL shape if the maximum VL happens to be 128, 256 or 512 (which honestly, should be 99% of the time). If this is going to be a contentious issue, I think we might as well bite the bullet and write the 16 versions, which are going to be almost identical. They could even be some thin layers over the current scalable vector class. Alejandro IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From samuel.audet at gmail.com Thu Oct 18 21:49:01 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Fri, 19 Oct 2018 06:49:01 +0900 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <0799c4df-7790-82af-d196-85d56463aa57@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> <0799c4df-7790-82af-d196-85d56463aa57@oracle.com> Message-ID: <40a8f564-f2a2-2a14-06b4-353a37ecc88d@gmail.com> Here I'm concerned about usability. Having to look at a bunch of irrelevant Offset annotations and/or weird layouts specification is a usability issue, but not a big one. The problem with jextract is that it needs to generate them by /parsing/ the header files, which is an error-prone process, especially for function-like macros and C++, as you tell me those are still goals. It doesn't make sense to want to parse random files when it's possible to specify manually but more easily everything in the target language. It just complicates things! (BTW, Go or Swift don't do function-like macros or C++ so they can afford to tell everyone to just parse everything). If jextract could have 2 mode of operations, one where it parses the header files, and another one, where it can generate the annotations at runtime, that's fine, but that's not how it works currently. (Which reminds me, we can probably do all that stuff at build time the way Lombok does it: https://projectlombok.org/ ) This is especially relevant for C++ template libraries like Boost, Eigen, Ceres Solver, or Thrust. Just writing out the few declarations manually is often easier than figuring out whatever hacks we can come up to specify some types and how to map them, for example: https://github.com/bytedeco/javacpp/wiki/Interface-Thrust-and-CUDA This really depends on the priorities of the project though. I really think Panama should concentrate on getting things like linkToNative ready in the JDK and leave things like jextract and Lombok-like functionality to others because we can do it outside the JDK, but that's just my opinion. Samuel On 10/18/2018 11:45 PM, Maurizio Cimadamore wrote: > Hi Samuel, > I'm really confused here; if the various annotated interfaces/artifacts > are generated in a jar bundle by jextract, what is the problem with > layout annotations? It's not like the user will see them? > > So, if you are concerned about usabilty (e.g. what the client see, as in > your 'main' method) using a different kind of annotation won't change > anything. > > If you are concerned with the (one time) runtime cost to parse the > layout annotations, we have already covered how the best way to address > that concern is by running jextract as a jlink at module install time > (as we do for other similar tasks in the JDK build itself). That will > create binding implementations for all the required interfaces > _statically_ which should help with startup. > > Maurizio > > On 17/10/2018 19:02, Samuel Audet wrote: >> And while we're at it, I think the runtime component could also take >> care of abstracting away the details of the layouts, so gettimeofday() >> could look something like this, again without having to parse anything >> for simple cases: >> >> ??? @Struct >> ??? interface Timeval { >> ??????? @SizeT long tv_sec(); >> ??????? Timeval tv_sec(long tv_sec); >> >> ??????? long tv_usec(); >> ??????? Timeval tv_usec(long tv_usec); >> ??? } >> >> ??? interface Dummy { >> ??????? int gettimeofday(Timeval tv, Pointer timezone); >> ??? } >> >> ??? import static Dummy.*; >> >> ??? public static void main(String[] args) { >> ????InitMagicBindings(Dummy.class, Timeval.class); >> ??????? Timeval t = Timeval.create() >> ????gettimeofday(t, null); >> ??? } >> } >> >> Now that would be awesome :) >> >> Samuel >> >> On 10/18/2018 09:16 AM, Samuel Audet wrote: >>> That looks good, thanks Sundar! Though, eventually, it would be great >>> to have those generated at runtime somehow, so that we don't need to >>> start parsing stuff when we just need to call single functions, like >>> we can do with JNA or JavaCPP, for example: >>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69#file-nativebenchmark-java >>> >>> >>> Samuel >>> >>> On 10/18/2018 02:35 AM, Sundararajan Athijegannathan wrote: >>>> Updated: >>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.02/index.html >>>> >>>> Added --static-forwarder boolean option (default true) >>>> >>>> -Sundar >>>> >>>> On 17/10/18, 9:55 PM, Sundararajan Athijegannathan wrote: >>>>> >>>>> comments below.. >>>>> >>>>> On 17/10/18, 9:13 PM, Jorn Vernee wrote: >>>>>> Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >>>>>>> On option: do we need an explicit option? given that one file extra >>>>>>> and that too only when -l is specified. (too many options >>>>>>> already? ;) >>>>>>> ) >>>>>> >>>>>> Maybe having an option is nice, but have it be turned on by >>>>>> default? That way if someone really wanted to not generate the >>>>>> forwarder they could, and for the general use case they don't have >>>>>> to bother with setting an option every time. >>>>>> >>>>> okay. >>>>> >>>>>>> On naming: we've derived automatic names elsewhere. I think we could >>>>>>> revisit all naming options by another round - perhaps even java >>>>>>> convention for header interface name. >>>>>>> >>>>>>> On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt >>>>>>> class >>>>>>> and extended it from AsmCodeFactory. visit methods now return >>>>>>> Boolean >>>>>>> to tell if the particular tree was handled or not. This is needed so >>>>>>> that subclass can avoid the same tree if super class avoided it (for >>>>>>> eg. function-like macros, repeated definitions..) >>>>>> >>>>>> I'm wondering if this runs into trouble later on when adding more >>>>>> code generation extensions/options. Let's say you add `foo` and >>>>>> `bar` options later on. You'd have to make an extension subclass >>>>>> for every combination of options (StaticFooBar, StaticFoo, >>>>>> StaticBar, FooBar, Static, Foo, Bar). >>>>>> >>>>>> Maybe you could have something like a `CodeFactory`, which >>>>>> consists of an `AsmCodeFactory` and a list of `CodeFactoryExt`, of >>>>>> which the static forwarder generator would be one. And have this >>>>>> kind of pattern: >>>>>> >>>>>> ``` >>>>>> @Override >>>>>> public Void visitVar(VarTree varTree, JType jt) { >>>>>> ??? if(asmCodeFactory.visitVar(varTree, jt)) { >>>>>> ??????? for(CodeFactoryExt cfe : extensions) { >>>>>> ??????????? cfe.visitVar(varTree, jt); >>>>>> ??????? } >>>>>> ??? } >>>>>> ??? return null; >>>>>> } >>>>>> ``` >>>>>> >>>>>> I think that also allows you to get rid of the if/else statements >>>>>> in the extension class. >>>>>> >>>>>> It's not really needed right now since there is only 1 extension, >>>>>> but it might be nice idea for the future. >>>>> >>>>> Right. We don't want to go there yet - but yes, if we happened to >>>>> add one more, we can revisit & refactor the code. >>>>> >>>>> -Sundar >>>>>> >>>>>> Jorn >>>>>> >>>>>>> Updated: >>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >>>>>>> >>>>>>> Thanks, >>>>>>> -Sundar >>>>>>> >>>>>>> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>>>>>>> I like it! Few questions/comments: >>>>>>>> >>>>>>>> * should it be enabled/disabled with explicit option >>>>>>>> * should the name of the statics class be customizable >>>>>>>> * I like the code organization - have you thought of pushing it >>>>>>>> further and make StaticForwarderGenerator a _subclass_ of >>>>>>>> AsmCodeFactory - each visitor could maybe delegate to >>>>>>>> super.visitXyz() first and then do its own bit? Then when you >>>>>>>> setup the pipeline, depending on what info is available on the >>>>>>>> context (e.g. presence of -l) you can decide whether to use a >>>>>>>> 'bare' ASMCodeFactory or the 'embellished' one. That should >>>>>>>> remove all the 'if staticFwd != null ...' sections from >>>>>>>> AsmCodeFactory. >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> >>>>>>>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>>>>>>> Please review. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> -Sundar >>> >> From Ningsheng.Jian at arm.com Fri Oct 19 02:11:27 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Fri, 19 Oct 2018 02:11:27 +0000 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: Message-ID: Hi Alejandro, Thanks for the comment! > > The scalable shape is just a convenient way to avoid having to code the 16 vector > lengths that SVE supports. We should always return a concrete VL shape if the > maximum VL happens to be 128, 256 or 512 (which honestly, should be 99% of > the time). > Yes, that's how we currently implemented. SVE has very good compatibility. :-) > If this is going to be a contentious issue, I think we might as well bite the bullet > and write the 16 versions, which are going to be almost identical. They could > even be some thin layers over the current scalable vector class. > That's fine and should not affect our hotspot internal support much, but needs additional lots of lines of code. However, my other concern is that may be misleading of encouraging the use of explicit sizes, since those shapes are public available to users. I think current vector length agnostic way is better fit for SVE (and even other arches?), and we are trying to resolve the reshaping issues. Thanks, Ningsheng IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From sundararajan.athijegannathan at oracle.com Fri Oct 19 02:32:49 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 19 Oct 2018 08:02:49 +0530 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <40a8f564-f2a2-2a14-06b4-353a37ecc88d@gmail.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> <0799c4df-7790-82af-d196-85d56463aa57@oracle.com> <40a8f564-f2a2-2a14-06b4-353a37ecc88d@gmail.com> Message-ID: <5BC94251.5080203@oracle.com> I think it has been already mentioned. But it is worth reiterating. Even if we're to leave at linkToNative + minimal API, we still need a tool to test it all! i.e., jextract is needed if we've to avoid "all manual" (and so difficult to maintain, error prone) tests. -Sundar On 19/10/18, 3:19 AM, Samuel Audet wrote: > Here I'm concerned about usability. Having to look at a bunch of > irrelevant Offset annotations and/or weird layouts specification is a > usability issue, but not a big one. The problem with jextract is that > it needs to generate them by /parsing/ the header files, which is an > error-prone process, especially for function-like macros and C++, as > you tell me those are still goals. It doesn't make sense to want to > parse random files when it's possible to specify manually but more > easily everything in the target language. It just complicates things! > (BTW, Go or Swift don't do function-like macros or C++ so they can > afford to tell everyone to just parse everything). If jextract could > have 2 mode of operations, one where it parses the header files, and > another one, where it can generate the annotations at runtime, that's > fine, but that's not how it works currently. (Which reminds me, we can > probably do all that stuff at build time the way Lombok does it: > https://projectlombok.org/ ) > > This is especially relevant for C++ template libraries like Boost, > Eigen, Ceres Solver, or Thrust. Just writing out the few declarations > manually is often easier than figuring out whatever hacks we can come > up to specify some types and how to map them, for example: > https://github.com/bytedeco/javacpp/wiki/Interface-Thrust-and-CUDA > > This really depends on the priorities of the project though. I really > think Panama should concentrate on getting things like linkToNative > ready in the JDK and leave things like jextract and Lombok-like > functionality to others because we can do it outside the JDK, but > that's just my opinion. > > Samuel > > On 10/18/2018 11:45 PM, Maurizio Cimadamore wrote: >> Hi Samuel, >> I'm really confused here; if the various annotated >> interfaces/artifacts are generated in a jar bundle by jextract, what >> is the problem with layout annotations? It's not like the user will >> see them? >> >> So, if you are concerned about usabilty (e.g. what the client see, as >> in your 'main' method) using a different kind of annotation won't >> change anything. >> >> If you are concerned with the (one time) runtime cost to parse the >> layout annotations, we have already covered how the best way to >> address that concern is by running jextract as a jlink at module >> install time (as we do for other similar tasks in the JDK build >> itself). That will create binding implementations for all the >> required interfaces _statically_ which should help with startup. >> >> Maurizio >> >> On 17/10/2018 19:02, Samuel Audet wrote: >>> And while we're at it, I think the runtime component could also take >>> care of abstracting away the details of the layouts, so >>> gettimeofday() could look something like this, again without having >>> to parse anything for simple cases: >>> >>> @Struct >>> interface Timeval { >>> @SizeT long tv_sec(); >>> Timeval tv_sec(long tv_sec); >>> >>> long tv_usec(); >>> Timeval tv_usec(long tv_usec); >>> } >>> >>> interface Dummy { >>> int gettimeofday(Timeval tv, Pointer timezone); >>> } >>> >>> import static Dummy.*; >>> >>> public static void main(String[] args) { >>> InitMagicBindings(Dummy.class, Timeval.class); >>> Timeval t = Timeval.create() >>> gettimeofday(t, null); >>> } >>> } >>> >>> Now that would be awesome :) >>> >>> Samuel >>> >>> On 10/18/2018 09:16 AM, Samuel Audet wrote: >>>> That looks good, thanks Sundar! Though, eventually, it would be >>>> great to have those generated at runtime somehow, so that we don't >>>> need to start parsing stuff when we just need to call single >>>> functions, like we can do with JNA or JavaCPP, for example: >>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69#file-nativebenchmark-java >>>> >>>> >>>> Samuel >>>> >>>> On 10/18/2018 02:35 AM, Sundararajan Athijegannathan wrote: >>>>> Updated: >>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.02/index.html >>>>> >>>>> Added --static-forwarder boolean option (default true) >>>>> >>>>> -Sundar >>>>> >>>>> On 17/10/18, 9:55 PM, Sundararajan Athijegannathan wrote: >>>>>> >>>>>> comments below.. >>>>>> >>>>>> On 17/10/18, 9:13 PM, Jorn Vernee wrote: >>>>>>> Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >>>>>>>> On option: do we need an explicit option? given that one file >>>>>>>> extra >>>>>>>> and that too only when -l is specified. (too many options >>>>>>>> already? ;) >>>>>>>> ) >>>>>>> >>>>>>> Maybe having an option is nice, but have it be turned on by >>>>>>> default? That way if someone really wanted to not generate the >>>>>>> forwarder they could, and for the general use case they don't >>>>>>> have to bother with setting an option every time. >>>>>>> >>>>>> okay. >>>>>> >>>>>>>> On naming: we've derived automatic names elsewhere. I think we >>>>>>>> could >>>>>>>> revisit all naming options by another round - perhaps even java >>>>>>>> convention for header interface name. >>>>>>>> >>>>>>>> On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt >>>>>>>> class >>>>>>>> and extended it from AsmCodeFactory. visit methods now return >>>>>>>> Boolean >>>>>>>> to tell if the particular tree was handled or not. This is >>>>>>>> needed so >>>>>>>> that subclass can avoid the same tree if super class avoided it >>>>>>>> (for >>>>>>>> eg. function-like macros, repeated definitions..) >>>>>>> >>>>>>> I'm wondering if this runs into trouble later on when adding >>>>>>> more code generation extensions/options. Let's say you add `foo` >>>>>>> and `bar` options later on. You'd have to make an extension >>>>>>> subclass for every combination of options (StaticFooBar, >>>>>>> StaticFoo, StaticBar, FooBar, Static, Foo, Bar). >>>>>>> >>>>>>> Maybe you could have something like a `CodeFactory`, which >>>>>>> consists of an `AsmCodeFactory` and a list of `CodeFactoryExt`, >>>>>>> of which the static forwarder generator would be one. And have >>>>>>> this kind of pattern: >>>>>>> >>>>>>> ``` >>>>>>> @Override >>>>>>> public Void visitVar(VarTree varTree, JType jt) { >>>>>>> if(asmCodeFactory.visitVar(varTree, jt)) { >>>>>>> for(CodeFactoryExt cfe : extensions) { >>>>>>> cfe.visitVar(varTree, jt); >>>>>>> } >>>>>>> } >>>>>>> return null; >>>>>>> } >>>>>>> ``` >>>>>>> >>>>>>> I think that also allows you to get rid of the if/else >>>>>>> statements in the extension class. >>>>>>> >>>>>>> It's not really needed right now since there is only 1 >>>>>>> extension, but it might be nice idea for the future. >>>>>> >>>>>> Right. We don't want to go there yet - but yes, if we happened to >>>>>> add one more, we can revisit & refactor the code. >>>>>> >>>>>> -Sundar >>>>>>> >>>>>>> Jorn >>>>>>> >>>>>>>> Updated: >>>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Sundar >>>>>>>> >>>>>>>> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>>>>>>>> I like it! Few questions/comments: >>>>>>>>> >>>>>>>>> * should it be enabled/disabled with explicit option >>>>>>>>> * should the name of the statics class be customizable >>>>>>>>> * I like the code organization - have you thought of pushing >>>>>>>>> it further and make StaticForwarderGenerator a _subclass_ of >>>>>>>>> AsmCodeFactory - each visitor could maybe delegate to >>>>>>>>> super.visitXyz() first and then do its own bit? Then when you >>>>>>>>> setup the pipeline, depending on what info is available on the >>>>>>>>> context (e.g. presence of -l) you can decide whether to use a >>>>>>>>> 'bare' ASMCodeFactory or the 'embellished' one. That should >>>>>>>>> remove all the 'if staticFwd != null ...' sections from >>>>>>>>> AsmCodeFactory. >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> >>>>>>>>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>>>>>>>> Please review. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> -Sundar >>>> >>> > From maurizio.cimadamore at oracle.com Fri Oct 19 04:03:10 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 18 Oct 2018 21:03:10 -0700 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <40a8f564-f2a2-2a14-06b4-353a37ecc88d@gmail.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> <0799c4df-7790-82af-d196-85d56463aa57@oracle.com> <40a8f564-f2a2-2a14-06b4-353a37ecc88d@gmail.com> Message-ID: <5f9cf860-af86-9d68-4f21-0ab742363266@oracle.com> On 18/10/2018 14:49, Samuel Audet wrote: > If jextract could have 2 mode of operations, one where it parses the > header files, and another one, where it can generate the annotations > at runtime Still not following; jextract is a static component - how can it generate annotations at runtime? Seems to me that your original comment was on being able to use a simpler system of annotations - as in: ??????? @SizeT long tv_sec(); Which might be a valid argument/question, but it has little to do with jextract and everything to do with the binder. The reason why annotations include layouts is that, in general cases, things are messy - there's padding for one, that is not captured well by annotations; also you can't rely on the order in which methods are declared when using reflection, as at runtime that order is not guaranteed. jextract is a tool, which takes an header and generates a set of interfaces with some annotations (which the binder likes), all bundled in a jar. That's what the tool does and (apart from some hiccups we are aware of) it does its job pretty well, as we have been able to extract a considerable set of non trivial libraries (such as TensorFlow, OpenGL, OpenCL, Clang, Python, ...). Extracting layouts from headers _is_ precise and does not require any guessing (as you seem to imply). The problem with function-like macros, or with other compile-time-only entities such as inline C++ methods, templates, overloaded methods is that these features are not reified in the system ABI - e.g. the shared library knows nothing e.g. about function-like macros - and as a result you have no native entry point to work with when it comes to Panama. We have already shared some ideas on how to cover that space [1], so please refer to that. Again, I have a feeling that another RFR has been hi-jacked into a big design goals re-discussion, so please, if needed create a new thread. [1] - http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001537.html Maurizio From samuel.audet at gmail.com Sat Oct 20 01:14:21 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Sat, 20 Oct 2018 10:14:21 +0900 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <5BC94251.5080203@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> <0799c4df-7790-82af-d196-85d56463aa57@oracle.com> <40a8f564-f2a2-2a14-06b4-353a37ecc88d@gmail.com> <5BC94251.5080203@oracle.com> Message-ID: Yes, I talked about that with John and Maurizio offline, which I mentioned in the other thread trying to make a parallel with Dvorak vs QWERTY keyboard layouts. I could, for example, have JavaCPP start targeting the classes from Panama, but the issue here is that I don't feel Panama will be able to provide a level of performance sufficiently higher than JNI to justify the cost of switching over, or in maintaining 2 sets of bindings for Android, old versions of the JDK, etc. John says it would be real easy to make it a lot faster than JNI (but why do we still have basically nothing after over 4 years?), Maurizio seems less certain... Who knows, really? Anyway, my point is if you could show me good numbers, I could be the one to take over the testing here. Because, as I also said before, that's basically what the JavaCPP Presets are, they are a testbed for JavaCPP: https://github.com/bytedeco/javacpp-presets Samuel On 10/19/2018 11:32 AM, Sundararajan Athijegannathan wrote: > I think it has been already mentioned. But it is worth reiterating. Even > if we're to leave at linkToNative + minimal API, we still need a tool to > test it all! i.e., jextract is needed if we've to avoid "all manual" > (and so difficult to maintain, error prone) tests. > > -Sundar > > On 19/10/18, 3:19 AM, Samuel Audet wrote: >> Here I'm concerned about usability. Having to look at a bunch of >> irrelevant Offset annotations and/or weird layouts specification is a >> usability issue, but not a big one. The problem with jextract is that >> it needs to generate them by /parsing/ the header files, which is an >> error-prone process, especially for function-like macros and C++, as >> you tell me those are still goals. It doesn't make sense to want to >> parse random files when it's possible to specify manually but more >> easily everything in the target language. It just complicates things! >> (BTW, Go or Swift don't do function-like macros or C++ so they can >> afford to tell everyone to just parse everything). If jextract could >> have 2 mode of operations, one where it parses the header files, and >> another one, where it can generate the annotations at runtime, that's >> fine, but that's not how it works currently. (Which reminds me, we can >> probably do all that stuff at build time the way Lombok does it: >> https://projectlombok.org/ ) >> >> This is especially relevant for C++ template libraries like Boost, >> Eigen, Ceres Solver, or Thrust. Just writing out the few declarations >> manually is often easier than figuring out whatever hacks we can come >> up to specify some types and how to map them, for example: >> https://github.com/bytedeco/javacpp/wiki/Interface-Thrust-and-CUDA >> >> This really depends on the priorities of the project though. I really >> think Panama should concentrate on getting things like linkToNative >> ready in the JDK and leave things like jextract and Lombok-like >> functionality to others because we can do it outside the JDK, but >> that's just my opinion. >> >> Samuel >> >> On 10/18/2018 11:45 PM, Maurizio Cimadamore wrote: >>> Hi Samuel, >>> I'm really confused here; if the various annotated >>> interfaces/artifacts are generated in a jar bundle by jextract, what >>> is the problem with layout annotations? It's not like the user will >>> see them? >>> >>> So, if you are concerned about usabilty (e.g. what the client see, as >>> in your 'main' method) using a different kind of annotation won't >>> change anything. >>> >>> If you are concerned with the (one time) runtime cost to parse the >>> layout annotations, we have already covered how the best way to >>> address that concern is by running jextract as a jlink at module >>> install time (as we do for other similar tasks in the JDK build >>> itself). That will create binding implementations for all the >>> required interfaces _statically_ which should help with startup. >>> >>> Maurizio >>> >>> On 17/10/2018 19:02, Samuel Audet wrote: >>>> And while we're at it, I think the runtime component could also take >>>> care of abstracting away the details of the layouts, so >>>> gettimeofday() could look something like this, again without having >>>> to parse anything for simple cases: >>>> >>>> ??? @Struct >>>> ??? interface Timeval { >>>> ??????? @SizeT long tv_sec(); >>>> ??????? Timeval tv_sec(long tv_sec); >>>> >>>> ??????? long tv_usec(); >>>> ??????? Timeval tv_usec(long tv_usec); >>>> ??? } >>>> >>>> ??? interface Dummy { >>>> ??????? int gettimeofday(Timeval tv, Pointer timezone); >>>> ??? } >>>> >>>> ??? import static Dummy.*; >>>> >>>> ??? public static void main(String[] args) { >>>> ??? InitMagicBindings(Dummy.class, Timeval.class); >>>> ??????? Timeval t = Timeval.create() >>>> ??? gettimeofday(t, null); >>>> ??? } >>>> } >>>> >>>> Now that would be awesome :) >>>> >>>> Samuel >>>> >>>> On 10/18/2018 09:16 AM, Samuel Audet wrote: >>>>> That looks good, thanks Sundar! Though, eventually, it would be >>>>> great to have those generated at runtime somehow, so that we don't >>>>> need to start parsing stuff when we just need to call single >>>>> functions, like we can do with JNA or JavaCPP, for example: >>>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69#file-nativebenchmark-java >>>>> >>>>> >>>>> Samuel >>>>> >>>>> On 10/18/2018 02:35 AM, Sundararajan Athijegannathan wrote: >>>>>> Updated: >>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.02/index.html >>>>>> >>>>>> Added --static-forwarder boolean option (default true) >>>>>> >>>>>> -Sundar >>>>>> >>>>>> On 17/10/18, 9:55 PM, Sundararajan Athijegannathan wrote: >>>>>>> >>>>>>> comments below.. >>>>>>> >>>>>>> On 17/10/18, 9:13 PM, Jorn Vernee wrote: >>>>>>>> Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >>>>>>>>> On option: do we need an explicit option? given that one file >>>>>>>>> extra >>>>>>>>> and that too only when -l is specified. (too many options >>>>>>>>> already? ;) >>>>>>>>> ) >>>>>>>> >>>>>>>> Maybe having an option is nice, but have it be turned on by >>>>>>>> default? That way if someone really wanted to not generate the >>>>>>>> forwarder they could, and for the general use case they don't >>>>>>>> have to bother with setting an option every time. >>>>>>>> >>>>>>> okay. >>>>>>> >>>>>>>>> On naming: we've derived automatic names elsewhere. I think we >>>>>>>>> could >>>>>>>>> revisit all naming options by another round - perhaps even java >>>>>>>>> convention for header interface name. >>>>>>>>> >>>>>>>>> On subclassing: Nice suggestion. I made it as AsmCodeFactoryExt >>>>>>>>> class >>>>>>>>> and extended it from AsmCodeFactory. visit methods now return >>>>>>>>> Boolean >>>>>>>>> to tell if the particular tree was handled or not. This is >>>>>>>>> needed so >>>>>>>>> that subclass can avoid the same tree if super class avoided it >>>>>>>>> (for >>>>>>>>> eg. function-like macros, repeated definitions..) >>>>>>>> >>>>>>>> I'm wondering if this runs into trouble later on when adding >>>>>>>> more code generation extensions/options. Let's say you add `foo` >>>>>>>> and `bar` options later on. You'd have to make an extension >>>>>>>> subclass for every combination of options (StaticFooBar, >>>>>>>> StaticFoo, StaticBar, FooBar, Static, Foo, Bar). >>>>>>>> >>>>>>>> Maybe you could have something like a `CodeFactory`, which >>>>>>>> consists of an `AsmCodeFactory` and a list of `CodeFactoryExt`, >>>>>>>> of which the static forwarder generator would be one. And have >>>>>>>> this kind of pattern: >>>>>>>> >>>>>>>> ``` >>>>>>>> @Override >>>>>>>> public Void visitVar(VarTree varTree, JType jt) { >>>>>>>> ??? if(asmCodeFactory.visitVar(varTree, jt)) { >>>>>>>> ??????? for(CodeFactoryExt cfe : extensions) { >>>>>>>> ??????????? cfe.visitVar(varTree, jt); >>>>>>>> ??????? } >>>>>>>> ??? } >>>>>>>> ??? return null; >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> I think that also allows you to get rid of the if/else >>>>>>>> statements in the extension class. >>>>>>>> >>>>>>>> It's not really needed right now since there is only 1 >>>>>>>> extension, but it might be nice idea for the future. >>>>>>> >>>>>>> Right. We don't want to go there yet - but yes, if we happened to >>>>>>> add one more, we can revisit & refactor the code. >>>>>>> >>>>>>> -Sundar >>>>>>>> >>>>>>>> Jorn >>>>>>>> >>>>>>>>> Updated: >>>>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> -Sundar >>>>>>>>> >>>>>>>>> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>>>>>>>>> I like it! Few questions/comments: >>>>>>>>>> >>>>>>>>>> * should it be enabled/disabled with explicit option >>>>>>>>>> * should the name of the statics class be customizable >>>>>>>>>> * I like the code organization - have you thought of pushing >>>>>>>>>> it further and make StaticForwarderGenerator a _subclass_ of >>>>>>>>>> AsmCodeFactory - each visitor could maybe delegate to >>>>>>>>>> super.visitXyz() first and then do its own bit? Then when you >>>>>>>>>> setup the pipeline, depending on what info is available on the >>>>>>>>>> context (e.g. presence of -l) you can decide whether to use a >>>>>>>>>> 'bare' ASMCodeFactory or the 'embellished' one. That should >>>>>>>>>> remove all the 'if staticFwd != null ...' sections from >>>>>>>>>> AsmCodeFactory. >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>>>>>>>>> Please review. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> -Sundar >>>>> >>>> >> From samuel.audet at gmail.com Sun Oct 21 02:12:33 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Sun, 21 Oct 2018 11:12:33 +0900 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: <5f9cf860-af86-9d68-4f21-0ab742363266@oracle.com> References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> <0799c4df-7790-82af-d196-85d56463aa57@oracle.com> <40a8f564-f2a2-2a14-06b4-353a37ecc88d@gmail.com> <5f9cf860-af86-9d68-4f21-0ab742363266@oracle.com> Message-ID: <34b449cd-2278-88c8-c6ad-fbc279748e0a@gmail.com> On 10/19/2018 01:03 PM, Maurizio Cimadamore wrote: > On 18/10/2018 14:49, Samuel Audet wrote: >> If jextract could have 2 mode of operations, one where it parses the >> header files, and another one, where it can generate the annotations >> at runtime > > Still not following; jextract is a static component - how can it > generate annotations at runtime? > > Seems to me that your original comment was on being able to use a > simpler system of annotations - as in: > > ??????? @SizeT long tv_sec(); > > Which might be a valid argument/question, but it has little to do with > jextract and everything to do with the binder. The reason why > annotations include layouts is that, in general cases, things are messy > - there's padding for one, that is not captured well by annotations; > also you can't rely on the order in which methods are declared when > using reflection, as at runtime that order is not guaranteed. The order is not guaranteed because of the current specifications of the JDK, but that's something you (the JDK developers) could improve, such as with the values types of Valhalla. BTW, is there a way to map layouts to value types and vice versa? I think that would go a long way in solving this kind of issue. If value types are not the answer, then why not do something about it anyway? Another way could be to let the binder access the header files, as with the Substrate VM. That's an approach Panama could use as well, but I find it much more natural to map value types to layouts. Then we don't need to mess at all with the C language. > jextract is a tool, which takes an header and generates a set of > interfaces with some annotations (which the binder likes), all bundled > in a jar. That's what the tool does and (apart from some hiccups we are > aware of) it does its job pretty well, as we have been able to extract a > considerable set of non trivial libraries (such as TensorFlow, OpenGL, > OpenCL, Clang, Python, ...). Extracting layouts from headers _is_ > precise and does not require any guessing (as you seem to imply). The > problem with function-like macros, or with other compile-time-only > entities such as inline C++ methods, templates, overloaded methods is > that these features are not reified in the system ABI - e.g. the shared > library knows nothing e.g. about function-like macros - and as a result > you have no native entry point to work with when it comes to Panama. No, there is still a lot of guess work involved. I guess I'll have to leave you guys go at it some more and fail before you listen further to what I have to say :( > We have already shared some ideas on how to cover that space [1], so > please refer to that. Again, I have a feeling that another RFR has been > hi-jacked into a big design goals re-discussion, so please, if needed > create a new thread. Well, I'm very glad that you take the time to listen to some of what I say, unlike John who basically ignored everything I said a few years back, but I feel we've come to a limit in our ability to discuss, so I think I'll leave things like they are for now. When you have some numbers to provide, then we can discuss. I'll refrain from hijacking any further thread until that time :) Sorry about that Samuel From sundararajan.athijegannathan at oracle.com Mon Oct 22 02:36:56 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 22 Oct 2018 08:06:56 +0530 Subject: [foreign] RFR 8212560 : jextract should generate a static forwarder class In-Reply-To: References: <5BC6CA19.5000101@oracle.com> <2dfa0fe1-e519-dcec-d604-68ac16468a0a@oracle.com> <5BC72CFC.9@oracle.com> <5BC7626E.1020406@oracle.com> <5BC772E0.3030706@oracle.com> <3fce37ee-488b-2fdd-6035-c95a1ebad1bd@gmail.com> <05eaf044-dc7e-508f-b7cf-a2929404ac45@gmail.com> <0799c4df-7790-82af-d196-85d56463aa57@oracle.com> <40a8f564-f2a2-2a14-06b4-353a37ecc88d@gmail.com> <5BC94251.5080203@oracle.com> Message-ID: <5BCD37C8.9090006@oracle.com> If you want to wait for good perf. numbers, please do so. But we still need a test framework today - and jextract serves that purpose as of today. PS. I think we should avoid RFR threads to discuss design/future etc. That clutters reviews. We could always start a new thread referring to a specific RFR thread if needed. Thanks, -Sundar On 20/10/18, 6:44 AM, Samuel Audet wrote: > Yes, I talked about that with John and Maurizio offline, which I > mentioned in the other thread trying to make a parallel with Dvorak vs > QWERTY keyboard layouts. I could, for example, have JavaCPP start > targeting the classes from Panama, but the issue here is that I don't > feel Panama will be able to provide a level of performance > sufficiently higher than JNI to justify the cost of switching over, or > in maintaining 2 sets of bindings for Android, old versions of the > JDK, etc. John says it would be real easy to make it a lot faster than > JNI (but why do we still have basically nothing after over 4 years?), > Maurizio seems less certain... Who knows, really? Anyway, my point is > if you could show me good numbers, I could be the one to take over the > testing here. Because, as I also said before, that's basically what > the JavaCPP Presets are, they are a testbed for JavaCPP: > https://github.com/bytedeco/javacpp-presets > > Samuel > > On 10/19/2018 11:32 AM, Sundararajan Athijegannathan wrote: >> I think it has been already mentioned. But it is worth reiterating. >> Even if we're to leave at linkToNative + minimal API, we still need a >> tool to test it all! i.e., jextract is needed if we've to avoid "all >> manual" (and so difficult to maintain, error prone) tests. >> >> -Sundar >> >> On 19/10/18, 3:19 AM, Samuel Audet wrote: >>> Here I'm concerned about usability. Having to look at a bunch of >>> irrelevant Offset annotations and/or weird layouts specification is >>> a usability issue, but not a big one. The problem with jextract is >>> that it needs to generate them by /parsing/ the header files, which >>> is an error-prone process, especially for function-like macros and >>> C++, as you tell me those are still goals. It doesn't make sense to >>> want to parse random files when it's possible to specify manually >>> but more easily everything in the target language. It just >>> complicates things! (BTW, Go or Swift don't do function-like macros >>> or C++ so they can afford to tell everyone to just parse >>> everything). If jextract could have 2 mode of operations, one where >>> it parses the header files, and another one, where it can generate >>> the annotations at runtime, that's fine, but that's not how it works >>> currently. (Which reminds me, we can probably do all that stuff at >>> build time the way Lombok does it: https://projectlombok.org/ ) >>> >>> This is especially relevant for C++ template libraries like Boost, >>> Eigen, Ceres Solver, or Thrust. Just writing out the few >>> declarations manually is often easier than figuring out whatever >>> hacks we can come up to specify some types and how to map them, for >>> example: >>> https://github.com/bytedeco/javacpp/wiki/Interface-Thrust-and-CUDA >>> >>> This really depends on the priorities of the project though. I >>> really think Panama should concentrate on getting things like >>> linkToNative ready in the JDK and leave things like jextract and >>> Lombok-like functionality to others because we can do it outside the >>> JDK, but that's just my opinion. >>> >>> Samuel >>> >>> On 10/18/2018 11:45 PM, Maurizio Cimadamore wrote: >>>> Hi Samuel, >>>> I'm really confused here; if the various annotated >>>> interfaces/artifacts are generated in a jar bundle by jextract, >>>> what is the problem with layout annotations? It's not like the user >>>> will see them? >>>> >>>> So, if you are concerned about usabilty (e.g. what the client see, >>>> as in your 'main' method) using a different kind of annotation >>>> won't change anything. >>>> >>>> If you are concerned with the (one time) runtime cost to parse the >>>> layout annotations, we have already covered how the best way to >>>> address that concern is by running jextract as a jlink at module >>>> install time (as we do for other similar tasks in the JDK build >>>> itself). That will create binding implementations for all the >>>> required interfaces _statically_ which should help with startup. >>>> >>>> Maurizio >>>> >>>> On 17/10/2018 19:02, Samuel Audet wrote: >>>>> And while we're at it, I think the runtime component could also >>>>> take care of abstracting away the details of the layouts, so >>>>> gettimeofday() could look something like this, again without >>>>> having to parse anything for simple cases: >>>>> >>>>> @Struct >>>>> interface Timeval { >>>>> @SizeT long tv_sec(); >>>>> Timeval tv_sec(long tv_sec); >>>>> >>>>> long tv_usec(); >>>>> Timeval tv_usec(long tv_usec); >>>>> } >>>>> >>>>> interface Dummy { >>>>> int gettimeofday(Timeval tv, Pointer timezone); >>>>> } >>>>> >>>>> import static Dummy.*; >>>>> >>>>> public static void main(String[] args) { >>>>> InitMagicBindings(Dummy.class, Timeval.class); >>>>> Timeval t = Timeval.create() >>>>> gettimeofday(t, null); >>>>> } >>>>> } >>>>> >>>>> Now that would be awesome :) >>>>> >>>>> Samuel >>>>> >>>>> On 10/18/2018 09:16 AM, Samuel Audet wrote: >>>>>> That looks good, thanks Sundar! Though, eventually, it would be >>>>>> great to have those generated at runtime somehow, so that we >>>>>> don't need to start parsing stuff when we just need to call >>>>>> single functions, like we can do with JNA or JavaCPP, for example: >>>>>> https://gist.github.com/saudet/1bf14a000e64c245675cf5d4e9ad6e69#file-nativebenchmark-java >>>>>> >>>>>> >>>>>> Samuel >>>>>> >>>>>> On 10/18/2018 02:35 AM, Sundararajan Athijegannathan wrote: >>>>>>> Updated: >>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.02/index.html >>>>>>> >>>>>>> Added --static-forwarder boolean option (default true) >>>>>>> >>>>>>> -Sundar >>>>>>> >>>>>>> On 17/10/18, 9:55 PM, Sundararajan Athijegannathan wrote: >>>>>>>> >>>>>>>> comments below.. >>>>>>>> >>>>>>>> On 17/10/18, 9:13 PM, Jorn Vernee wrote: >>>>>>>>> Sundararajan Athijegannathan schreef op 2018-10-17 14:37: >>>>>>>>>> On option: do we need an explicit option? given that one file >>>>>>>>>> extra >>>>>>>>>> and that too only when -l is specified. (too many options >>>>>>>>>> already? ;) >>>>>>>>>> ) >>>>>>>>> >>>>>>>>> Maybe having an option is nice, but have it be turned on by >>>>>>>>> default? That way if someone really wanted to not generate the >>>>>>>>> forwarder they could, and for the general use case they don't >>>>>>>>> have to bother with setting an option every time. >>>>>>>>> >>>>>>>> okay. >>>>>>>> >>>>>>>>>> On naming: we've derived automatic names elsewhere. I think >>>>>>>>>> we could >>>>>>>>>> revisit all naming options by another round - perhaps even java >>>>>>>>>> convention for header interface name. >>>>>>>>>> >>>>>>>>>> On subclassing: Nice suggestion. I made it as >>>>>>>>>> AsmCodeFactoryExt class >>>>>>>>>> and extended it from AsmCodeFactory. visit methods now return >>>>>>>>>> Boolean >>>>>>>>>> to tell if the particular tree was handled or not. This is >>>>>>>>>> needed so >>>>>>>>>> that subclass can avoid the same tree if super class avoided >>>>>>>>>> it (for >>>>>>>>>> eg. function-like macros, repeated definitions..) >>>>>>>>> >>>>>>>>> I'm wondering if this runs into trouble later on when adding >>>>>>>>> more code generation extensions/options. Let's say you add >>>>>>>>> `foo` and `bar` options later on. You'd have to make an >>>>>>>>> extension subclass for every combination of options >>>>>>>>> (StaticFooBar, StaticFoo, StaticBar, FooBar, Static, Foo, Bar). >>>>>>>>> >>>>>>>>> Maybe you could have something like a `CodeFactory`, which >>>>>>>>> consists of an `AsmCodeFactory` and a list of >>>>>>>>> `CodeFactoryExt`, of which the static forwarder generator >>>>>>>>> would be one. And have this kind of pattern: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> @Override >>>>>>>>> public Void visitVar(VarTree varTree, JType jt) { >>>>>>>>> if(asmCodeFactory.visitVar(varTree, jt)) { >>>>>>>>> for(CodeFactoryExt cfe : extensions) { >>>>>>>>> cfe.visitVar(varTree, jt); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> return null; >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> I think that also allows you to get rid of the if/else >>>>>>>>> statements in the extension class. >>>>>>>>> >>>>>>>>> It's not really needed right now since there is only 1 >>>>>>>>> extension, but it might be nice idea for the future. >>>>>>>> >>>>>>>> Right. We don't want to go there yet - but yes, if we happened >>>>>>>> to add one more, we can revisit & refactor the code. >>>>>>>> >>>>>>>> -Sundar >>>>>>>>> >>>>>>>>> Jorn >>>>>>>>> >>>>>>>>>> Updated: >>>>>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.01/index.html >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> -Sundar >>>>>>>>>> >>>>>>>>>> On 17/10/18, 3:25 PM, Maurizio Cimadamore wrote: >>>>>>>>>>> I like it! Few questions/comments: >>>>>>>>>>> >>>>>>>>>>> * should it be enabled/disabled with explicit option >>>>>>>>>>> * should the name of the statics class be customizable >>>>>>>>>>> * I like the code organization - have you thought of pushing >>>>>>>>>>> it further and make StaticForwarderGenerator a _subclass_ of >>>>>>>>>>> AsmCodeFactory - each visitor could maybe delegate to >>>>>>>>>>> super.visitXyz() first and then do its own bit? Then when >>>>>>>>>>> you setup the pipeline, depending on what info is available >>>>>>>>>>> on the context (e.g. presence of -l) you can decide whether >>>>>>>>>>> to use a 'bare' ASMCodeFactory or the 'embellished' one. >>>>>>>>>>> That should remove all the 'if staticFwd != null ...' >>>>>>>>>>> sections from AsmCodeFactory. >>>>>>>>>>> >>>>>>>>>>> Maurizio >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 17/10/2018 06:35, Sundararajan Athijegannathan wrote: >>>>>>>>>>>> Please review. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212560 >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sundar/8212560/webrev.00/index.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> -Sundar >>>>>> >>>>> >>> > From Yang.Zhang at arm.com Tue Oct 23 01:40:23 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Tue, 23 Oct 2018 01:40:23 +0000 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Message-ID: Hi, I'm working on supporting vector api for aarch64 NEON. I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ Regards, Yang From Yang.Zhang at arm.com Tue Oct 23 01:57:01 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Tue, 23 Oct 2018 01:57:01 +0000 Subject: [vector api] RFC: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: Message-ID: Hi I have updated the subject of this thread to RFR. Please check the new thread: http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002975.html Regards Yang -----Original Message----- From: panama-dev On Behalf Of Yang Zhang (Arm Technology China) Sent: Thursday, October 18, 2018 6:08 PM To: panama-dev at openjdk.java.net Cc: nd Subject: [vector api] RFC: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Hi, I'm working on supporting vector api for aarch64 NEON. I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ Could you please help to review this? Regards, Yang From jean-philippe.halimi at intel.com Tue Oct 23 20:51:25 2018 From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe) Date: Tue, 23 Oct 2018 20:51:25 +0000 Subject: SVML on Windows Overhead Message-ID: Dear all, Following our earlier discussion in the past week, I have spent some time evaluating the memory overhead of SVML assembly routines on Windows. It looks like it generates a 6.84% overhead on JVM.dll. Here are the details: Jvm.dll size: With SVML: 13,363,200 bytes Without SVML: 12,508,160 bytes Will this be considered as a blocker for the merging of VectorAPI in the main branch? Thanks, Jp From maurizio.cimadamore at oracle.com Wed Oct 24 04:40:37 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 23 Oct 2018 21:40:37 -0700 Subject: Panama/foreign binaries are now live! Message-ID: <61616fa3-4bcf-2b47-7ebc-a37dbaf5df58@oracle.com> Dear fellow citizens of the Isthmus, it's with great pleasure that we'd like to announce the public availability of the Panama/foreign early access binaries: http://jdk.java.net/panama/ For me personally, it's been a great ride since I started working on this project almost an year ago, and I'd like to thank everybody on the Panama team for their dedication and effort that was instrumental in getting us where we are today. But an even bigger thanks goes to everybody who joined along for the ride on panama-dev: your ideas, suggestions and comments are the very essence of what drives us towards better products. Please keep the flow coming! Now, let's roll up our sleeves and get ready to hack some more ;-) Cheers Maurizio From michel.trudeau at oracle.com Wed Oct 24 05:26:10 2018 From: michel.trudeau at oracle.com (Michel Trudeau) Date: Tue, 23 Oct 2018 22:26:10 -0700 Subject: Panama/foreign binaries are now live! In-Reply-To: <61616fa3-4bcf-2b47-7ebc-a37dbaf5df58@oracle.com> References: <61616fa3-4bcf-2b47-7ebc-a37dbaf5df58@oracle.com> Message-ID: <23D79FD2-D72B-4F53-9344-ED649B379F12@oracle.com> I second everything that Maurizio said. Congratulations to the team and the panama community!!! This is a great milestone. -Michel On Oct 23, 2018, at 9:40 PM, Maurizio Cimadamore wrote: Dear fellow citizens of the Isthmus, it's with great pleasure that we'd like to announce the public availability of the Panama/foreign early access binaries: http://jdk.java.net/panama/ For me personally, it's been a great ride since I started working on this project almost an year ago, and I'd like to thank everybody on the Panama team for their dedication and effort that was instrumental in getting us where we are today. But an even bigger thanks goes to everybody who joined along for the ride on panama-dev: your ideas, suggestions and comments are the very essence of what drives us towards better products. Please keep the flow coming! Now, let's roll up our sleeves and get ready to hack some more ;-) Cheers Maurizio From sundararajan.athijegannathan at oracle.com Wed Oct 24 09:50:22 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 24 Oct 2018 09:50:22 +0000 Subject: hg: panama/dev: adding doc/panama_foreign.md Message-ID: <201810240950.w9O9oNW7021735@aojmv0008.oracle.com> Changeset: a0412c403700 Author: sundar Date: 2018-10-24 15:30 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/a0412c403700 adding doc/panama_foreign.md + doc/panama_foreign.html + doc/panama_foreign.md From sundararajan.athijegannathan at oracle.com Wed Oct 24 12:06:43 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 24 Oct 2018 12:06:43 +0000 Subject: hg: panama/dev: added readline example to doc/panama_foreign.md Message-ID: <201810241206.w9OC6i5s022232@aojmv0008.oracle.com> Changeset: 0490078d3641 Author: sundar Date: 2018-10-24 17:47 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/0490078d3641 added readline example to doc/panama_foreign.md ! doc/panama_foreign.html ! doc/panama_foreign.md From sundararajan.athijegannathan at oracle.com Wed Oct 24 12:28:25 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 24 Oct 2018 12:28:25 +0000 Subject: hg: panama/dev: added getpid Linux sample to doc/panama_foreign.md Message-ID: <201810241228.w9OCSPGg004528@aojmv0008.oracle.com> Changeset: 6fcf80812a4e Author: sundar Date: 2018-10-24 05:12 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/6fcf80812a4e added getpid Linux sample to doc/panama_foreign.md ! doc/panama_foreign.md From sundararajan.athijegannathan at oracle.com Wed Oct 24 12:31:37 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 24 Oct 2018 12:31:37 +0000 Subject: hg: panama/dev: regenerated doc/panama_foreign.html Message-ID: <201810241231.w9OCVbHT005352@aojmv0008.oracle.com> Changeset: edbd76da626c Author: sundar Date: 2018-10-24 18:12 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/edbd76da626c regenerated doc/panama_foreign.html ! doc/panama_foreign.html From jbvernee at xs4all.nl Wed Oct 24 14:43:36 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Wed, 24 Oct 2018 16:43:36 +0200 Subject: [foreign] RFR 8212920 : Tweak StructByValueTest to verify for by-value semantics. Message-ID: <83412803b616dfdad60fdbc2b793a9a6@xs4all.nl> Hello, I'd like to contribute a patch that tweaks StructByValueTest to verify that by-value semantics are being followed. It turns out that this wasn't the case, and a bug snuck into my windows binder changes like that. I'm also doing this to test out the workflow now that I'm an author, so any comments in that field (e.g. about the JBS bug I've made) are welcome as well :) As a reminder, I'm not a committer, so someone else will have to push this. Bug : https://bugs.openjdk.java.net/browse/JDK-8212920 Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212920/webrev.00/ Thanks, Jorn From henry.jen at oracle.com Wed Oct 24 16:47:10 2018 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 24 Oct 2018 09:47:10 -0700 Subject: [foreign] RFR 8212920 : Tweak StructByValueTest to verify for by-value semantics. In-Reply-To: <83412803b616dfdad60fdbc2b793a9a6@xs4all.nl> References: <83412803b616dfdad60fdbc2b793a9a6@xs4all.nl> Message-ID: <3DEC5E1B-B464-4069-8ECF-E01E3F70099F@oracle.com> Looks good. I?ll push it. Cheers, Henry > On Oct 24, 2018, at 7:43 AM, Jorn Vernee wrote: > > Hello, > > I'd like to contribute a patch that tweaks StructByValueTest to verify that by-value semantics are being followed. It turns out that this wasn't the case, and a bug snuck into my windows binder changes like that. > > I'm also doing this to test out the workflow now that I'm an author, so any comments in that field (e.g. about the JBS bug I've made) are welcome as well :) > > As a reminder, I'm not a committer, so someone else will have to push this. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8212920 > Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212920/webrev.00/ > > Thanks, > Jorn From jbvernee at xs4all.nl Wed Oct 24 17:32:11 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Wed, 24 Oct 2018 19:32:11 +0200 Subject: [foreign] RFR 8212920 : Tweak StructByValueTest to verify for by-value semantics. In-Reply-To: <3DEC5E1B-B464-4069-8ECF-E01E3F70099F@oracle.com> References: <83412803b616dfdad60fdbc2b793a9a6@xs4all.nl> <3DEC5E1B-B464-4069-8ECF-E01E3F70099F@oracle.com> Message-ID: <374231aa045732cc01fe80a3f6fdc1a8@xs4all.nl> Thanks Henry! I'll mark the bug as resolved when I see the automated hg email then. Jorn Henry Jen schreef op 2018-10-24 18:47: > Looks good. I?ll push it. > > Cheers, > Henry > > >> On Oct 24, 2018, at 7:43 AM, Jorn Vernee wrote: >> >> Hello, >> >> I'd like to contribute a patch that tweaks StructByValueTest to verify >> that by-value semantics are being followed. It turns out that this >> wasn't the case, and a bug snuck into my windows binder changes like >> that. >> >> I'm also doing this to test out the workflow now that I'm an author, >> so any comments in that field (e.g. about the JBS bug I've made) are >> welcome as well :) >> >> As a reminder, I'm not a committer, so someone else will have to push >> this. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8212920 >> Webrev : >> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212920/webrev.00/ >> >> Thanks, >> Jorn From henry.jen at oracle.com Wed Oct 24 17:37:55 2018 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Wed, 24 Oct 2018 17:37:55 +0000 Subject: hg: panama/dev: 8212920: Tweak StructByValueTest to verify for by-value semantics Message-ID: <201810241737.w9OHbu6Q001514@aojmv0008.oracle.com> Changeset: 4b634b7d0cdb Author: henryjen Date: 2018-10-24 10:36 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/4b634b7d0cdb 8212920: Tweak StructByValueTest to verify for by-value semantics Reviewed-by: henryjen Contributed-by: Jorn Vernee ! test/jdk/java/foreign/StructByValueTest.java ! test/jdk/java/foreign/libstructbyvalue.c From vladimir.x.ivanov at oracle.com Wed Oct 24 18:20:29 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 24 Oct 2018 11:20:29 -0700 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: Message-ID: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: > Hi, > > I'm working on supporting vector api for aarch64 NEON. > I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? > > Webrev: > http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ src/hotspot/share/opto/library_call.cpp: +#ifdef X86 int bits = num_elem * BitsPerByte * type2aelembytes(bt); if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { return NULL; } +#endif That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. So far, platform-specific logic is hidden behind Matcher. Jp, I see you added the problematic code [1]. Please, fix it. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 From vladimir.x.ivanov at oracle.com Wed Oct 24 18:27:34 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 24 Oct 2018 11:27:34 -0700 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: Message-ID: Thanks for the clarifications, Alejandro. > The scalable shape is just a convenient way to avoid having to code the 16 vector lengths that SVE supports. We should always return a concrete VL shape if the maximum VL happens to be 128, 256 or 512 (which honestly, should be 99% of the time). Sounds good. > If this is going to be a contentious issue, I think we might as well bite the bullet and write the 16 versions, which are going to be almost identical. They could even be some thin layers over the current scalable vector class. Agreed, but I'd like to avoid that :-) So far, I don't see a compelling reason to introduce them. Best regards, Vladimir Ivanov From jean-philippe.halimi at intel.com Wed Oct 24 18:33:23 2018 From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe) Date: Wed, 24 Oct 2018 18:33:23 +0000 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> Message-ID: Working on it now. Apologies for the inconvenience. Jp -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Wednesday, October 24, 2018 11:20 AM To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe Cc: nd Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: > Hi, > > I'm working on supporting vector api for aarch64 NEON. > I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? > > Webrev: > http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ src/hotspot/share/opto/library_call.cpp: +#ifdef X86 int bits = num_elem * BitsPerByte * type2aelembytes(bt); if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { return NULL; } +#endif That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. So far, platform-specific logic is hidden behind Matcher. Jp, I see you added the problematic code [1]. Please, fix it. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 From jean-philippe.halimi at intel.com Wed Oct 24 18:57:19 2018 From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe) Date: Wed, 24 Oct 2018 18:57:19 +0000 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> Message-ID: Hi, Please review the following webrev. It should fix the problem. http://cr.openjdk.java.net/~jphalimi/webrev_x86_check_fix/webrev/ Jp -----Original Message----- From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Halimi, Jean-Philippe Sent: Wednesday, October 24, 2018 11:33 AM To: Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Working on it now. Apologies for the inconvenience. Jp -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Wednesday, October 24, 2018 11:20 AM To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe Cc: nd Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: > Hi, > > I'm working on supporting vector api for aarch64 NEON. > I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? > > Webrev: > http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ src/hotspot/share/opto/library_call.cpp: +#ifdef X86 int bits = num_elem * BitsPerByte * type2aelembytes(bt); if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { return NULL; } +#endif That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. So far, platform-specific logic is hidden behind Matcher. Jp, I see you added the problematic code [1]. Please, fix it. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 From vladimir.x.ivanov at oracle.com Wed Oct 24 21:42:26 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 24 Oct 2018 14:42:26 -0700 Subject: SVML on Windows Overhead In-Reply-To: References: Message-ID: <5da5f033-bc0c-1c6c-0f47-936dfa7886c7@oracle.com> Thanks for the data, Jp. I checked Linux and the increase is roughly the same (~850K) in absolute numbers [1]. Also, vectorIntrinsics changes contribute ~4M in total, so ~20-25% is attributed to SVML. Static footprint alone doesn't look like a blocker to me, but it definitely falls into the category of negative effects, especially for an incubating module. Best regards, Vladimir Ivanov [1] libjvm.so default branch: 22384560 vectorIntrinsic - svml: 25635648 vectorIntrinsic + svml: 26483016 On 23/10/2018 13:51, Halimi, Jean-Philippe wrote: > Dear all, > > Following our earlier discussion in the past week, I have spent some time evaluating the memory overhead of SVML assembly routines on Windows. It looks like it generates a 6.84% overhead on JVM.dll. Here are the details: > > Jvm.dll size: > With SVML: 13,363,200 bytes > Without SVML: 12,508,160 bytes > > Will this be considered as a blocker for the merging of VectorAPI in the main branch? > > Thanks, > Jp > From Yang.Zhang at arm.com Thu Oct 25 05:29:59 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Thu, 25 Oct 2018 05:29:59 +0000 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> Message-ID: Hi Jp When you patch is merged, I will update my patch based on yours. Regards Yang -----Original Message----- From: Halimi, Jean-Philippe Sent: Thursday, October 25, 2018 2:57 AM To: Halimi, Jean-Philippe ; Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Hi, Please review the following webrev. It should fix the problem. http://cr.openjdk.java.net/~jphalimi/webrev_x86_check_fix/webrev/ Jp -----Original Message----- From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Halimi, Jean-Philippe Sent: Wednesday, October 24, 2018 11:33 AM To: Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Working on it now. Apologies for the inconvenience. Jp -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Wednesday, October 24, 2018 11:20 AM To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe Cc: nd Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: > Hi, > > I'm working on supporting vector api for aarch64 NEON. > I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? > > Webrev: > http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ src/hotspot/share/opto/library_call.cpp: +#ifdef X86 int bits = num_elem * BitsPerByte * type2aelembytes(bt); if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { return NULL; } +#endif That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. So far, platform-specific logic is hidden behind Matcher. Jp, I see you added the problematic code [1]. Please, fix it. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 From jbvernee at xs4all.nl Thu Oct 25 11:02:48 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Thu, 25 Oct 2018 13:02:48 +0200 Subject: [foreign] Handling pointers with special (negative) values Message-ID: <39ccb2b7dc6608776f22431636b5f544@xs4all.nl> Hello, I was in the process of adding a windows equivalent for the getpid test. The windows equivalent calls GetCurrentProcess [1] to get a handle to the current process, and then calls GetProcessId [2] using that handle. The problem is that the returned handle for the current process has a special value, which after converting to a Java long shows up as -1. It's type is `void *` ([3] see `HANDLE`). The constructor of BoundedMemoryRegion checks to make sure that the base (i.e. `min`) is not smaller than 0, but in this case it is, so an IAE is thrown [4]. I have simply removed the check on `min` and all tests that I'm running currently are still passing, but I don't think this is a definitive solution. I wanted to bring this up to discuss how we should handle pointers with special (negative) values, or pointers that otherwise end up negative after converting to a Java long. Perhaps there was some earlier discussion about this that I missed? Jorn [1] : https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-getcurrentprocess [2] : https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-getprocessid [3] : https://docs.microsoft.com/en-us/windows/desktop/winprog/windows-data-types [4] : http://hg.openjdk.java.net/panama/dev/file/4b634b7d0cdb/src/java.base/share/classes/jdk/internal/foreign/memory/BoundedMemoryRegion.java#l74 From fweimer at redhat.com Thu Oct 25 11:06:51 2018 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 25 Oct 2018 13:06:51 +0200 Subject: [foreign] Handling pointers with special (negative) values In-Reply-To: <39ccb2b7dc6608776f22431636b5f544@xs4all.nl> (Jorn Vernee's message of "Thu, 25 Oct 2018 13:02:48 +0200") References: <39ccb2b7dc6608776f22431636b5f544@xs4all.nl> Message-ID: <87woq6l1ys.fsf@oldenburg.str.redhat.com> * Jorn Vernee: > The constructor of BoundedMemoryRegion checks to make sure that the > base (i.e. `min`) is not smaller than 0, but in this case it is, so an > IAE is thrown [4]. Isn't the check simply incorrect? I was under the impression that Solaris has userspace pointers in the upper region of the address space on x86-64 (i.e, where the 17 or so most significant bits are set). Thanks, Florian From jbvernee at xs4all.nl Thu Oct 25 11:27:48 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Thu, 25 Oct 2018 13:27:48 +0200 Subject: [foreign] Handling pointers with special (negative) values In-Reply-To: <87woq6l1ys.fsf@oldenburg.str.redhat.com> References: <39ccb2b7dc6608776f22431636b5f544@xs4all.nl> <87woq6l1ys.fsf@oldenburg.str.redhat.com> Message-ID: Florian Weimer schreef op 2018-10-25 13:06: > Isn't the check simply incorrect? I was under the impression that > Solaris has userspace pointers in the upper region of the address space > on x86-64 (i.e, where the 17 or so most significant bits are set). I think it is incorrect, but I'm not sure how to proceed. We use `long` to model pointers everywhere, but as far as I can tell the size of a pointer is an implementation detail, and all the C standard says about them is that the size must be sufficient to cover anything you might want to get a pointer to. The value is used in several places to calculate a memory offset to pass to `Unsafe` routines. I'm not sure if removing the check will break anything, it's hard to test on my machine (Windows) since I'm not running all the tests currently, and it's hard to check manually since afaik you can't just ask the OS for a dereferenceable pointer with it's high-order bit set. Jorn > Thanks, > Florian From maurizio.cimadamore at oracle.com Thu Oct 25 16:03:27 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 25 Oct 2018 09:03:27 -0700 Subject: [foreign] Handling pointers with special (negative) values In-Reply-To: References: <39ccb2b7dc6608776f22431636b5f544@xs4all.nl> <87woq6l1ys.fsf@oldenburg.str.redhat.com> Message-ID: All good points raised here. I think I'm with Florian: the check is incorrect, or at least partially so. Let me explain what I mean by that; Unsafe uses two different kind of addressing mode, as documented here: http://hg.openjdk.java.net/jdk/jdk/file/9c260a6b6471/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#l129 If the 'base' object is set, then the long becomes a (positive) offset. But if there's no 'base' object, then the long argument is simply an absolute address, which can be anything. So, I think it could be fine to enforce that the offset is positive, but only if the underlying memory region has a non-null base. Thoughts? Maurizio On 25/10/2018 04:27, Jorn Vernee wrote: > Florian Weimer schreef op 2018-10-25 13:06: >> Isn't the check simply incorrect?? I was under the impression that >> Solaris has userspace pointers in the upper region of the address space >> on x86-64 (i.e, where the 17 or so most significant bits are set). > > I think it is incorrect, but I'm not sure how to proceed. We use > `long` to model pointers everywhere, but as far as I can tell the size > of a pointer is an implementation detail, and all the C standard says > about them is that the size must be sufficient to cover anything you > might want to get a pointer to. > > The value is used in several places to calculate a memory offset to > pass to `Unsafe` routines. I'm not sure if removing the check will > break anything, it's hard to test on my machine (Windows) since I'm > not running all the tests currently, and it's hard to check manually > since afaik you can't just ask the OS for a dereferenceable pointer > with it's high-order bit set. > > Jorn > >> Thanks, >> Florian From jbvernee at xs4all.nl Thu Oct 25 17:15:41 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Thu, 25 Oct 2018 19:15:41 +0200 Subject: [foreign] Handling pointers with special (negative) values In-Reply-To: References: <39ccb2b7dc6608776f22431636b5f544@xs4all.nl> <87woq6l1ys.fsf@oldenburg.str.redhat.com> Message-ID: <1d6e9252585c8056f2f96af4fbbb210f@xs4all.nl> Maurizio Cimadamore schreef op 2018-10-25 18:03: > All good points raised here. > > I think I'm with Florian: the check is incorrect, or at least > partially so. Let me explain what I mean by that; Unsafe uses two > different kind of addressing mode, as documented here: > > http://hg.openjdk.java.net/jdk/jdk/file/9c260a6b6471/src/java.base/share/classes/jdk/internal/misc/Unsafe.java#l129 > > If the 'base' object is set, then the long becomes a (positive) > offset. But if there's no 'base' object, then the long argument is > simply an absolute address, which can be anything. > > So, I think it could be fine to enforce that the offset is positive, > but only if the underlying memory region has a non-null base. > > Thoughts? I wonder if the check is needed for either. The current implementation seems to just add the resolved oop to the offset and cast it to an address [1]. But if those are the expected semantics for Unsafe I think we should go with your solution. I worry about things like Pointer::addr reporting negative values in some cases, and maybe we will have to allow negative values for offset and length in the future, but I guess we can cross that bridge when we get to it. Either way, I have filed a bug for this: https://bugs.openjdk.java.net/browse/JDK-8212987 I could submit an RFR later if there are no further comments. Thanks, Jorn [1] : http://hg.openjdk.java.net/panama/dev/file/4b634b7d0cdb/src/hotspot/share/prims/unsafe.cpp#l122 From jean-philippe.halimi at intel.com Thu Oct 25 18:29:41 2018 From: jean-philippe.halimi at intel.com (jean-philippe.halimi at intel.com) Date: Thu, 25 Oct 2018 18:29:41 +0000 Subject: hg: panama/dev: Move x86 check in x86 Matcher. Message-ID: <201810251829.w9PITgLR027185@aojmv0008.oracle.com> Changeset: 1d68a55a86fa Author: jphalimi Date: 2018-10-24 11:50 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1d68a55a86fa Move x86 check in x86 Matcher. ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/opto/library_call.cpp From maurizio.cimadamore at oracle.com Thu Oct 25 18:32:26 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 25 Oct 2018 18:32:26 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810251832.w9PIWRhH028318@aojmv0008.oracle.com> Changeset: c519e9b3591a Author: mcimadamore Date: 2018-10-25 20:34 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c519e9b3591a Automatic merge with vectorIntrinsics From jean-philippe.halimi at intel.com Thu Oct 25 18:42:27 2018 From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe) Date: Thu, 25 Oct 2018 18:42:27 +0000 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> Message-ID: Hi Yang, I have just merged the patch. Can you please confirm that it works on your side? Jp -----Original Message----- From: Yang Zhang (Arm Technology China) [mailto:Yang.Zhang at arm.com] Sent: Wednesday, October 24, 2018 10:30 PM To: Halimi, Jean-Philippe ; Vladimir Ivanov ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Hi Jp When you patch is merged, I will update my patch based on yours. Regards Yang -----Original Message----- From: Halimi, Jean-Philippe Sent: Thursday, October 25, 2018 2:57 AM To: Halimi, Jean-Philippe ; Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Hi, Please review the following webrev. It should fix the problem. http://cr.openjdk.java.net/~jphalimi/webrev_x86_check_fix/webrev/ Jp -----Original Message----- From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Halimi, Jean-Philippe Sent: Wednesday, October 24, 2018 11:33 AM To: Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Working on it now. Apologies for the inconvenience. Jp -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Wednesday, October 24, 2018 11:20 AM To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe Cc: nd Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: > Hi, > > I'm working on supporting vector api for aarch64 NEON. > I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? > > Webrev: > http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ src/hotspot/share/opto/library_call.cpp: +#ifdef X86 int bits = num_elem * BitsPerByte * type2aelembytes(bt); if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { return NULL; } +#endif That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. So far, platform-specific logic is hidden behind Matcher. Jp, I see you added the problematic code [1]. Please, fix it. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 From jean-philippe.halimi at intel.com Thu Oct 25 22:40:56 2018 From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe) Date: Thu, 25 Oct 2018 22:40:56 +0000 Subject: VectorAPI SVML crashes on Windows fixed Message-ID: Dear all, I would like to merge a patch fixing compiler crashes on Windows for SVML assembly routines in VectorAPI. Could you please spend some time and let me know your thoughts. http://cr.openjdk.java.net/~jphalimi/webrev_svml_fixes_windows/webrev/ Thank you, Jp From henry.jen at oracle.com Fri Oct 26 04:44:56 2018 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 25 Oct 2018 21:44:56 -0700 Subject: RFR: [panama foreign] Build tweak to enable build on Windows Message-ID: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> Hi, Please review a web rev[1] that address following, 1. Copy the essential share library as recorded by the linker following the symbolic link of libclang.so for unix/mac. This leads to only one copy of share library instead of a duplicate copy of libclang.so. It would be nice to have create libclang as a symbolic link, but it?s not needed now. This issue is what failed the build when using system provided libclang on some systems such as Debian-based Linux distribution. After this patch, Debian-based system can be build as described in README.foreign. 2. Enable build on Windows. This patch allow build image to be completed successfully and libclang.dll copied to bin as expected. However, this doesn?t mean binder is working on Windows, it?s simply get the build going and jextract should be functional. Some test still have compiling errors to be fixed, and we don?t have Windows ABI. It?s the first step to allow build on Windows. I believe a lot of this had been addressed by Jorn, and he actually have made more progress on Windows support. Hopefully this is just the first step and get Windows going. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev From sundararajan.athijegannathan at oracle.com Fri Oct 26 06:10:20 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 26 Oct 2018 06:10:20 +0000 Subject: hg: panama/dev: Adding OpenBLAS jextract command, sample code for Mac OS. Message-ID: <201810260610.w9Q6ALst002498@aojmv0008.oracle.com> Changeset: 4aab9cac5115 Author: sundar Date: 2018-10-26 11:50 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/4aab9cac5115 Adding OpenBLAS jextract command, sample code for Mac OS. ! doc/panama_foreign.html ! doc/panama_foreign.md From Yang.Zhang at arm.com Fri Oct 26 06:36:36 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Fri, 26 Oct 2018 06:36:36 +0000 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> Message-ID: Hi Jp I rebase my patch and it works well. Hi Vladimir Could you please help to review my new patch? http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.01/ Regards Yang -----Original Message----- From: Halimi, Jean-Philippe Sent: Friday, October 26, 2018 2:42 AM To: Yang Zhang (Arm Technology China) ; Vladimir Ivanov ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Hi Yang, I have just merged the patch. Can you please confirm that it works on your side? Jp -----Original Message----- From: Yang Zhang (Arm Technology China) [mailto:Yang.Zhang at arm.com] Sent: Wednesday, October 24, 2018 10:30 PM To: Halimi, Jean-Philippe ; Vladimir Ivanov ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Hi Jp When you patch is merged, I will update my patch based on yours. Regards Yang -----Original Message----- From: Halimi, Jean-Philippe Sent: Thursday, October 25, 2018 2:57 AM To: Halimi, Jean-Philippe ; Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Hi, Please review the following webrev. It should fix the problem. http://cr.openjdk.java.net/~jphalimi/webrev_x86_check_fix/webrev/ Jp -----Original Message----- From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Halimi, Jean-Philippe Sent: Wednesday, October 24, 2018 11:33 AM To: Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Working on it now. Apologies for the inconvenience. Jp -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Wednesday, October 24, 2018 11:20 AM To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe Cc: nd Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: > Hi, > > I'm working on supporting vector api for aarch64 NEON. > I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? > > Webrev: > http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ src/hotspot/share/opto/library_call.cpp: +#ifdef X86 int bits = num_elem * BitsPerByte * type2aelembytes(bt); if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { return NULL; } +#endif That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. So far, platform-specific logic is hidden behind Matcher. Jp, I see you added the problematic code [1]. Please, fix it. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 From vladimir.x.ivanov at oracle.com Fri Oct 26 06:58:49 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 25 Oct 2018 23:58:49 -0700 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> Message-ID: <35b89b9f-1395-0c0d-6315-9b87fab458fd@oracle.com> > http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.01/ Looks good. I'll push it once Jp's fix lands in the repo. Best regards, Vladimir Ivanov > -----Original Message----- > From: Halimi, Jean-Philippe > Sent: Friday, October 26, 2018 2:42 AM > To: Yang Zhang (Arm Technology China) ; Vladimir Ivanov ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > Hi Yang, > > I have just merged the patch. Can you please confirm that it works on your side? > > Jp > > -----Original Message----- > From: Yang Zhang (Arm Technology China) [mailto:Yang.Zhang at arm.com] > Sent: Wednesday, October 24, 2018 10:30 PM > To: Halimi, Jean-Philippe ; Vladimir Ivanov ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > Hi Jp > > When you patch is merged, I will update my patch based on yours. > > Regards > Yang > > -----Original Message----- > From: Halimi, Jean-Philippe > Sent: Thursday, October 25, 2018 2:57 AM > To: Halimi, Jean-Philippe ; Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > Hi, > > Please review the following webrev. It should fix the problem. > http://cr.openjdk.java.net/~jphalimi/webrev_x86_check_fix/webrev/ > > Jp > > -----Original Message----- > From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Halimi, Jean-Philippe > Sent: Wednesday, October 24, 2018 11:33 AM > To: Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > Working on it now. Apologies for the inconvenience. > > Jp > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Wednesday, October 24, 2018 11:20 AM > To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe > Cc: nd > Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > > > On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: >> Hi, >> >> I'm working on supporting vector api for aarch64 NEON. >> I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? >> >> Webrev: >> http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ > > src/hotspot/share/opto/library_call.cpp: > +#ifdef X86 > int bits = num_elem * BitsPerByte * type2aelembytes(bt); > if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { > return NULL; > } > +#endif > > That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. > > So far, platform-specific logic is hidden behind Matcher. > > Jp, I see you added the problematic code [1]. Please, fix it. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 > From erik.joelsson at oracle.com Fri Oct 26 16:05:44 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Oct 2018 09:05:44 -0700 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> Message-ID: <1f61d3de-43f1-6fa3-57a1-5f607acaf4a4@oracle.com> Hello Henry, lib-clang.mr4: I think you need to restore CXX and CXXCPP after the tests. Otherwise they will show up with double fixpath in spec.gmk. I think the TOOLCHAIN_TYPE != microsoft "if" blocks should be inverted and flipped for easier reading. Otherwise I think this looks ok. /Erik On 2018-10-25 21:44, Henry Jen wrote: > Hi, > > Please review a web rev[1] that address following, > > 1. Copy the essential share library as recorded by the linker following the symbolic link of libclang.so for unix/mac. This leads to only one copy of share library instead of a duplicate copy of libclang.so. It would be nice to have create libclang as a symbolic link, but it?s not needed now. > > This issue is what failed the build when using system provided libclang on some systems such as Debian-based Linux distribution. After this patch, Debian-based system can be build as described in README.foreign. > > 2. Enable build on Windows. This patch allow build image to be completed successfully and libclang.dll copied to bin as expected. > > However, this doesn?t mean binder is working on Windows, it?s simply get the build going and jextract should be functional. Some test still have compiling errors to be fixed, and we don?t have Windows ABI. It?s the first step to allow build on Windows. > > I believe a lot of this had been addressed by Jorn, and he actually have made more progress on Windows support. Hopefully this is just the first step and get Windows going. > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev > > From jean-philippe.halimi at intel.com Fri Oct 26 16:29:24 2018 From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe) Date: Fri, 26 Oct 2018 16:29:24 +0000 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: <35b89b9f-1395-0c0d-6315-9b87fab458fd@oracle.com> References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> <35b89b9f-1395-0c0d-6315-9b87fab458fd@oracle.com> Message-ID: Hi Vladimir, It should be in now. Jp -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Thursday, October 25, 2018 11:59 PM To: Yang Zhang (Arm Technology China) ; Halimi, Jean-Philippe ; panama-dev at openjdk.java.net Cc: nd Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.01/ Looks good. I'll push it once Jp's fix lands in the repo. Best regards, Vladimir Ivanov > -----Original Message----- > From: Halimi, Jean-Philippe > Sent: Friday, October 26, 2018 2:42 AM > To: Yang Zhang (Arm Technology China) ; Vladimir Ivanov ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > Hi Yang, > > I have just merged the patch. Can you please confirm that it works on your side? > > Jp > > -----Original Message----- > From: Yang Zhang (Arm Technology China) [mailto:Yang.Zhang at arm.com] > Sent: Wednesday, October 24, 2018 10:30 PM > To: Halimi, Jean-Philippe ; Vladimir Ivanov ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > Hi Jp > > When you patch is merged, I will update my patch based on yours. > > Regards > Yang > > -----Original Message----- > From: Halimi, Jean-Philippe > Sent: Thursday, October 25, 2018 2:57 AM > To: Halimi, Jean-Philippe ; Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > Hi, > > Please review the following webrev. It should fix the problem. > http://cr.openjdk.java.net/~jphalimi/webrev_x86_check_fix/webrev/ > > Jp > > -----Original Message----- > From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Halimi, Jean-Philippe > Sent: Wednesday, October 24, 2018 11:33 AM > To: Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > Working on it now. Apologies for the inconvenience. > > Jp > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Wednesday, October 24, 2018 11:20 AM > To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe > Cc: nd > Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > > > On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: >> Hi, >> >> I'm working on supporting vector api for aarch64 NEON. >> I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? >> >> Webrev: >> http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ > > src/hotspot/share/opto/library_call.cpp: > +#ifdef X86 > int bits = num_elem * BitsPerByte * type2aelembytes(bt); > if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { > return NULL; > } > +#endif > > That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. > > So far, platform-specific logic is hidden behind Matcher. > > Jp, I see you added the problematic code [1]. Please, fix it. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 > From vladimir.x.ivanov at oracle.com Fri Oct 26 17:04:54 2018 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Fri, 26 Oct 2018 17:04:54 +0000 Subject: hg: panama/dev: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Message-ID: <201810261704.w9QH4t27029823@aojmv0008.oracle.com> Changeset: 5e27e0d2b863 Author: yzhang Date: 2018-10-26 14:27 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/5e27e0d2b863 Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Summary: add vector_size_supported check for long64/double64. ! src/hotspot/cpu/aarch64/aarch64.ad From vladimir.x.ivanov at oracle.com Fri Oct 26 17:06:07 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 26 Oct 2018 10:06:07 -0700 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> <35b89b9f-1395-0c0d-6315-9b87fab458fd@oracle.com> Message-ID: Thanks. Pushed [1] Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/5e27e0d2b863 On 26/10/2018 09:29, Halimi, Jean-Philippe wrote: > Hi Vladimir, > > It should be in now. > > Jp > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Thursday, October 25, 2018 11:59 PM > To: Yang Zhang (Arm Technology China) ; Halimi, Jean-Philippe ; panama-dev at openjdk.java.net > Cc: nd > Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > >> http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.01/ > > Looks good. I'll push it once Jp's fix lands in the repo. > > Best regards, > Vladimir Ivanov > >> -----Original Message----- >> From: Halimi, Jean-Philippe >> Sent: Friday, October 26, 2018 2:42 AM >> To: Yang Zhang (Arm Technology China) ; Vladimir Ivanov ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> Hi Yang, >> >> I have just merged the patch. Can you please confirm that it works on your side? >> >> Jp >> >> -----Original Message----- >> From: Yang Zhang (Arm Technology China) [mailto:Yang.Zhang at arm.com] >> Sent: Wednesday, October 24, 2018 10:30 PM >> To: Halimi, Jean-Philippe ; Vladimir Ivanov ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> Hi Jp >> >> When you patch is merged, I will update my patch based on yours. >> >> Regards >> Yang >> >> -----Original Message----- >> From: Halimi, Jean-Philippe >> Sent: Thursday, October 25, 2018 2:57 AM >> To: Halimi, Jean-Philippe ; Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> Hi, >> >> Please review the following webrev. It should fix the problem. >> http://cr.openjdk.java.net/~jphalimi/webrev_x86_check_fix/webrev/ >> >> Jp >> >> -----Original Message----- >> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Halimi, Jean-Philippe >> Sent: Wednesday, October 24, 2018 11:33 AM >> To: Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> Working on it now. Apologies for the inconvenience. >> >> Jp >> >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Wednesday, October 24, 2018 11:20 AM >> To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe >> Cc: nd >> Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> >> >> On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: >>> Hi, >>> >>> I'm working on supporting vector api for aarch64 NEON. >>> I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? >>> >>> Webrev: >>> http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ >> >> src/hotspot/share/opto/library_call.cpp: >> +#ifdef X86 >> int bits = num_elem * BitsPerByte * type2aelembytes(bt); >> if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { >> return NULL; >> } >> +#endif >> >> That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. >> >> So far, platform-specific logic is hidden behind Matcher. >> >> Jp, I see you added the problematic code [1]. Please, fix it. >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 >> From maurizio.cimadamore at oracle.com Fri Oct 26 17:07:29 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 26 Oct 2018 17:07:29 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810261707.w9QH7U7f000820@aojmv0008.oracle.com> Changeset: bd9ea4e5216e Author: mcimadamore Date: 2018-10-26 19:09 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/bd9ea4e5216e Automatic merge with vectorIntrinsics From vladimir.x.ivanov at oracle.com Fri Oct 26 17:29:16 2018 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Fri, 26 Oct 2018 17:29:16 +0000 Subject: hg: panama/dev: Manual merge Message-ID: <201810261729.w9QHTHfj013893@aojmv0008.oracle.com> Changeset: 4d33ee124888 Author: vlivanov Date: 2018-10-26 10:28 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/4d33ee124888 Manual merge ! make/common/NativeCompilation.gmk ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/stubRoutines_x86_64.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/subnode.hpp - test/jdk/java/util/Locale/LocaleCategory.sh - test/jdk/java/util/Locale/LocaleProviders.sh - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java - test/jdk/lib/testlibrary/ModuleTargetHelper.java - test/jdk/lib/testlibrary/ModuleUtils.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys From maurizio.cimadamore at oracle.com Fri Oct 26 23:21:44 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 26 Oct 2018 23:21:44 +0000 Subject: hg: panama/dev: Add docs on blas/LAPACK in Ubuntu Message-ID: <201810262321.w9QNLiCl012318@aojmv0008.oracle.com> Changeset: c6e34390ab50 Author: mcimadamore Date: 2018-10-26 16:21 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c6e34390ab50 Add docs on blas/LAPACK in Ubuntu ! doc/panama_foreign.html ! doc/panama_foreign.md From maurizio.cimadamore at oracle.com Sat Oct 27 00:17:27 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 27 Oct 2018 00:17:27 +0000 Subject: hg: panama/dev: Add docs on OpenGL in Ubuntu Message-ID: <201810270017.w9R0HSXL005291@aojmv0008.oracle.com> Changeset: 91b85a618709 Author: mcimadamore Date: 2018-10-26 17:17 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/91b85a618709 Add docs on OpenGL in Ubuntu ! doc/panama_foreign.html ! doc/panama_foreign.md From henry.jen at oracle.com Sat Oct 27 06:45:24 2018 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Sat, 27 Oct 2018 06:45:24 +0000 Subject: hg: panama/dev: 3 new changesets Message-ID: <201810270645.w9R6jPXb004061@aojmv0008.oracle.com> Changeset: 9e20c0ba2c72 Author: henryjen Date: 2018-10-26 23:40 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9e20c0ba2c72 Enable update-build-docs to convert panama_foreign.md into html ! make/UpdateBuildDocs.gmk Changeset: 70abe1950ef7 Author: henryjen Date: 2018-10-26 23:41 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/70abe1950ef7 Update panama_foreign.html with `make update-build-docs` ! doc/panama_foreign.html Changeset: 476d3bee49e7 Author: henryjen Date: 2018-10-26 23:44 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/476d3bee49e7 Add docs on libtensorflow ! doc/panama_foreign.html ! doc/panama_foreign.md From jbvernee at xs4all.nl Sat Oct 27 17:53:11 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Sat, 27 Oct 2018 19:53:11 +0200 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> Message-ID: <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> Hi Henry, I'm testing out this patch and can confirm jextract.exe is being built, but I can't use it to extract a header file. I'm getting an UnsatisfiedLinkError when loading jclang.dll: ``` PS J:\WS\JNI test\C> jextract Main.h Exception in thread "main" java.lang.UnsatisfiedLinkError: J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid Win32 application at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462) at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534) at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851) at java.base/java.lang.System.loadLibrary(System.java:1903) at jdk.internal.clang/jdk.internal.clang.LibClang.(LibClang.java:35) at jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74) at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411) at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387) at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251) at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316) ``` When inspecting jclang.dll with 'dependency walker' (a DLL inspection tool [1]) it's giving an error about libclang.dll (a dependency of jclang.dll), which tells me "No DOS or PE signature found. This file is not a valid 32-bit or 64-bit Windows module.". However, when I open the original libclang.dll file from my LLVM installation it _is_ being recognized as a valid DLL. I think something is going wrong when copying libclang.dll over? I have tried manually copying over the libclang.dll file to the jclang and jdk/bin folders, which allows me to extract a header file using that command line, but when re-running the build the DLL is being overwritten again with the corrupted/invalid version. Cheers, Jorn [1] : http://www.dependencywalker.com/ Henry Jen schreef op 2018-10-26 06:44: > Hi, > > Please review a web rev[1] that address following, > > 1. Copy the essential share library as recorded by the linker > following the symbolic link of libclang.so for unix/mac. This leads to > only one copy of share library instead of a duplicate copy of > libclang.so. It would be nice to have create libclang as a symbolic > link, but it?s not needed now. > > This issue is what failed the build when using system provided > libclang on some systems such as Debian-based Linux distribution. > After this patch, Debian-based system can be build as described in > README.foreign. > > 2. Enable build on Windows. This patch allow build image to be > completed successfully and libclang.dll copied to bin as expected. > > However, this doesn?t mean binder is working on Windows, it?s simply > get the build going and jextract should be functional. Some test still > have compiling errors to be fixed, and we don?t have Windows ABI. It?s > the first step to allow build on Windows. > > I believe a lot of this had been addressed by Jorn, and he actually > have made more progress on Windows support. Hopefully this is just the > first step and get Windows going. > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev From samuel.audet at gmail.com Sun Oct 28 01:48:29 2018 From: samuel.audet at gmail.com (Samuel Audet) Date: Sun, 28 Oct 2018 10:48:29 +0900 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> Message-ID: Building LLVM and Clang as DLLs on Windows is tricky as they are not maintaining the build system for this use case. For reference, here's a build script that works: https://github.com/bytedeco/javacpp-presets/blob/master/llvm/cppbuild.sh Samuel On 10/28/2018 02:53 AM, Jorn Vernee wrote: > Hi Henry, > > I'm testing out this patch and can confirm jextract.exe is being built, > but I can't use it to extract a header file. > > I'm getting an UnsatisfiedLinkError when loading jclang.dll: > > ``` > PS J:\WS\JNI test\C> jextract Main.h > Exception in thread "main" java.lang.UnsatisfiedLinkError: > J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8 > 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid Win32 > application > ??????? at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native > Method) > ??????? at > java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462) > ??????? at > java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534) > > ??????? at > java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744) > ??????? at > java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690) > ??????? at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851) > ??????? at java.base/java.lang.System.loadLibrary(System.java:1903) > ??????? at > jdk.internal.clang/jdk.internal.clang.LibClang.(LibClang.java:35) > ??????? at > jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74) > ??????? at > jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411) > ??????? at > jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387) > ??????? at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251) > ??????? at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316) > ``` > > When inspecting jclang.dll with 'dependency walker' (a DLL inspection > tool [1]) it's giving an error about libclang.dll (a dependency of > jclang.dll), which tells me "No DOS or PE signature found. This file is > not a valid 32-bit or 64-bit Windows module.". However, when I open the > original libclang.dll file from my LLVM installation it _is_ being > recognized as a valid DLL. > > I think something is going wrong when copying libclang.dll over? I have > tried manually copying over the libclang.dll file to the jclang and > jdk/bin folders, which allows me to extract a header file using that > command line, but when re-running the build the DLL is being overwritten > again with the corrupted/invalid version. > > Cheers, > Jorn > > [1] : http://www.dependencywalker.com/ > > Henry Jen schreef op 2018-10-26 06:44: >> Hi, >> >> Please review a web rev[1] that address following, >> >> 1. Copy the essential share library as recorded by the linker >> following the symbolic link of libclang.so for unix/mac. This leads to >> only one copy of share library instead of a duplicate copy of >> libclang.so. It would be nice to have create libclang as a symbolic >> link, but it?s not needed now. >> >> This issue is what failed the build when using system provided >> libclang on some systems such as Debian-based Linux distribution. >> After this patch, Debian-based system can be build as described in >> README.foreign. >> >> 2. Enable build on Windows. This patch allow build image to be >> completed successfully and libclang.dll copied to bin as expected. >> >> However, this doesn?t mean binder is working on Windows, it?s simply >> get the build going and jextract should be functional. Some test still >> have compiling errors to be fixed, and we don?t have Windows ABI. It?s >> the first step to allow build on Windows. >> >> I believe a lot of this had been addressed by Jorn, and he actually >> have made more progress on Windows support. Hopefully this is just the >> first step and get Windows going. >> >> Cheers, >> Henry >> >> [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev From jbvernee at xs4all.nl Sun Oct 28 13:04:54 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Sun, 28 Oct 2018 14:04:54 +0100 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> Message-ID: <6d867c10c5b829ba43db46217e8c7190@xs4all.nl> To add to this (and add missing CCs, sorry about that); There are 3 libclang.dll files in the build output after running `make clean images`; images\jdk\bin\libclang.dll jdk\bin\libclang.dll support\modules_libs\jdk.internal.clang\libclang.dll All of these files are only 80 bytes in size, while they are supposed to be 57+ MB. So I think definitely something is going wrong with the copy. I can't find the build system code that does the copying though, so I'm not sure how to debug this. AFAIK we are not building the library from scratch on Windows right? Just copying over the .dll from the pre-built distribution? Jorn Jorn Vernee schreef op 2018-10-27 19:53: > Hi Henry, > > I'm testing out this patch and can confirm jextract.exe is being > built, but I can't use it to extract a header file. > > I'm getting an UnsatisfiedLinkError when loading jclang.dll: > > ``` > PS J:\WS\JNI test\C> jextract Main.h > Exception in thread "main" java.lang.UnsatisfiedLinkError: > J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8 > 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid Win32 > application > at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native > Method) > at > java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462) > at > java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534) > at > java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744) > at > java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690) > at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851) > at java.base/java.lang.System.loadLibrary(System.java:1903) > at > jdk.internal.clang/jdk.internal.clang.LibClang.(LibClang.java:35) > at > jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74) > at > jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411) > at > jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387) > at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251) > at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316) > ``` > > When inspecting jclang.dll with 'dependency walker' (a DLL inspection > tool [1]) it's giving an error about libclang.dll (a dependency of > jclang.dll), which tells me "No DOS or PE signature found. This file > is not a valid 32-bit or 64-bit Windows module.". However, when I open > the original libclang.dll file from my LLVM installation it _is_ being > recognized as a valid DLL. > > I think something is going wrong when copying libclang.dll over? I > have tried manually copying over the libclang.dll file to the jclang > and jdk/bin folders, which allows me to extract a header file using > that command line, but when re-running the build the DLL is being > overwritten again with the corrupted/invalid version. > > Cheers, > Jorn > > [1] : http://www.dependencywalker.com/ > > Henry Jen schreef op 2018-10-26 06:44: >> Hi, >> >> Please review a web rev[1] that address following, >> >> 1. Copy the essential share library as recorded by the linker >> following the symbolic link of libclang.so for unix/mac. This leads to >> only one copy of share library instead of a duplicate copy of >> libclang.so. It would be nice to have create libclang as a symbolic >> link, but it?s not needed now. >> >> This issue is what failed the build when using system provided >> libclang on some systems such as Debian-based Linux distribution. >> After this patch, Debian-based system can be build as described in >> README.foreign. >> >> 2. Enable build on Windows. This patch allow build image to be >> completed successfully and libclang.dll copied to bin as expected. >> >> However, this doesn?t mean binder is working on Windows, it?s simply >> get the build going and jextract should be functional. Some test still >> have compiling errors to be fixed, and we don?t have Windows ABI. It?s >> the first step to allow build on Windows. >> >> I believe a lot of this had been addressed by Jorn, and he actually >> have made more progress on Windows support. Hopefully this is just the >> first step and get Windows going. >> >> Cheers, >> Henry >> >> [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev From henry.jen at oracle.com Sun Oct 28 16:11:07 2018 From: henry.jen at oracle.com (Henry Jen) Date: Sun, 28 Oct 2018 09:11:07 -0700 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: <6d867c10c5b829ba43db46217e8c7190@xs4all.nl> References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> <6d867c10c5b829ba43db46217e8c7190@xs4all.nl> Message-ID: <2364D4E1-3D83-435A-9FCB-86EF7EE91D3C@oracle.com> I think the is caused by link under cygwin on Windows. I?ll double check and fix them. Cheers, Henry > On Oct 28, 2018, at 6:04 AM, Jorn Vernee wrote: > > To add to this (and add missing CCs, sorry about that); > > There are 3 libclang.dll files in the build output after running `make clean images`; > > images\jdk\bin\libclang.dll > jdk\bin\libclang.dll > support\modules_libs\jdk.internal.clang\libclang.dll > > All of these files are only 80 bytes in size, while they are supposed to be 57+ MB. So I think definitely something is going wrong with the copy. I can't find the build system code that does the copying though, so I'm not sure how to debug this. > > AFAIK we are not building the library from scratch on Windows right? Just copying over the .dll from the pre-built distribution? > > Jorn > > Jorn Vernee schreef op 2018-10-27 19:53: >> Hi Henry, >> I'm testing out this patch and can confirm jextract.exe is being >> built, but I can't use it to extract a header file. >> I'm getting an UnsatisfiedLinkError when loading jclang.dll: >> ``` >> PS J:\WS\JNI test\C> jextract Main.h >> Exception in thread "main" java.lang.UnsatisfiedLinkError: >> J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8 >> 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid Win32 >> application >> at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) >> at >> java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462) >> at >> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534) >> at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744) >> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690) >> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851) >> at java.base/java.lang.System.loadLibrary(System.java:1903) >> at >> jdk.internal.clang/jdk.internal.clang.LibClang.(LibClang.java:35) >> at >> jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74) >> at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411) >> at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387) >> at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251) >> at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316) >> ``` >> When inspecting jclang.dll with 'dependency walker' (a DLL inspection >> tool [1]) it's giving an error about libclang.dll (a dependency of >> jclang.dll), which tells me "No DOS or PE signature found. This file >> is not a valid 32-bit or 64-bit Windows module.". However, when I open >> the original libclang.dll file from my LLVM installation it _is_ being >> recognized as a valid DLL. >> I think something is going wrong when copying libclang.dll over? I >> have tried manually copying over the libclang.dll file to the jclang >> and jdk/bin folders, which allows me to extract a header file using >> that command line, but when re-running the build the DLL is being >> overwritten again with the corrupted/invalid version. >> Cheers, >> Jorn >> [1] : http://www.dependencywalker.com/ >> Henry Jen schreef op 2018-10-26 06:44: >>> Hi, >>> Please review a web rev[1] that address following, >>> 1. Copy the essential share library as recorded by the linker >>> following the symbolic link of libclang.so for unix/mac. This leads to >>> only one copy of share library instead of a duplicate copy of >>> libclang.so. It would be nice to have create libclang as a symbolic >>> link, but it?s not needed now. >>> This issue is what failed the build when using system provided >>> libclang on some systems such as Debian-based Linux distribution. >>> After this patch, Debian-based system can be build as described in >>> README.foreign. >>> 2. Enable build on Windows. This patch allow build image to be >>> completed successfully and libclang.dll copied to bin as expected. >>> However, this doesn?t mean binder is working on Windows, it?s simply >>> get the build going and jextract should be functional. Some test still >>> have compiling errors to be fixed, and we don?t have Windows ABI. It?s >>> the first step to allow build on Windows. >>> I believe a lot of this had been addressed by Jorn, and he actually >>> have made more progress on Windows support. Hopefully this is just the >>> first step and get Windows going. >>> Cheers, >>> Henry >>> [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev From Yang.Zhang at arm.com Mon Oct 29 01:59:39 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Mon, 29 Oct 2018 01:59:39 +0000 Subject: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON In-Reply-To: References: <73655275-d15c-9af5-a9f0-1b8d1d70ff87@oracle.com> <35b89b9f-1395-0c0d-6315-9b87fab458fd@oracle.com> Message-ID: Thanks very much for your help. Regards Yang -----Original Message----- From: Vladimir Ivanov Sent: Saturday, October 27, 2018 1:06 AM To: Halimi, Jean-Philippe ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON Thanks. Pushed [1] Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/5e27e0d2b863 On 26/10/2018 09:29, Halimi, Jean-Philippe wrote: > Hi Vladimir, > > It should be in now. > > Jp > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Thursday, October 25, 2018 11:59 PM > To: Yang Zhang (Arm Technology China) ; Halimi, Jean-Philippe ; panama-dev at openjdk.java.net > Cc: nd > Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON > > >> http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.01/ > > Looks good. I'll push it once Jp's fix lands in the repo. > > Best regards, > Vladimir Ivanov > >> -----Original Message----- >> From: Halimi, Jean-Philippe >> Sent: Friday, October 26, 2018 2:42 AM >> To: Yang Zhang (Arm Technology China) ; Vladimir Ivanov ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> Hi Yang, >> >> I have just merged the patch. Can you please confirm that it works on your side? >> >> Jp >> >> -----Original Message----- >> From: Yang Zhang (Arm Technology China) [mailto:Yang.Zhang at arm.com] >> Sent: Wednesday, October 24, 2018 10:30 PM >> To: Halimi, Jean-Philippe ; Vladimir Ivanov ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> Hi Jp >> >> When you patch is merged, I will update my patch based on yours. >> >> Regards >> Yang >> >> -----Original Message----- >> From: Halimi, Jean-Philippe >> Sent: Thursday, October 25, 2018 2:57 AM >> To: Halimi, Jean-Philippe ; Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> Hi, >> >> Please review the following webrev. It should fix the problem. >> http://cr.openjdk.java.net/~jphalimi/webrev_x86_check_fix/webrev/ >> >> Jp >> >> -----Original Message----- >> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of Halimi, Jean-Philippe >> Sent: Wednesday, October 24, 2018 11:33 AM >> To: Vladimir Ivanov ; Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> Working on it now. Apologies for the inconvenience. >> >> Jp >> >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Wednesday, October 24, 2018 11:20 AM >> To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe >> Cc: nd >> Subject: Re: [vector api] RFR: Fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON >> >> >> >> On 22/10/2018 18:40, Yang Zhang (Arm Technology China) wrote: >>> Hi, >>> >>> I'm working on supporting vector api for aarch64 NEON. >>> I have a patch which can fix AArch64 build failure and jtreg long64/double64 failures for AArch64 NEON. Could you please help to review this? >>> >>> Webrev: >>> http://cr.openjdk.java.net/~yzhang/vectorapi.bugfix/webrev.00/ >> >> src/hotspot/share/opto/library_call.cpp: >> +#ifdef X86 >> int bits = num_elem * BitsPerByte * type2aelembytes(bt); >> if (bits == 512 && !VM_Version::supports_avx512vlbwdq()) { >> return NULL; >> } >> +#endif >> >> That's ok as a temporary workaround, but shared code shouldn't access platform-specific API and VM_Version::supports_avx512vlbwdq() is x86-specific. >> >> So far, platform-specific logic is hidden behind Matcher. >> >> Jp, I see you added the problematic code [1]. Please, fix it. >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://hg.openjdk.java.net/panama/dev/rev/a6e1c1fd5e27 >> From Ningsheng.Jian at arm.com Mon Oct 29 03:58:21 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Mon, 29 Oct 2018 03:58:21 +0000 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> Message-ID: Hi, Thanks a lot for Vladimir's comments!! I have updated the patch with reshaping/casting supports: http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev01/ and the test cases: http://cr.openjdk.java.net/~njian/sve/vectorapi-test.webrev01/ All the vector api cases passed on my x86 machines with and without VectorApiIntrinsics. There are some failures on AArch64, but they are not related to this patch and we will fix them in follow-up patches. Please help to review the changes. Thanks, Ningsheng > -----Original Message----- > From: Vladimir Ivanov > Sent: Friday, October 12, 2018 11:18 AM > To: Ningsheng Jian (Arm Technology China) ; > panama-dev at openjdk.java.net > Cc: nd > Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension > > > > >>>> So, my question boils down to: how vector shape checks are expected > >>>> to work on *ScalableVectors in presence of operations which change > >>>> vector > >> size. > >>>> > >>>> For example, IntScalableVector.rebracket() => LongScalableVector > >>>> which is fine, but ISV.resize() => ISV is what I'm concerned about > >>>> and existing checks aren't enough for *ScalableVectors unless you > >>>> check their length at runtime. > >>> > >>> Thanks for the detailed explanation. So, which checks do you mean > >>> here? Do > >> you mean this [1]? I find that current Java implementations already > >> has some runtime length checks. One thing we need to consider is the > >> ambiguity between existing sizes and scalable size. Current > >> VectorIntrinsics.reinterpret() just tries to get the shape from size > >> (library_call.cpp:get_exact_klass_for_vector_box) instead of getting > >> the real class from input argument, which will lead to > >> ClassCastException. Maybe that can be fixed by adding real klass type to the > reinterpret function. > >> > >> The checks I referred to are the casts on vector shapes which are > >> part of every vector operation (e.g., [2]), but they don't > >> immediately relate to shape-changing operations. > >> > > > > OK, but I would expect the normal operations between SV and other vectors > are illegal, though they may have the same size, since users usually don't know > the real size of SV. We should treat SV different from other vectors. > > Yes, the checks currently in place effectively forbid mixing vectors of different > shapes. But API allows to reshape/cast vectors to arbitrary shapes and that may > cause problems if equivalent shapes meet at runtime. > > Since concrete vector shapes aren't part of API, I believe it is possible to exclude > duplicating shapes at runtime. For example, SVs can be used as a substitute for > *512V shapes on 512-bit SVE or AVX512-capable hardware. It seems current JDK- > JVM interface > (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), but it would > be very interesting to hear your experience. > > API allows to query vectors of smaller/larger sizes than hardware natively > supports and implementation has to support that (even if performance suffers). > It means SV shapes can coexist at runtime with existing shapes (*64V/.../*512V) > and casts/reshapes between all those shapes should work. > > Best regards, > Vladimir Ivanov > > >> It seems I had some wrong assumptions when coming up with the examples. > >> Sorry for the confusion. Taking those into account, here's my take on > >> current state of vector shape changing operations w.r.t. SV shapes. > >> > >> There'll be 30 vector shapes in total (5 sizes x 6 element types): > >> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV > >> * Short64V, ..., ShortSV > >> ... > >> * Double64V, Double128V, ... Double512V, DoubleSV > >> > >> Depending on hardware, SVs may alias with "explicitly sized" shapes > >> (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). > >> > >> (1) Vector.rebracket(): works fine for SVs since vector size (in bits) stays the > same: > >> IntSV <-> LongSV <-> ... <-> DoubleSV. > >> > >> (2) Vector.resize(): SV->SV doesn't make sense and the operation > >> should involve both SV and existing vector shapes: IntSV <-> > >> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause > >> problems and needs to be carefully handled to avoid 2 equivalent > >> shapes to meet at runtime. Otherwise, vector shape checks I mentioned > earlier should be changed. > >> > > > > Yes, we will try to address this issue carefully in the follow-up webrev. > > > >> (3) Vector.cast(): SV->SV, SV<->64V/.../512V > >> * size-preserving transformations (int <-> float): > >> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV; > >> > >> * widening casts (e.g., int->long) > >> SV->SV/64V/...: truncate upper part of the vector, since SVs > >> already represent widest vector shapes; > >> 64V/...->SV: either truncated or filled with defaults > >> depending on actual size > >> > >> * narrowing casts (e.g., long->int) > >> SV->SV/64V/...: fill upper part of SV with defaults; > >> 64V/...->SV: either truncated or filled with defaults > >> depending on actual size > >> > > > > Thanks, > > Ningsheng > > From henry.jen at oracle.com Mon Oct 29 05:55:28 2018 From: henry.jen at oracle.com (Henry Jen) Date: Sun, 28 Oct 2018 22:55:28 -0700 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: <2364D4E1-3D83-435A-9FCB-86EF7EE91D3C@oracle.com> References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> <6d867c10c5b829ba43db46217e8c7190@xs4all.nl> <2364D4E1-3D83-435A-9FCB-86EF7EE91D3C@oracle.com> Message-ID: Updated webrev[1] fix the link issue and revert CXX CXXCPP as suggested by Erik. [1] https://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev.01/webrev/ Cheers, Henry > On Oct 28, 2018, at 9:11 AM, Henry Jen wrote: > > I think the is caused by link under cygwin on Windows. I?ll double check and fix them. > > Cheers, > Henry > >> On Oct 28, 2018, at 6:04 AM, Jorn Vernee wrote: >> >> To add to this (and add missing CCs, sorry about that); >> >> There are 3 libclang.dll files in the build output after running `make clean images`; >> >> images\jdk\bin\libclang.dll >> jdk\bin\libclang.dll >> support\modules_libs\jdk.internal.clang\libclang.dll >> >> All of these files are only 80 bytes in size, while they are supposed to be 57+ MB. So I think definitely something is going wrong with the copy. I can't find the build system code that does the copying though, so I'm not sure how to debug this. >> >> AFAIK we are not building the library from scratch on Windows right? Just copying over the .dll from the pre-built distribution? >> >> Jorn >> >> Jorn Vernee schreef op 2018-10-27 19:53: >>> Hi Henry, >>> I'm testing out this patch and can confirm jextract.exe is being >>> built, but I can't use it to extract a header file. >>> I'm getting an UnsatisfiedLinkError when loading jclang.dll: >>> ``` >>> PS J:\WS\JNI test\C> jextract Main.h >>> Exception in thread "main" java.lang.UnsatisfiedLinkError: >>> J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8 >>> 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid Win32 >>> application >>> at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) >>> at >>> java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462) >>> at >>> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534) >>> at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744) >>> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690) >>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851) >>> at java.base/java.lang.System.loadLibrary(System.java:1903) >>> at >>> jdk.internal.clang/jdk.internal.clang.LibClang.(LibClang.java:35) >>> at >>> jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74) >>> at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411) >>> at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387) >>> at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251) >>> at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316) >>> ``` >>> When inspecting jclang.dll with 'dependency walker' (a DLL inspection >>> tool [1]) it's giving an error about libclang.dll (a dependency of >>> jclang.dll), which tells me "No DOS or PE signature found. This file >>> is not a valid 32-bit or 64-bit Windows module.". However, when I open >>> the original libclang.dll file from my LLVM installation it _is_ being >>> recognized as a valid DLL. >>> I think something is going wrong when copying libclang.dll over? I >>> have tried manually copying over the libclang.dll file to the jclang >>> and jdk/bin folders, which allows me to extract a header file using >>> that command line, but when re-running the build the DLL is being >>> overwritten again with the corrupted/invalid version. >>> Cheers, >>> Jorn >>> [1] : http://www.dependencywalker.com/ >>> Henry Jen schreef op 2018-10-26 06:44: >>>> Hi, >>>> Please review a web rev[1] that address following, >>>> 1. Copy the essential share library as recorded by the linker >>>> following the symbolic link of libclang.so for unix/mac. This leads to >>>> only one copy of share library instead of a duplicate copy of >>>> libclang.so. It would be nice to have create libclang as a symbolic >>>> link, but it?s not needed now. >>>> This issue is what failed the build when using system provided >>>> libclang on some systems such as Debian-based Linux distribution. >>>> After this patch, Debian-based system can be build as described in >>>> README.foreign. >>>> 2. Enable build on Windows. This patch allow build image to be >>>> completed successfully and libclang.dll copied to bin as expected. >>>> However, this doesn?t mean binder is working on Windows, it?s simply >>>> get the build going and jextract should be functional. Some test still >>>> have compiling errors to be fixed, and we don?t have Windows ABI. It?s >>>> the first step to allow build on Windows. >>>> I believe a lot of this had been addressed by Jorn, and he actually >>>> have made more progress on Windows support. Hopefully this is just the >>>> first step and get Windows going. >>>> Cheers, >>>> Henry >>>> [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev > From Yang.Zhang at arm.com Mon Oct 29 08:01:59 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Mon, 29 Oct 2018 08:01:59 +0000 Subject: [vector api] RFR: Implement Vector API abs and not for AArch64 NEON Message-ID: Hi, I have a patch which implement Vector API abs() and not() for AArch64 NEON. Could you please help to review this? Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi.abs_not/webrev.00/ Regards, Yang From sundararajan.athijegannathan at oracle.com Mon Oct 29 09:57:46 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 29 Oct 2018 09:57:46 +0000 Subject: hg: panama/dev: added title. added platform info for tensorflow sample. Message-ID: <201810290957.w9T9vlD5016145@aojmv0008.oracle.com> Changeset: ddaa534b306a Author: sundar Date: 2018-10-29 15:38 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/ddaa534b306a added title. added platform info for tensorflow sample. ! doc/panama_foreign.html ! doc/panama_foreign.md From jbvernee at xs4all.nl Mon Oct 29 13:03:39 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Mon, 29 Oct 2018 14:03:39 +0100 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> <6d867c10c5b829ba43db46217e8c7190@xs4all.nl> <2364D4E1-3D83-435A-9FCB-86EF7EE91D3C@oracle.com> Message-ID: <4538dbeffeae6caca027719748a2e219@xs4all.nl> Thanks Henry, the files are now copied over as expected :) Just now I was also looking at the way you're solving the problem of missing `alloca` in `jdk_internal_clang.cpp`, which I've ran into myself in other places. I see you've switched to calloc, but you're not freeing the pointer it creates, so this is a memory leak (this problem doesn't exist with alloca since it allocates space on the stack). You can put `free(filteredTokens);` after the `out:` label to ensure that it gets freed in the case of an exception as well. I remember seeing some talk recently about bumping up the C/C++ standard the JDK operates on, so soon we could hopefully use C99 variable length arrays and this won't be a problem :) I'm currently using the C++ version of alloca (called _alloca) using this macro: #ifdef _WIN64 #include #define alloca _alloca #endif Which also seems to work. --- I'm also looking at /hotspot/cpu/x86/directUpcallHandler_x86.cpp You're putting `mask` and `rec_adr` into rdi and rsi, but those or not argument registers on MSx64 [1], so this won't work. The direct invoker doesn't work for Windows currently since it can't handle the argument shuffling and it uses a different number of registers, so I've also put in that compiler switch, but left the Windows branch with a FIXME, since there's no real quick-fix. Picking which invoker is used is done by the binder code, so on Windows it will just choose not to use the direct invoker at all for now. Cheers, Jorn [1] : https://docs.microsoft.com/en-us/cpp/build/parameter-passing?view=vs-2017 Henry Jen schreef op 2018-10-29 06:55: > Updated webrev[1] fix the link issue and revert CXX CXXCPP as suggested > by Erik. > > [1] > https://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev.01/webrev/ > > Cheers, > Henry > > >> On Oct 28, 2018, at 9:11 AM, Henry Jen wrote: >> >> I think the is caused by link under cygwin on Windows. I?ll double >> check and fix them. >> >> Cheers, >> Henry >> >>> On Oct 28, 2018, at 6:04 AM, Jorn Vernee wrote: >>> >>> To add to this (and add missing CCs, sorry about that); >>> >>> There are 3 libclang.dll files in the build output after running >>> `make clean images`; >>> >>> images\jdk\bin\libclang.dll >>> jdk\bin\libclang.dll >>> support\modules_libs\jdk.internal.clang\libclang.dll >>> >>> All of these files are only 80 bytes in size, while they are supposed >>> to be 57+ MB. So I think definitely something is going wrong with the >>> copy. I can't find the build system code that does the copying >>> though, so I'm not sure how to debug this. >>> >>> AFAIK we are not building the library from scratch on Windows right? >>> Just copying over the .dll from the pre-built distribution? >>> >>> Jorn >>> >>> Jorn Vernee schreef op 2018-10-27 19:53: >>>> Hi Henry, >>>> I'm testing out this patch and can confirm jextract.exe is being >>>> built, but I can't use it to extract a header file. >>>> I'm getting an UnsatisfiedLinkError when loading jclang.dll: >>>> ``` >>>> PS J:\WS\JNI test\C> jextract Main.h >>>> Exception in thread "main" java.lang.UnsatisfiedLinkError: >>>> J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8 >>>> 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid >>>> Win32 >>>> application >>>> at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native >>>> Method) >>>> at >>>> java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462) >>>> at >>>> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534) >>>> at >>>> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744) >>>> at >>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690) >>>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851) >>>> at java.base/java.lang.System.loadLibrary(System.java:1903) >>>> at >>>> jdk.internal.clang/jdk.internal.clang.LibClang.(LibClang.java:35) >>>> at >>>> jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74) >>>> at >>>> jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411) >>>> at >>>> jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387) >>>> at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251) >>>> at >>>> jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316) >>>> ``` >>>> When inspecting jclang.dll with 'dependency walker' (a DLL >>>> inspection >>>> tool [1]) it's giving an error about libclang.dll (a dependency of >>>> jclang.dll), which tells me "No DOS or PE signature found. This file >>>> is not a valid 32-bit or 64-bit Windows module.". However, when I >>>> open >>>> the original libclang.dll file from my LLVM installation it _is_ >>>> being >>>> recognized as a valid DLL. >>>> I think something is going wrong when copying libclang.dll over? I >>>> have tried manually copying over the libclang.dll file to the jclang >>>> and jdk/bin folders, which allows me to extract a header file using >>>> that command line, but when re-running the build the DLL is being >>>> overwritten again with the corrupted/invalid version. >>>> Cheers, >>>> Jorn >>>> [1] : http://www.dependencywalker.com/ >>>> Henry Jen schreef op 2018-10-26 06:44: >>>>> Hi, >>>>> Please review a web rev[1] that address following, >>>>> 1. Copy the essential share library as recorded by the linker >>>>> following the symbolic link of libclang.so for unix/mac. This leads >>>>> to >>>>> only one copy of share library instead of a duplicate copy of >>>>> libclang.so. It would be nice to have create libclang as a symbolic >>>>> link, but it?s not needed now. >>>>> This issue is what failed the build when using system provided >>>>> libclang on some systems such as Debian-based Linux distribution. >>>>> After this patch, Debian-based system can be build as described in >>>>> README.foreign. >>>>> 2. Enable build on Windows. This patch allow build image to be >>>>> completed successfully and libclang.dll copied to bin as expected. >>>>> However, this doesn?t mean binder is working on Windows, it?s >>>>> simply >>>>> get the build going and jextract should be functional. Some test >>>>> still >>>>> have compiling errors to be fixed, and we don?t have Windows ABI. >>>>> It?s >>>>> the first step to allow build on Windows. >>>>> I believe a lot of this had been addressed by Jorn, and he actually >>>>> have made more progress on Windows support. Hopefully this is just >>>>> the >>>>> first step and get Windows going. >>>>> Cheers, >>>>> Henry >>>>> [1] >>>>> http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev >> From henry.jen at oracle.com Mon Oct 29 15:36:10 2018 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 29 Oct 2018 08:36:10 -0700 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: <4538dbeffeae6caca027719748a2e219@xs4all.nl> References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> <6d867c10c5b829ba43db46217e8c7190@xs4all.nl> <2364D4E1-3D83-435A-9FCB-86EF7EE91D3C@oracle.com> <4538dbeffeae6caca027719748a2e219@xs4all.nl> Message-ID: <38379A99-B745-4A35-883C-8AB673A1E70F@oracle.com> On Oct 29, 2018, at 6:03 AM, Jorn Vernee wrote: > > Thanks Henry, the files are now copied over as expected :) > > Just now I was also looking at the way you're solving the problem of missing `alloca` in `jdk_internal_clang.cpp`, which I've ran into myself in other places. > Uh, I wasn?t paying attention, thanks for catching this. > I see you've switched to calloc, but you're not freeing the pointer it creates, so this is a memory leak (this problem doesn't exist with alloca since it allocates space on the stack). You can put `free(filteredTokens);` after the `out:` label to ensure that it gets freed in the case of an exception as well. > > I remember seeing some talk recently about bumping up the C/C++ standard the JDK operates on, so soon we could hopefully use C99 variable length arrays and this won't be a problem :) > > I'm currently using the C++ version of alloca (called _alloca) using this macro: > > #ifdef _WIN64 > #include > #define alloca _alloca > #endif > > Which also seems to work. > I like this approach better. > --- > > I'm also looking at /hotspot/cpu/x86/directUpcallHandler_x86.cpp > > You're putting `mask` and `rec_adr` into rdi and rsi, but those or not argument registers on MSx64 [1], so this won't work. > I am justing get it compiled, should have put a ?FIXME? on it. Those two registers picked based on src/hotspot/cpu/x86/assembler_x86.hpp Cheers, Henry > The direct invoker doesn't work for Windows currently since it can't handle the argument shuffling and it uses a different number of registers, so I've also put in that compiler switch, but left the Windows branch with a FIXME, since there's no real quick-fix. > > Picking which invoker is used is done by the binder code, so on Windows it will just choose not to use the direct invoker at all for now. > > Cheers, > Jorn > > [1] : https://docs.microsoft.com/en-us/cpp/build/parameter-passing?view=vs-2017 > > Henry Jen schreef op 2018-10-29 06:55: >> Updated webrev[1] fix the link issue and revert CXX CXXCPP as suggested by Erik. >> [1] https://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev.01/webrev/ >> Cheers, >> Henry From erik.joelsson at oracle.com Mon Oct 29 15:59:16 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 29 Oct 2018 08:59:16 -0700 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> <6d867c10c5b829ba43db46217e8c7190@xs4all.nl> <2364D4E1-3D83-435A-9FCB-86EF7EE91D3C@oracle.com> Message-ID: <4eb272ea-c25c-f941-feea-b873f469500a@oracle.com> Build changes look ok. /Erik On 2018-10-28 22:55, Henry Jen wrote: > Updated webrev[1] fix the link issue and revert CXX CXXCPP as suggested by Erik. > > [1] https://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev.01/webrev/ > > Cheers, > Henry > > >> On Oct 28, 2018, at 9:11 AM, Henry Jen wrote: >> >> I think the is caused by link under cygwin on Windows. I?ll double check and fix them. >> >> Cheers, >> Henry >> >>> On Oct 28, 2018, at 6:04 AM, Jorn Vernee wrote: >>> >>> To add to this (and add missing CCs, sorry about that); >>> >>> There are 3 libclang.dll files in the build output after running `make clean images`; >>> >>> images\jdk\bin\libclang.dll >>> jdk\bin\libclang.dll >>> support\modules_libs\jdk.internal.clang\libclang.dll >>> >>> All of these files are only 80 bytes in size, while they are supposed to be 57+ MB. So I think definitely something is going wrong with the copy. I can't find the build system code that does the copying though, so I'm not sure how to debug this. >>> >>> AFAIK we are not building the library from scratch on Windows right? Just copying over the .dll from the pre-built distribution? >>> >>> Jorn >>> >>> Jorn Vernee schreef op 2018-10-27 19:53: >>>> Hi Henry, >>>> I'm testing out this patch and can confirm jextract.exe is being >>>> built, but I can't use it to extract a header file. >>>> I'm getting an UnsatisfiedLinkError when loading jclang.dll: >>>> ``` >>>> PS J:\WS\JNI test\C> jextract Main.h >>>> Exception in thread "main" java.lang.UnsatisfiedLinkError: >>>> J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8 >>>> 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid Win32 >>>> application >>>> at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) >>>> at >>>> java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462) >>>> at >>>> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534) >>>> at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744) >>>> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690) >>>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851) >>>> at java.base/java.lang.System.loadLibrary(System.java:1903) >>>> at >>>> jdk.internal.clang/jdk.internal.clang.LibClang.(LibClang.java:35) >>>> at >>>> jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74) >>>> at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411) >>>> at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387) >>>> at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251) >>>> at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316) >>>> ``` >>>> When inspecting jclang.dll with 'dependency walker' (a DLL inspection >>>> tool [1]) it's giving an error about libclang.dll (a dependency of >>>> jclang.dll), which tells me "No DOS or PE signature found. This file >>>> is not a valid 32-bit or 64-bit Windows module.". However, when I open >>>> the original libclang.dll file from my LLVM installation it _is_ being >>>> recognized as a valid DLL. >>>> I think something is going wrong when copying libclang.dll over? I >>>> have tried manually copying over the libclang.dll file to the jclang >>>> and jdk/bin folders, which allows me to extract a header file using >>>> that command line, but when re-running the build the DLL is being >>>> overwritten again with the corrupted/invalid version. >>>> Cheers, >>>> Jorn >>>> [1] : http://www.dependencywalker.com/ >>>> Henry Jen schreef op 2018-10-26 06:44: >>>>> Hi, >>>>> Please review a web rev[1] that address following, >>>>> 1. Copy the essential share library as recorded by the linker >>>>> following the symbolic link of libclang.so for unix/mac. This leads to >>>>> only one copy of share library instead of a duplicate copy of >>>>> libclang.so. It would be nice to have create libclang as a symbolic >>>>> link, but it?s not needed now. >>>>> This issue is what failed the build when using system provided >>>>> libclang on some systems such as Debian-based Linux distribution. >>>>> After this patch, Debian-based system can be build as described in >>>>> README.foreign. >>>>> 2. Enable build on Windows. This patch allow build image to be >>>>> completed successfully and libclang.dll copied to bin as expected. >>>>> However, this doesn?t mean binder is working on Windows, it?s simply >>>>> get the build going and jextract should be functional. Some test still >>>>> have compiling errors to be fixed, and we don?t have Windows ABI. It?s >>>>> the first step to allow build on Windows. >>>>> I believe a lot of this had been addressed by Jorn, and he actually >>>>> have made more progress on Windows support. Hopefully this is just the >>>>> first step and get Windows going. >>>>> Cheers, >>>>> Henry >>>>> [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev From sundararajan.athijegannathan at oracle.com Mon Oct 29 17:00:01 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 29 Oct 2018 22:30:01 +0530 Subject: [foreign] RFR 8213013: jextract does not handle C99 _Complex type Message-ID: <5BD73C91.5000209@oracle.com> Please review support for C99 _Complex type. Note that "long double" is not yet supported by the binder (a separate bug has been filed). So "long double _Complex" won't work yet. I tested this patch on Mac and Linux. Because of the way complex.h declares functions (using a macro from ), jextract does not extract anything useful with complex.h. I had to redeclare functions of interest in mycomplex.h. In any case, long double _Complex handling functions won't work on Mac as well - hence mycomplex.h file. Bug: https://bugs.openjdk.java.net/browse/JDK-8213013 Webrev: https://cr.openjdk.java.net/~sundar/8213013/webrev.00/index.html Thanks, -Sundar From jbvernee at xs4all.nl Mon Oct 29 17:04:11 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Mon, 29 Oct 2018 18:04:11 +0100 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers Message-ID: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> Hello, Please review this patch which tweaks the binder to allow negative values for native pointers. The problem was previously discussed here: http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ As a reminder, I'm not a committer, so someone else will have to push this. Thanks, Jorn From vladimir.x.ivanov at oracle.com Mon Oct 29 21:47:56 2018 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Mon, 29 Oct 2018 21:47:56 +0000 Subject: hg: panama/dev: Implement Vector API abs and not for AArch64 NEON Message-ID: <201810292147.w9TLlvT2014418@aojmv0008.oracle.com> Changeset: ae8a17841a0c Author: yzhang Date: 2018-10-29 15:52 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/ae8a17841a0c Implement Vector API abs and not for AArch64 NEON Add vabs8B/16B/4S/8S/2I/4I/2L and vnot8b/16B instructions to AArch64 backend to implement Vector API abs() and not(). ! src/hotspot/cpu/aarch64/aarch64.ad From vladimir.x.ivanov at oracle.com Mon Oct 29 22:20:07 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 29 Oct 2018 15:20:07 -0700 Subject: [vector api] RFR: Implement Vector API abs and not for AArch64 NEON In-Reply-To: References: Message-ID: Yang, I'm not AArch64 expert, but it looks fine. Pushed [1] Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/ae8a17841a0c PS: Vector API project policies (in particular and Project Panama policies in general) are lax compared to jdk, so there's no formal requirement to review the changes before the push (still it's a good habit). Once you have Committer rights in the Project, there won't be any need to review Arm-specific code unless you are looking for a feedback. Reviewing & coordingating changes in shared code will still be needed because they may affect many others working on the project. On 29/10/2018 01:01, Yang Zhang (Arm Technology China) wrote: > Hi, > > I have a patch which implement Vector API abs() and not() for AArch64 NEON. > Could you please help to review this? > > Webrev: > http://cr.openjdk.java.net/~yzhang/vectorapi.abs_not/webrev.00/ > > Regards, > Yang > From vladimir.x.ivanov at oracle.com Mon Oct 29 23:15:43 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 29 Oct 2018 16:15:43 -0700 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> Message-ID: <4ce6a73e-6776-c2c6-c039-eb00eeeb3eba@oracle.com> Ningsheng, > http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev01/ > and the test cases: > http://cr.openjdk.java.net/~njian/sve/vectorapi-test.webrev01/ > > All the vector api cases passed on my x86 machines with and without VectorApiIntrinsics. There are some failures on AArch64, but they are not related to this patch and we will fix them in follow-up patches. vectorapi-test.webrev01 looks good. Jp, do you have any comments? Regarding vectorapi.webrev01, please, separate it in 3 patches: (1) VectorIntrinsics-related changes (2) ScalableVector-related changes (3) aarch64-specific changes IMO #3 is fine, but I'd like to hear from Intel folks about #1 & #2. Best regards, Vladimir Ivanov > > Please help to review the changes. > > Thanks, > Ningsheng > > >> -----Original Message----- >> From: Vladimir Ivanov >> Sent: Friday, October 12, 2018 11:18 AM >> To: Ningsheng Jian (Arm Technology China) ; >> panama-dev at openjdk.java.net >> Cc: nd >> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension >> >> >> >>>>>> So, my question boils down to: how vector shape checks are expected >>>>>> to work on *ScalableVectors in presence of operations which change >>>>>> vector >>>> size. >>>>>> >>>>>> For example, IntScalableVector.rebracket() => LongScalableVector >>>>>> which is fine, but ISV.resize() => ISV is what I'm concerned about >>>>>> and existing checks aren't enough for *ScalableVectors unless you >>>>>> check their length at runtime. >>>>> >>>>> Thanks for the detailed explanation. So, which checks do you mean >>>>> here? Do >>>> you mean this [1]? I find that current Java implementations already >>>> has some runtime length checks. One thing we need to consider is the >>>> ambiguity between existing sizes and scalable size. Current >>>> VectorIntrinsics.reinterpret() just tries to get the shape from size >>>> (library_call.cpp:get_exact_klass_for_vector_box) instead of getting >>>> the real class from input argument, which will lead to >>>> ClassCastException. Maybe that can be fixed by adding real klass type to the >> reinterpret function. >>>> >>>> The checks I referred to are the casts on vector shapes which are >>>> part of every vector operation (e.g., [2]), but they don't >>>> immediately relate to shape-changing operations. >>>> >>> >>> OK, but I would expect the normal operations between SV and other vectors >> are illegal, though they may have the same size, since users usually don't know >> the real size of SV. We should treat SV different from other vectors. >> >> Yes, the checks currently in place effectively forbid mixing vectors of different >> shapes. But API allows to reshape/cast vectors to arbitrary shapes and that may >> cause problems if equivalent shapes meet at runtime. >> >> Since concrete vector shapes aren't part of API, I believe it is possible to exclude >> duplicating shapes at runtime. For example, SVs can be used as a substitute for >> *512V shapes on 512-bit SVE or AVX512-capable hardware. It seems current JDK- >> JVM interface >> (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), but it would >> be very interesting to hear your experience. >> >> API allows to query vectors of smaller/larger sizes than hardware natively >> supports and implementation has to support that (even if performance suffers). >> It means SV shapes can coexist at runtime with existing shapes (*64V/.../*512V) >> and casts/reshapes between all those shapes should work. >> >> Best regards, >> Vladimir Ivanov >> >>>> It seems I had some wrong assumptions when coming up with the examples. >>>> Sorry for the confusion. Taking those into account, here's my take on >>>> current state of vector shape changing operations w.r.t. SV shapes. >>>> >>>> There'll be 30 vector shapes in total (5 sizes x 6 element types): >>>> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV >>>> * Short64V, ..., ShortSV >>>> ... >>>> * Double64V, Double128V, ... Double512V, DoubleSV >>>> >>>> Depending on hardware, SVs may alias with "explicitly sized" shapes >>>> (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). >>>> >>>> (1) Vector.rebracket(): works fine for SVs since vector size (in bits) stays the >> same: >>>> IntSV <-> LongSV <-> ... <-> DoubleSV. >>>> >>>> (2) Vector.resize(): SV->SV doesn't make sense and the operation >>>> should involve both SV and existing vector shapes: IntSV <-> >>>> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause >>>> problems and needs to be carefully handled to avoid 2 equivalent >>>> shapes to meet at runtime. Otherwise, vector shape checks I mentioned >> earlier should be changed. >>>> >>> >>> Yes, we will try to address this issue carefully in the follow-up webrev. >>> >>>> (3) Vector.cast(): SV->SV, SV<->64V/.../512V >>>> * size-preserving transformations (int <-> float): >>>> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV; >>>> >>>> * widening casts (e.g., int->long) >>>> SV->SV/64V/...: truncate upper part of the vector, since SVs >>>> already represent widest vector shapes; >>>> 64V/...->SV: either truncated or filled with defaults >>>> depending on actual size >>>> >>>> * narrowing casts (e.g., long->int) >>>> SV->SV/64V/...: fill upper part of SV with defaults; >>>> 64V/...->SV: either truncated or filled with defaults >>>> depending on actual size >>>> >>> >>> Thanks, >>> Ningsheng >>> From henry.jen at oracle.com Mon Oct 29 23:54:08 2018 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 29 Oct 2018 16:54:08 -0700 Subject: RFR: [panama foreign] Build tweak to enable build on Windows In-Reply-To: <4eb272ea-c25c-f941-feea-b873f469500a@oracle.com> References: <42BB9EDB-306D-419C-B8F3-491406C7D664@oracle.com> <2c2e1ac05c52e231749e40fc9f2e2840@xs4all.nl> <6d867c10c5b829ba43db46217e8c7190@xs4all.nl> <2364D4E1-3D83-435A-9FCB-86EF7EE91D3C@oracle.com> <4eb272ea-c25c-f941-feea-b873f469500a@oracle.com> Message-ID: <3D5AE244-87F0-46DE-A754-58489F2EAE0E@oracle.com> Thanks for the review, Erik and Jorn. After looking into alloca, I decided to stick with calloc with free, as alloca is discouraged to use for security concerns and macro is not to be trusted input. I?ll push the webrev with minor change to add a free() and a FIXME comment. Cheers, Henry > On Oct 29, 2018, at 8:59 AM, Erik Joelsson wrote: > > Build changes look ok. > > /Erik > > > On 2018-10-28 22:55, Henry Jen wrote: >> Updated webrev[1] fix the link issue and revert CXX CXXCPP as suggested by Erik. >> >> [1] https://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev.01/webrev/ >> >> Cheers, >> Henry >> >> >>> On Oct 28, 2018, at 9:11 AM, Henry Jen wrote: >>> >>> I think the is caused by link under cygwin on Windows. I?ll double check and fix them. >>> >>> Cheers, >>> Henry >>> >>>> On Oct 28, 2018, at 6:04 AM, Jorn Vernee wrote: >>>> >>>> To add to this (and add missing CCs, sorry about that); >>>> >>>> There are 3 libclang.dll files in the build output after running `make clean images`; >>>> >>>> images\jdk\bin\libclang.dll >>>> jdk\bin\libclang.dll >>>> support\modules_libs\jdk.internal.clang\libclang.dll >>>> >>>> All of these files are only 80 bytes in size, while they are supposed to be 57+ MB. So I think definitely something is going wrong with the copy. I can't find the build system code that does the copying though, so I'm not sure how to debug this. >>>> >>>> AFAIK we are not building the library from scratch on Windows right? Just copying over the .dll from the pre-built distribution? >>>> >>>> Jorn >>>> >>>> Jorn Vernee schreef op 2018-10-27 19:53: >>>>> Hi Henry, >>>>> I'm testing out this patch and can confirm jextract.exe is being >>>>> built, but I can't use it to extract a header file. >>>>> I'm getting an UnsatisfiedLinkError when loading jclang.dll: >>>>> ``` >>>>> PS J:\WS\JNI test\C> jextract Main.h >>>>> Exception in thread "main" java.lang.UnsatisfiedLinkError: >>>>> J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8 >>>>> 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid Win32 >>>>> application >>>>> at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) >>>>> at >>>>> java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462) >>>>> at >>>>> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534) >>>>> at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744) >>>>> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690) >>>>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851) >>>>> at java.base/java.lang.System.loadLibrary(System.java:1903) >>>>> at >>>>> jdk.internal.clang/jdk.internal.clang.LibClang.(LibClang.java:35) >>>>> at >>>>> jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74) >>>>> at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411) >>>>> at jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387) >>>>> at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251) >>>>> at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316) >>>>> ``` >>>>> When inspecting jclang.dll with 'dependency walker' (a DLL inspection >>>>> tool [1]) it's giving an error about libclang.dll (a dependency of >>>>> jclang.dll), which tells me "No DOS or PE signature found. This file >>>>> is not a valid 32-bit or 64-bit Windows module.". However, when I open >>>>> the original libclang.dll file from my LLVM installation it _is_ being >>>>> recognized as a valid DLL. >>>>> I think something is going wrong when copying libclang.dll over? I >>>>> have tried manually copying over the libclang.dll file to the jclang >>>>> and jdk/bin folders, which allows me to extract a header file using >>>>> that command line, but when re-running the build the DLL is being >>>>> overwritten again with the corrupted/invalid version. >>>>> Cheers, >>>>> Jorn >>>>> [1] : http://www.dependencywalker.com/ >>>>> Henry Jen schreef op 2018-10-26 06:44: >>>>>> Hi, >>>>>> Please review a web rev[1] that address following, >>>>>> 1. Copy the essential share library as recorded by the linker >>>>>> following the symbolic link of libclang.so for unix/mac. This leads to >>>>>> only one copy of share library instead of a duplicate copy of >>>>>> libclang.so. It would be nice to have create libclang as a symbolic >>>>>> link, but it?s not needed now. >>>>>> This issue is what failed the build when using system provided >>>>>> libclang on some systems such as Debian-based Linux distribution. >>>>>> After this patch, Debian-based system can be build as described in >>>>>> README.foreign. >>>>>> 2. Enable build on Windows. This patch allow build image to be >>>>>> completed successfully and libclang.dll copied to bin as expected. >>>>>> However, this doesn?t mean binder is working on Windows, it?s simply >>>>>> get the build going and jextract should be functional. Some test still >>>>>> have compiling errors to be fixed, and we don?t have Windows ABI. It?s >>>>>> the first step to allow build on Windows. >>>>>> I believe a lot of this had been addressed by Jorn, and he actually >>>>>> have made more progress on Windows support. Hopefully this is just the >>>>>> first step and get Windows going. >>>>>> Cheers, >>>>>> Henry >>>>>> [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev > From jean-philippe.halimi at intel.com Tue Oct 30 00:55:23 2018 From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe) Date: Tue, 30 Oct 2018 00:55:23 +0000 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: <4ce6a73e-6776-c2c6-c039-eb00eeeb3eba@oracle.com> References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> <4ce6a73e-6776-c2c6-c039-eb00eeeb3eba@oracle.com> Message-ID: I do not have more comments, tests look good to me. Jp -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Monday, October 29, 2018 4:16 PM To: Ningsheng Jian (Arm Technology China) ; panama-dev at openjdk.java.net; Halimi, Jean-Philippe Cc: nd Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension Ningsheng, > http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev01/ > and the test cases: > http://cr.openjdk.java.net/~njian/sve/vectorapi-test.webrev01/ > > All the vector api cases passed on my x86 machines with and without VectorApiIntrinsics. There are some failures on AArch64, but they are not related to this patch and we will fix them in follow-up patches. vectorapi-test.webrev01 looks good. Jp, do you have any comments? Regarding vectorapi.webrev01, please, separate it in 3 patches: (1) VectorIntrinsics-related changes (2) ScalableVector-related changes (3) aarch64-specific changes IMO #3 is fine, but I'd like to hear from Intel folks about #1 & #2. Best regards, Vladimir Ivanov > > Please help to review the changes. > > Thanks, > Ningsheng > > >> -----Original Message----- >> From: Vladimir Ivanov >> Sent: Friday, October 12, 2018 11:18 AM >> To: Ningsheng Jian (Arm Technology China) ; >> panama-dev at openjdk.java.net >> Cc: nd >> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable >> Vector Extension >> >> >> >>>>>> So, my question boils down to: how vector shape checks are >>>>>> expected to work on *ScalableVectors in presence of operations >>>>>> which change vector >>>> size. >>>>>> >>>>>> For example, IntScalableVector.rebracket() => LongScalableVector >>>>>> which is fine, but ISV.resize() => ISV is what I'm concerned >>>>>> about and existing checks aren't enough for *ScalableVectors >>>>>> unless you check their length at runtime. >>>>> >>>>> Thanks for the detailed explanation. So, which checks do you mean >>>>> here? Do >>>> you mean this [1]? I find that current Java implementations already >>>> has some runtime length checks. One thing we need to consider is >>>> the ambiguity between existing sizes and scalable size. Current >>>> VectorIntrinsics.reinterpret() just tries to get the shape from >>>> size >>>> (library_call.cpp:get_exact_klass_for_vector_box) instead of >>>> getting the real class from input argument, which will lead to >>>> ClassCastException. Maybe that can be fixed by adding real klass >>>> type to the >> reinterpret function. >>>> >>>> The checks I referred to are the casts on vector shapes which are >>>> part of every vector operation (e.g., [2]), but they don't >>>> immediately relate to shape-changing operations. >>>> >>> >>> OK, but I would expect the normal operations between SV and other >>> vectors >> are illegal, though they may have the same size, since users usually >> don't know the real size of SV. We should treat SV different from other vectors. >> >> Yes, the checks currently in place effectively forbid mixing vectors >> of different shapes. But API allows to reshape/cast vectors to >> arbitrary shapes and that may cause problems if equivalent shapes meet at runtime. >> >> Since concrete vector shapes aren't part of API, I believe it is >> possible to exclude duplicating shapes at runtime. For example, SVs >> can be used as a substitute for *512V shapes on 512-bit SVE or >> AVX512-capable hardware. It seems current JDK- JVM interface >> (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), >> but it would be very interesting to hear your experience. >> >> API allows to query vectors of smaller/larger sizes than hardware >> natively supports and implementation has to support that (even if performance suffers). >> It means SV shapes can coexist at runtime with existing shapes >> (*64V/.../*512V) and casts/reshapes between all those shapes should work. >> >> Best regards, >> Vladimir Ivanov >> >>>> It seems I had some wrong assumptions when coming up with the examples. >>>> Sorry for the confusion. Taking those into account, here's my take >>>> on current state of vector shape changing operations w.r.t. SV shapes. >>>> >>>> There'll be 30 vector shapes in total (5 sizes x 6 element types): >>>> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV >>>> * Short64V, ..., ShortSV >>>> ... >>>> * Double64V, Double128V, ... Double512V, DoubleSV >>>> >>>> Depending on hardware, SVs may alias with "explicitly sized" shapes >>>> (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). >>>> >>>> (1) Vector.rebracket(): works fine for SVs since vector size (in >>>> bits) stays the >> same: >>>> IntSV <-> LongSV <-> ... <-> DoubleSV. >>>> >>>> (2) Vector.resize(): SV->SV doesn't make sense and the operation >>>> should involve both SV and existing vector shapes: IntSV <-> >>>> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause >>>> problems and needs to be carefully handled to avoid 2 equivalent >>>> shapes to meet at runtime. Otherwise, vector shape checks I >>>> mentioned >> earlier should be changed. >>>> >>> >>> Yes, we will try to address this issue carefully in the follow-up webrev. >>> >>>> (3) Vector.cast(): SV->SV, SV<->64V/.../512V >>>> * size-preserving transformations (int <-> float): >>>> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV; >>>> >>>> * widening casts (e.g., int->long) >>>> SV->SV/64V/...: truncate upper part of the vector, since >>>> SVs already represent widest vector shapes; >>>> 64V/...->SV: either truncated or filled with defaults >>>> depending on actual size >>>> >>>> * narrowing casts (e.g., long->int) >>>> SV->SV/64V/...: fill upper part of SV with defaults; >>>> 64V/...->SV: either truncated or filled with defaults >>>> depending on actual size >>>> >>> >>> Thanks, >>> Ningsheng >>> From henry.jen at oracle.com Tue Oct 30 00:56:30 2018 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 29 Oct 2018 17:56:30 -0700 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> Message-ID: I am afraid this is not that simple, we need to at least protect length from overflow the address to >= 0. I haven?t completely check the implementation, we need to make sure all other operation will not expand or shift the region, which I believe is the constraint of the design. If that?s indeed the case, guard at construction is probably good enough. Cheers, Henry > On Oct 29, 2018, at 10:04 AM, Jorn Vernee wrote: > > Hello, > > Please review this patch which tweaks the binder to allow negative values for native pointers. > > The problem was previously discussed here: http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html > > Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 > Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ > > As a reminder, I'm not a committer, so someone else will have to push this. > > Thanks, > Jorn From henry.jen at oracle.com Tue Oct 30 00:59:11 2018 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 29 Oct 2018 17:59:11 -0700 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> Message-ID: BTW, the change in toString is not needed, as toUnsignedString(l, 16) is same as toHexString(l)? Cheers, Henry > On Oct 29, 2018, at 5:56 PM, Henry Jen wrote: > > I am afraid this is not that simple, we need to at least protect length from overflow the address to >= 0. > > I haven?t completely check the implementation, we need to make sure all other operation will not expand or shift the region, which I believe is the constraint of the design. If that?s indeed the case, guard at construction is probably good enough. > > Cheers, > Henry > >> On Oct 29, 2018, at 10:04 AM, Jorn Vernee wrote: >> >> Hello, >> >> Please review this patch which tweaks the binder to allow negative values for native pointers. >> >> The problem was previously discussed here: http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >> Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >> >> As a reminder, I'm not a committer, so someone else will have to push this. >> >> Thanks, >> Jorn > From jbvernee at xs4all.nl Tue Oct 30 10:26:17 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 30 Oct 2018 11:26:17 +0100 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> Message-ID: You're right about `toUnsignedString`. For some reason I thought `toHexString` had the `-` as a prefix if the argument is negative. About the length constraint; My initial thought was just to trust the pointer returned from native, but I guess we should do better. In the specific case I'm testing, void *, the length that is being used is Long.MAX_VALUE, basically the length is unknown, so I don't think I can do a range check on min + length in the constructor in that case. As far as I can see, the `min` value is only used in a few min + offset calculations before passing to Unsafe put/get routines, I think we'd want to allow overflow to negative there, but not overflow to positive, basically treating the long as if it was unsigned. I think I will switch BoundedMemoryRegion to having factory methods that do the validation, and then have ones where the length is known, which do a range check, and ones where the length is unknown, that cap the it to where it can not overflow. Then I can use the latter for void *. If a bad pointer is passed from native, the known-length case should fail on construction of the memory region, and the unknown-length case should fail when dereferencing (since there is already a bounds check being done). What do you think? Thanks, Jorn Henry Jen schreef op 2018-10-30 01:59: > BTW, the change in toString is not needed, as toUnsignedString(l, 16) > is same as toHexString(l)? > > Cheers, > Henry > > >> On Oct 29, 2018, at 5:56 PM, Henry Jen wrote: >> >> I am afraid this is not that simple, we need to at least protect >> length from overflow the address to >= 0. >> >> I haven?t completely check the implementation, we need to make sure >> all other operation will not expand or shift the region, which I >> believe is the constraint of the design. If that?s indeed the case, >> guard at construction is probably good enough. >> >> Cheers, >> Henry >> >>> On Oct 29, 2018, at 10:04 AM, Jorn Vernee wrote: >>> >>> Hello, >>> >>> Please review this patch which tweaks the binder to allow negative >>> values for native pointers. >>> >>> The problem was previously discussed here: >>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >>> Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >>> >>> As a reminder, I'm not a committer, so someone else will have to push >>> this. >>> >>> Thanks, >>> Jorn >> From Ningsheng.Jian at arm.com Tue Oct 30 10:58:12 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Tue, 30 Oct 2018 10:58:12 +0000 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> <4ce6a73e-6776-c2c6-c039-eb00eeeb3eba@oracle.com> Message-ID: Thank you Vladimir and Jp for the comments! I have separated vectorapi.webrev01 into three patches. Now they are: The scalable vector related changes: http://cr.openjdk.java.net/~njian/vectorapi/01-scalable-vector.webrev0/ Vector intrinsics related changes: http://cr.openjdk.java.net/~njian/vectorapi/02-vector-intrinsics.webrev0/ AArch64 specific changes: http://cr.openjdk.java.net/~njian/vectorapi/03-aarch64-sve.webrev0/ And the tests (the same as previous version): http://cr.openjdk.java.net/~njian/vectorapi/04-tests-scalable-vector.webrev0/ Could you please help to take a look? Thanks, Ningsheng > -----Original Message----- > From: Halimi, Jean-Philippe > Sent: Tuesday, October 30, 2018 8:55 AM > To: Vladimir Ivanov ; Ningsheng Jian (Arm > Technology China) ; panama-dev at openjdk.java.net > Cc: nd > Subject: RE: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension > > I do not have more comments, tests look good to me. > > Jp > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Monday, October 29, 2018 4:16 PM > To: Ningsheng Jian (Arm Technology China) ; > panama-dev at openjdk.java.net; Halimi, Jean-Philippe philippe.halimi at intel.com> > Cc: nd > Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension > > Ningsheng, > > > http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev01/ > > and the test cases: > > http://cr.openjdk.java.net/~njian/sve/vectorapi-test.webrev01/ > > > > All the vector api cases passed on my x86 machines with and without > VectorApiIntrinsics. There are some failures on AArch64, but they are not related > to this patch and we will fix them in follow-up patches. > > vectorapi-test.webrev01 looks good. Jp, do you have any comments? > > Regarding vectorapi.webrev01, please, separate it in 3 patches: > (1) VectorIntrinsics-related changes > (2) ScalableVector-related changes > (3) aarch64-specific changes > > IMO #3 is fine, but I'd like to hear from Intel folks about #1 & #2. > > Best regards, > Vladimir Ivanov > > > > > Please help to review the changes. > > > > Thanks, > > Ningsheng > > > > > >> -----Original Message----- > >> From: Vladimir Ivanov > >> Sent: Friday, October 12, 2018 11:18 AM > >> To: Ningsheng Jian (Arm Technology China) ; > >> panama-dev at openjdk.java.net > >> Cc: nd > >> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable > >> Vector Extension > >> > >> > >> > >>>>>> So, my question boils down to: how vector shape checks are > >>>>>> expected to work on *ScalableVectors in presence of operations > >>>>>> which change vector > >>>> size. > >>>>>> > >>>>>> For example, IntScalableVector.rebracket() => LongScalableVector > >>>>>> which is fine, but ISV.resize() => ISV is what I'm concerned > >>>>>> about and existing checks aren't enough for *ScalableVectors > >>>>>> unless you check their length at runtime. > >>>>> > >>>>> Thanks for the detailed explanation. So, which checks do you mean > >>>>> here? Do > >>>> you mean this [1]? I find that current Java implementations already > >>>> has some runtime length checks. One thing we need to consider is > >>>> the ambiguity between existing sizes and scalable size. Current > >>>> VectorIntrinsics.reinterpret() just tries to get the shape from > >>>> size > >>>> (library_call.cpp:get_exact_klass_for_vector_box) instead of > >>>> getting the real class from input argument, which will lead to > >>>> ClassCastException. Maybe that can be fixed by adding real klass > >>>> type to the > >> reinterpret function. > >>>> > >>>> The checks I referred to are the casts on vector shapes which are > >>>> part of every vector operation (e.g., [2]), but they don't > >>>> immediately relate to shape-changing operations. > >>>> > >>> > >>> OK, but I would expect the normal operations between SV and other > >>> vectors > >> are illegal, though they may have the same size, since users usually > >> don't know the real size of SV. We should treat SV different from other > vectors. > >> > >> Yes, the checks currently in place effectively forbid mixing vectors > >> of different shapes. But API allows to reshape/cast vectors to > >> arbitrary shapes and that may cause problems if equivalent shapes meet at > runtime. > >> > >> Since concrete vector shapes aren't part of API, I believe it is > >> possible to exclude duplicating shapes at runtime. For example, SVs > >> can be used as a substitute for *512V shapes on 512-bit SVE or > >> AVX512-capable hardware. It seems current JDK- JVM interface > >> (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), > >> but it would be very interesting to hear your experience. > >> > >> API allows to query vectors of smaller/larger sizes than hardware > >> natively supports and implementation has to support that (even if > performance suffers). > >> It means SV shapes can coexist at runtime with existing shapes > >> (*64V/.../*512V) and casts/reshapes between all those shapes should work. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>>> It seems I had some wrong assumptions when coming up with the examples. > >>>> Sorry for the confusion. Taking those into account, here's my take > >>>> on current state of vector shape changing operations w.r.t. SV shapes. > >>>> > >>>> There'll be 30 vector shapes in total (5 sizes x 6 element types): > >>>> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV > >>>> * Short64V, ..., ShortSV > >>>> ... > >>>> * Double64V, Double128V, ... Double512V, DoubleSV > >>>> > >>>> Depending on hardware, SVs may alias with "explicitly sized" shapes > >>>> (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). > >>>> > >>>> (1) Vector.rebracket(): works fine for SVs since vector size (in > >>>> bits) stays the > >> same: > >>>> IntSV <-> LongSV <-> ... <-> DoubleSV. > >>>> > >>>> (2) Vector.resize(): SV->SV doesn't make sense and the operation > >>>> should involve both SV and existing vector shapes: IntSV <-> > >>>> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause > >>>> problems and needs to be carefully handled to avoid 2 equivalent > >>>> shapes to meet at runtime. Otherwise, vector shape checks I > >>>> mentioned > >> earlier should be changed. > >>>> > >>> > >>> Yes, we will try to address this issue carefully in the follow-up webrev. > >>> > >>>> (3) Vector.cast(): SV->SV, SV<->64V/.../512V > >>>> * size-preserving transformations (int <-> float): > >>>> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV; > >>>> > >>>> * widening casts (e.g., int->long) > >>>> SV->SV/64V/...: truncate upper part of the vector, since > >>>> SVs already represent widest vector shapes; > >>>> 64V/...->SV: either truncated or filled with defaults > >>>> depending on actual size > >>>> > >>>> * narrowing casts (e.g., long->int) > >>>> SV->SV/64V/...: fill upper part of SV with defaults; > >>>> 64V/...->SV: either truncated or filled with defaults > >>>> depending on actual size > >>>> > >>> > >>> Thanks, > >>> Ningsheng > >>> From henry.jen at oracle.com Tue Oct 30 16:18:05 2018 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 30 Oct 2018 09:18:05 -0700 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> Message-ID: <1AEAA386-A4CC-4BBF-AF85-2A1AB9BACD34@oracle.com> > On Oct 30, 2018, at 3:26 AM, Jorn Vernee wrote: > > You're right about `toUnsignedString`. For some reason I thought `toHexString` had the `-` as a prefix if the argument is negative. > > About the length constraint; My initial thought was just to trust the pointer returned from native, but I guess we should do better. In the specific case I'm testing, void *, the length that is being used is Long.MAX_VALUE, basically the length is unknown, so I don't think I can do a range check on min + length in the constructor in that case. > > As far as I can see, the `min` value is only used in a few min + offset calculations before passing to Unsafe put/get routines, I think we'd want to allow overflow to negative there, but not overflow to positive, basically treating the long as if it was unsigned. > > I think I will switch BoundedMemoryRegion to having factory methods that do the validation, and then have ones where the length is known, which do a range check, and ones where the length is unknown, that cap the it to where it can not overflow. Then I can use the latter for void *. If a bad pointer is passed from native, the known-length case should fail on construction of the memory region, and the unknown-length case should fail when dereferencing (since there is already a bounds check being done). > > What do you think? > +1. Cheers, Henry > Thanks, > Jorn > > Henry Jen schreef op 2018-10-30 01:59: >> BTW, the change in toString is not needed, as toUnsignedString(l, 16) >> is same as toHexString(l)? >> Cheers, >> Henry >>> On Oct 29, 2018, at 5:56 PM, Henry Jen wrote: >>> I am afraid this is not that simple, we need to at least protect length from overflow the address to >= 0. >>> I haven?t completely check the implementation, we need to make sure all other operation will not expand or shift the region, which I believe is the constraint of the design. If that?s indeed the case, guard at construction is probably good enough. >>> Cheers, >>> Henry >>>> On Oct 29, 2018, at 10:04 AM, Jorn Vernee wrote: >>>> Hello, >>>> Please review this patch which tweaks the binder to allow negative values for native pointers. >>>> The problem was previously discussed here: http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >>>> Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >>>> As a reminder, I'm not a committer, so someone else will have to push this. >>>> Thanks, >>>> Jorn From maurizio.cimadamore at oracle.com Tue Oct 30 16:45:47 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 30 Oct 2018 16:45:47 +0000 Subject: [foreign] RFR 8213013: jextract does not handle C99 _Complex type In-Reply-To: <5BD73C91.5000209@oracle.com> References: <5BD73C91.5000209@oracle.com> Message-ID: <6cba0cf8-e11e-2292-e27b-fa50abdc3b1e@oracle.com> Looks good, I'll work on binder support for BigDecimal/BigInteger Maurizio On 29/10/2018 17:00, Sundararajan Athijegannathan wrote: > Please review support for C99 _Complex type. Note that "long double" > is not yet supported by the binder (a separate bug has been filed). So > "long double _Complex" won't work yet. I tested this patch on Mac and > Linux. Because of the way complex.h declares functions (using a macro > from ), jextract does not extract anything useful > with complex.h. I had to redeclare functions of interest in > mycomplex.h. In any case, long double _Complex handling functions > won't work on Mac as well - hence mycomplex.h file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213013 > Webrev: https://cr.openjdk.java.net/~sundar/8213013/webrev.00/index.html > > Thanks, > -Sundar From jbvernee at xs4all.nl Tue Oct 30 16:49:49 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 30 Oct 2018 17:49:49 +0100 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> Message-ID: <1bdc08c88a872f1a1469a9184ee64c09@xs4all.nl> Updated webrev: http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.03/ (beware that the BoundedMemoryRegion diff turned out a bit confusing) - Changed BoundeMemoryRegion to use factory methods. - Factories that don't take a length calculate a max length that can not overflow (in the unsigned sense). - Moved BoundedMemoryRegion anonymous class from Pointer to BoundedMemoryRegion, since constructor is now private. - Added one more test to check for the error in the case where the automatic length calculated for a native pointer is shorter than the length required by the carrier type. - Switched PointerTest to TestNG, since that makes it easier to test for exceptions. I've added a check for the overflow to BoundedMemoryRegion, but when trying to test for it it turned out that BoundedPointer was already catching that case. I've left the check there as it will still be useful to catch programming errors when an explicit length is being passed. Trying to treat a signed long as unsigned is somewhat confusing, maybe we should add an UnsignedLong utility class that abstracts this away in a later RFR, especially if we start allowing 'unsigned' longs in more places. Jorn Jorn Vernee schreef op 2018-10-30 11:26: > You're right about `toUnsignedString`. For some reason I thought > `toHexString` had the `-` as a prefix if the argument is negative. > > About the length constraint; My initial thought was just to trust the > pointer returned from native, but I guess we should do better. In the > specific case I'm testing, void *, the length that is being used is > Long.MAX_VALUE, basically the length is unknown, so I don't think I > can do a range check on min + length in the constructor in that case. > > As far as I can see, the `min` value is only used in a few min + > offset calculations before passing to Unsafe put/get routines, I think > we'd want to allow overflow to negative there, but not overflow to > positive, basically treating the long as if it was unsigned. > > I think I will switch BoundedMemoryRegion to having factory methods > that do the validation, and then have ones where the length is known, > which do a range check, and ones where the length is unknown, that cap > the it to where it can not overflow. Then I can use the latter for > void *. If a bad pointer is passed from native, the known-length case > should fail on construction of the memory region, and the > unknown-length case should fail when dereferencing (since there is > already a bounds check being done). > > What do you think? > > Thanks, > Jorn > > Henry Jen schreef op 2018-10-30 01:59: >> BTW, the change in toString is not needed, as toUnsignedString(l, 16) >> is same as toHexString(l)? >> >> Cheers, >> Henry >> >> >>> On Oct 29, 2018, at 5:56 PM, Henry Jen wrote: >>> >>> I am afraid this is not that simple, we need to at least protect >>> length from overflow the address to >= 0. >>> >>> I haven?t completely check the implementation, we need to make sure >>> all other operation will not expand or shift the region, which I >>> believe is the constraint of the design. If that?s indeed the case, >>> guard at construction is probably good enough. >>> >>> Cheers, >>> Henry >>> >>>> On Oct 29, 2018, at 10:04 AM, Jorn Vernee >>>> wrote: >>>> >>>> Hello, >>>> >>>> Please review this patch which tweaks the binder to allow negative >>>> values for native pointers. >>>> >>>> The problem was previously discussed here: >>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >>>> Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >>>> >>>> As a reminder, I'm not a committer, so someone else will have to >>>> push this. >>>> >>>> Thanks, >>>> Jorn >>> From sundararajan.athijegannathan at oracle.com Tue Oct 30 17:11:57 2018 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 30 Oct 2018 17:11:57 +0000 Subject: hg: panama/dev: 8213013: jextract does not handle C99 _Complex type Message-ID: <201810301711.w9UHBwO0028225@aojmv0008.oracle.com> Changeset: fbcc3855741e Author: sundar Date: 2018-10-30 22:52 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/fbcc3855741e 8213013: jextract does not handle C99 _Complex type Reviewed-by: mcimadamore + src/java.base/share/classes/java/foreign/memory/DoubleComplex.java + src/java.base/share/classes/java/foreign/memory/FloatComplex.java + src/java.base/share/classes/java/foreign/memory/LongDoubleComplex.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/HeaderFile.java ! src/jdk.jextract/share/classes/com/sun/tools/jextract/tree/LayoutUtils.java + test/jdk/com/sun/tools/jextract/complex/ComplexTest.java + test/jdk/com/sun/tools/jextract/complex/mycomplex.h From maurizio.cimadamore at oracle.com Tue Oct 30 17:20:12 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 30 Oct 2018 17:20:12 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810301720.w9UHKCsX002615@aojmv0008.oracle.com> Changeset: 62eec25536f5 Author: mcimadamore Date: 2018-10-30 18:26 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/62eec25536f5 Automatic merge with vectorIntrinsics ! make/RunTests.gmk ! make/conf/jib-profiles.js ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/java.base/share/classes/java/lang/System.java ! test/jdk/TEST.groups - test/jdk/java/util/Locale/LocaleCategory.sh - test/jdk/java/util/Locale/LocaleProviders.sh - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java - test/jdk/lib/testlibrary/ModuleTargetHelper.java - test/jdk/lib/testlibrary/ModuleUtils.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys From maurizio.cimadamore at oracle.com Tue Oct 30 17:20:30 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 30 Oct 2018 17:20:30 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810301720.w9UHKVZJ002906@aojmv0008.oracle.com> Changeset: d9a8ece6322f Author: mcimadamore Date: 2018-10-30 18:26 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/d9a8ece6322f Automatic merge with foreign ! src/hotspot/cpu/x86/macroAssembler_x86.hpp From henry.jen at oracle.com Tue Oct 30 17:21:56 2018 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 30 Oct 2018 17:21:56 +0000 Subject: hg: panama/dev: 8213155: Build should copy libclang using real filename as recorded by linker Message-ID: <201810301721.w9UHLua6003382@aojmv0008.oracle.com> Changeset: 6c2cd902c927 Author: henryjen Date: 2018-10-30 09:56 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/6c2cd902c927 8213155: Build should copy libclang using real filename as recorded by linker Reviewed-by: erikj, Jorn Vernee - enable to build on Windows ! make/autoconf/lib-clang.m4 ! make/autoconf/spec.gmk.in ! make/lib/Lib-jdk.internal.clang.gmk ! src/hotspot/cpu/x86/directUpcallHandler_x86.cpp ! src/hotspot/cpu/x86/foreign_globals_x86.cpp ! src/hotspot/share/prims/directNativeInvoker.cpp ! src/hotspot/share/prims/directUpcallHandler.cpp ! src/hotspot/share/prims/universalUpcallHandler.cpp ! src/hotspot/share/prims/upcallHandler.cpp ! src/jdk.internal.clang/share/native/libjclang/jdk_internal_clang.cpp From maurizio.cimadamore at oracle.com Tue Oct 30 17:23:13 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 30 Oct 2018 17:23:13 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810301723.w9UHNDla004215@aojmv0008.oracle.com> Changeset: 04f8800405cb Author: mcimadamore Date: 2018-10-30 18:29 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/04f8800405cb Automatic merge with foreign From maurizio.cimadamore at oracle.com Tue Oct 30 17:39:03 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 30 Oct 2018 17:39:03 +0000 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: <1bdc08c88a872f1a1469a9184ee64c09@xs4all.nl> References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> <1bdc08c88a872f1a1469a9184ee64c09@xs4all.nl> Message-ID: <29cbc208-28ef-7167-f199-c0ff61737ce2@oracle.com> Looks like a solid piece of work. I like the suggestion proposed in this thread, as well as their implementation. One minor quibble: the PointerTest has a spurious import: import java.beans.Transient Maurizio On 30/10/2018 16:49, Jorn Vernee wrote: > Updated webrev: > http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.03/ > (beware that the BoundedMemoryRegion diff turned out a bit confusing) > > - Changed BoundeMemoryRegion to use factory methods. > - Factories that don't take a length calculate a max length that can > not overflow (in the unsigned sense). > - Moved BoundedMemoryRegion anonymous class from Pointer to > BoundedMemoryRegion, since constructor is now private. > - Added one more test to check for the error in the case where the > automatic length calculated for a native pointer is shorter than the > length required by the carrier type. > - Switched PointerTest to TestNG, since that makes it easier to test > for exceptions. > > I've added a check for the overflow to BoundedMemoryRegion, but when > trying to test for it it turned out that BoundedPointer was already > catching that case. I've left the check there as it will still be > useful to catch programming errors when an explicit length is being > passed. > > Trying to treat a signed long as unsigned is somewhat confusing, maybe > we should add an UnsignedLong utility class that abstracts this away > in a later RFR, especially if we start allowing 'unsigned' longs in > more places. > > Jorn > > Jorn Vernee schreef op 2018-10-30 11:26: >> You're right about `toUnsignedString`. For some reason I thought >> `toHexString` had the `-` as a prefix if the argument is negative. >> >> About the length constraint; My initial thought was just to trust the >> pointer returned from native, but I guess we should do better. In the >> specific case I'm testing, void *, the length that is being used is >> Long.MAX_VALUE, basically the length is unknown, so I don't think I >> can do a range check on min + length in the constructor in that case. >> >> As far as I can see, the `min` value is only used in a few min + >> offset calculations before passing to Unsafe put/get routines, I think >> we'd want to allow overflow to negative there, but not overflow to >> positive, basically treating the long as if it was unsigned. >> >> I think I will switch BoundedMemoryRegion to having factory methods >> that do the validation, and then have ones where the length is known, >> which do a range check, and ones where the length is unknown, that cap >> the it to where it can not overflow. Then I can use the latter for >> void *. If a bad pointer is passed from native, the known-length case >> should fail on construction of the memory region, and the >> unknown-length case should fail when dereferencing (since there is >> already a bounds check being done). >> >> What do you think? >> >> Thanks, >> Jorn >> >> Henry Jen schreef op 2018-10-30 01:59: >>> BTW, the change in toString is not needed, as toUnsignedString(l, 16) >>> is same as toHexString(l)? >>> >>> Cheers, >>> Henry >>> >>> >>>> On Oct 29, 2018, at 5:56 PM, Henry Jen wrote: >>>> >>>> I am afraid this is not that simple, we need to at least protect >>>> length from overflow the address to >= 0. >>>> >>>> I haven?t completely check the implementation, we need to make sure >>>> all other operation will not expand or shift the region, which I >>>> believe is the constraint of the design. If that?s indeed the case, >>>> guard at construction is probably good enough. >>>> >>>> Cheers, >>>> Henry >>>> >>>>> On Oct 29, 2018, at 10:04 AM, Jorn Vernee wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review this patch which tweaks the binder to allow negative >>>>> values for native pointers. >>>>> >>>>> The problem was previously discussed here: >>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >>>>> >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >>>>> Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >>>>> >>>>> As a reminder, I'm not a committer, so someone else will have to >>>>> push this. >>>>> >>>>> Thanks, >>>>> Jorn >>>> From vladimir.x.ivanov at oracle.com Tue Oct 30 17:40:14 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 30 Oct 2018 10:40:14 -0700 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> <4ce6a73e-6776-c2c6-c039-eb00eeeb3eba@oracle.com> Message-ID: <4a761a82-b15d-21b0-a181-79dab3553849@oracle.com> Thanks, Ningsheng. > I have separated vectorapi.webrev01 into three patches. Now they are: > > The scalable vector related changes: > http://cr.openjdk.java.net/~njian/vectorapi/01-scalable-vector.webrev0/ > > Vector intrinsics related changes: > http://cr.openjdk.java.net/~njian/vectorapi/02-vector-intrinsics.webrev0/ What I had in mind is getting VectorIntrinsics.reinterpret/cast() and all related changes (jdk + hotspot) separated, to focus on *ScalableVector shapes in a separate webrev. Sorry for the confusion. > AArch64 specific changes: > http://cr.openjdk.java.net/~njian/vectorapi/03-aarch64-sve.webrev0/ Looks fine. It looks like a stand-alone change ready to be pushed. Do you agree? Best regards, Vladimir Ivanov > > And the tests (the same as previous version): > http://cr.openjdk.java.net/~njian/vectorapi/04-tests-scalable-vector.webrev0/ > > Could you please help to take a look? > > Thanks, > Ningsheng > >> -----Original Message----- >> From: Halimi, Jean-Philippe >> Sent: Tuesday, October 30, 2018 8:55 AM >> To: Vladimir Ivanov ; Ningsheng Jian (Arm >> Technology China) ; panama-dev at openjdk.java.net >> Cc: nd >> Subject: RE: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension >> >> I do not have more comments, tests look good to me. >> >> Jp >> >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Monday, October 29, 2018 4:16 PM >> To: Ningsheng Jian (Arm Technology China) ; >> panama-dev at openjdk.java.net; Halimi, Jean-Philippe > philippe.halimi at intel.com> >> Cc: nd >> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension >> >> Ningsheng, >> >>> http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev01/ >>> and the test cases: >>> http://cr.openjdk.java.net/~njian/sve/vectorapi-test.webrev01/ >>> >>> All the vector api cases passed on my x86 machines with and without >> VectorApiIntrinsics. There are some failures on AArch64, but they are not related >> to this patch and we will fix them in follow-up patches. >> >> vectorapi-test.webrev01 looks good. Jp, do you have any comments? >> >> Regarding vectorapi.webrev01, please, separate it in 3 patches: >> (1) VectorIntrinsics-related changes >> (2) ScalableVector-related changes >> (3) aarch64-specific changes >> >> IMO #3 is fine, but I'd like to hear from Intel folks about #1 & #2. >> >> Best regards, >> Vladimir Ivanov >> >>> >>> Please help to review the changes. >>> >>> Thanks, >>> Ningsheng >>> >>> >>>> -----Original Message----- >>>> From: Vladimir Ivanov >>>> Sent: Friday, October 12, 2018 11:18 AM >>>> To: Ningsheng Jian (Arm Technology China) ; >>>> panama-dev at openjdk.java.net >>>> Cc: nd >>>> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable >>>> Vector Extension >>>> >>>> >>>> >>>>>>>> So, my question boils down to: how vector shape checks are >>>>>>>> expected to work on *ScalableVectors in presence of operations >>>>>>>> which change vector >>>>>> size. >>>>>>>> >>>>>>>> For example, IntScalableVector.rebracket() => LongScalableVector >>>>>>>> which is fine, but ISV.resize() => ISV is what I'm concerned >>>>>>>> about and existing checks aren't enough for *ScalableVectors >>>>>>>> unless you check their length at runtime. >>>>>>> >>>>>>> Thanks for the detailed explanation. So, which checks do you mean >>>>>>> here? Do >>>>>> you mean this [1]? I find that current Java implementations already >>>>>> has some runtime length checks. One thing we need to consider is >>>>>> the ambiguity between existing sizes and scalable size. Current >>>>>> VectorIntrinsics.reinterpret() just tries to get the shape from >>>>>> size >>>>>> (library_call.cpp:get_exact_klass_for_vector_box) instead of >>>>>> getting the real class from input argument, which will lead to >>>>>> ClassCastException. Maybe that can be fixed by adding real klass >>>>>> type to the >>>> reinterpret function. >>>>>> >>>>>> The checks I referred to are the casts on vector shapes which are >>>>>> part of every vector operation (e.g., [2]), but they don't >>>>>> immediately relate to shape-changing operations. >>>>>> >>>>> >>>>> OK, but I would expect the normal operations between SV and other >>>>> vectors >>>> are illegal, though they may have the same size, since users usually >>>> don't know the real size of SV. We should treat SV different from other >> vectors. >>>> >>>> Yes, the checks currently in place effectively forbid mixing vectors >>>> of different shapes. But API allows to reshape/cast vectors to >>>> arbitrary shapes and that may cause problems if equivalent shapes meet at >> runtime. >>>> >>>> Since concrete vector shapes aren't part of API, I believe it is >>>> possible to exclude duplicating shapes at runtime. For example, SVs >>>> can be used as a substitute for *512V shapes on 512-bit SVE or >>>> AVX512-capable hardware. It seems current JDK- JVM interface >>>> (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), >>>> but it would be very interesting to hear your experience. >>>> >>>> API allows to query vectors of smaller/larger sizes than hardware >>>> natively supports and implementation has to support that (even if >> performance suffers). >>>> It means SV shapes can coexist at runtime with existing shapes >>>> (*64V/.../*512V) and casts/reshapes between all those shapes should work. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>>> It seems I had some wrong assumptions when coming up with the examples. >>>>>> Sorry for the confusion. Taking those into account, here's my take >>>>>> on current state of vector shape changing operations w.r.t. SV shapes. >>>>>> >>>>>> There'll be 30 vector shapes in total (5 sizes x 6 element types): >>>>>> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV >>>>>> * Short64V, ..., ShortSV >>>>>> ... >>>>>> * Double64V, Double128V, ... Double512V, DoubleSV >>>>>> >>>>>> Depending on hardware, SVs may alias with "explicitly sized" shapes >>>>>> (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). >>>>>> >>>>>> (1) Vector.rebracket(): works fine for SVs since vector size (in >>>>>> bits) stays the >>>> same: >>>>>> IntSV <-> LongSV <-> ... <-> DoubleSV. >>>>>> >>>>>> (2) Vector.resize(): SV->SV doesn't make sense and the operation >>>>>> should involve both SV and existing vector shapes: IntSV <-> >>>>>> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause >>>>>> problems and needs to be carefully handled to avoid 2 equivalent >>>>>> shapes to meet at runtime. Otherwise, vector shape checks I >>>>>> mentioned >>>> earlier should be changed. >>>>>> >>>>> >>>>> Yes, we will try to address this issue carefully in the follow-up webrev. >>>>> >>>>>> (3) Vector.cast(): SV->SV, SV<->64V/.../512V >>>>>> * size-preserving transformations (int <-> float): >>>>>> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> DoubleSV; >>>>>> >>>>>> * widening casts (e.g., int->long) >>>>>> SV->SV/64V/...: truncate upper part of the vector, since >>>>>> SVs already represent widest vector shapes; >>>>>> 64V/...->SV: either truncated or filled with defaults >>>>>> depending on actual size >>>>>> >>>>>> * narrowing casts (e.g., long->int) >>>>>> SV->SV/64V/...: fill upper part of SV with defaults; >>>>>> 64V/...->SV: either truncated or filled with defaults >>>>>> depending on actual size >>>>>> >>>>> >>>>> Thanks, >>>>> Ningsheng >>>>> From henry.jen at oracle.com Tue Oct 30 17:46:19 2018 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 30 Oct 2018 10:46:19 -0700 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: <1bdc08c88a872f1a1469a9184ee64c09@xs4all.nl> References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> <1bdc08c88a872f1a1469a9184ee64c09@xs4all.nl> Message-ID: <7FA573B7-C838-4431-9512-B3D8BF396996@oracle.com> I wonder if it can be simplified a little bit, let?s say address is indeed 0xFFFFFFFF, we should be able to have a memory region of length 1. When the min(real address) is negative, the cap of length for unknown is pretty much just to negate the value of min. min + length should be <= 0. We can only access min + offset - 1, so that we won?t access 0x0 in negative case. What do you think? Cheers, Henry > On Oct 30, 2018, at 9:49 AM, Jorn Vernee wrote: > > Updated webrev: http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.03/ > (beware that the BoundedMemoryRegion diff turned out a bit confusing) > > - Changed BoundeMemoryRegion to use factory methods. > - Factories that don't take a length calculate a max length that can not overflow (in the unsigned sense). > - Moved BoundedMemoryRegion anonymous class from Pointer to BoundedMemoryRegion, since constructor is now private. > - Added one more test to check for the error in the case where the automatic length calculated for a native pointer is shorter than the length required by the carrier type. > - Switched PointerTest to TestNG, since that makes it easier to test for exceptions. > > I've added a check for the overflow to BoundedMemoryRegion, but when trying to test for it it turned out that BoundedPointer was already catching that case. I've left the check there as it will still be useful to catch programming errors when an explicit length is being passed. > > Trying to treat a signed long as unsigned is somewhat confusing, maybe we should add an UnsignedLong utility class that abstracts this away in a later RFR, especially if we start allowing 'unsigned' longs in more places. > > Jorn > > Jorn Vernee schreef op 2018-10-30 11:26: >> You're right about `toUnsignedString`. For some reason I thought >> `toHexString` had the `-` as a prefix if the argument is negative. >> About the length constraint; My initial thought was just to trust the >> pointer returned from native, but I guess we should do better. In the >> specific case I'm testing, void *, the length that is being used is >> Long.MAX_VALUE, basically the length is unknown, so I don't think I >> can do a range check on min + length in the constructor in that case. >> As far as I can see, the `min` value is only used in a few min + >> offset calculations before passing to Unsafe put/get routines, I think >> we'd want to allow overflow to negative there, but not overflow to >> positive, basically treating the long as if it was unsigned. >> I think I will switch BoundedMemoryRegion to having factory methods >> that do the validation, and then have ones where the length is known, >> which do a range check, and ones where the length is unknown, that cap >> the it to where it can not overflow. Then I can use the latter for >> void *. If a bad pointer is passed from native, the known-length case >> should fail on construction of the memory region, and the >> unknown-length case should fail when dereferencing (since there is >> already a bounds check being done). >> What do you think? >> Thanks, >> Jorn >> Henry Jen schreef op 2018-10-30 01:59: >>> BTW, the change in toString is not needed, as toUnsignedString(l, 16) >>> is same as toHexString(l)? >>> Cheers, >>> Henry >>>> On Oct 29, 2018, at 5:56 PM, Henry Jen wrote: >>>> I am afraid this is not that simple, we need to at least protect length from overflow the address to >= 0. >>>> I haven?t completely check the implementation, we need to make sure all other operation will not expand or shift the region, which I believe is the constraint of the design. If that?s indeed the case, guard at construction is probably good enough. >>>> Cheers, >>>> Henry >>>>> On Oct 29, 2018, at 10:04 AM, Jorn Vernee wrote: >>>>> Hello, >>>>> Please review this patch which tweaks the binder to allow negative values for native pointers. >>>>> The problem was previously discussed here: http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >>>>> Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >>>>> As a reminder, I'm not a committer, so someone else will have to push this. >>>>> Thanks, >>>>> Jorn From jean-philippe.halimi at intel.com Tue Oct 30 18:44:29 2018 From: jean-philippe.halimi at intel.com (jean-philippe.halimi at intel.com) Date: Tue, 30 Oct 2018 18:44:29 +0000 Subject: hg: panama/dev: VectorAPI: Crash fixes in SVML for Windows Message-ID: <201810301844.w9UIiTDa020783@aojmv0008.oracle.com> Changeset: 02dc87f48e2f Author: jphalimi Date: 2018-10-30 11:43 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/02dc87f48e2f VectorAPI: Crash fixes in SVML for Windows ! src/hotspot/os_cpu/windows_x86/svml_d_acos_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_asin_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_atan2_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_atan_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_cbrt_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_cos_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_cosh_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_exp_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_expm1_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_hypot_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_log10_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_log1p_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_log_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_pow_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_sin_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_sinh_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_tan_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_d_tanh_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_acos_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_asin_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_atan2_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_atan_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_cbrt_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_cos_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_cosh_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_exp_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_expm1_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_hypot_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_log10_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_log1p_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_log_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_pow_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_sin_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_sinh_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_tan_windows_x86.s ! src/hotspot/os_cpu/windows_x86/svml_s_tanh_windows_x86.s From maurizio.cimadamore at oracle.com Tue Oct 30 18:48:00 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 30 Oct 2018 18:48:00 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810301848.w9UIm1F9022414@aojmv0008.oracle.com> Changeset: f1afd0ae2932 Author: mcimadamore Date: 2018-10-30 19:54 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/f1afd0ae2932 Automatic merge with vectorIntrinsics From jbvernee at xs4all.nl Tue Oct 30 18:52:11 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Tue, 30 Oct 2018 19:52:11 +0100 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: <7FA573B7-C838-4431-9512-B3D8BF396996@oracle.com> References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> <1bdc08c88a872f1a1469a9184ee64c09@xs4all.nl> <7FA573B7-C838-4431-9512-B3D8BF396996@oracle.com> Message-ID: Henry Jen schreef op 2018-10-30 18:46: > I wonder if it can be simplified a little bit, let?s say address is > indeed 0xFFFFFFFF, we should be able to have a memory region of length > 1. Yes, that's a good point. That will allow for a 1 byte memory region at 0xFFFFFFFF. I've also added a test for that exact case. > When the min(real address) is negative, the cap of length for unknown > is pretty much just to negate the value of min. Yes! And I think when min is positive the length maximum is always Long.MAX_VALUE. > min + length should be <= 0. We can only access min + offset - 1, so > that we won?t access 0x0 in negative case. That won't work for the case where min and length are both positive, but min + length is also positive. In that case the check should also pass. The way I have it right now, since length is always positive, min + length can only overflow to positive if min is negative, so that's also the check :) But I've changed it to check for min + length > 0 to allow for a 1 byte region if min == -1L. > What do you think? Good suggestions, here is the updated webrev: http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.04/index.html I've also removed the spurious import in PointerTest, which auto-complete put in there when auto-completing to @Transient instead of @Test :) > Cheers, > Henry > Thanks for the reviews, Jorn > >> On Oct 30, 2018, at 9:49 AM, Jorn Vernee wrote: >> >> Updated webrev: >> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.03/ >> (beware that the BoundedMemoryRegion diff turned out a bit confusing) >> >> - Changed BoundeMemoryRegion to use factory methods. >> - Factories that don't take a length calculate a max length that can >> not overflow (in the unsigned sense). >> - Moved BoundedMemoryRegion anonymous class from Pointer to >> BoundedMemoryRegion, since constructor is now private. >> - Added one more test to check for the error in the case where the >> automatic length calculated for a native pointer is shorter than the >> length required by the carrier type. >> - Switched PointerTest to TestNG, since that makes it easier to test >> for exceptions. >> >> I've added a check for the overflow to BoundedMemoryRegion, but when >> trying to test for it it turned out that BoundedPointer was already >> catching that case. I've left the check there as it will still be >> useful to catch programming errors when an explicit length is being >> passed. >> >> Trying to treat a signed long as unsigned is somewhat confusing, maybe >> we should add an UnsignedLong utility class that abstracts this away >> in a later RFR, especially if we start allowing 'unsigned' longs in >> more places. >> >> Jorn >> >> Jorn Vernee schreef op 2018-10-30 11:26: >>> You're right about `toUnsignedString`. For some reason I thought >>> `toHexString` had the `-` as a prefix if the argument is negative. >>> About the length constraint; My initial thought was just to trust the >>> pointer returned from native, but I guess we should do better. In the >>> specific case I'm testing, void *, the length that is being used is >>> Long.MAX_VALUE, basically the length is unknown, so I don't think I >>> can do a range check on min + length in the constructor in that case. >>> As far as I can see, the `min` value is only used in a few min + >>> offset calculations before passing to Unsafe put/get routines, I >>> think >>> we'd want to allow overflow to negative there, but not overflow to >>> positive, basically treating the long as if it was unsigned. >>> I think I will switch BoundedMemoryRegion to having factory methods >>> that do the validation, and then have ones where the length is known, >>> which do a range check, and ones where the length is unknown, that >>> cap >>> the it to where it can not overflow. Then I can use the latter for >>> void *. If a bad pointer is passed from native, the known-length case >>> should fail on construction of the memory region, and the >>> unknown-length case should fail when dereferencing (since there is >>> already a bounds check being done). >>> What do you think? >>> Thanks, >>> Jorn >>> Henry Jen schreef op 2018-10-30 01:59: >>>> BTW, the change in toString is not needed, as toUnsignedString(l, >>>> 16) >>>> is same as toHexString(l)? >>>> Cheers, >>>> Henry >>>>> On Oct 29, 2018, at 5:56 PM, Henry Jen >>>>> wrote: >>>>> I am afraid this is not that simple, we need to at least protect >>>>> length from overflow the address to >= 0. >>>>> I haven?t completely check the implementation, we need to make sure >>>>> all other operation will not expand or shift the region, which I >>>>> believe is the constraint of the design. If that?s indeed the case, >>>>> guard at construction is probably good enough. >>>>> Cheers, >>>>> Henry >>>>>> On Oct 29, 2018, at 10:04 AM, Jorn Vernee >>>>>> wrote: >>>>>> Hello, >>>>>> Please review this patch which tweaks the binder to allow negative >>>>>> values for native pointers. >>>>>> The problem was previously discussed here: >>>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >>>>>> Webrev : >>>>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >>>>>> As a reminder, I'm not a committer, so someone else will have to >>>>>> push this. >>>>>> Thanks, >>>>>> Jorn From jean-philippe.halimi at intel.com Tue Oct 30 23:30:55 2018 From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe) Date: Tue, 30 Oct 2018 23:30:55 +0000 Subject: VectorAPI: Fix for cos, sin and tan routines on Windows for IA/AVX512 Message-ID: Hi, I would like to contribute to VectorAPI with a fix for SVML routines for Windows on IA/AVX512. http://cr.openjdk.java.net/~jphalimi/webrev_svml_fix_avx512/webrev/ Please let me know what your thoughts are. Thanks, Jp From henry.jen at oracle.com Wed Oct 31 00:05:19 2018 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 30 Oct 2018 17:05:19 -0700 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> <1bdc08c88a872f1a1469a9184ee64c09@xs4all.nl> <7FA573B7-C838-4431-9512-B3D8BF396996@oracle.com> Message-ID: <384BCAC0-0EB6-419B-A91A-6BE7596539C7@oracle.com> That looks good, but we still have a little issue to iron out. New test failed because of BoundedPointer is offsetting EVERYTHING region, where length set to Long.MAX_VALUE. Cheers, Henry > test PointerTest.test1ByteRegionAtMaxHeapOffset(): failure > java.lang.IndexOutOfBoundsException: offset=0xffffffffffffffff length=0x7fffffffffffffff > at java.base/jdk.internal.foreign.memory.BoundedMemoryRegion.checkBounds(BoundedMemoryRegion.java:153) > at java.base/jdk.internal.foreign.memory.BoundedMemoryRegion.checkRange(BoundedMemoryRegion.java:158) > at java.base/jdk.internal.foreign.memory.BoundedPointer.(BoundedPointer.java:77) > at java.base/jdk.internal.foreign.memory.BoundedPointer.(BoundedPointer.java:68) > at java.base/jdk.internal.foreign.memory.BoundedPointer.createNativeVoidPointer(BoundedPointer.java:175) > at java.base/jdk.internal.foreign.invokers.DirectSignatureShuffler.longToPointer(DirectSignatureShuffler.java:335) > at PointerTest$pointers$Impl/0x00000007c035b440.get_1_byte_pointer(Unknown Source) > at PointerTest.test1ByteRegionAtMaxHeapOffset(PointerTest.java:297) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Metho > On Oct 30, 2018, at 11:52 AM, Jorn Vernee wrote: > > Henry Jen schreef op 2018-10-30 18:46: >> I wonder if it can be simplified a little bit, let?s say address is >> indeed 0xFFFFFFFF, we should be able to have a memory region of length >> 1. > > Yes, that's a good point. That will allow for a 1 byte memory region at 0xFFFFFFFF. > > I've also added a test for that exact case. > >> When the min(real address) is negative, the cap of length for unknown >> is pretty much just to negate the value of min. > > Yes! And I think when min is positive the length maximum is always Long.MAX_VALUE. > >> min + length should be <= 0. We can only access min + offset - 1, so >> that we won?t access 0x0 in negative case. > > That won't work for the case where min and length are both positive, but min + length is also positive. In that case the check should also pass. > > The way I have it right now, since length is always positive, min + length can only overflow to positive if min is negative, so that's also the check :) But I've changed it to check for min + length > 0 to allow for a 1 byte region if min == -1L. > >> What do you think? > > Good suggestions, here is the updated webrev: http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.04/index.html > > I've also removed the spurious import in PointerTest, which auto-complete put in there when auto-completing to @Transient instead of @Test :) > >> Cheers, >> Henry > > Thanks for the reviews, > Jorn > >>> On Oct 30, 2018, at 9:49 AM, Jorn Vernee wrote: >>> Updated webrev: http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.03/ >>> (beware that the BoundedMemoryRegion diff turned out a bit confusing) >>> - Changed BoundeMemoryRegion to use factory methods. >>> - Factories that don't take a length calculate a max length that can not overflow (in the unsigned sense). >>> - Moved BoundedMemoryRegion anonymous class from Pointer to BoundedMemoryRegion, since constructor is now private. >>> - Added one more test to check for the error in the case where the automatic length calculated for a native pointer is shorter than the length required by the carrier type. >>> - Switched PointerTest to TestNG, since that makes it easier to test for exceptions. >>> I've added a check for the overflow to BoundedMemoryRegion, but when trying to test for it it turned out that BoundedPointer was already catching that case. I've left the check there as it will still be useful to catch programming errors when an explicit length is being passed. >>> Trying to treat a signed long as unsigned is somewhat confusing, maybe we should add an UnsignedLong utility class that abstracts this away in a later RFR, especially if we start allowing 'unsigned' longs in more places. >>> Jorn >>> Jorn Vernee schreef op 2018-10-30 11:26: >>>> You're right about `toUnsignedString`. For some reason I thought >>>> `toHexString` had the `-` as a prefix if the argument is negative. >>>> About the length constraint; My initial thought was just to trust the >>>> pointer returned from native, but I guess we should do better. In the >>>> specific case I'm testing, void *, the length that is being used is >>>> Long.MAX_VALUE, basically the length is unknown, so I don't think I >>>> can do a range check on min + length in the constructor in that case. >>>> As far as I can see, the `min` value is only used in a few min + >>>> offset calculations before passing to Unsafe put/get routines, I think >>>> we'd want to allow overflow to negative there, but not overflow to >>>> positive, basically treating the long as if it was unsigned. >>>> I think I will switch BoundedMemoryRegion to having factory methods >>>> that do the validation, and then have ones where the length is known, >>>> which do a range check, and ones where the length is unknown, that cap >>>> the it to where it can not overflow. Then I can use the latter for >>>> void *. If a bad pointer is passed from native, the known-length case >>>> should fail on construction of the memory region, and the >>>> unknown-length case should fail when dereferencing (since there is >>>> already a bounds check being done). >>>> What do you think? >>>> Thanks, >>>> Jorn >>>> Henry Jen schreef op 2018-10-30 01:59: >>>>> BTW, the change in toString is not needed, as toUnsignedString(l, 16) >>>>> is same as toHexString(l)? >>>>> Cheers, >>>>> Henry >>>>>> On Oct 29, 2018, at 5:56 PM, Henry Jen wrote: >>>>>> I am afraid this is not that simple, we need to at least protect length from overflow the address to >= 0. >>>>>> I haven?t completely check the implementation, we need to make sure all other operation will not expand or shift the region, which I believe is the constraint of the design. If that?s indeed the case, guard at construction is probably good enough. >>>>>> Cheers, >>>>>> Henry >>>>>>> On Oct 29, 2018, at 10:04 AM, Jorn Vernee wrote: >>>>>>> Hello, >>>>>>> Please review this patch which tweaks the binder to allow negative values for native pointers. >>>>>>> The problem was previously discussed here: http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >>>>>>> Webrev : http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >>>>>>> As a reminder, I'm not a committer, so someone else will have to push this. >>>>>>> Thanks, >>>>>>> Jorn From Yang.Zhang at arm.com Wed Oct 31 03:56:44 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Wed, 31 Oct 2018 03:56:44 +0000 Subject: [vector api] RFR: Implement Vector API abs and not for AArch64 NEON In-Reply-To: References: Message-ID: Vladimir Thanks very much. Regards Yang -----Original Message----- From: Vladimir Ivanov Sent: Tuesday, October 30, 2018 6:20 AM To: Yang Zhang (Arm Technology China) ; panama-dev at openjdk.java.net Cc: nd Subject: Re: [vector api] RFR: Implement Vector API abs and not for AArch64 NEON Yang, I'm not AArch64 expert, but it looks fine. Pushed [1] Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/ae8a17841a0c PS: Vector API project policies (in particular and Project Panama policies in general) are lax compared to jdk, so there's no formal requirement to review the changes before the push (still it's a good habit). Once you have Committer rights in the Project, there won't be any need to review Arm-specific code unless you are looking for a feedback. Reviewing & coordingating changes in shared code will still be needed because they may affect many others working on the project. On 29/10/2018 01:01, Yang Zhang (Arm Technology China) wrote: > Hi, > > I have a patch which implement Vector API abs() and not() for AArch64 NEON. > Could you please help to review this? > > Webrev: > http://cr.openjdk.java.net/~yzhang/vectorapi.abs_not/webrev.00/ > > Regards, > Yang > From Ningsheng.Jian at arm.com Wed Oct 31 10:19:40 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Wed, 31 Oct 2018 10:19:40 +0000 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: <4a761a82-b15d-21b0-a181-79dab3553849@oracle.com> References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> <4ce6a73e-6776-c2c6-c039-eb00eeeb3eba@oracle.com> <4a761a82-b15d-21b0-a181-79dab3553849@oracle.com> Message-ID: Thank you Vladimir! I have restructured the webrevs as follows: 1) VectorIntrinsics reinterpret/cast changes: http://cr.openjdk.java.net/~njian/vectorapi/01-vectorintrinsics-reinterpret.webrev1/ 2) Scalable vector related changes: http://cr.openjdk.java.net/~njian/vectorapi/02-scalable-vector.webrev1/ 3) AArch64 specific changes: http://cr.openjdk.java.net/~njian/vectorapi/03-aarch64-sve.webrev1/ This is the same as previous version, and yes, this is a standalone change and can be applied and pushed cleanly. I am OK to push this first. Thanks! 4) Tests (the same as previous version): http://cr.openjdk.java.net/~njian/vectorapi/04-tests-scalable-vector.webrev1/ Thanks, Ningsheng > -----Original Message----- > From: Vladimir Ivanov > Sent: Wednesday, October 31, 2018 1:40 AM > To: Ningsheng Jian (Arm Technology China) ; > panama-dev at openjdk.java.net > Cc: nd > Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension > > Thanks, Ningsheng. > > > I have separated vectorapi.webrev01 into three patches. Now they are: > > > > The scalable vector related changes: > > http://cr.openjdk.java.net/~njian/vectorapi/01-scalable-vector.webrev0 > > / > > > > Vector intrinsics related changes: > > http://cr.openjdk.java.net/~njian/vectorapi/02-vector-intrinsics.webre > > v0/ > > What I had in mind is getting VectorIntrinsics.reinterpret/cast() and all related > changes (jdk + hotspot) separated, to focus on *ScalableVector shapes in a > separate webrev. > > Sorry for the confusion. > > > AArch64 specific changes: > > http://cr.openjdk.java.net/~njian/vectorapi/03-aarch64-sve.webrev0/ > > Looks fine. It looks like a stand-alone change ready to be pushed. Do you agree? > > Best regards, > Vladimir Ivanov > > > > > And the tests (the same as previous version): > > http://cr.openjdk.java.net/~njian/vectorapi/04-tests-scalable-vector.w > > ebrev0/ > > > > Could you please help to take a look? > > > > Thanks, > > Ningsheng > > > >> -----Original Message----- > >> From: Halimi, Jean-Philippe > >> Sent: Tuesday, October 30, 2018 8:55 AM > >> To: Vladimir Ivanov ; Ningsheng Jian > >> (Arm Technology China) ; > >> panama-dev at openjdk.java.net > >> Cc: nd > >> Subject: RE: [vector] RFC: Add scalable shapes for Arm Scalable > >> Vector Extension > >> > >> I do not have more comments, tests look good to me. > >> > >> Jp > >> > >> -----Original Message----- > >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > >> Sent: Monday, October 29, 2018 4:16 PM > >> To: Ningsheng Jian (Arm Technology China) ; > >> panama-dev at openjdk.java.net; Halimi, Jean-Philippe >> philippe.halimi at intel.com> > >> Cc: nd > >> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable > >> Vector Extension > >> > >> Ningsheng, > >> > >>> http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev01/ > >>> and the test cases: > >>> http://cr.openjdk.java.net/~njian/sve/vectorapi-test.webrev01/ > >>> > >>> All the vector api cases passed on my x86 machines with and without > >> VectorApiIntrinsics. There are some failures on AArch64, but they are > >> not related to this patch and we will fix them in follow-up patches. > >> > >> vectorapi-test.webrev01 looks good. Jp, do you have any comments? > >> > >> Regarding vectorapi.webrev01, please, separate it in 3 patches: > >> (1) VectorIntrinsics-related changes > >> (2) ScalableVector-related changes > >> (3) aarch64-specific changes > >> > >> IMO #3 is fine, but I'd like to hear from Intel folks about #1 & #2. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>> > >>> Please help to review the changes. > >>> > >>> Thanks, > >>> Ningsheng > >>> > >>> > >>>> -----Original Message----- > >>>> From: Vladimir Ivanov > >>>> Sent: Friday, October 12, 2018 11:18 AM > >>>> To: Ningsheng Jian (Arm Technology China) ; > >>>> panama-dev at openjdk.java.net > >>>> Cc: nd > >>>> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable > >>>> Vector Extension > >>>> > >>>> > >>>> > >>>>>>>> So, my question boils down to: how vector shape checks are > >>>>>>>> expected to work on *ScalableVectors in presence of operations > >>>>>>>> which change vector > >>>>>> size. > >>>>>>>> > >>>>>>>> For example, IntScalableVector.rebracket() => > >>>>>>>> LongScalableVector which is fine, but ISV.resize() => ISV is > >>>>>>>> what I'm concerned about and existing checks aren't enough for > >>>>>>>> *ScalableVectors unless you check their length at runtime. > >>>>>>> > >>>>>>> Thanks for the detailed explanation. So, which checks do you > >>>>>>> mean here? Do > >>>>>> you mean this [1]? I find that current Java implementations > >>>>>> already has some runtime length checks. One thing we need to > >>>>>> consider is the ambiguity between existing sizes and scalable > >>>>>> size. Current > >>>>>> VectorIntrinsics.reinterpret() just tries to get the shape from > >>>>>> size > >>>>>> (library_call.cpp:get_exact_klass_for_vector_box) instead of > >>>>>> getting the real class from input argument, which will lead to > >>>>>> ClassCastException. Maybe that can be fixed by adding real klass > >>>>>> type to the > >>>> reinterpret function. > >>>>>> > >>>>>> The checks I referred to are the casts on vector shapes which are > >>>>>> part of every vector operation (e.g., [2]), but they don't > >>>>>> immediately relate to shape-changing operations. > >>>>>> > >>>>> > >>>>> OK, but I would expect the normal operations between SV and other > >>>>> vectors > >>>> are illegal, though they may have the same size, since users > >>>> usually don't know the real size of SV. We should treat SV > >>>> different from other > >> vectors. > >>>> > >>>> Yes, the checks currently in place effectively forbid mixing > >>>> vectors of different shapes. But API allows to reshape/cast vectors > >>>> to arbitrary shapes and that may cause problems if equivalent > >>>> shapes meet at > >> runtime. > >>>> > >>>> Since concrete vector shapes aren't part of API, I believe it is > >>>> possible to exclude duplicating shapes at runtime. For example, SVs > >>>> can be used as a substitute for *512V shapes on 512-bit SVE or > >>>> AVX512-capable hardware. It seems current JDK- JVM interface > >>>> (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), > >>>> but it would be very interesting to hear your experience. > >>>> > >>>> API allows to query vectors of smaller/larger sizes than hardware > >>>> natively supports and implementation has to support that (even if > >> performance suffers). > >>>> It means SV shapes can coexist at runtime with existing shapes > >>>> (*64V/.../*512V) and casts/reshapes between all those shapes should work. > >>>> > >>>> Best regards, > >>>> Vladimir Ivanov > >>>> > >>>>>> It seems I had some wrong assumptions when coming up with the > examples. > >>>>>> Sorry for the confusion. Taking those into account, here's my > >>>>>> take on current state of vector shape changing operations w.r.t. SV > shapes. > >>>>>> > >>>>>> There'll be 30 vector shapes in total (5 sizes x 6 element types): > >>>>>> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV > >>>>>> * Short64V, ..., ShortSV > >>>>>> ... > >>>>>> * Double64V, Double128V, ... Double512V, DoubleSV > >>>>>> > >>>>>> Depending on hardware, SVs may alias with "explicitly sized" > >>>>>> shapes (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). > >>>>>> > >>>>>> (1) Vector.rebracket(): works fine for SVs since vector size (in > >>>>>> bits) stays the > >>>> same: > >>>>>> IntSV <-> LongSV <-> ... <-> DoubleSV. > >>>>>> > >>>>>> (2) Vector.resize(): SV->SV doesn't make sense and the operation > >>>>>> should involve both SV and existing vector shapes: IntSV <-> > >>>>>> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause > >>>>>> problems and needs to be carefully handled to avoid 2 equivalent > >>>>>> shapes to meet at runtime. Otherwise, vector shape checks I > >>>>>> mentioned > >>>> earlier should be changed. > >>>>>> > >>>>> > >>>>> Yes, we will try to address this issue carefully in the follow-up webrev. > >>>>> > >>>>>> (3) Vector.cast(): SV->SV, SV<->64V/.../512V > >>>>>> * size-preserving transformations (int <-> float): > >>>>>> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> > >>>>>> DoubleSV; > >>>>>> > >>>>>> * widening casts (e.g., int->long) > >>>>>> SV->SV/64V/...: truncate upper part of the vector, > >>>>>> since SVs already represent widest vector shapes; > >>>>>> 64V/...->SV: either truncated or filled with defaults > >>>>>> depending on actual size > >>>>>> > >>>>>> * narrowing casts (e.g., long->int) > >>>>>> SV->SV/64V/...: fill upper part of SV with defaults; > >>>>>> 64V/...->SV: either truncated or filled with defaults > >>>>>> depending on actual size > >>>>>> > >>>>> > >>>>> Thanks, > >>>>> Ningsheng > >>>>> From jbvernee at xs4all.nl Wed Oct 31 11:02:59 2018 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Wed, 31 Oct 2018 12:02:59 +0100 Subject: [foreign] RFR 8212987 : Binder should allows negative values for native pointers In-Reply-To: <384BCAC0-0EB6-419B-A91A-6BE7596539C7@oracle.com> References: <239bc5ed9a98b3b6585006676fbc179b@xs4all.nl> <1bdc08c88a872f1a1469a9184ee64c09@xs4all.nl> <7FA573B7-C838-4431-9512-B3D8BF396996@oracle.com> <384BCAC0-0EB6-419B-A91A-6BE7596539C7@oracle.com> Message-ID: <2cfbb133ba447f652116e099082cf5eb@xs4all.nl> Oh. I ran the tests, but I'm getting a pass there since Windows does not use the direct invoker, which means a different factory method on BoundedPointer is getting called, which doesn't offset into EVERYTHING. I'm afraid that's not something I can test right now by myself. I tried to fix it by removing EVERYTHING in favor of calling BoundedMemoryRegion.of(offset). But when testing that I'm seeing a bunch of crashes in `V ~BufferBlob::invoke_native_blob` [1]. I think that is the generated downcall stub that's crashing right? Not sure what that's about, but I guess maybe some objects are now getting GC'd too early since the memory region is no longer saved in a static field, or maybe I still have a bug in that stub generation code :/ (I took another look, but everything looks OK to me). So instead I've made EVERYTHING an anonymous subclass which overrides checkBounds to be empty, since technically any offset is in bounds. I also realized the calculation still needed a special case for Long.MIN_VALUE since that can't be negated. Can you test the new webrev? http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.05/ Thanks, Jorn [1] : http://hg.openjdk.java.net/panama/dev/file/f1afd0ae2932/src/hotspot/share/prims/universalNativeInvoker.cpp#l44 Henry Jen schreef op 2018-10-31 01:05: > That looks good, but we still have a little issue to iron out. > > New test failed because of BoundedPointer is offsetting EVERYTHING > region, where length set to Long.MAX_VALUE. > > Cheers, > Henry > >> test PointerTest.test1ByteRegionAtMaxHeapOffset(): failure >> java.lang.IndexOutOfBoundsException: offset=0xffffffffffffffff >> length=0x7fffffffffffffff >> at >> java.base/jdk.internal.foreign.memory.BoundedMemoryRegion.checkBounds(BoundedMemoryRegion.java:153) >> at >> java.base/jdk.internal.foreign.memory.BoundedMemoryRegion.checkRange(BoundedMemoryRegion.java:158) >> at >> java.base/jdk.internal.foreign.memory.BoundedPointer.(BoundedPointer.java:77) >> at >> java.base/jdk.internal.foreign.memory.BoundedPointer.(BoundedPointer.java:68) >> at >> java.base/jdk.internal.foreign.memory.BoundedPointer.createNativeVoidPointer(BoundedPointer.java:175) >> at >> java.base/jdk.internal.foreign.invokers.DirectSignatureShuffler.longToPointer(DirectSignatureShuffler.java:335) >> at >> PointerTest$pointers$Impl/0x00000007c035b440.get_1_byte_pointer(Unknown >> Source) >> at PointerTest.test1ByteRegionAtMaxHeapOffset(PointerTest.java:297) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Metho > >> On Oct 30, 2018, at 11:52 AM, Jorn Vernee wrote: >> >> Henry Jen schreef op 2018-10-30 18:46: >>> I wonder if it can be simplified a little bit, let?s say address is >>> indeed 0xFFFFFFFF, we should be able to have a memory region of >>> length >>> 1. >> >> Yes, that's a good point. That will allow for a 1 byte memory region >> at 0xFFFFFFFF. >> >> I've also added a test for that exact case. >> >>> When the min(real address) is negative, the cap of length for unknown >>> is pretty much just to negate the value of min. >> >> Yes! And I think when min is positive the length maximum is always >> Long.MAX_VALUE. >> >>> min + length should be <= 0. We can only access min + offset - 1, so >>> that we won?t access 0x0 in negative case. >> >> That won't work for the case where min and length are both positive, >> but min + length is also positive. In that case the check should also >> pass. >> >> The way I have it right now, since length is always positive, min + >> length can only overflow to positive if min is negative, so that's >> also the check :) But I've changed it to check for min + length > 0 to >> allow for a 1 byte region if min == -1L. >> >>> What do you think? >> >> Good suggestions, here is the updated webrev: >> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.04/index.html >> >> I've also removed the spurious import in PointerTest, which >> auto-complete put in there when auto-completing to @Transient instead >> of @Test :) >> >>> Cheers, >>> Henry >> >> Thanks for the reviews, >> Jorn >> >>>> On Oct 30, 2018, at 9:49 AM, Jorn Vernee wrote: >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/webrev.03/ >>>> (beware that the BoundedMemoryRegion diff turned out a bit >>>> confusing) >>>> - Changed BoundeMemoryRegion to use factory methods. >>>> - Factories that don't take a length calculate a max length that can >>>> not overflow (in the unsigned sense). >>>> - Moved BoundedMemoryRegion anonymous class from Pointer to >>>> BoundedMemoryRegion, since constructor is now private. >>>> - Added one more test to check for the error in the case where the >>>> automatic length calculated for a native pointer is shorter than the >>>> length required by the carrier type. >>>> - Switched PointerTest to TestNG, since that makes it easier to test >>>> for exceptions. >>>> I've added a check for the overflow to BoundedMemoryRegion, but when >>>> trying to test for it it turned out that BoundedPointer was already >>>> catching that case. I've left the check there as it will still be >>>> useful to catch programming errors when an explicit length is being >>>> passed. >>>> Trying to treat a signed long as unsigned is somewhat confusing, >>>> maybe we should add an UnsignedLong utility class that abstracts >>>> this away in a later RFR, especially if we start allowing 'unsigned' >>>> longs in more places. >>>> Jorn >>>> Jorn Vernee schreef op 2018-10-30 11:26: >>>>> You're right about `toUnsignedString`. For some reason I thought >>>>> `toHexString` had the `-` as a prefix if the argument is negative. >>>>> About the length constraint; My initial thought was just to trust >>>>> the >>>>> pointer returned from native, but I guess we should do better. In >>>>> the >>>>> specific case I'm testing, void *, the length that is being used is >>>>> Long.MAX_VALUE, basically the length is unknown, so I don't think I >>>>> can do a range check on min + length in the constructor in that >>>>> case. >>>>> As far as I can see, the `min` value is only used in a few min + >>>>> offset calculations before passing to Unsafe put/get routines, I >>>>> think >>>>> we'd want to allow overflow to negative there, but not overflow to >>>>> positive, basically treating the long as if it was unsigned. >>>>> I think I will switch BoundedMemoryRegion to having factory methods >>>>> that do the validation, and then have ones where the length is >>>>> known, >>>>> which do a range check, and ones where the length is unknown, that >>>>> cap >>>>> the it to where it can not overflow. Then I can use the latter for >>>>> void *. If a bad pointer is passed from native, the known-length >>>>> case >>>>> should fail on construction of the memory region, and the >>>>> unknown-length case should fail when dereferencing (since there is >>>>> already a bounds check being done). >>>>> What do you think? >>>>> Thanks, >>>>> Jorn >>>>> Henry Jen schreef op 2018-10-30 01:59: >>>>>> BTW, the change in toString is not needed, as toUnsignedString(l, >>>>>> 16) >>>>>> is same as toHexString(l)? >>>>>> Cheers, >>>>>> Henry >>>>>>> On Oct 29, 2018, at 5:56 PM, Henry Jen >>>>>>> wrote: >>>>>>> I am afraid this is not that simple, we need to at least protect >>>>>>> length from overflow the address to >= 0. >>>>>>> I haven?t completely check the implementation, we need to make >>>>>>> sure all other operation will not expand or shift the region, >>>>>>> which I believe is the constraint of the design. If that?s indeed >>>>>>> the case, guard at construction is probably good enough. >>>>>>> Cheers, >>>>>>> Henry >>>>>>>> On Oct 29, 2018, at 10:04 AM, Jorn Vernee >>>>>>>> wrote: >>>>>>>> Hello, >>>>>>>> Please review this patch which tweaks the binder to allow >>>>>>>> negative values for native pointers. >>>>>>>> The problem was previously discussed here: >>>>>>>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002994.html >>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8212987 >>>>>>>> Webrev : >>>>>>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8212987/ >>>>>>>> As a reminder, I'm not a committer, so someone else will have to >>>>>>>> push this. >>>>>>>> Thanks, >>>>>>>> Jorn From vladimir.x.ivanov at oracle.com Wed Oct 31 18:28:05 2018 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Wed, 31 Oct 2018 18:28:05 +0000 Subject: hg: panama/dev: AArch64: SVE changes Message-ID: <201810311828.w9VIS6Us019166@aojmv0008.oracle.com> Changeset: aa68196d5ef3 Author: njian Date: 2018-10-31 11:27 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/aa68196d5ef3 AArch64: SVE changes ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp From vladimir.x.ivanov at oracle.com Wed Oct 31 18:29:39 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2018 11:29:39 -0700 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> <4ce6a73e-6776-c2c6-c039-eb00eeeb3eba@oracle.com> <4a761a82-b15d-21b0-a181-79dab3553849@oracle.com> Message-ID: <900d8470-e889-4196-60b0-f002f25389a6@oracle.com> Thank you, Ningsheng. > 1) VectorIntrinsics reinterpret/cast changes: > http://cr.openjdk.java.net/~njian/vectorapi/01-vectorintrinsics-reinterpret.webrev1/ Looks good. Any objections from others? > 3) AArch64 specific changes: > http://cr.openjdk.java.net/~njian/vectorapi/03-aarch64-sve.webrev1/ > This is the same as previous version, and yes, this is a standalone change and can be applied and pushed cleanly. I am OK to push this first. Ok, pushed [1]. Will comment on Scalable shapes separately. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/rev/aa68196d5ef3 >> -----Original Message----- >> From: Vladimir Ivanov >> Sent: Wednesday, October 31, 2018 1:40 AM >> To: Ningsheng Jian (Arm Technology China) ; >> panama-dev at openjdk.java.net >> Cc: nd >> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension >> >> Thanks, Ningsheng. >> >>> I have separated vectorapi.webrev01 into three patches. Now they are: >>> >>> The scalable vector related changes: >>> http://cr.openjdk.java.net/~njian/vectorapi/01-scalable-vector.webrev0 >>> / >>> >>> Vector intrinsics related changes: >>> http://cr.openjdk.java.net/~njian/vectorapi/02-vector-intrinsics.webre >>> v0/ >> >> What I had in mind is getting VectorIntrinsics.reinterpret/cast() and all related >> changes (jdk + hotspot) separated, to focus on *ScalableVector shapes in a >> separate webrev. >> >> Sorry for the confusion. >> >>> AArch64 specific changes: >>> http://cr.openjdk.java.net/~njian/vectorapi/03-aarch64-sve.webrev0/ >> >> Looks fine. It looks like a stand-alone change ready to be pushed. Do you agree? >> >> Best regards, >> Vladimir Ivanov >> >>> >>> And the tests (the same as previous version): >>> http://cr.openjdk.java.net/~njian/vectorapi/04-tests-scalable-vector.w >>> ebrev0/ >>> >>> Could you please help to take a look? >>> >>> Thanks, >>> Ningsheng >>> >>>> -----Original Message----- >>>> From: Halimi, Jean-Philippe >>>> Sent: Tuesday, October 30, 2018 8:55 AM >>>> To: Vladimir Ivanov ; Ningsheng Jian >>>> (Arm Technology China) ; >>>> panama-dev at openjdk.java.net >>>> Cc: nd >>>> Subject: RE: [vector] RFC: Add scalable shapes for Arm Scalable >>>> Vector Extension >>>> >>>> I do not have more comments, tests look good to me. >>>> >>>> Jp >>>> >>>> -----Original Message----- >>>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>>> Sent: Monday, October 29, 2018 4:16 PM >>>> To: Ningsheng Jian (Arm Technology China) ; >>>> panama-dev at openjdk.java.net; Halimi, Jean-Philippe >>> philippe.halimi at intel.com> >>>> Cc: nd >>>> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable >>>> Vector Extension >>>> >>>> Ningsheng, >>>> >>>>> http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev01/ >>>>> and the test cases: >>>>> http://cr.openjdk.java.net/~njian/sve/vectorapi-test.webrev01/ >>>>> >>>>> All the vector api cases passed on my x86 machines with and without >>>> VectorApiIntrinsics. There are some failures on AArch64, but they are >>>> not related to this patch and we will fix them in follow-up patches. >>>> >>>> vectorapi-test.webrev01 looks good. Jp, do you have any comments? >>>> >>>> Regarding vectorapi.webrev01, please, separate it in 3 patches: >>>> (1) VectorIntrinsics-related changes >>>> (2) ScalableVector-related changes >>>> (3) aarch64-specific changes >>>> >>>> IMO #3 is fine, but I'd like to hear from Intel folks about #1 & #2. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> >>>>> Please help to review the changes. >>>>> >>>>> Thanks, >>>>> Ningsheng >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Ivanov >>>>>> Sent: Friday, October 12, 2018 11:18 AM >>>>>> To: Ningsheng Jian (Arm Technology China) ; >>>>>> panama-dev at openjdk.java.net >>>>>> Cc: nd >>>>>> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable >>>>>> Vector Extension >>>>>> >>>>>> >>>>>> >>>>>>>>>> So, my question boils down to: how vector shape checks are >>>>>>>>>> expected to work on *ScalableVectors in presence of operations >>>>>>>>>> which change vector >>>>>>>> size. >>>>>>>>>> >>>>>>>>>> For example, IntScalableVector.rebracket() => >>>>>>>>>> LongScalableVector which is fine, but ISV.resize() => ISV is >>>>>>>>>> what I'm concerned about and existing checks aren't enough for >>>>>>>>>> *ScalableVectors unless you check their length at runtime. >>>>>>>>> >>>>>>>>> Thanks for the detailed explanation. So, which checks do you >>>>>>>>> mean here? Do >>>>>>>> you mean this [1]? I find that current Java implementations >>>>>>>> already has some runtime length checks. One thing we need to >>>>>>>> consider is the ambiguity between existing sizes and scalable >>>>>>>> size. Current >>>>>>>> VectorIntrinsics.reinterpret() just tries to get the shape from >>>>>>>> size >>>>>>>> (library_call.cpp:get_exact_klass_for_vector_box) instead of >>>>>>>> getting the real class from input argument, which will lead to >>>>>>>> ClassCastException. Maybe that can be fixed by adding real klass >>>>>>>> type to the >>>>>> reinterpret function. >>>>>>>> >>>>>>>> The checks I referred to are the casts on vector shapes which are >>>>>>>> part of every vector operation (e.g., [2]), but they don't >>>>>>>> immediately relate to shape-changing operations. >>>>>>>> >>>>>>> >>>>>>> OK, but I would expect the normal operations between SV and other >>>>>>> vectors >>>>>> are illegal, though they may have the same size, since users >>>>>> usually don't know the real size of SV. We should treat SV >>>>>> different from other >>>> vectors. >>>>>> >>>>>> Yes, the checks currently in place effectively forbid mixing >>>>>> vectors of different shapes. But API allows to reshape/cast vectors >>>>>> to arbitrary shapes and that may cause problems if equivalent >>>>>> shapes meet at >>>> runtime. >>>>>> >>>>>> Since concrete vector shapes aren't part of API, I believe it is >>>>>> possible to exclude duplicating shapes at runtime. For example, SVs >>>>>> can be used as a substitute for *512V shapes on 512-bit SVE or >>>>>> AVX512-capable hardware. It seems current JDK- JVM interface >>>>>> (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), >>>>>> but it would be very interesting to hear your experience. >>>>>> >>>>>> API allows to query vectors of smaller/larger sizes than hardware >>>>>> natively supports and implementation has to support that (even if >>>> performance suffers). >>>>>> It means SV shapes can coexist at runtime with existing shapes >>>>>> (*64V/.../*512V) and casts/reshapes between all those shapes should work. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>>> It seems I had some wrong assumptions when coming up with the >> examples. >>>>>>>> Sorry for the confusion. Taking those into account, here's my >>>>>>>> take on current state of vector shape changing operations w.r.t. SV >> shapes. >>>>>>>> >>>>>>>> There'll be 30 vector shapes in total (5 sizes x 6 element types): >>>>>>>> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV >>>>>>>> * Short64V, ..., ShortSV >>>>>>>> ... >>>>>>>> * Double64V, Double128V, ... Double512V, DoubleSV >>>>>>>> >>>>>>>> Depending on hardware, SVs may alias with "explicitly sized" >>>>>>>> shapes (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). >>>>>>>> >>>>>>>> (1) Vector.rebracket(): works fine for SVs since vector size (in >>>>>>>> bits) stays the >>>>>> same: >>>>>>>> IntSV <-> LongSV <-> ... <-> DoubleSV. >>>>>>>> >>>>>>>> (2) Vector.resize(): SV->SV doesn't make sense and the operation >>>>>>>> should involve both SV and existing vector shapes: IntSV <-> >>>>>>>> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause >>>>>>>> problems and needs to be carefully handled to avoid 2 equivalent >>>>>>>> shapes to meet at runtime. Otherwise, vector shape checks I >>>>>>>> mentioned >>>>>> earlier should be changed. >>>>>>>> >>>>>>> >>>>>>> Yes, we will try to address this issue carefully in the follow-up webrev. >>>>>>> >>>>>>>> (3) Vector.cast(): SV->SV, SV<->64V/.../512V >>>>>>>> * size-preserving transformations (int <-> float): >>>>>>>> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> >>>>>>>> DoubleSV; >>>>>>>> >>>>>>>> * widening casts (e.g., int->long) >>>>>>>> SV->SV/64V/...: truncate upper part of the vector, >>>>>>>> since SVs already represent widest vector shapes; >>>>>>>> 64V/...->SV: either truncated or filled with defaults >>>>>>>> depending on actual size >>>>>>>> >>>>>>>> * narrowing casts (e.g., long->int) >>>>>>>> SV->SV/64V/...: fill upper part of SV with defaults; >>>>>>>> 64V/...->SV: either truncated or filled with defaults >>>>>>>> depending on actual size >>>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Ningsheng >>>>>>> From maurizio.cimadamore at oracle.com Wed Oct 31 18:33:12 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 31 Oct 2018 18:33:12 +0000 Subject: hg: panama/dev: Automatic merge with vectorIntrinsics Message-ID: <201810311833.w9VIXDwi021166@aojmv0008.oracle.com> Changeset: ee5a136444af Author: mcimadamore Date: 2018-10-31 19:39 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/ee5a136444af Automatic merge with vectorIntrinsics From henry.jen at oracle.com Wed Oct 31 19:47:20 2018 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Wed, 31 Oct 2018 19:47:20 +0000 Subject: hg: panama/dev: Do wildcard copy before we figure out how to do symbolic link Message-ID: <201810311947.w9VJlKEg022956@aojmv0008.oracle.com> Changeset: 22015e7174eb Author: henryjen Date: 2018-10-31 12:33 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/22015e7174eb Do wildcard copy before we figure out how to do symbolic link ! make/lib/Lib-jdk.internal.clang.gmk From maurizio.cimadamore at oracle.com Wed Oct 31 19:52:51 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 31 Oct 2018 19:52:51 +0000 Subject: hg: panama/dev: Automatic merge with foreign Message-ID: <201810311952.w9VJqpW5024701@aojmv0008.oracle.com> Changeset: 0260ce01533b Author: mcimadamore Date: 2018-10-31 20:59 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/0260ce01533b Automatic merge with foreign From vladimir.x.ivanov at oracle.com Wed Oct 31 20:51:20 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2018 13:51:20 -0700 Subject: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension In-Reply-To: References: <5a9d8c0d-dfd9-efb0-0198-f5d84e8ea925@oracle.com> <0c06408d-2136-6488-7b6d-f1f13f20adf6@oracle.com> <3e43e8df-4215-7108-5deb-f39ae0b9e975@oracle.com> <6e763d20-ff35-7221-f608-0d76a5934bf4@oracle.com> <4ce6a73e-6776-c2c6-c039-eb00eeeb3eba@oracle.com> <4a761a82-b15d-21b0-a181-79dab3553849@oracle.com> Message-ID: <5f66032e-570f-90c5-763f-93214e695f8b@oracle.com> Ningsheng, > 2) Scalable vector related changes: > http://cr.openjdk.java.net/~njian/vectorapi/02-scalable-vector.webrev1/ First of all, looking at the changes in isolation, I think it's the right time to choose a better name. The usages are scattered around the code base and it'll be harder to change it later. As I mentioned earlier, IMO "Scalable" term doesn't communicate the intent clearly enough. From VM perspective with its Matcher::max_vector_size(), [Int|...]*Max*Vector looks natural. On JDK level, [Int|...]*Preferred*Vector looks a bit more favorable considering there's Vector.preferredSpecies(). As for me, [Int|...]MaxVector looks better. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Shapes.java: + public static final SScalableBit S_Scalable_BIT = new SScalableBit(); + public static final class SScalableBit extends Vector.Shape { I don't think there's a need in additional Shape instantiation. It conflicts with Vector.preferredSpecies() and current API should already support shape-agnostic usages. Also, its size may depend on element type and Vector.preferredSpecies() handles that. Am I missing any pros of SScalableBit compared to Vector.preferredSpecies()? There's a need to access new shapes in unit tests, but it doesn't require public API and can be implemented differently (e.g., by module patching, see MethodHandleHelper [1] for an example). src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template: - if (o.bitSize() == 64) { + if ((o.bitSize() == 64) && (o instanceof $Type$64Vector)) { If SScalableBit is gone, any other use cases for that checks except testing? From Alejandro comment [2], I got an impression that explicitly sized variants should be preferred to new variants. In that case, I don't see a way for vectors of equivalent (but different) shapes to meet at runtime. > 4) Tests (the same as previous version): > http://cr.openjdk.java.net/~njian/vectorapi/04-tests-scalable-vector.webrev1/ Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/dev/file/aa68196d5ef3/test/jdk/java/lang/invoke/java.base/java/lang/invoke/MethodHandleHelper.java [2] http://mail.openjdk.java.net/pipermail/panama-dev/2018-October/002967.html >> -----Original Message----- >> From: Vladimir Ivanov >> Sent: Wednesday, October 31, 2018 1:40 AM >> To: Ningsheng Jian (Arm Technology China) ; >> panama-dev at openjdk.java.net >> Cc: nd >> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable Vector Extension >> >> Thanks, Ningsheng. >> >>> I have separated vectorapi.webrev01 into three patches. Now they are: >>> >>> The scalable vector related changes: >>> http://cr.openjdk.java.net/~njian/vectorapi/01-scalable-vector.webrev0 >>> / >>> >>> Vector intrinsics related changes: >>> http://cr.openjdk.java.net/~njian/vectorapi/02-vector-intrinsics.webre >>> v0/ >> >> What I had in mind is getting VectorIntrinsics.reinterpret/cast() and all related >> changes (jdk + hotspot) separated, to focus on *ScalableVector shapes in a >> separate webrev. >> >> Sorry for the confusion. >> >>> AArch64 specific changes: >>> http://cr.openjdk.java.net/~njian/vectorapi/03-aarch64-sve.webrev0/ >> >> Looks fine. It looks like a stand-alone change ready to be pushed. Do you agree? >> >> Best regards, >> Vladimir Ivanov >> >>> >>> And the tests (the same as previous version): >>> http://cr.openjdk.java.net/~njian/vectorapi/04-tests-scalable-vector.w >>> ebrev0/ >>> >>> Could you please help to take a look? >>> >>> Thanks, >>> Ningsheng >>> >>>> -----Original Message----- >>>> From: Halimi, Jean-Philippe >>>> Sent: Tuesday, October 30, 2018 8:55 AM >>>> To: Vladimir Ivanov ; Ningsheng Jian >>>> (Arm Technology China) ; >>>> panama-dev at openjdk.java.net >>>> Cc: nd >>>> Subject: RE: [vector] RFC: Add scalable shapes for Arm Scalable >>>> Vector Extension >>>> >>>> I do not have more comments, tests look good to me. >>>> >>>> Jp >>>> >>>> -----Original Message----- >>>> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >>>> Sent: Monday, October 29, 2018 4:16 PM >>>> To: Ningsheng Jian (Arm Technology China) ; >>>> panama-dev at openjdk.java.net; Halimi, Jean-Philippe >>> philippe.halimi at intel.com> >>>> Cc: nd >>>> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable >>>> Vector Extension >>>> >>>> Ningsheng, >>>> >>>>> http://cr.openjdk.java.net/~njian/sve/vectorapi.webrev01/ >>>>> and the test cases: >>>>> http://cr.openjdk.java.net/~njian/sve/vectorapi-test.webrev01/ >>>>> >>>>> All the vector api cases passed on my x86 machines with and without >>>> VectorApiIntrinsics. There are some failures on AArch64, but they are >>>> not related to this patch and we will fix them in follow-up patches. >>>> >>>> vectorapi-test.webrev01 looks good. Jp, do you have any comments? >>>> >>>> Regarding vectorapi.webrev01, please, separate it in 3 patches: >>>> (1) VectorIntrinsics-related changes >>>> (2) ScalableVector-related changes >>>> (3) aarch64-specific changes >>>> >>>> IMO #3 is fine, but I'd like to hear from Intel folks about #1 & #2. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> >>>>> Please help to review the changes. >>>>> >>>>> Thanks, >>>>> Ningsheng >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Ivanov >>>>>> Sent: Friday, October 12, 2018 11:18 AM >>>>>> To: Ningsheng Jian (Arm Technology China) ; >>>>>> panama-dev at openjdk.java.net >>>>>> Cc: nd >>>>>> Subject: Re: [vector] RFC: Add scalable shapes for Arm Scalable >>>>>> Vector Extension >>>>>> >>>>>> >>>>>> >>>>>>>>>> So, my question boils down to: how vector shape checks are >>>>>>>>>> expected to work on *ScalableVectors in presence of operations >>>>>>>>>> which change vector >>>>>>>> size. >>>>>>>>>> >>>>>>>>>> For example, IntScalableVector.rebracket() => >>>>>>>>>> LongScalableVector which is fine, but ISV.resize() => ISV is >>>>>>>>>> what I'm concerned about and existing checks aren't enough for >>>>>>>>>> *ScalableVectors unless you check their length at runtime. >>>>>>>>> >>>>>>>>> Thanks for the detailed explanation. So, which checks do you >>>>>>>>> mean here? Do >>>>>>>> you mean this [1]? I find that current Java implementations >>>>>>>> already has some runtime length checks. One thing we need to >>>>>>>> consider is the ambiguity between existing sizes and scalable >>>>>>>> size. Current >>>>>>>> VectorIntrinsics.reinterpret() just tries to get the shape from >>>>>>>> size >>>>>>>> (library_call.cpp:get_exact_klass_for_vector_box) instead of >>>>>>>> getting the real class from input argument, which will lead to >>>>>>>> ClassCastException. Maybe that can be fixed by adding real klass >>>>>>>> type to the >>>>>> reinterpret function. >>>>>>>> >>>>>>>> The checks I referred to are the casts on vector shapes which are >>>>>>>> part of every vector operation (e.g., [2]), but they don't >>>>>>>> immediately relate to shape-changing operations. >>>>>>>> >>>>>>> >>>>>>> OK, but I would expect the normal operations between SV and other >>>>>>> vectors >>>>>> are illegal, though they may have the same size, since users >>>>>> usually don't know the real size of SV. We should treat SV >>>>>> different from other >>>> vectors. >>>>>> >>>>>> Yes, the checks currently in place effectively forbid mixing >>>>>> vectors of different shapes. But API allows to reshape/cast vectors >>>>>> to arbitrary shapes and that may cause problems if equivalent >>>>>> shapes meet at >>>> runtime. >>>>>> >>>>>> Since concrete vector shapes aren't part of API, I believe it is >>>>>> possible to exclude duplicating shapes at runtime. For example, SVs >>>>>> can be used as a substitute for *512V shapes on 512-bit SVE or >>>>>> AVX512-capable hardware. It seems current JDK- JVM interface >>>>>> (VectorIntrinsics) should fit SV purposes well (both on x86 & ARM), >>>>>> but it would be very interesting to hear your experience. >>>>>> >>>>>> API allows to query vectors of smaller/larger sizes than hardware >>>>>> natively supports and implementation has to support that (even if >>>> performance suffers). >>>>>> It means SV shapes can coexist at runtime with existing shapes >>>>>> (*64V/.../*512V) and casts/reshapes between all those shapes should work. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>>> It seems I had some wrong assumptions when coming up with the >> examples. >>>>>>>> Sorry for the confusion. Taking those into account, here's my >>>>>>>> take on current state of vector shape changing operations w.r.t. SV >> shapes. >>>>>>>> >>>>>>>> There'll be 30 vector shapes in total (5 sizes x 6 element types): >>>>>>>> * Byte64V, Byte128V, Byte256V, Byte512V, ByteSV >>>>>>>> * Short64V, ..., ShortSV >>>>>>>> ... >>>>>>>> * Double64V, Double128V, ... Double512V, DoubleSV >>>>>>>> >>>>>>>> Depending on hardware, SVs may alias with "explicitly sized" >>>>>>>> shapes (e.g., IntSV is equivalent to Int512V on AVX512 capable H/W). >>>>>>>> >>>>>>>> (1) Vector.rebracket(): works fine for SVs since vector size (in >>>>>>>> bits) stays the >>>>>> same: >>>>>>>> IntSV <-> LongSV <-> ... <-> DoubleSV. >>>>>>>> >>>>>>>> (2) Vector.resize(): SV->SV doesn't make sense and the operation >>>>>>>> should involve both SV and existing vector shapes: IntSV <-> >>>>>>>> Int64V/Int128V/.../Int512V. The ambiguity you mention can cause >>>>>>>> problems and needs to be carefully handled to avoid 2 equivalent >>>>>>>> shapes to meet at runtime. Otherwise, vector shape checks I >>>>>>>> mentioned >>>>>> earlier should be changed. >>>>>>>> >>>>>>> >>>>>>> Yes, we will try to address this issue carefully in the follow-up webrev. >>>>>>> >>>>>>>> (3) Vector.cast(): SV->SV, SV<->64V/.../512V >>>>>>>> * size-preserving transformations (int <-> float): >>>>>>>> SV->SV work fine: IntSV <-> FloatSV, LongSV <-> >>>>>>>> DoubleSV; >>>>>>>> >>>>>>>> * widening casts (e.g., int->long) >>>>>>>> SV->SV/64V/...: truncate upper part of the vector, >>>>>>>> since SVs already represent widest vector shapes; >>>>>>>> 64V/...->SV: either truncated or filled with defaults >>>>>>>> depending on actual size >>>>>>>> >>>>>>>> * narrowing casts (e.g., long->int) >>>>>>>> SV->SV/64V/...: fill upper part of SV with defaults; >>>>>>>> 64V/...->SV: either truncated or filled with defaults >>>>>>>> depending on actual size >>>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Ningsheng >>>>>>> From maurizio.cimadamore at oracle.com Wed Oct 31 20:57:46 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 31 Oct 2018 20:57:46 +0000 Subject: hg: panama/dev: 181 new changesets Message-ID: <201810312058.w9VKw0SE023388@aojmv0008.oracle.com> Changeset: 597ed181a9e8 Author: rkennke Date: 2018-10-17 22:26 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/597ed181a9e8 8212186: JVMTI lacks a few GC barriers/hooks Reviewed-by: eosterlund, shade ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiTagMap.cpp Changeset: a817954f4081 Author: shade Date: 2018-10-17 22:42 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/a817954f4081 8212616: x86_32 build failures after JDK-8210498 (nmethod entry barriers) Reviewed-by: kvn, eosterlund ! src/hotspot/cpu/x86/x86_32.ad Changeset: d5a96cafdd4a Author: shade Date: 2018-10-17 22:47 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d5a96cafdd4a 8212617: ARM32 build failures after JDK-7041262 (VM_Version should be called instead of Abstract_VM_Version so that overriding works) Reviewed-by: hseigel ! src/hotspot/cpu/arm/vm_version_arm.hpp Changeset: c28fb7557d62 Author: jwilhelm Date: 2018-10-18 00:50 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/c28fb7557d62 Added tag jdk-12+16 for changeset 199658d1ef86 ! .hgtags Changeset: e3c221bc1711 Author: jjiang Date: 2018-10-18 07:56 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/e3c221bc1711 8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java Summary: javax/net/ssl/TLSCommon/CipherSuite.java supports key exchange algorithms Reviewed-by: xuelei ! test/jdk/javax/net/ssl/TLSCommon/CipherSuite.java + test/jdk/javax/net/ssl/TLSCommon/KeyExAlgorithm.java Changeset: 672bc2213cef Author: jcbeyler Date: 2018-10-17 21:28 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/672bc2213cef 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] Summary: Remove the NSK_CPP_STUB macros from tests Reviewed-by: amenkov, phh, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/em02t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t007/em02t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t008/em02t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t009/em02t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t010/em02t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t011/em02t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012/em02t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t001/em05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t002/em05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t001/em07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/em07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/ex03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF01/gf01t001/gf01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF04/gf04t001/gf04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF06/gf06t001/gf06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t001/gf08t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t002/gf08t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t003/gf08t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS103/hs103t002/hs103t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t002/hs104t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t001/hs201t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/hs203t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t002/hs301t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t003/hs301t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004/hs301t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI06/ji06t001/ji06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/ma02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/ma02t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/ma03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/ma04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/ma04t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/ma04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/ma04t003a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/ma05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/ma05t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/ma06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/ma06t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/ma07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/ma07t001a.cpp Changeset: c657b5b0e666 Author: iklam Date: 2018-10-17 21:51 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c657b5b0e666 8212612: Add documentation about Arguments::_exit_hook Reviewed-by: hseigel, dlong, dholmes ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/java.base/share/native/include/jni.h Changeset: 0dac3131b0fd Author: ihse Date: 2018-10-18 09:19 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/0dac3131b0fd 8212587: equals in MakeBase does not handle empty strings correctly Reviewed-by: erikj ! make/common/MakeBase.gmk ! test/make/TestMakeBase.gmk Changeset: 8d140834fbb0 Author: dzhou Date: 2018-10-18 00:56 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/8d140834fbb0 8210406: Refactor java.util.PluggableLocale:i18n shell tests to plain java tests Reviewed-by: naoto ! test/jdk/java/util/PluggableLocale/BreakIteratorProviderTest.java - test/jdk/java/util/PluggableLocale/BreakIteratorProviderTest.sh ! test/jdk/java/util/PluggableLocale/CalendarDataProviderTest.java - test/jdk/java/util/PluggableLocale/CalendarDataProviderTest.sh ! test/jdk/java/util/PluggableLocale/CalendarNameProviderTest.java - test/jdk/java/util/PluggableLocale/CalendarNameProviderTest.sh ! test/jdk/java/util/PluggableLocale/ClasspathTest.java - test/jdk/java/util/PluggableLocale/ClasspathTest.sh ! test/jdk/java/util/PluggableLocale/CollatorProviderTest.java - test/jdk/java/util/PluggableLocale/CollatorProviderTest.sh ! test/jdk/java/util/PluggableLocale/CurrencyNameProviderTest.java - test/jdk/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/jdk/java/util/PluggableLocale/DateFormatProviderTest.java - test/jdk/java/util/PluggableLocale/DateFormatProviderTest.sh ! test/jdk/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java - test/jdk/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/jdk/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java - test/jdk/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/ExecTest.sh ! test/jdk/java/util/PluggableLocale/GenericTest.java - test/jdk/java/util/PluggableLocale/GenericTest.sh ! test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java - test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/jdk/java/util/PluggableLocale/NumberFormatProviderTest.java - test/jdk/java/util/PluggableLocale/NumberFormatProviderTest.sh ! test/jdk/java/util/PluggableLocale/PermissionTest.java - test/jdk/java/util/PluggableLocale/PermissionTest.sh ! test/jdk/java/util/PluggableLocale/TimeZoneNameProviderTest.java - test/jdk/java/util/PluggableLocale/TimeZoneNameProviderTest.sh - test/jdk/java/util/PluggableLocale/barprovider.jar + test/jdk/java/util/PluggableLocale/dummy.policy - test/jdk/java/util/PluggableLocale/fooprovider.jar - test/jdk/java/util/PluggableLocale/providersrc/BreakIteratorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CollatorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DecimalFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/FooDateFormat.java - test/jdk/java/util/PluggableLocale/providersrc/FooNumberFormat.java - test/jdk/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_kyoto.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_osaka.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_xx.properties - test/jdk/java/util/PluggableLocale/providersrc/Makefile - test/jdk/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/TimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/Utils.java + test/jdk/java/util/PluggableLocale/providersrc/barprovider/META-INF/services/java.util.spi.CalendarDataProvider + test/jdk/java/util/PluggableLocale/providersrc/barprovider/META-INF/services/java.util.spi.CalendarNameProvider + test/jdk/java/util/PluggableLocale/providersrc/barprovider/META-INF/services/java.util.spi.CurrencyNameProvider + test/jdk/java/util/PluggableLocale/providersrc/barprovider/META-INF/services/java.util.spi.LocaleNameProvider + test/jdk/java/util/PluggableLocale/providersrc/barprovider/META-INF/services/java.util.spi.TimeZoneNameProvider + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/CalendarDataProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/CalendarNameProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/CurrencyNameProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/CurrencyNameProviderImpl2.java + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/GenericTimeZoneNameProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNameProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames.properties + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja.properties + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja_JP_kyoto.properties + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_ja_JP_osaka.properties + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/LocaleNames_xx.properties + test/jdk/java/util/PluggableLocale/providersrc/barprovider/com/bar/TimeZoneNameProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/foobarutils/com/foobar/Utils.java + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/META-INF/services/java.text.spi.BreakIteratorProvider + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/META-INF/services/java.text.spi.CollatorProvider + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/META-INF/services/java.text.spi.DateFormatProvider + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/META-INF/services/java.text.spi.DateFormatSymbolsProvider + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/META-INF/services/java.text.spi.DecimalFormatSymbolsProvider + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/META-INF/services/java.text.spi.NumberFormatProvider + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/com/foo/BreakIteratorProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/com/foo/CollatorProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/com/foo/DateFormatProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/com/foo/DateFormatSymbolsProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/com/foo/DecimalFormatSymbolsProviderImpl.java + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/com/foo/FooDateFormat.java + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/com/foo/FooNumberFormat.java + test/jdk/java/util/PluggableLocale/providersrc/fooprovider/com/foo/NumberFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.BreakIteratorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.CollatorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DecimalFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.NumberFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.LocaleNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider Changeset: 0fcd1285435e Author: lkorinth Date: 2018-10-18 11:23 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/0fcd1285435e 8212595: Remove unused size_helper() in oop_oop_iterate* in instanceKlass.inline.hpp Reviewed-by: shade, pliden ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/instanceKlass.inline.hpp Changeset: 83b78c3c212b Author: mullan Date: 2018-10-18 10:08 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/83b78c3c212b 8210448: Copy Java XML Digital Signature API Specification into java.xml.crypto javadocs Reviewed-by: weijun + src/java.xml.crypto/share/classes/javax/xml/crypto/dom/package-info.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dom/package.html ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java + src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/package-info.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/package.html ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java + src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/package-info.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/package.html + src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/package-info.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/package.html + src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/package-info.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/package.html + src/java.xml.crypto/share/classes/javax/xml/crypto/package-info.java - src/java.xml.crypto/share/classes/javax/xml/crypto/package.html Changeset: 4e04b7ab20a3 Author: hseigel Date: 2018-10-18 10:35 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/4e04b7ab20a3 8209087: Clean up runtime code that compares 'this' to NULL Summary: Remove 'this' to NULL comparisons from methods and check if calling objects of these methods could be NULL. Reviewed-by: lfoltan, gziemski ! src/hotspot/share/classfile/verificationType.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/runtime/perfData.cpp ! src/hotspot/share/runtime/perfData.inline.hpp Changeset: e5fab74748fb Author: lancea Date: 2018-10-18 10:45 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/e5fab74748fb 8212662: Fix javadoc typo in java.lang.ref.Cleaner Reviewed-by: lancea, rriggs Contributed-by: Andrew Luo ! src/java.base/share/classes/java/lang/ref/Cleaner.java Changeset: faa582d5a574 Author: thartmann Date: 2018-10-18 17:50 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/faa582d5a574 8212553: [TESTBUG] TestTrichotomyExpressions.java times out with Graal as JIT Summary: Removed -Xcomp and increased timeout. Reviewed-by: kvn ! test/hotspot/jtreg/compiler/codegen/TestTrichotomyExpressions.java Changeset: a3cab5d26ef8 Author: igerasim Date: 2018-10-18 09:46 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/a3cab5d26ef8 8201355: Avoid native memory allocation in sun.security.mscapi.PRNG.generateSeed Reviewed-by: weijun ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp Changeset: 6eb876ac6827 Author: rkennke Date: 2018-10-18 21:14 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/6eb876ac6827 8212603: Need to step over GC barriers in Node::eqv_uncast() Reviewed-by: shade, kvn, eosterlund ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp Changeset: f08c1d7a5c53 Author: iklam Date: 2018-10-18 23:05 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f08c1d7a5c53 8212642: Remove SystemDictionary::InitOption enum Reviewed-by: dholmes, kvn, redestad ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/jvmci/jvmciJavaClasses.hpp ! src/hotspot/share/jvmci/systemDictionary_jvmci.hpp ! src/hotspot/share/runtime/reflection.cpp Changeset: 420445d16008 Author: michaelm Date: 2018-10-19 14:23 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/420445d16008 8211437: java.net.http.HttpClient hangs on 204 reply without Content-length 0 Reviewed-by: chegar, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java + test/jdk/java/net/httpclient/Response204.java + test/jdk/java/net/httpclient/http2/NoBodyTest.java ! test/jdk/java/net/httpclient/http2/server/Http2TestExchangeImpl.java Changeset: 94b85ea16cf9 Author: mullan Date: 2018-10-19 09:31 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/94b85ea16cf9 8195793: Remove GTE CyberTrust Global Root Reviewed-by: rhalade ! src/java.base/share/lib/security/cacerts ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: cb94f3a51aed Author: mullan Date: 2018-10-19 09:32 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/cb94f3a51aed Merge Changeset: 4d1e5697b32b Author: amenkov Date: 2018-10-19 09:31 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/4d1e5697b32b 8212629: [TEST] wrong breakpoint in test/jdk/com/sun/jdi/DeferredStepTest Reviewed-by: cjplummer, jcbeyler ! test/jdk/com/sun/jdi/DeferredStepTest.java Changeset: 38ecfe5dc351 Author: phh Date: 2018-10-19 17:54 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/38ecfe5dc351 8212698: Minor g1 #include changes and memoryService.hpp copyright date update Summary: Fix #includes in g1FullGCOopClosures.inline.hpp, g1HeapVerifier.hpp + memoryService.hpp copyright date Reviewed-by: tschatzl, jcbeyler ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/services/memoryService.hpp Changeset: 7c6dfd16373f Author: jnimeh Date: 2018-10-19 18:05 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/7c6dfd16373f 8211806: TLS 1.3 handshake server name indication is missing on a session resume Reviewed-by: xuelei, wetmore ! src/java.base/share/classes/sun/security/ssl/PostHandshakeContext.java + test/jdk/javax/net/ssl/SSLSession/ResumeTLS13withSNI.java Changeset: d1a1a5af1239 Author: kzhaldyb Date: 2018-10-19 16:29 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/d1a1a5af1239 8171097: Convert TestReservedSpace_test to Gtest Reviewed-by: stuefe, jcbeyler, iignatyev ! src/hotspot/share/utilities/internalVMTests.cpp + test/hotspot/gtest/memory/test_virtualspace.cpp Changeset: 5e894b0f5e63 Author: iignatyev Date: 2018-10-19 16:29 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/5e894b0f5e63 8177709: Convert TestVirtualSpace_test to GTest Reviewed-by: stuefe, jcbeyler ! src/hotspot/share/utilities/internalVMTests.cpp ! test/hotspot/gtest/memory/test_virtualspace.cpp Changeset: cf3fafc740bb Author: pmuthuswamy Date: 2018-10-22 10:16 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/cf3fafc740bb 8211879: Broken links in API overview Reviewed-by: jjg, erikj ! make/Docs.gmk Changeset: a562c65c3c74 Author: xyin Date: 2018-10-22 13:53 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/a562c65c3c74 8200151: Add 8 JNDI tests to com/sun/jndi/dns/ConfigTests/ Reviewed-by: vtewari, rriggs ! test/jdk/ProblemList.txt + test/jdk/com/sun/jndi/dns/ConfigTests/AuthDefault.dns + test/jdk/com/sun/jndi/dns/ConfigTests/AuthFalse.dns + test/jdk/com/sun/jndi/dns/ConfigTests/AuthRecursiveBase.java + test/jdk/com/sun/jndi/dns/ConfigTests/AuthTest.java + test/jdk/com/sun/jndi/dns/ConfigTests/AuthTrue.dns + test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java + test/jdk/com/sun/jndi/dns/ConfigTests/RecursiveDefault.dns + test/jdk/com/sun/jndi/dns/ConfigTests/RecursiveFalse.dns + test/jdk/com/sun/jndi/dns/ConfigTests/RecursiveTest.java + test/jdk/com/sun/jndi/dns/ConfigTests/RecursiveTrue.dns + test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java ! test/jdk/com/sun/jndi/dns/lib/DNSTestUtils.java Changeset: 2e495bbdc2b7 Author: xyin Date: 2018-10-22 14:03 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/2e495bbdc2b7 8208542: Add 4 JNDI tests to com/sun/jndi/dns/ListTests/ Reviewed-by: vtewari, rriggs + test/jdk/com/sun/jndi/dns/ListTests/ListBindingsInteriorNotFound.dns + test/jdk/com/sun/jndi/dns/ListTests/ListBindingsInteriorNotFound.java + test/jdk/com/sun/jndi/dns/ListTests/ListBindingsLeafNotFound.dns + test/jdk/com/sun/jndi/dns/ListTests/ListBindingsLeafNotFound.java + test/jdk/com/sun/jndi/dns/ListTests/ListInteriorNotFound.dns + test/jdk/com/sun/jndi/dns/ListTests/ListInteriorNotFound.java + test/jdk/com/sun/jndi/dns/ListTests/ListLeafNotFound.dns + test/jdk/com/sun/jndi/dns/ListTests/ListLeafNotFound.java + test/jdk/com/sun/jndi/dns/ListTests/ListTestBase.java Changeset: bca2b63dd839 Author: xyin Date: 2018-10-22 14:08 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/bca2b63dd839 8210339: Add 10 JNDI tests to com/sun/jndi/dns/FedTests/ Reviewed-by: vtewari, rriggs + test/jdk/com/sun/jndi/dns/FedTests/CannotProceed.dns + test/jdk/com/sun/jndi/dns/FedTests/CannotProceed.java + test/jdk/com/sun/jndi/dns/FedTests/FedObjectFactory.java + test/jdk/com/sun/jndi/dns/FedTests/FedSubordinateNs.java + test/jdk/com/sun/jndi/dns/FedTests/GetAttrsNns.dns + test/jdk/com/sun/jndi/dns/FedTests/GetAttrsNns.java + test/jdk/com/sun/jndi/dns/FedTests/GetAttrsSubInterior.dns + test/jdk/com/sun/jndi/dns/FedTests/GetAttrsSubInterior.java + test/jdk/com/sun/jndi/dns/FedTests/GetAttrsSubLeaf.dns + test/jdk/com/sun/jndi/dns/FedTests/GetAttrsSubLeaf.java + test/jdk/com/sun/jndi/dns/FedTests/ListFedBase.java + test/jdk/com/sun/jndi/dns/FedTests/ListNns.dns + test/jdk/com/sun/jndi/dns/FedTests/ListNns.java + test/jdk/com/sun/jndi/dns/FedTests/ListSubInterior.dns + test/jdk/com/sun/jndi/dns/FedTests/ListSubInterior.java + test/jdk/com/sun/jndi/dns/FedTests/ListSubLeaf.dns + test/jdk/com/sun/jndi/dns/FedTests/ListSubLeaf.java + test/jdk/com/sun/jndi/dns/FedTests/LookupNns.dns + test/jdk/com/sun/jndi/dns/FedTests/LookupNns.java + test/jdk/com/sun/jndi/dns/FedTests/LookupSubInterior.dns + test/jdk/com/sun/jndi/dns/FedTests/LookupSubInterior.java + test/jdk/com/sun/jndi/dns/FedTests/LookupSubLeaf.dns + test/jdk/com/sun/jndi/dns/FedTests/LookupSubLeaf.java Changeset: 5bf98ad48412 Author: coffeys Date: 2018-10-22 10:47 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/5bf98ad48412 8212752: Typo in SSL log message related to inactive/disabled signature scheme Reviewed-by: coffeys Contributed-by: jai.forums2013 at gmail.com ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java Changeset: 3b2e68c9e7a6 Author: vtewari Date: 2018-10-22 15:20 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/3b2e68c9e7a6 8212114: Reconsider the affect on closed streams resulting from 8189366 Reviewed-by: chegar, dfuchs ! src/java.base/share/classes/java/net/SocketInputStream.java ! test/jdk/java/net/Socket/CloseAvailable.java Changeset: f59960ebed20 Author: tschatzl Date: 2018-10-22 11:51 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/f59960ebed20 8211853: Avoid additional duplicate work when a reference in the task queue has already been evacuated Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp Changeset: f298d05357fe Author: chegar Date: 2018-10-22 12:25 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/f298d05357fe 8212695: Add explicit timeout to several HTTP Client tests Reviewed-by: dfuchs, michaelm ! test/jdk/java/net/httpclient/DigestEchoClientSSL.java ! test/jdk/java/net/httpclient/ProxyAuthDisabledSchemesSSL.java Changeset: e6973df15152 Author: eosterlund Date: 2018-10-22 12:13 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/e6973df15152 8212663: Remove conservative at_safepoint assert when JFR writes type sets during class unloading Reviewed-by: coleenp, dholmes, mgronlun ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp Changeset: 51c0b3936f01 Author: rfield Date: 2018-10-22 08:30 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/51c0b3936f01 8210923: JShell: support for switch expressions Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! src/jdk.jshell/share/classes/jdk/jshell/ReplParser.java ! test/langtools/jdk/jshell/ToolLocalSimpleTest.java ! test/langtools/jdk/jshell/ToolSimpleTest.java Changeset: b3c7c5a62521 Author: rfield Date: 2018-10-22 09:26 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/b3c7c5a62521 8210959: JShell fails and exits when statement throws an exception whose message contains a '%'. Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/langtools/jdk/jshell/ToolSimpleTest.java Changeset: 0b0ba3a2fec9 Author: jcbeyler Date: 2018-10-22 12:43 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/0b0ba3a2fec9 8212148: Remove remaining NSK_CPP_STUBs Summary: Remove remaining macros Reviewed-by: amenkov, phh, iignatyev ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag001/setvrbflag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/setvrbflag002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep001/singlestep001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep002/singlestep002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep003/singlestep003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd007/stopthrd007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd001/suspendthrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd002/suspendthrd002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst001/suspendthrdlst001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst002/suspendthrdlst002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadEnd/threadend002/threadend002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMDeath/vmdeath001/vmdeath001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMObjectAlloc/vmobjalloc001/vmobjalloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/followref001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/followref002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/followref004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/followref005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/JVMTIagent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/README ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch_agent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToSystemClassLoaderSearch/systemclssearch_agent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/README ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.h ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/README ! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/share/IndyRedefineClass.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/stepBreakPopReturn.cpp Changeset: b705eb06588f Author: coleenp Date: 2018-10-22 15:32 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/b705eb06588f 8212774: Remove dead code touching Klass::_lower_dimension Summary: Found dead code removal while looking at usage of Compile_lock. This dead code doesn't have Compile_lock but other code touching Klass::_{upper,lower}_dimension do. Reviewed-by: shade ! src/hotspot/share/oops/arrayKlass.hpp ! src/hotspot/share/runtime/reflection.cpp ! src/hotspot/share/runtime/reflection.hpp Changeset: 5e3a8f387701 Author: jjg Date: 2018-10-22 13:31 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/5e3a8f387701 8211876: Broken links in java.base files (ClassLoader.html#name) Reviewed-by: lancea ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/StackWalker.java Changeset: 111ba072921b Author: ccheung Date: 2018-10-22 14:31 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/111ba072921b 8210990: [TESTBUG] Some CDS tests don't respect JVM variant being tested Summary: use CDSTestUtils.run() instead of CDSTestUtils.executeAndLog(). Reviewed-by: iklam ! test/hotspot/jtreg/runtime/SharedArchiveFile/NonBootLoaderClasses.java ! test/hotspot/jtreg/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java Changeset: 151b990e3764 Author: amenkov Date: 2018-10-22 14:41 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/151b990e3764 8212665: com/sun/jdi/DeferredStepTest.java: jj1 (line 57) - unexpected. lastLine=52, minLine=52, maxLine=55 Reviewed-by: jcbeyler, gadams, sspitsyn ! test/jdk/com/sun/jdi/DeferredStepTest.java Changeset: 9c260a6b6471 Author: mchung Date: 2018-10-22 17:00 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9c260a6b6471 8207146: Rename jdk.internal.misc.Unsafe::xxxObject to xxxReference Reviewed-by: dholmes, thartmann ! make/gensrc/GensrcVarHandles.gmk ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/gc/g1/c2/g1BarrierSetC2.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/java.base/share/classes/java/io/BufferedInputStream.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! src/java.base/share/classes/java/math/BigDecimal.java ! src/java.base/share/classes/java/math/BigInteger.java ! src/java.base/share/classes/java/net/Inet6Address.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/InetSocketAddress.java ! src/java.base/share/classes/java/util/Random.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java ! src/java.base/share/classes/java/util/zip/ZipUtils.java ! src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeQualifiedObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeQualifiedStaticObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeStaticObjectFieldAccessorImpl.java ! src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/SafeThread.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64GraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.jdk9.test/src/org/graalvm/compiler/replacements/jdk9/UnsafeReplacementsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java ! test/hotspot/jtreg/compiler/c2/Test7190310_unsafe.java ! test/hotspot/jtreg/compiler/c2/aarch64/TestUnsafeVolatileCAS.java ! test/hotspot/jtreg/compiler/c2/aarch64/TestUnsafeVolatileLoad.java ! test/hotspot/jtreg/compiler/c2/aarch64/TestUnsafeVolatileStore.java ! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java ! test/hotspot/jtreg/compiler/intrinsics/unsafe/TestCAEAntiDep.java ! test/hotspot/jtreg/compiler/intrinsics/unsafe/TestUnsafeMismatchedArrayFieldAccess.java ! test/hotspot/jtreg/compiler/profiling/UnsafeAccess.java ! test/hotspot/jtreg/compiler/regalloc/C1ObjectSpillInLogicOp.java ! test/hotspot/jtreg/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java ! test/hotspot/jtreg/compiler/unsafe/JdkInternalMiscUnsafeAccessTestObject.java ! test/hotspot/jtreg/compiler/unsafe/MixedUnsafeStoreObject.java ! test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java ! test/hotspot/jtreg/compiler/unsafe/UnsafeGetConstantField.java ! test/hotspot/jtreg/compiler/unsafe/UnsafeGetStableArrayElement.java ! test/hotspot/jtreg/runtime/Unsafe/GetPutObject.java ! test/hotspot/jtreg/runtime/Unsafe/RangeCheck.java Changeset: 27ba7cc31f9f Author: jcbeyler Date: 2018-10-22 19:31 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/27ba7cc31f9f 8212535: Remove spaces before/after () for vmTestbase/[a-j]* Summary: Remove white spaces from tests Reviewed-by: amenkov, cjplummer, phh, sspitsyn ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC01/libnativeGC01.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC02/libnativeGC02.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/attach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/attach002aAgent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach008/attach008Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach009/attach009Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach012/attach012Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach014/attach014Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach037/attach037Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach038/attach038Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach039/attach039Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach040/attach040Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach041/attach041Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach042/attach042Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent02.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent03.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach046/attach046Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/FieldAccess/fieldacc003/fieldacc003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat002/thrstat002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadState/thrstat005/thrstat005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap004/iterheap004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap006/iterheap006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls006/iterinstcls006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj003/iterobjreachobj003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj004/iterobjreachobj004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj005/iterobjreachobj005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj002/iterreachobj002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj003/iterreachobj003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj004/iterreachobj004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj005/iterreachobj005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst002/resumethrdlst002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetExtensionEventCallback/setextevent001/setextevent001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001/setlocal001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP01/ap01t001/ap01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP02/ap02t001/ap02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP03/ap03t001/ap03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/ap04t001.cpp Changeset: d80d077d65b1 Author: weijun Date: 2018-10-23 12:25 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/d80d077d65b1 8212216: JGSS: Fix leak in exception cases in getJavaOID() Reviewed-by: mullan, weijun Contributed-by: Nico Williams ! src/java.security.jgss/share/native/libj2gss/NativeUtil.c Changeset: d0983f073c54 Author: amlu Date: 2018-10-23 13:47 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/d0983f073c54 8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 Reviewed-by: forax, weijun ! test/jdk/TEST.groups ! test/jdk/java/util/Arrays/TimSortStackSize2.java Changeset: 4f2215a00ed1 Author: roland Date: 2018-10-17 10:19 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/4f2215a00ed1 8212611: Small collection of simple changes from shenandoah Reviewed-by: thartmann, kvn, eosterlund ! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/subnode.cpp Changeset: 3c12f0c0a68c Author: shade Date: 2018-10-23 10:55 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/3c12f0c0a68c 8212754: Build failure: undefined JvmtiSampledObjectAllocEventCollector::object_alloc_is_safe_to_sample Reviewed-by: jcbeyler, zgu, coleenp ! src/hotspot/share/prims/jvmtiExport.hpp Changeset: b4b932c6001f Author: redestad Date: 2018-10-23 11:03 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b4b932c6001f 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory Reviewed-by: jlaskey, vlivanov ! src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: eadd0abbfdf4 Author: rehn Date: 2018-10-23 13:24 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/eadd0abbfdf4 8212707: GlobalCounter padding is too optimistic Reviewed-by: shade, redestad, mdoerr ! src/hotspot/share/utilities/globalCounter.hpp Changeset: 0ca91992dd8e Author: dtitov Date: 2018-10-23 07:57 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/0ca91992dd8e 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD Reviewed-by: cjplummer, amenkov, gadams, jcbeyler ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java + test/jdk/com/sun/jdi/JdbStopThreadTest.java ! test/jdk/com/sun/jdi/lib/jdb/Jdb.java ! test/jdk/com/sun/jdi/lib/jdb/JdbCommand.java Changeset: d8843761f478 Author: jcbeyler Date: 2018-10-23 09:43 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/d8843761f478 8212771: Remove remaining spaces before/after () for vmTestbase Summary: Remove spaces around () Reviewed-by: phh, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/StackTrace/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/clsldrclss00x/clsldrclss00x.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/AddToBootstrapClassLoaderSearch/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/Dispose/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/ForceGarbageCollection/gc/gc.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/environment/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendStackTrace/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/rawmonitor.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/setNullVMInit/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/timers/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/native_utils.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace011.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/share/IndyRedefineClass.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/stepBreakPopReturn.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/nativeAndMH.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp ! test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.cpp Changeset: fb01ea9dcee3 Author: dnsimon Date: 2018-10-23 18:49 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/fb01ea9dcee3 8212817: [JVMCI] ResolvedJavaMethod.isInVirtualMethodTable throws InternalError Reviewed-by: never, iveresov ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java Changeset: 66432f0e91bd Author: darcy Date: 2018-10-23 10:32 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/66432f0e91bd 8212718: Refactor some annotation processor tests to better use collections Reviewed-by: jlaskey, vromero ! test/langtools/tools/javac/processing/model/element/TestAnonClassNames.java ! test/langtools/tools/javac/processing/model/element/TypeParamBounds.java Changeset: c9459e2f7bc8 Author: dholmes Date: 2018-10-23 17:01 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/c9459e2f7bc8 8199567: [Nestmates] Cleanup instanceKlass.cpp Reviewed-by: lfoltan, coleenp ! src/hotspot/share/oops/instanceKlass.cpp Changeset: d682023cdd8c Author: stuefe Date: 2018-10-24 10:42 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/d682023cdd8c 8212896: AIX build breaks after 8212611 Reviewed-by: simonis, dholmes ! src/hotspot/share/opto/cfgnode.cpp Changeset: 5bd3a6017943 Author: mli Date: 2018-10-24 17:52 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/5bd3a6017943 8210407: Refactor java.util.Calendar:i18n shell tests to plain java tests Reviewed-by: naoto ! test/jdk/java/util/Calendar/GenericTimeZoneNamesTest.java - test/jdk/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/jdk/java/util/Calendar/NarrowNamesTest.java - test/jdk/java/util/Calendar/NarrowNamesTest.sh ! test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.java - test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.sh + test/jdk/java/util/Calendar/SupplementalJapaneseEraTestRun.java Changeset: 876e91d9bb13 Author: thartmann Date: 2018-10-24 12:39 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/876e91d9bb13 8150552: Remove -XX:+AggressiveOpts Summary: Removed the -XX:+AggressiveOpts flags and its usages. Reviewed-by: ecaspole, sjohanss ! src/bsd/doc/man/java.1 ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/java.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/java.1 ! test/hotspot/jtreg/gc/TestNUMAPageSize.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData00.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData05.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData10.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData15.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData20.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData25.java ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryData30.java Changeset: 2105d8064ca2 Author: kaddepalli Date: 2018-09-27 14:36 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/2105d8064ca2 8208638: Instead of circle rendered in appl window, but ellipse is produced JEditor Pane Reviewed-by: serb, psadhukhan ! src/java.desktop/share/classes/javax/swing/text/html/ImageView.java ! test/jdk/javax/swing/JEditorPane/8195095/ImageViewTest.java Changeset: 170e876d529c Author: prr Date: 2018-09-27 11:46 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/170e876d529c Merge Changeset: b5afdf0bbd9e Author: psadhukhan Date: 2018-09-28 09:17 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/b5afdf0bbd9e 8210306: Missing closing bracket in GridBagLayout gridwidth, gridheight description Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/GridBagLayout.java Changeset: 80b2fa2bf60b Author: clanger Date: 2018-09-28 06:39 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/80b2fa2bf60b 8211218: remove double semicolon in src/java.desktop/macosx/classes/sun/font/CFont.java Reviewed-by: serb ! src/java.desktop/macosx/classes/sun/font/CFont.java Changeset: 26cbbcc2cdb3 Author: psadhukhan Date: 2018-09-29 09:41 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/26cbbcc2cdb3 6994403: Grammatical error in documentation of javax.swing.GroupLayout.ParallelGroup Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/GroupLayout.java Changeset: 5fc701128281 Author: psadhukhan Date: 2018-09-29 09:43 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/5fc701128281 6821316: comment in source code of SynthStyleFactory.java has a self-reference Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyleFactory.java Changeset: 7bd9745e8e15 Author: prr Date: 2018-10-03 11:10 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/7bd9745e8e15 8211031: Remove un-needed qualified export to java.desktop from java.base on macos Reviewed-by: serb, mchung - src/java.base/macosx/classes/module-info.java.extra ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java Changeset: c70468fc7118 Author: vagarwal Date: 2018-10-04 13:01 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/c70468fc7118 8210910: Create test for FileChooserDemo Reviewed-by: serb Contributed-by: vikrant.v.agarwal at oracle.com + test/jdk/sanity/client/SwingSet/src/FileChooserDemoTest.java + test/jdk/sanity/client/SwingSet/src/resources/images/duke.jpg + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/FileChooserDemo.java + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/FileChooserDemo.gif + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/apply.png + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/fliphor.png + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/flipvert.png + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/rotateleft.png + test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/images/rotateright.png Changeset: 8716dd44bc37 Author: psadhukhan Date: 2018-10-04 14:17 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/8716dd44bc37 Merge - make/Jprt.gmk - make/jprt.properties - test/hotspot/jtreg/jprt.config - test/jaxp/javax/xml/jaxp/libs/jaxp/library/JarUtils.java - test/jdk/com/sun/jdi/CatchPatternTest.sh - test/jdk/com/sun/jdi/ImmutableResourceTest.sh - test/jdk/com/sun/jdi/JITDebug.sh - test/jdk/com/sun/jdi/PrivateTransportTest.sh - test/jdk/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh - test/jdk/com/sun/jdi/redefine/RedefineSetUp.sh - test/jdk/com/sun/jdi/redefineMethod/RedefineSetUp.sh - test/jdk/jprt.config - test/jdk/lib/testlibrary/JarUtils.java - test/jdk/sun/security/tools/keytool/autotest.sh - test/jdk/sun/security/tools/keytool/standard.sh Changeset: 651c3558ae2b Author: psadhukhan Date: 2018-10-04 14:56 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/651c3558ae2b 8203281: [Windows] JComboBox change in ui when editor.setBorder() is called Reviewed-by: psadhukhan Contributed-by: mraz.martin.dev at gmail.com ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Changeset: f49c340e3f39 Author: psadhukhan Date: 2018-10-04 15:03 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/f49c340e3f39 8211055: Provide print to a file (PDF) feature even when printer was not connected Reviewed-by: prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m + test/jdk/java/awt/print/PrinterJob/TestSaveFileWithoutPrinter.java Changeset: f775f83d6b60 Author: prr Date: 2018-10-04 11:07 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f775f83d6b60 8208595: [parfait] Better X11 font support Reviewed-by: serb, psadhukhan ! src/java.desktop/unix/native/libfontmanager/X11FontScaler.c Changeset: 2e330da7cbf4 Author: tvaleev Date: 2018-10-04 12:40 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/2e330da7cbf4 8211300: Convert C-style array declarations in JDK client code Reviewed-by: prr, serb ! src/java.desktop/aix/classes/sun/awt/X11InputMethod.java ! src/java.desktop/macosx/classes/com/apple/eio/FileManager.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuItemUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneTabState.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenu.java ! src/java.desktop/macosx/classes/sun/font/CCompositeGlyphMapper.java ! src/java.desktop/macosx/classes/sun/java2d/CRenderer.java ! src/java.desktop/macosx/classes/sun/java2d/CompositeCRenderer.java ! src/java.desktop/macosx/classes/sun/java2d/DataBufferNIOInt.java ! src/java.desktop/macosx/classes/sun/java2d/IntegerNIORaster.java ! src/java.desktop/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java ! src/java.desktop/macosx/classes/sun/java2d/OSXSurfaceData.java ! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CImage.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTextPipe.java ! src/java.desktop/share/classes/com/sun/beans/editors/ColorEditor.java ! src/java.desktop/share/classes/com/sun/beans/editors/FontEditor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/BitFile.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/InputStreamAdapter.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleRenderedImage.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFaxDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFLZWDecompressor.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFLZWUtil.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuUI.java ! src/java.desktop/share/classes/com/sun/media/sound/AiffFileWriter.java ! src/java.desktop/share/classes/com/sun/media/sound/AlawCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/AuFileWriter.java ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/java.desktop/share/classes/com/sun/media/sound/EmergencySoundbank.java ! src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java ! src/java.desktop/share/classes/com/sun/media/sound/ModelByteBuffer.java ! src/java.desktop/share/classes/com/sun/media/sound/RIFFReader.java ! src/java.desktop/share/classes/com/sun/media/sound/RIFFWriter.java ! src/java.desktop/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftReverb.java ! src/java.desktop/share/classes/com/sun/media/sound/StandardMidiFileWriter.java ! src/java.desktop/share/classes/com/sun/media/sound/SunFileWriter.java ! src/java.desktop/share/classes/com/sun/media/sound/UlawCodec.java ! src/java.desktop/share/classes/com/sun/media/sound/WaveFileWriter.java ! src/java.desktop/share/classes/java/awt/AWTEvent.java ! src/java.desktop/share/classes/java/awt/BasicStroke.java ! src/java.desktop/share/classes/java/awt/BufferCapabilities.java ! src/java.desktop/share/classes/java/awt/Color.java ! src/java.desktop/share/classes/java/awt/Cursor.java ! src/java.desktop/share/classes/java/awt/Event.java ! src/java.desktop/share/classes/java/awt/FileDialog.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/java/awt/FontMetrics.java ! src/java.desktop/share/classes/java/awt/GradientPaintContext.java ! src/java.desktop/share/classes/java/awt/Graphics.java ! src/java.desktop/share/classes/java/awt/GridBagLayout.java ! src/java.desktop/share/classes/java/awt/GridBagLayoutInfo.java ! src/java.desktop/share/classes/java/awt/JobAttributes.java ! src/java.desktop/share/classes/java/awt/List.java ! src/java.desktop/share/classes/java/awt/MediaTracker.java ! src/java.desktop/share/classes/java/awt/MultipleGradientPaintContext.java ! src/java.desktop/share/classes/java/awt/PageAttributes.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/RadialGradientPaintContext.java ! src/java.desktop/share/classes/java/awt/Robot.java ! src/java.desktop/share/classes/java/awt/SystemColor.java ! src/java.desktop/share/classes/java/awt/TexturePaintContext.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/font/TextLine.java ! src/java.desktop/share/classes/java/awt/geom/AffineTransform.java ! src/java.desktop/share/classes/java/awt/geom/Area.java ! src/java.desktop/share/classes/java/awt/geom/CubicCurve2D.java ! src/java.desktop/share/classes/java/awt/geom/EllipseIterator.java ! src/java.desktop/share/classes/java/awt/geom/FlatteningPathIterator.java ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! src/java.desktop/share/classes/java/awt/geom/QuadCurve2D.java ! src/java.desktop/share/classes/java/awt/geom/RoundRectIterator.java ! src/java.desktop/share/classes/java/awt/image/AreaAveragingScaleFilter.java ! src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java ! src/java.desktop/share/classes/java/awt/image/BufferedImageFilter.java ! src/java.desktop/share/classes/java/awt/image/ByteLookupTable.java ! src/java.desktop/share/classes/java/awt/image/ColorModel.java ! src/java.desktop/share/classes/java/awt/image/ComponentColorModel.java ! src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java ! src/java.desktop/share/classes/java/awt/image/CropImageFilter.java ! src/java.desktop/share/classes/java/awt/image/DataBuffer.java ! src/java.desktop/share/classes/java/awt/image/DataBufferByte.java ! src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java ! src/java.desktop/share/classes/java/awt/image/DataBufferFloat.java ! src/java.desktop/share/classes/java/awt/image/DataBufferInt.java ! src/java.desktop/share/classes/java/awt/image/DataBufferShort.java ! src/java.desktop/share/classes/java/awt/image/DataBufferUShort.java ! src/java.desktop/share/classes/java/awt/image/DirectColorModel.java ! src/java.desktop/share/classes/java/awt/image/ImageConsumer.java ! src/java.desktop/share/classes/java/awt/image/ImageFilter.java ! src/java.desktop/share/classes/java/awt/image/IndexColorModel.java ! src/java.desktop/share/classes/java/awt/image/Kernel.java ! src/java.desktop/share/classes/java/awt/image/LookupOp.java ! src/java.desktop/share/classes/java/awt/image/MemoryImageSource.java ! src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java ! src/java.desktop/share/classes/java/awt/image/PixelGrabber.java ! src/java.desktop/share/classes/java/awt/image/PixelInterleavedSampleModel.java ! src/java.desktop/share/classes/java/awt/image/RGBImageFilter.java ! src/java.desktop/share/classes/java/awt/image/Raster.java ! src/java.desktop/share/classes/java/awt/image/ReplicateScaleFilter.java ! src/java.desktop/share/classes/java/awt/image/RescaleOp.java ! src/java.desktop/share/classes/java/awt/image/SampleModel.java ! src/java.desktop/share/classes/java/awt/image/ShortLookupTable.java ! src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/java.desktop/share/classes/java/awt/image/WritableRaster.java ! src/java.desktop/share/classes/java/awt/image/renderable/RenderableImageProducer.java ! src/java.desktop/share/classes/java/beans/EventSetDescriptor.java ! src/java.desktop/share/classes/java/beans/Introspector.java ! src/java.desktop/share/classes/java/beans/MetaData.java ! src/java.desktop/share/classes/java/beans/MethodDescriptor.java ! src/java.desktop/share/classes/javax/imageio/stream/ImageOutputStream.java ! src/java.desktop/share/classes/javax/imageio/stream/ImageOutputStreamImpl.java ! src/java.desktop/share/classes/javax/sound/midi/MidiSystem.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java ! src/java.desktop/share/classes/javax/swing/AbstractButton.java ! src/java.desktop/share/classes/javax/swing/ArrayTable.java ! src/java.desktop/share/classes/javax/swing/DebugGraphics.java ! src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java ! src/java.desktop/share/classes/javax/swing/DefaultListModel.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JDesktopPane.java ! src/java.desktop/share/classes/javax/swing/JLabel.java ! src/java.desktop/share/classes/javax/swing/JMenu.java ! src/java.desktop/share/classes/javax/swing/JMenuBar.java ! src/java.desktop/share/classes/javax/swing/JMenuItem.java ! src/java.desktop/share/classes/javax/swing/JPasswordField.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/JTabbedPane.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/JViewport.java ! src/java.desktop/share/classes/javax/swing/MenuElement.java ! src/java.desktop/share/classes/javax/swing/MenuSelectionManager.java ! src/java.desktop/share/classes/javax/swing/PopupFactory.java ! src/java.desktop/share/classes/javax/swing/ProgressMonitorInputStream.java ! src/java.desktop/share/classes/javax/swing/SizeSequence.java ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java ! src/java.desktop/share/classes/javax/swing/ToolTipManager.java ! src/java.desktop/share/classes/javax/swing/TransferHandler.java ! src/java.desktop/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/java.desktop/share/classes/javax/swing/event/MenuKeyEvent.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicRadioButtonMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBumps.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java ! src/java.desktop/share/classes/javax/swing/text/ParagraphView.java ! src/java.desktop/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/html/CSSBorder.java ! src/java.desktop/share/classes/javax/swing/text/html/FrameSetView.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/javax/swing/text/html/MuxingAttributeSet.java ! src/java.desktop/share/classes/javax/swing/text/html/ObjectView.java ! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java ! src/java.desktop/share/classes/javax/swing/text/html/TableView.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/DTD.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/Entity.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java ! src/java.desktop/share/classes/javax/swing/text/rtf/AbstractFilter.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFAttributes.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFParser.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFReader.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/java.desktop/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java ! src/java.desktop/share/classes/sun/awt/CharsetString.java ! src/java.desktop/share/classes/sun/awt/DebugSettings.java ! src/java.desktop/share/classes/sun/awt/FontConfiguration.java ! src/java.desktop/share/classes/sun/awt/IconInfo.java ! src/java.desktop/share/classes/sun/awt/PlatformFont.java ! src/java.desktop/share/classes/sun/awt/RepaintArea.java ! src/java.desktop/share/classes/sun/awt/TracedEventQueue.java ! src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/java.desktop/share/classes/sun/awt/geom/AreaOp.java ! src/java.desktop/share/classes/sun/awt/geom/Crossings.java ! src/java.desktop/share/classes/sun/awt/geom/Curve.java ! src/java.desktop/share/classes/sun/awt/geom/Edge.java ! src/java.desktop/share/classes/sun/awt/geom/Order0.java ! src/java.desktop/share/classes/sun/awt/geom/Order1.java ! src/java.desktop/share/classes/sun/awt/geom/Order2.java ! src/java.desktop/share/classes/sun/awt/geom/Order3.java ! src/java.desktop/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/java.desktop/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java ! src/java.desktop/share/classes/sun/awt/image/ByteBandedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ByteComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/BytePackedRaster.java ! src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java ! src/java.desktop/share/classes/sun/awt/image/ImageDecoder.java ! src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java ! src/java.desktop/share/classes/sun/awt/image/IntegerComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/IntegerInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java ! src/java.desktop/share/classes/sun/awt/image/ShortBandedRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortComponentRaster.java ! src/java.desktop/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java ! src/java.desktop/share/classes/sun/awt/util/IdentityArrayList.java ! src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java ! src/java.desktop/share/classes/sun/font/Font2D.java ! src/java.desktop/share/classes/sun/font/FontDesignMetrics.java ! src/java.desktop/share/classes/sun/font/GlyphList.java ! src/java.desktop/share/classes/sun/font/ScriptRun.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/share/classes/sun/font/TrueTypeFont.java ! src/java.desktop/share/classes/sun/font/Type1Font.java ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java ! src/java.desktop/share/classes/sun/java2d/loops/Blit.java ! src/java.desktop/share/classes/sun/java2d/loops/CustomComponent.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphList.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListAA.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawPolygons.java ! src/java.desktop/share/classes/sun/java2d/loops/GeneralRenderer.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java ! src/java.desktop/share/classes/sun/java2d/loops/MaskBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/MaskFill.java ! src/java.desktop/share/classes/sun/java2d/loops/ProcessPath.java ! src/java.desktop/share/classes/sun/java2d/loops/RenderCache.java ! src/java.desktop/share/classes/sun/java2d/loops/TransformHelper.java ! src/java.desktop/share/classes/sun/java2d/pipe/AATileGenerator.java ! src/java.desktop/share/classes/sun/java2d/pipe/BufferedContext.java ! src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java ! src/java.desktop/share/classes/sun/java2d/pipe/GlyphListPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/LoopPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/NullPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/OutlineTextRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/PixelDrawPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/PixelFillPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java ! src/java.desktop/share/classes/sun/java2d/pipe/PixelToShapeConverter.java ! src/java.desktop/share/classes/sun/java2d/pipe/Region.java ! src/java.desktop/share/classes/sun/java2d/pipe/RegionClipSpanIterator.java ! src/java.desktop/share/classes/sun/java2d/pipe/RegionIterator.java ! src/java.desktop/share/classes/sun/java2d/pipe/RegionSpanIterator.java ! src/java.desktop/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/pipe/ShapeSpanIterator.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanClipRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanIterator.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanShapeRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/TextPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/TextRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/ValidatePipe.java ! src/java.desktop/share/classes/sun/print/PSPrinterJob.java ! src/java.desktop/share/classes/sun/print/PSStreamPrintService.java ! src/java.desktop/share/classes/sun/print/PathGraphics.java ! src/java.desktop/share/classes/sun/print/PeekGraphics.java ! src/java.desktop/share/classes/sun/print/PrintJob2D.java ! src/java.desktop/share/classes/sun/print/ProxyGraphics.java ! src/java.desktop/share/classes/sun/print/ProxyGraphics2D.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/swing/plaf/DesktopProperty.java ! src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/ListHelper.java ! src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java ! src/java.desktop/unix/classes/sun/awt/X11/XAWTLookAndFeel.java ! src/java.desktop/unix/classes/sun/awt/X11/XAWTXSettings.java ! src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XChoicePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XComponentPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XConstants.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedServerTester.java ! src/java.desktop/unix/classes/sun/awt/X11/XFileDialogPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XKeysym.java ! src/java.desktop/unix/classes/sun/awt/X11/XListPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java ! src/java.desktop/unix/classes/sun/awt/X11/XMenuBarPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XRobotPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XScrollPanePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XScrollbar.java ! src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/XWM.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java ! src/java.desktop/unix/classes/sun/awt/X11CustomCursor.java ! src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java ! src/java.desktop/unix/classes/sun/awt/X11InputMethod.java ! src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java ! src/java.desktop/unix/classes/sun/font/DoubleByteEncoder.java ! src/java.desktop/unix/classes/sun/font/X11GB18030_0.java ! src/java.desktop/unix/classes/sun/font/X11GB18030_1.java ! src/java.desktop/unix/classes/sun/font/X11Johab.java ! src/java.desktop/unix/classes/sun/font/X11SunUnicode_0.java ! src/java.desktop/unix/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11Renderer.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRPaints.java ! src/java.desktop/unix/classes/sun/java2d/xr/XRRenderer.java ! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/unix/classes/sun/print/UnixPrintJob.java ! src/java.desktop/unix/classes/sun/print/UnixPrintService.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuBarUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsScrollBarUI.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/java.desktop/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/java.desktop/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/java.desktop/windows/classes/sun/awt/windows/WCustomCursor.java ! src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java ! src/java.desktop/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/java.desktop/windows/classes/sun/awt/windows/WFontMetrics.java ! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java ! src/java.desktop/windows/classes/sun/awt/windows/WListPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/classes/sun/awt/windows/WRobotPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WTrayIconPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java ! src/java.desktop/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java ! src/java.desktop/windows/classes/sun/java2d/windows/GDIRenderer.java Changeset: 715642098c0b Author: kaddepalli Date: 2018-10-05 14:35 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/715642098c0b 8182041: File Chooser Shortcut Panel folders under on JDK 9 8062648: FileSystemView.getDefaultDirectory() should check read access on Unix systems Reviewed-by: serb, prr, psadhukhan ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ! src/java.desktop/share/classes/sun/awt/shell/ShellFolderManager.java ! src/java.desktop/share/classes/sun/swing/WindowsPlacesBar.java + test/jdk/javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesSecurityManagerTest.java ! test/jdk/javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java + test/jdk/javax/swing/JFileChooser/ShellFolderQueries/shellfolderqueries.policy Changeset: cebf87487c33 Author: kaddepalli Date: 2018-10-09 12:08 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/cebf87487c33 8014503: AWT Choice implementation should be made consistent across platforms. Reviewed-by: serb, aghaisas, sveerabhadra ! src/java.desktop/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XChoicePeer.java ! test/jdk/java/awt/Choice/SelectCurrentItemTest/SelectCurrentItemTest.java Changeset: b43c2aa001a5 Author: mbaesken Date: 2018-10-01 12:06 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/b43c2aa001a5 8211317: avoid memory leak in Java_sun_awt_UNIXToolkit_load_1stock_1icon Reviewed-by: clanger, goetz ! src/java.desktop/unix/native/libawt_xawt/awt/awt_UNIXToolkit.c Changeset: de9486d74a74 Author: tvaleev Date: 2018-10-09 18:25 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/de9486d74a74 8211693: Convert C-style array declarations in client demos and jdk.accessibility Reviewed-by: serb ! src/demo/share/java2d/J2DBench/src/j2dbench/Destinations.java ! src/demo/share/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/demo/share/java2d/J2DBench/src/j2dbench/Option.java ! src/demo/share/java2d/J2DBench/src/j2dbench/Result.java ! src/demo/share/java2d/J2DBench/src/j2dbench/ResultSet.java ! src/demo/share/java2d/J2DBench/src/j2dbench/report/HTMLSeriesReporter.java ! src/demo/share/java2d/J2DBench/src/j2dbench/report/IIOComparator.java ! src/demo/share/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/demo/share/java2d/J2DBench/src/j2dbench/report/XMLHTMLReporter.java ! src/demo/share/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/demo/share/java2d/J2DBench/src/j2dbench/tests/ImageTests.java ! src/demo/share/java2d/J2DBench/src/j2dbench/tests/PixelTests.java ! src/demo/share/java2d/J2DBench/src/j2dbench/tests/RenderTests.java ! src/demo/share/java2d/J2DBench/src/j2dbench/ui/EnableButton.java ! src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java ! src/demo/share/jfc/Font2DTest/Font2DTest.java ! src/demo/share/jfc/Font2DTest/FontPanel.java ! src/demo/share/jfc/J2Ddemo/java2d/CloningFeature.java ! src/demo/share/jfc/J2Ddemo/java2d/DemoGroup.java ! src/demo/share/jfc/J2Ddemo/java2d/DemoPanel.java ! src/demo/share/jfc/J2Ddemo/java2d/Intro.java ! src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java ! src/demo/share/jfc/J2Ddemo/java2d/MemoryMonitor.java ! src/demo/share/jfc/J2Ddemo/java2d/TextureChooser.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Arcs_Curves/Arcs.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Arcs_Curves/BezierAnim.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Arcs_Curves/Curves.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Arcs_Curves/Ellipses.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/Areas.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/ClipAnim.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/Intersection.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Clipping/Text.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Colors/BullsEye.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Colors/ColorConvert.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Colors/Rotator3D.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Composite/ACimages.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Composite/ACrules.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Composite/FadeAnim.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/AllFonts.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/AttributedStr.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/Highlighting.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/Outline.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Fonts/Tree.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Images/DukeAnim.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Images/ImageOps.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Images/JPEGFlip.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Images/WarpImage.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Lines/Caps.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Lines/Dash.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Lines/Joins.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Lines/LineAnim.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/Balls.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/BezierScroller.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Mix/Stars3D.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/GradAnim.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/Gradient.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/Texture.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Paint/TextureAnim.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Paths/Append.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Paths/CurveQuadTo.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Paths/FillStroke.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Paths/WindingRule.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Transforms/Rotate.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Transforms/SelectTx.java ! src/demo/share/jfc/J2Ddemo/java2d/demos/Transforms/TransformAnim.java ! src/demo/share/jfc/SampleTree/SampleTree.java ! src/demo/share/jfc/SwingSet2/BezierAnimationPanel.java ! src/demo/share/jfc/SwingSet2/ListDemo.java ! src/demo/share/jfc/SwingSet2/TabbedPaneDemo.java ! src/demo/share/jfc/TableExample/TableExample.java ! src/demo/share/jfc/TableExample/TableSorter.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/Translator.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java Changeset: c2d3b6d84115 Author: psadhukhan Date: 2018-10-10 16:20 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/c2d3b6d84115 8211886: Bad/broken link in synthFileFormat.html Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html Changeset: ac510fd737eb Author: psadhukhan Date: 2018-10-11 14:19 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/ac510fd737eb 6828982: UIDefaults.getUI swallows original exception Reviewed-by: kaddepalli, prr ! src/java.desktop/share/classes/javax/swing/UIDefaults.java + test/jdk/javax/swing/UIDefaults/TestUIDefaultsErrorHandling.java Changeset: c7afaa79cbb3 Author: psadhukhan Date: 2018-10-14 18:05 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/c7afaa79cbb3 8212040: Compilation error due to wrong usage of NSPrintJobDispositionValue in mac10.12 Reviewed-by: jdv ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m Changeset: 8e408bf62635 Author: sveerabhadra Date: 2018-10-15 10:29 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/8e408bf62635 8061359: [macosx] Checkbox toggles on Space press but does not spoken by Voice Over Reviewed-by: mhalder, serb ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java Changeset: 30d5f10ace94 Author: jdv Date: 2018-10-16 14:26 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/30d5f10ace94 Merge - test/hotspot/jtreg/ProblemList-cds-mode.txt - test/jdk/com/sun/jdi/DeferredStepTest.sh - test/jdk/com/sun/jdi/ShellScaffold.sh - test/jdk/com/sun/jdi/ZZZcleanup.sh - test/jdk/lib/security/CheckBlacklistedCerts.java - test/jdk/lib/security/cacerts/VerifyCACerts.java - test/jdk/lib/testlibrary/ModuleTargetHelper.java - test/jdk/lib/testlibrary/ModuleUtils.java - test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java - test/jdk/lib/testlibrary/jdk/testlibrary/testkeys Changeset: 02e4b0ab0f97 Author: prr Date: 2018-10-16 10:54 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/02e4b0ab0f97 8212071: Need to set the FreeType LCD Filter to reduce fringing. Reviewed-by: prr, lbourges Contributed-by: John Neffenger ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: 22517c8020d3 Author: serb Date: 2018-10-16 15:47 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/22517c8020d3 8210739: Calling JSpinner's setFont with null throws NullPointerException Reviewed-by: psadhukhan ! src/java.desktop/macosx/classes/com/apple/laf/AquaSpinnerUI.java ! src/java.desktop/share/classes/javax/swing/JSpinner.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java + test/jdk/javax/swing/JSpinner/WrongEditorTextFieldFont/FontSetToNull.java Changeset: 1cfc72a40bb8 Author: serb Date: 2018-10-16 16:49 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1cfc72a40bb8 8133713: [macosx] Accessible JTables always reported as empty Reviewed-by: prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m Changeset: bd20f7a84e3e Author: psadhukhan Date: 2018-10-19 12:39 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/bd20f7a84e3e 8212098: Cleanup of ProblemList.txt for fixed swing tests Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 7dc391950b19 Author: psadhukhan Date: 2018-10-19 12:50 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/7dc391950b19 8211987: Menu bar gets input focus even if Alt-released event is consumed Reviewed-by: serb ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java + test/jdk/com/sun/java/swing/plaf/windows/AltFocusIssueTest.java Changeset: 680ab6b53f6f Author: itakiguchi Date: 2018-10-19 15:26 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/680ab6b53f6f 8211393: Memory leak issue on awt_InputMethod.c Reviewed-by: naoto, clanger ! src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c ! src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c Changeset: d6c322e900b2 Author: serb Date: 2018-10-19 11:15 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/d6c322e900b2 8212213: All tests for splashscreen stopped worked in jdk12b13 Reviewed-by: ihse, prr ! src/java.base/macosx/native/libjli/java_md_macosx.m ! test/jdk/java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java Changeset: 297450fcab26 Author: jdv Date: 2018-10-16 23:21 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/297450fcab26 Merge - src/java.xml.crypto/share/classes/javax/xml/crypto/dom/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/package.html - test/jdk/java/util/Locale/LocaleCategory.sh - test/jdk/java/util/Locale/LocaleProviders.sh - test/jdk/java/util/PluggableLocale/BreakIteratorProviderTest.sh - test/jdk/java/util/PluggableLocale/CalendarDataProviderTest.sh - test/jdk/java/util/PluggableLocale/CalendarNameProviderTest.sh - test/jdk/java/util/PluggableLocale/ClasspathTest.sh - test/jdk/java/util/PluggableLocale/CollatorProviderTest.sh - test/jdk/java/util/PluggableLocale/CurrencyNameProviderTest.sh - test/jdk/java/util/PluggableLocale/DateFormatProviderTest.sh - test/jdk/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/ExecTest.sh - test/jdk/java/util/PluggableLocale/GenericTest.sh - test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.sh - test/jdk/java/util/PluggableLocale/NumberFormatProviderTest.sh - test/jdk/java/util/PluggableLocale/PermissionTest.sh - test/jdk/java/util/PluggableLocale/TimeZoneNameProviderTest.sh - test/jdk/java/util/PluggableLocale/barprovider.jar - test/jdk/java/util/PluggableLocale/fooprovider.jar - test/jdk/java/util/PluggableLocale/providersrc/BreakIteratorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CollatorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DecimalFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/FooDateFormat.java - test/jdk/java/util/PluggableLocale/providersrc/FooNumberFormat.java - test/jdk/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_kyoto.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_osaka.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_xx.properties - test/jdk/java/util/PluggableLocale/providersrc/Makefile - test/jdk/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/TimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/Utils.java - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.BreakIteratorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.CollatorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DecimalFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.NumberFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.LocaleNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider Changeset: 7530494ed51d Author: jdv Date: 2018-10-23 15:29 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/7530494ed51d Merge ! test/jdk/ProblemList.txt Changeset: 0f81b26228ec Author: jdv Date: 2018-10-24 13:35 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/0f81b26228ec Merge Changeset: da2ddafdd4e1 Author: jdv Date: 2018-10-24 15:57 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/da2ddafdd4e1 Merge - test/jdk/java/util/Calendar/GenericTimeZoneNamesTest.sh - test/jdk/java/util/Calendar/NarrowNamesTest.sh - test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.sh Changeset: a083dbe558f7 Author: jdv Date: 2018-10-24 16:29 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/a083dbe558f7 Merge Changeset: 487bd00f4ea8 Author: stuefe Date: 2018-10-24 14:59 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/487bd00f4ea8 8212913: (Nested)ThreadsListHandleInErrorHandlingTest need to disable ShowRegistersOnAssert Reviewed-by: dholmes, mdoerr ! test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java ! test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java Changeset: 1587306fe23f Author: tschatzl Date: 2018-10-24 16:22 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/1587306fe23f 8212753: Improve oopDesc::forward_to_atomic Summary: Avoid multiple unnecessary reloads of the mark oop in oopDesc::forward_to_atomic Reviewed-by: kbarrett, mdoerr ! src/hotspot/share/gc/cms/parNewGeneration.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: be166557c8dc Author: ecaspole Date: 2018-10-24 11:02 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/be166557c8dc 8212706: nmethod jvmci_installed_code_name need to be XML escaped Summary: Call text instead of print to escape chars properly Reviewed-by: thartmann ! src/hotspot/share/code/nmethod.cpp Changeset: 97b761e247b3 Author: dcubed Date: 2018-10-24 11:04 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/97b761e247b3 8212220: add code to verify results to metaspace/stressDictionary/StressDictionary.java Summary: Also change the test's default timeout to 5 minutes. Reviewed-by: dholmes, stuefe ! test/hotspot/jtreg/vmTestbase/metaspace/stressDictionary/StressDictionary.java Changeset: eefa65e142af Author: dcubed Date: 2018-10-24 11:05 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/eefa65e142af Merge Changeset: f39073b97db7 Author: epavlova Date: 2018-10-24 09:56 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f39073b97db7 8212877: Restore JTREG_VERBOSE value for mach5 testing Reviewed-by: dholmes ! make/conf/jib-profiles.js Changeset: ad9077f044be Author: sspitsyn Date: 2018-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/ad9077f044be 8024368: private methods are allocated vtable slots Summary: Stop allocating vtable slots for private methods Reviewed-by: dholmes, acorn, lfoltan ! src/hotspot/share/oops/klassVtable.cpp Changeset: c2f38eb6b31a Author: darcy Date: 2018-10-24 15:45 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c2f38eb6b31a 8212880: Cannot access ftp: site for fdlibm.tar Reviewed-by: jjg, lancea, bpb ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: e11a53698d57 Author: cushon Date: 2018-09-17 11:09 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/e11a53698d57 8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter Reviewed-by: wmdietl, abuckley, martin ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnonymousClassTest.java Changeset: a8d239bdaaee Author: jwilhelm Date: 2018-10-24 18:14 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/a8d239bdaaee Added tag jdk-12+17 for changeset eefa65e142af ! .hgtags Changeset: 09be9fd37b91 Author: amlu Date: 2018-10-25 11:00 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/09be9fd37b91 8210908: Refactor java/util/prefs/PrefsSpi.sh to plain java test Reviewed-by: bchristi ! test/jdk/java/util/prefs/PrefsSpi.java - test/jdk/java/util/prefs/PrefsSpi.sh + test/jdk/java/util/prefs/PrefsSpiTest.java + test/jdk/java/util/prefs/StubPreferences.java + test/jdk/java/util/prefs/StubPreferencesFactory.java Changeset: b646c9ea2394 Author: amlu Date: 2018-10-25 11:05 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/b646c9ea2394 8209768: Refactor java/util/prefs/CheckUserPrefsStorage.sh to plain java test Reviewed-by: bchristi, weijun ! test/jdk/java/util/prefs/CheckUserPrefFirst.java ! test/jdk/java/util/prefs/CheckUserPrefLater.java + test/jdk/java/util/prefs/CheckUserPrefsStorage.java - test/jdk/java/util/prefs/CheckUserPrefsStorage.sh Changeset: 003c062e16ea Author: rfield Date: 2018-10-24 21:17 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/003c062e16ea 8211694: JShell: Redeclared variable should be reset Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! test/langtools/jdk/jshell/SnippetTest.java ! test/langtools/jdk/jshell/ToolBasicTest.java ! test/langtools/jdk/jshell/VariablesTest.java Changeset: ef0fed0a3953 Author: michaelm Date: 2018-10-25 12:09 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/ef0fed0a3953 8212926: HttpClient does not retrieve files with large sizes over HTTP/1.1 Reviewed-by: chegar, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseContent.java + test/jdk/java/net/httpclient/LargeResponseContent.java Changeset: 1f402d1f630f Author: jcbeyler Date: 2018-10-25 08:18 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/1f402d1f630f 8212770: Remove spaces before/after () for vmTestbase/jvmti/[s-u] Summary: Remove spaces before/after () Reviewed-by: amenkov, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/ap04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t001/ap05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t002/ap05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t001/ap07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t002/ap07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP09/ap09t001/ap09t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/ap12t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/bi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t002/bi01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/em01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/ex03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS103/hs103t002/hs103t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t001/hs104t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t002/hs104t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t001/hs202t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t001/hs203t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t002/hs203t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/hs203t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t002/hs204t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t004/hs204t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t002/hs301t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t003/hs301t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004/hs301t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t005/hs301t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t001/hs302t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t002/hs302t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t003/hs302t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t004/hs302t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t005/hs302t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t006/hs302t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t007/hs302t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t008/hs302t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t009/hs302t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t010/hs302t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t011/hs302t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t012/hs302t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t003/sp02t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/followref001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/followref002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/followref004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/followref005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp Changeset: 8e575009ac4a Author: dlong Date: 2018-10-25 09:20 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/8e575009ac4a 8212978: Add RedefineMethodUsedByMultipleMethodHandles.java to problem list Reviewed-by: kvn ! test/hotspot/jtreg/ProblemList-graal.txt Changeset: d98fb44ad6bf Author: mullan Date: 2018-10-25 13:55 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/d98fb44ad6bf 8211883: Disable anon and NULL cipher suites Reviewed-by: jnimeh ! src/java.base/share/conf/security/java.security ! test/jdk/javax/net/ssl/SSLSession/JSSERenegotiate.java ! test/jdk/javax/net/ssl/ciphersuites/DisabledAlgorithms.java ! test/jdk/sun/security/ssl/SSLContextImpl/CustomizedCipherSuites.java Changeset: 2f6c9127dd97 Author: mchung Date: 2018-10-25 10:56 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/2f6c9127dd97 8212948: Remove unused jdk.internal.misc.VMNotification interface Reviewed-by: alanb - src/java.base/share/classes/jdk/internal/misc/VMNotification.java Changeset: 2b29df6dfa68 Author: mchung Date: 2018-10-25 10:57 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/2b29df6dfa68 8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData Reviewed-by: dfuchs ! src/java.management/share/classes/sun/management/LockInfoCompositeData.java ! src/java.management/share/classes/sun/management/MonitorInfoCompositeData.java ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java ! test/jdk/java/lang/management/CompositeData/ThreadInfoCompositeData.java Changeset: 04e6910792b3 Author: mchung Date: 2018-10-25 10:58 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/04e6910792b3 Merge Changeset: db83eceba962 Author: ppunegov Date: 2018-10-25 11:18 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/db83eceba962 8164546: Convert DirectivesParser_test to GTest Reviewed-by: kvn, iignatyev, neliasso ! src/hotspot/share/compiler/directivesParser.cpp ! src/hotspot/share/compiler/directivesParser.hpp ! src/hotspot/share/utilities/internalVMTests.cpp + test/hotspot/gtest/compiler/test_directivesParser.cpp Changeset: fa61165a3f2b Author: amenkov Date: 2018-10-25 11:48 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/fa61165a3f2b 8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 Reviewed-by: sspitsyn, jcbeyler ! test/jdk/com/sun/jdi/ExclusiveBind.java + test/jdk/com/sun/jdi/lib/jdb/Debuggee.java ! test/jdk/com/sun/jdi/lib/jdb/JdbTest.java Changeset: 39f8fa3a7be8 Author: akolarkunnu Date: 2018-10-25 08:59 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/39f8fa3a7be8 8212897: Some improvements in the EditorPaneDemotest Reviewed-by: serb Contributed-by: abdul.kolarkunnu at oracle.com ! test/jdk/sanity/client/SwingSet/src/EditorPaneDemoTest.java Changeset: d01d4bd7c5b3 Author: jcbeyler Date: 2018-10-25 14:23 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/d01d4bd7c5b3 8212884: Remove the assignments in ifs for vmTestbase/[a-s] Summary: Extract assignments from if statements in vmTestbase Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine09/agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/attach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/attach002aAgent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach008/attach008Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach009/attach009Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach012/attach012Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach014/attach014Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach037/attach037Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach038/attach038Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach039/attach039Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach040/attach040Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach041/attach041Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach042/attach042Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent02.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent03.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach046/attach046Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach050/attach050Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/sharedAgents/simpleAgent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/abort/Abort.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/callbacks/Callbacks.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/concrete-klass-filter/ConcreteKlassFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/HeapFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/non-concrete-klass-filter/NonConcreteKlassFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadEnd/threadend002/threadend002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/bi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t002/bi01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/bi04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t001/em01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/em01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t001/em02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t002/em02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/em02t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t004/em02t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/em02t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/em02t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t007/em02t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t008/em02t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t009/em02t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t010/em02t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t011/em02t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012/em02t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp Changeset: bd8c721954a4 Author: dholmes Date: 2018-10-25 19:12 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/bd8c721954a4 8210242: vmTestbase/nsk/stress/jni/jnistress001.java crashes with EXCEPTION_ACCESS_VIOLATION on windows-x86 Summary: Non-NUL-terminated string was passed to %s - use %.*s to specify the actual length. Reviewed-by: lfoltan, hseigel ! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/jnihelper.h ! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress001.cpp Changeset: 57d299cdd068 Author: erikj Date: 2018-10-25 16:47 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/57d299cdd068 8213005: Missing symbols in hs_err files on Windows after JDK-8212028 Reviewed-by: ctornqvi ! make/RunTests.gmk ! make/RunTestsPrebuiltSpec.gmk Changeset: 26207007d234 Author: iris Date: 2018-10-25 17:06 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/26207007d234 8212994: Links to Oracle websites should use "https:" Reviewed-by: erikj, lancea ! make/Docs.gmk Changeset: 99962c340e73 Author: dlong Date: 2018-10-25 18:41 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/99962c340e73 8021335: Missing synchronization when reading counters for live threads and peak thread count Reviewed-by: dholmes, mchung ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/services/threadService.cpp ! src/hotspot/share/services/threadService.hpp ! test/jdk/java/lang/management/ThreadMXBean/ResetPeakThreadCount.java Changeset: 83039b8e6a42 Author: never Date: 2018-10-25 19:00 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/83039b8e6a42 8212956: [JVCMI] SpeculationReason should maintain identity Reviewed-by: kvn ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SpeculationLog.java + test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestSpeculationLog.java Changeset: 17826b492ddd Author: weijun Date: 2018-10-26 11:11 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/17826b492ddd 8212867: Link to DRBG test vectors is redirected to a broken link Reviewed-by: mullan ! src/java.base/share/classes/java/security/DrbgParameters.java Changeset: 9e29d8388514 Author: ccheung Date: 2018-10-25 21:40 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9e29d8388514 8209598: Clean up how messages are printed when CDS aborts start-up Summary: added a new function vm_exit_during_cds_dumping() to java.cpp so that it can be used when an error condition is encountered during CDS dumping. Reviewed-by: iklam, dholmes, jiangli ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/java.hpp Changeset: fbfcdc5bf694 Author: hseigel Date: 2018-10-26 08:23 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/fbfcdc5bf694 8192864: defmeth tests can hide failures Summary: Add a call to addFailureCount() to record previously hidden failures. Reviewed-by: lfoltan, coleenp ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/DefMethTest.java Changeset: 912b79d983d9 Author: stuefe Date: 2018-10-19 09:39 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/912b79d983d9 8212173: Thread._stack_base/_stack_size initialized too late for new threads Reviewed-by: dholmes, simonis ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/solaris/os_solaris.cpp ! src/hotspot/os/solaris/os_solaris.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp ! src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp ! src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp ! src/hotspot/share/gc/parallel/gcTaskThread.cpp ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmThread.cpp Changeset: 91a57277c419 Author: weijun Date: 2018-10-26 22:58 +0800 URL: http://hg.openjdk.java.net/panama/dev/rev/91a57277c419 8213007: Update the link in test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java Reviewed-by: mullan ! test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java Changeset: 72f2fc52ef85 Author: gziemski Date: 2018-10-26 10:47 -0500 URL: http://hg.openjdk.java.net/panama/dev/rev/72f2fc52ef85 8017061: os_bsd.cpp contains code for UseSHM and UseHugeTLBFS Summary: Removed the code using unused flags. Reviewed-by: dholmes, coleenp ! src/hotspot/os/bsd/globals_bsd.hpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/share/runtime/arguments.cpp Changeset: 52a97e06a5e3 Author: lancea Date: 2018-10-26 14:02 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/52a97e06a5e3 8212129: Remove finalize methods from java.util.zip.ZipFIle/Inflator/Deflator Reviewed-by: rriggs, sherman, alanb, clanger ! src/java.base/share/classes/java/util/zip/Deflater.java ! src/java.base/share/classes/java/util/zip/Inflater.java ! src/java.base/share/classes/java/util/zip/ZipFile.java - test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java ! test/jdk/java/util/zip/ZipFile/TestCleaner.java Changeset: 3a767a000aab Author: mchung Date: 2018-10-26 13:59 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/3a767a000aab 8213043: Add internal Unsafe xxxObject methods as jsr166 is broken Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: b553825935fc Author: jjg Date: 2018-10-26 15:13 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/b553825935fc 8213056: Nested anchor tags in java.lang.module Reviewed-by: darcy ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/module/package-info.java Changeset: 3ef47d047efc Author: tschatzl Date: 2018-10-29 08:52 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/3ef47d047efc 8212974: Update RS Skipped cards uses wrong enum to register to phase Reviewed-by: kbarrett ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp Changeset: 3b6680f7542f Author: tschatzl Date: 2018-10-29 08:55 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/3b6680f7542f 8212766: TestPromotionEventWithG1.java failed due to "RuntimeException: PLAB size is smaller than object size." Summary: Also send PLAB size in bytes, not in heap words. Reviewed-by: shade, sjohanss ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! test/jdk/jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java Changeset: a8e43293b4c4 Author: hseigel Date: 2018-10-29 08:38 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/a8e43293b4c4 8212997: [TESTBUG] Remove defmeth tests for class file versions 50 and 51 Summary: Remove the unneeded tests. Keep the tests for class file versions 49 and 52. Reviewed-by: acorn, coleenp ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/README - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_reflect_redefine/TestDescription.java Changeset: 274ba8fbd96d Author: coleenp Date: 2018-10-29 10:21 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/274ba8fbd96d 8212958: Allow Klass::_subklass and _next_sibling to have unloaded classes Summary: Don't return unloaded klasses. Make sure access is protected by Compile_lock. Reviewed-by: eosterlund, dlong ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/jfr/jni/jfrGetAllEventClasses.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/utilities/vmError.cpp + test/hotspot/jtreg/runtime/ClassUnload/UnloadInterfaceTest.java + test/hotspot/jtreg/runtime/ClassUnload/test/ImplementorClass.java + test/hotspot/jtreg/runtime/ClassUnload/test/Interface.java ! test/hotspot/jtreg/runtime/testlibrary/ClassUnloadCommon.java Changeset: 5b9c8d77a9fe Author: jlaskey Date: 2018-10-29 12:31 -0300 URL: http://hg.openjdk.java.net/panama/dev/rev/5b9c8d77a9fe 8212694: Using Raw String Literals with align() and Integer.MIN_VALUE causes out of memory error Reviewed-by: smarks, sherman ! src/java.base/share/classes/java/lang/String.java ! test/jdk/java/lang/String/AlignIndent.java Changeset: f300b4ca2637 Author: rfield Date: 2018-10-29 08:34 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/f300b4ca2637 8210808: jshell tool: only considers the first snippet of the external editor Reviewed-by: jlahoda, sundar ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! test/langtools/jdk/jshell/EditorTestBase.java ! test/langtools/jdk/jshell/ExternalEditorTest.java Changeset: e53af5fa0dae Author: iklam Date: 2018-10-25 11:23 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/e53af5fa0dae 8212205: VM asserts after CDS archive has been unmapped Reviewed-by: dholmes, jiangli, hseigel, stuefe ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/metaspaceShared.hpp Changeset: 50426919edbb Author: jiangli Date: 2018-10-29 14:00 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/50426919edbb 8205327: Clean up #if INCLUDE_CDS in classLoaderExt.cpp and classLoaderExt.hpp Summary: Clean up #if INCLUDE_CDS in classLoaderExt.* files. Reviewed-by: dholmes ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/classLoaderExt.hpp Changeset: 3152b928769d Author: ccheung Date: 2018-10-29 11:05 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/3152b928769d 8209566: [TESTBUG] runtime/appcds/jigsaw/modulepath/JvmtiAddPath.java timeout on tier6 on sparc Summary: increased the timeout from 120s (default) to 240s Reviewed-by: dcubed, mseledtsov ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/JvmtiAddPath.java Changeset: 3c981e581f93 Author: darcy Date: 2018-10-29 11:31 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/3c981e581f93 8212081: AnnotatedType.toString implementation don't print annotations on embedded types Reviewed-by: jfranck, wmdietl ! src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java Changeset: 124af9276e44 Author: jjg Date: 2018-10-29 12:33 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/124af9276e44 8213102: Oracle Unilinks are [301 Moved Permanently] to https://docs.oracle.com Reviewed-by: lancea, mchung ! make/Docs.gmk ! make/jdk/src/classes/build/tools/taglet/ExtLink.java Changeset: 625f6c742392 Author: iklam Date: 2018-10-17 15:57 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/625f6c742392 8212200: assert when shared java.lang.Object is redefined by JVMTI agent Reviewed-by: dholmes, jiangli, hseigel, lfoltan, sspitsyn ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/heapShared.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiExport.hpp + test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java ! test/hotspot/jtreg/testlibrary/jvmti/libSimpleClassFileLoadHook.c ! test/lib/jdk/test/lib/cds/CDSOptions.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 26777794ade5 Author: ccheung Date: 2018-10-29 13:58 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/26777794ade5 8212154: [TESTBUG] CheckArchivedModuleApp fails with NPE when JVMCI is absent Summary: added a null check on wb.getBooleanVMFlag("EnableJVMCI"). Reviewed-by: hseigel, jiangli ! test/hotspot/jtreg/runtime/appcds/cacheObject/CheckArchivedModuleApp.java Changeset: 52d3bb5ba2f7 Author: kzhaldyb Date: 2018-10-29 14:04 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/52d3bb5ba2f7 8157728: Convert GCTimer_test to GTest Reviewed-by: tschatzl, jcbeyler, iignatyev ! src/hotspot/share/gc/shared/gcTimer.cpp ! src/hotspot/share/gc/shared/gcTimer.hpp ! src/hotspot/share/utilities/internalVMTests.cpp ! src/hotspot/share/utilities/ticks.hpp + test/hotspot/gtest/gc/shared/test_gcTimer.cpp Changeset: 3d33e20a5794 Author: iignatyev Date: 2018-10-29 14:04 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/3d33e20a5794 8177710: Convert TestMetaspaceUtils_test to GTest Reviewed-by: tschatzl ! src/hotspot/share/utilities/internalVMTests.cpp + test/hotspot/gtest/memory/test_metaspace.cpp Changeset: c306abfeae0d Author: vromero Date: 2018-10-29 17:09 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/c306abfeae0d 8213100: fix test OptionSmokeTest before removing it from the problem list Reviewed-by: jlahoda ! test/langtools/tools/javac/options/smokeTests/OptionSmokeTest.java Changeset: 0c5fc2063221 Author: vromero Date: 2018-10-29 17:11 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/0c5fc2063221 8212624: remove outdated entries from langtools problem list Reviewed-by: darcy ! test/langtools/ProblemList.txt Changeset: 0451e0a2f1f5 Author: thartmann Date: 2018-10-30 09:06 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/0451e0a2f1f5 8177899: Tests fail due to code cache exhaustion on machines with many cores Summary: Implemented upper limit on CICompilerCount based on code cache size. Reviewed-by: kvn, mdoerr ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/c2compiler.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/runtime/compilationPolicy.cpp ! src/hotspot/share/runtime/tieredThresholdPolicy.cpp Changeset: 77018c2b97df Author: redestad Date: 2018-10-30 09:34 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/77018c2b97df 8213035: Pack MethodHandleInlineStrategy coder and length into a long Reviewed-by: vlivanov, mchung ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: 6fe18b0c0e88 Author: stuefe Date: 2018-10-26 16:49 +0200 URL: http://hg.openjdk.java.net/panama/dev/rev/6fe18b0c0e88 8213017: jspawnhelper: need to handle pipe write failure when sending return code Reviewed-by: alanb ! src/java.base/unix/native/jspawnhelper/jspawnhelper.c Changeset: 16950b2eaebf Author: hseigel Date: 2018-10-30 09:13 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/16950b2eaebf 8213148: JDK build fails because of missing #includes Summary: Add missing #includes Reviewed-by: dcubed ! test/hotspot/gtest/memory/test_metaspace.cpp Changeset: 51a3e729535c Author: naoto Date: 2018-10-30 10:32 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/51a3e729535c 8212941: Loosen the range of JapaneseEra Reviewed-by: rriggs ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java Changeset: df10a0cacf3e Author: apetcher Date: 2018-10-30 13:48 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/df10a0cacf3e 8205476: KeyAgreement#generateSecret is not reset for ECDH based algorithm Summary: Clarify spec of generateSecret and modify ECDH in SunEC to conform to spec Reviewed-by: mullan ! src/java.base/share/classes/javax/crypto/KeyAgreement.java ! src/java.base/share/classes/javax/crypto/KeyAgreementSpi.java ! src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java ! test/jdk/java/security/KeyAgreement/KeyAgreementTest.java Changeset: 8d8702585652 Author: kvn Date: 2018-10-30 14:38 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/8d8702585652 8210853: JIT: C2 doesn't skip post barrier for new allocated objects Summary: skip copy Region node when look for last allocation Reviewed-by: thartmann, kvn Contributed-by: kuaiwei.kw at alibaba-inc.com ! src/hotspot/share/opto/graphKit.cpp Changeset: d2a3503c72f7 Author: kbarrett Date: 2018-10-30 18:06 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/d2a3503c72f7 8212827: GlobalCounter should support nested critical sections Summary: Support nested critical sections. Reviewed-by: eosterlund, rehn, tschatzl ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp ! src/hotspot/share/utilities/globalCounter.cpp ! src/hotspot/share/utilities/globalCounter.hpp ! src/hotspot/share/utilities/globalCounter.inline.hpp ! src/hotspot/share/utilities/singleWriterSynchronizer.hpp ! test/hotspot/gtest/utilities/test_globalCounter.cpp + test/hotspot/gtest/utilities/test_globalCounter_nested.cpp Changeset: c401c536cea1 Author: dlong Date: 2018-10-30 15:17 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c401c536cea1 8211743: [AOT] crash in ScopeDesc::decode_body() when JVMTI walks AOT frames Reviewed-by: kvn ! src/hotspot/share/aot/aotLoader.cpp Changeset: a181612f0715 Author: egahlin Date: 2018-10-31 02:10 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/a181612f0715 8203629: Produce events in the JDK without a dependency on jdk.jfr Reviewed-by: mgronlun ! src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp ! src/hotspot/share/jfr/jni/jfrGetAllEventClasses.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp + src/java.base/share/classes/jdk/internal/event/Event.java ! src/java.base/share/classes/module-info.java ! src/jdk.jfr/share/classes/jdk/jfr/Event.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventHandlerCreator.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java + src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SettingsManager.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Type.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java ! test/jdk/jdk/jfr/jvm/TestGetAllEventClasses.java Changeset: 6507eeb6f047 Author: jiangli Date: 2018-10-30 22:24 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/6507eeb6f047 8203953: Rename SystemDictionary::load_shared_class(Symbol*, Handle, TRAPS) to load_shared_boot_class(). Summary: Rename SystemDictionary::load_shared_class. Reviewed-by: coleenp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp Changeset: 9ae99ef38c16 Author: dtitov Date: 2018-10-30 19:29 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/9ae99ef38c16 8195627: [Graal] nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026 hangs with Graal in Xcomp mode Reviewed-by: sspitsyn, kvn ! src/hotspot/share/compiler/compileBroker.cpp Changeset: 346ad00d6154 Author: xuelei Date: 2018-10-30 19:47 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/346ad00d6154 8212738: Incorrectly named signature scheme ecdsa_secp512r1_sha512 Reviewed-by: ascarpino ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java Changeset: ac4ea1fe09b9 Author: joehw Date: 2018-10-30 20:44 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/ac4ea1fe09b9 8212866: Broken link to schematron.com Reviewed-by: lancea ! src/java.xml/share/classes/javax/xml/validation/package-info.java Changeset: cda2f582500e Author: pmuthuswamy Date: 2018-10-31 10:29 +0530 URL: http://hg.openjdk.java.net/panama/dev/rev/cda2f582500e 8210244: {@value} should be permitted in module documentation Reviewed-by: jjg, sundar ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ValueTaglet.java ! test/langtools/jdk/javadoc/doclet/testTaglets/TestTaglets.out + test/langtools/jdk/javadoc/doclet/testValueTag/TestValueTagInModule.java Changeset: adb107c71a12 Author: mgronlun Date: 2018-10-31 09:09 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/adb107c71a12 8213172: CDS and JFR tests fail with assert(JdkJfrEvent::is(klass)) failed: invariant Reviewed-by: egahlin, dholmes ! src/hotspot/share/classfile/dictionary.cpp Changeset: 2b58b8e1d28f Author: rehn Date: 2018-10-31 08:09 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/2b58b8e1d28f 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks Reviewed-by: eosterlund, dcubed, sspitsyn, dholmes ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/threadSMR.cpp + test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java Changeset: 9341b077bd55 Author: ihse Date: 2018-10-31 09:30 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/9341b077bd55 8210958: Rename "make run-test" to "make test" Reviewed-by: erikj ! doc/testing.html ! doc/testing.md ! make/Help.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/RunTests.gmk ! make/common/FindTests.gmk ! make/conf/jib-profiles.js ! test/Makefile ! test/make/TestMake.gmk ! test/make/TestMakeBase.gmk Changeset: b66b51c4e405 Author: ihse Date: 2018-10-31 11:36 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/b66b51c4e405 8213184: Revert change in jib-profiles.js from run-test-prebuilt to test-prebuilt Reviewed-by: dholmes ! make/conf/jib-profiles.js Changeset: 55711b181dfc Author: coleenp Date: 2018-10-31 07:06 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/55711b181dfc 8213107: Make ClassLoaderDataGraph iterator skip unloaded CLDs Summary: with concurrent class unloading, the CLDG could contain unloaded CLDs while iterating in a safepoint Reviewed-by: lfoltan, eosterlund ! src/hotspot/share/classfile/classLoaderDataGraph.cpp Changeset: 418fb8bb5151 Author: tschatzl Date: 2018-10-31 13:43 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/418fb8bb5151 8071913: Filter out entries to free/uncommitted regions during iteration Reviewed-by: sjohanss, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/heapRegionManager.hpp ! src/hotspot/share/gc/g1/heapRegionManager.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp Changeset: 08041b0d7c08 Author: tschatzl Date: 2018-10-31 13:43 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/08041b0d7c08 6490394: G1: Allow heap shrinking / memory unmapping after reclaiming regions during Remark Reviewed-by: sjohanss, sangheki ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! test/hotspot/jtreg/gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java Changeset: 14ef0f74667b Author: tschatzl Date: 2018-10-31 13:43 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/14ef0f74667b 8211388: Make OtherRegionsTable independent of the region it is for Reviewed-by: sjohanss, sangheki ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp ! src/hotspot/share/gc/g1/sparsePRT.cpp ! src/hotspot/share/gc/g1/sparsePRT.hpp Changeset: 21fdf8d9a8b6 Author: tschatzl Date: 2018-10-31 13:43 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/21fdf8d9a8b6 8212911: Unify and micro-optimize handling of non-in-collection set references in oop closures Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1OopClosures.cpp ! src/hotspot/share/gc/g1/g1OopClosures.hpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: f34a2e0069c7 Author: tschatzl Date: 2018-10-31 13:43 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/f34a2e0069c7 8213142: Use RAII to set the scanning source in G1ScanEvacuatedObjClosure Reviewed-by: sangheki, kbarrett ! src/hotspot/share/gc/g1/g1OopClosures.hpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp Changeset: 9e3fd0cc3936 Author: mdoerr Date: 2018-10-31 14:48 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/9e3fd0cc3936 8213086: Compiler thread creation should be bounded by available space in memory and Code Cache Reviewed-by: kvn, thartmann ! src/hotspot/share/compiler/compileBroker.cpp Changeset: 0ecb4e520110 Author: bobv Date: 2018-10-30 10:39 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/0ecb4e520110 8209093: JEP 340: One AArch64 Port, Not Two Reviewed-by: dholmes, erikj, mikael, shade, avoitylov, bulasevich ! doc/building.html ! doc/building.md ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-ldflags.m4 ! make/autoconf/flags.m4 ! make/autoconf/hotspot.m4 ! make/conf/jib-profiles.js ! make/hotspot/lib/CompileJvm.gmk ! src/hotspot/cpu/arm/abstractInterpreter_arm.cpp ! src/hotspot/cpu/arm/arm.ad - src/hotspot/cpu/arm/arm_64.ad ! src/hotspot/cpu/arm/assembler_arm.hpp - src/hotspot/cpu/arm/assembler_arm_64.cpp - src/hotspot/cpu/arm/assembler_arm_64.hpp ! src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp ! src/hotspot/cpu/arm/c1_Defs_arm.hpp ! src/hotspot/cpu/arm/c1_FrameMap_arm.cpp ! src/hotspot/cpu/arm/c1_FrameMap_arm.hpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.hpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.hpp ! src/hotspot/cpu/arm/c1_LIR_arm.cpp ! src/hotspot/cpu/arm/c1_LinearScan_arm.hpp ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp ! src/hotspot/cpu/arm/c2_globals_arm.hpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/arm/frame_arm.hpp ! src/hotspot/cpu/arm/frame_arm.inline.hpp ! src/hotspot/cpu/arm/gc/g1/g1BarrierSetAssembler_arm.cpp ! src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp ! src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp ! src/hotspot/cpu/arm/globalDefinitions_arm.hpp ! src/hotspot/cpu/arm/globals_arm.hpp ! src/hotspot/cpu/arm/icBuffer_arm.cpp ! src/hotspot/cpu/arm/icache_arm.cpp ! src/hotspot/cpu/arm/interp_masm_arm.cpp ! src/hotspot/cpu/arm/interp_masm_arm.hpp ! src/hotspot/cpu/arm/interpreterRT_arm.cpp ! src/hotspot/cpu/arm/interpreterRT_arm.hpp ! src/hotspot/cpu/arm/jniFastGetField_arm.cpp ! src/hotspot/cpu/arm/jniTypes_arm.hpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.hpp ! src/hotspot/cpu/arm/macroAssembler_arm.inline.hpp ! src/hotspot/cpu/arm/methodHandles_arm.cpp ! src/hotspot/cpu/arm/nativeInst_arm.hpp - src/hotspot/cpu/arm/nativeInst_arm_64.cpp - src/hotspot/cpu/arm/nativeInst_arm_64.hpp ! src/hotspot/cpu/arm/register_arm.cpp ! src/hotspot/cpu/arm/register_arm.hpp ! src/hotspot/cpu/arm/register_definitions_arm.cpp ! src/hotspot/cpu/arm/relocInfo_arm.cpp ! src/hotspot/cpu/arm/runtime_arm.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/stubGenerator_arm.cpp ! src/hotspot/cpu/arm/stubRoutines_arm.cpp ! src/hotspot/cpu/arm/stubRoutines_arm.hpp ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/arm/vm_version_arm.hpp - src/hotspot/cpu/arm/vm_version_arm_64.cpp ! src/hotspot/cpu/arm/vm_version_ext_arm.cpp ! src/hotspot/cpu/arm/vtableStubs_arm.cpp ! src/hotspot/os_cpu/linux_arm/atomic_linux_arm.hpp ! src/hotspot/os_cpu/linux_arm/copy_linux_arm.inline.hpp ! src/hotspot/os_cpu/linux_arm/globals_linux_arm.hpp ! src/hotspot/os_cpu/linux_arm/linux_arm_32.s - src/hotspot/os_cpu/linux_arm/linux_arm_64.s ! src/hotspot/os_cpu/linux_arm/orderAccess_linux_arm.hpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ! src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp ! src/hotspot/os_cpu/linux_arm/prefetch_linux_arm.inline.hpp ! src/hotspot/os_cpu/linux_arm/thread_linux_arm.cpp ! src/hotspot/share/utilities/macros.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java Changeset: 0c25fa66b5c5 Author: bobv Date: 2018-10-31 10:48 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/0c25fa66b5c5 Merge ! make/conf/jib-profiles.js Changeset: 896e80158d35 Author: simonis Date: 2018-10-31 16:02 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/896e80158d35 8213151: [AIX] Some class library files are missing the Classpath exception Reviewed-by: stuefe, rriggs, mbaesken ! src/java.base/aix/native/libjli/java_md_aix.c ! src/java.base/aix/native/libjli/java_md_aix.h ! src/java.desktop/aix/native/libawt/porting_aix.c ! src/java.desktop/aix/native/libawt/porting_aix.h Changeset: a39d9d4ab891 Author: shade Date: 2018-10-31 19:00 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/a39d9d4ab891 8213182: Minimal VM build failure after JDK-8212200 (assert when shared java.lang.Object is redefined by JVMTI agent) Reviewed-by: dholmes, iklam ! src/hotspot/share/prims/jvmtiExport.hpp Changeset: 0caa36de8703 Author: gromero Date: 2018-10-16 16:26 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/0caa36de8703 8212481: PPC64: Enable POWER9 CPU detection Reviewed-by: mdoerr, simonis ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/cpu/ppc/vm_version_ppc.hpp Changeset: 19c4a3eec4d7 Author: coleenp Date: 2018-10-31 14:38 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/19c4a3eec4d7 8213211: [BACKOUT] Allow Klass::_subklass and _next_sibling to have unloaded classes Reviewed-by: jiangli, jwilhelm ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/jfr/jni/jfrGetAllEventClasses.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/utilities/vmError.cpp - test/hotspot/jtreg/runtime/ClassUnload/UnloadInterfaceTest.java - test/hotspot/jtreg/runtime/ClassUnload/test/ImplementorClass.java - test/hotspot/jtreg/runtime/ClassUnload/test/Interface.java ! test/hotspot/jtreg/runtime/testlibrary/ClassUnloadCommon.java Changeset: e2478be9c682 Author: erikj Date: 2018-10-31 13:14 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/e2478be9c682 8210837: Add libXrandr-devel to the Linux devkits Reviewed-by: prr, mikael ! make/conf/jib-profiles.js ! make/devkit/Makefile ! make/devkit/Tools.gmk Changeset: c42cd17e8e64 Author: bobv Date: 2018-10-31 16:27 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/c42cd17e8e64 8213204: ReservedStackTest and ReservedStackTestCompiler tests fail on windows Reviewed-by: fparain, dcubed, jwilhelm ! test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java Changeset: e38473506688 Author: bobv Date: 2018-10-31 16:27 -0400 URL: http://hg.openjdk.java.net/panama/dev/rev/e38473506688 Merge - test/hotspot/jtreg/runtime/ClassUnload/UnloadInterfaceTest.java - test/hotspot/jtreg/runtime/ClassUnload/test/ImplementorClass.java - test/hotspot/jtreg/runtime/ClassUnload/test/Interface.java From maurizio.cimadamore at oracle.com Wed Oct 31 21:02:49 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 31 Oct 2018 21:02:49 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810312102.w9VL2nlp024864@aojmv0008.oracle.com> Changeset: c7a92f0dac84 Author: mcimadamore Date: 2018-10-31 22:09 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/c7a92f0dac84 Automatic merge with default ! make/RunTests.gmk ! make/autoconf/flags.m4 ! make/conf/jib-profiles.js - src/hotspot/cpu/arm/arm_64.ad - src/hotspot/cpu/arm/assembler_arm_64.cpp - src/hotspot/cpu/arm/assembler_arm_64.hpp - src/hotspot/cpu/arm/nativeInst_arm_64.cpp - src/hotspot/cpu/arm/nativeInst_arm_64.hpp - src/hotspot/cpu/arm/vm_version_arm_64.cpp - src/hotspot/os_cpu/linux_arm/linux_arm_64.s - src/java.base/macosx/classes/module-info.java.extra ! src/java.base/share/classes/java/lang/ClassLoader.java - src/java.base/share/classes/jdk/internal/misc/VMNotification.java ! src/java.base/share/classes/module-info.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dom/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/package.html - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_reflect_redefine/TestDescription.java ! test/jdk/TEST.groups - test/jdk/java/util/Calendar/GenericTimeZoneNamesTest.sh - test/jdk/java/util/Calendar/NarrowNamesTest.sh - test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.sh - test/jdk/java/util/PluggableLocale/BreakIteratorProviderTest.sh - test/jdk/java/util/PluggableLocale/CalendarDataProviderTest.sh - test/jdk/java/util/PluggableLocale/CalendarNameProviderTest.sh - test/jdk/java/util/PluggableLocale/ClasspathTest.sh - test/jdk/java/util/PluggableLocale/CollatorProviderTest.sh - test/jdk/java/util/PluggableLocale/CurrencyNameProviderTest.sh - test/jdk/java/util/PluggableLocale/DateFormatProviderTest.sh - test/jdk/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/ExecTest.sh - test/jdk/java/util/PluggableLocale/GenericTest.sh - test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.sh - test/jdk/java/util/PluggableLocale/NumberFormatProviderTest.sh - test/jdk/java/util/PluggableLocale/PermissionTest.sh - test/jdk/java/util/PluggableLocale/TimeZoneNameProviderTest.sh - test/jdk/java/util/PluggableLocale/barprovider.jar - test/jdk/java/util/PluggableLocale/fooprovider.jar - test/jdk/java/util/PluggableLocale/providersrc/BreakIteratorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CollatorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DecimalFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/FooDateFormat.java - test/jdk/java/util/PluggableLocale/providersrc/FooNumberFormat.java - test/jdk/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_kyoto.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_osaka.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_xx.properties - test/jdk/java/util/PluggableLocale/providersrc/Makefile - test/jdk/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/TimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/Utils.java - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.BreakIteratorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.CollatorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DecimalFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.NumberFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.LocaleNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider - test/jdk/java/util/prefs/CheckUserPrefsStorage.sh - test/jdk/java/util/prefs/PrefsSpi.sh - test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java From maurizio.cimadamore at oracle.com Wed Oct 31 21:03:09 2018 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 31 Oct 2018 21:03:09 +0000 Subject: hg: panama/dev: Automatic merge with default Message-ID: <201810312103.w9VL3ABN025131@aojmv0008.oracle.com> Changeset: aa0b2c515bbb Author: mcimadamore Date: 2018-10-31 22:09 +0100 URL: http://hg.openjdk.java.net/panama/dev/rev/aa0b2c515bbb Automatic merge with default - src/hotspot/cpu/arm/arm_64.ad - src/hotspot/cpu/arm/assembler_arm_64.cpp - src/hotspot/cpu/arm/assembler_arm_64.hpp - src/hotspot/cpu/arm/nativeInst_arm_64.cpp - src/hotspot/cpu/arm/nativeInst_arm_64.hpp - src/hotspot/cpu/arm/vm_version_arm_64.cpp - src/hotspot/os_cpu/linux_arm/linux_arm_64.s - src/java.base/macosx/classes/module-info.java.extra - src/java.base/share/classes/jdk/internal/misc/VMNotification.java ! src/java.base/share/classes/module-info.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dom/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/package.html - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_reflect_redefine/TestDescription.java - test/jdk/java/util/Calendar/GenericTimeZoneNamesTest.sh - test/jdk/java/util/Calendar/NarrowNamesTest.sh - test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.sh - test/jdk/java/util/PluggableLocale/BreakIteratorProviderTest.sh - test/jdk/java/util/PluggableLocale/CalendarDataProviderTest.sh - test/jdk/java/util/PluggableLocale/CalendarNameProviderTest.sh - test/jdk/java/util/PluggableLocale/ClasspathTest.sh - test/jdk/java/util/PluggableLocale/CollatorProviderTest.sh - test/jdk/java/util/PluggableLocale/CurrencyNameProviderTest.sh - test/jdk/java/util/PluggableLocale/DateFormatProviderTest.sh - test/jdk/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/ExecTest.sh - test/jdk/java/util/PluggableLocale/GenericTest.sh - test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.sh - test/jdk/java/util/PluggableLocale/NumberFormatProviderTest.sh - test/jdk/java/util/PluggableLocale/PermissionTest.sh - test/jdk/java/util/PluggableLocale/TimeZoneNameProviderTest.sh - test/jdk/java/util/PluggableLocale/barprovider.jar - test/jdk/java/util/PluggableLocale/fooprovider.jar - test/jdk/java/util/PluggableLocale/providersrc/BreakIteratorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CollatorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DecimalFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/FooDateFormat.java - test/jdk/java/util/PluggableLocale/providersrc/FooNumberFormat.java - test/jdk/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_kyoto.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_osaka.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_xx.properties - test/jdk/java/util/PluggableLocale/providersrc/Makefile - test/jdk/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/TimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/Utils.java - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.BreakIteratorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.CollatorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DecimalFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.NumberFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.LocaleNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider - test/jdk/java/util/prefs/CheckUserPrefsStorage.sh - test/jdk/java/util/prefs/PrefsSpi.sh - test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java From vladimir.x.ivanov at oracle.com Wed Oct 31 21:04:45 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2018 14:04:45 -0700 Subject: CFV: New panama Committer: Yang Zhang Message-ID: <3b4fc6ce-cfe8-d5ce-0c23-ea689890251d@oracle.com> I hereby nominate Yang Zhang (openjdk id: yzhang) to Committer role in Project Panama. Yang works on NEON/SVE support for Vector API at Arm. Votes are due by November, 7, 2018. Only current panama Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Vladimir Ivanov [1] http://openjdk.java.net/census#panama [2] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Wed Oct 31 21:06:36 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2018 14:06:36 -0700 Subject: CFV: New panama Committer: Ningsheng Jian Message-ID: <4fa9ec25-7281-792d-65e7-db68dbe8f99a@oracle.com> I hereby nominate Ningsheng Jian (openjdk id: njian) to Committer role in Project Panama. Ningsheng works on NEON/SVE support for Vector API at Arm. Votes are due by November, 7, 2018. Only current panama Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Vladimir Ivanov [1] http://openjdk.java.net/census#panama [2] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Wed Oct 31 21:06:54 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2018 14:06:54 -0700 Subject: CFV: New panama Committer: Yang Zhang In-Reply-To: <3b4fc6ce-cfe8-d5ce-0c23-ea689890251d@oracle.com> References: <3b4fc6ce-cfe8-d5ce-0c23-ea689890251d@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 31/10/2018 14:04, Vladimir Ivanov wrote: > I hereby nominate Yang Zhang (openjdk id: yzhang) to Committer role in > Project Panama. From vladimir.x.ivanov at oracle.com Wed Oct 31 21:07:03 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2018 14:07:03 -0700 Subject: CFV: New panama Committer: Ningsheng Jian In-Reply-To: <4fa9ec25-7281-792d-65e7-db68dbe8f99a@oracle.com> References: <4fa9ec25-7281-792d-65e7-db68dbe8f99a@oracle.com> Message-ID: <0663ecd9-a5a3-b073-8e9e-355be6a17bd3@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 31/10/2018 14:06, Vladimir Ivanov wrote: > I hereby nominate Ningsheng Jian (openjdk id: njian) to Committer role > in Project Panama. From vladimir.x.ivanov at oracle.com Wed Oct 31 22:33:22 2018 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Wed, 31 Oct 2018 22:33:22 +0000 Subject: hg: panama/dev: 2 new changesets Message-ID: <201810312233.w9VMXNai001963@aojmv0008.oracle.com> Changeset: 696d19c400ff Author: vlivanov Date: 2018-10-31 14:17 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/696d19c400ff Manual merge - src/hotspot/cpu/arm/arm_64.ad - src/hotspot/cpu/arm/assembler_arm_64.cpp - src/hotspot/cpu/arm/assembler_arm_64.hpp ! src/hotspot/cpu/arm/methodHandles_arm.cpp - src/hotspot/cpu/arm/nativeInst_arm_64.cpp - src/hotspot/cpu/arm/nativeInst_arm_64.hpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp - src/hotspot/cpu/arm/vm_version_arm_64.cpp - src/hotspot/os_cpu/linux_arm/linux_arm_64.s ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/globals.hpp - src/java.base/macosx/classes/module-info.java.extra ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java - src/java.base/share/classes/jdk/internal/misc/VMNotification.java - src/java.xml.crypto/share/classes/javax/xml/crypto/dom/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/spec/package.html - src/java.xml.crypto/share/classes/javax/xml/crypto/package.html - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Basic_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/ConflictingDefaults_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/DefaultVsAbstract_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/MethodResolution_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/PrivateMethods_v51_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/Redefine_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v50_syncstrict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_none_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_strict_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_sync_reflect_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_direct_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_direct_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_invoke_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_invoke_redefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_reflect_noredefine/TestDescription.java - test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios/StaticMethods_v51_syncstrict_reflect_redefine/TestDescription.java - test/jdk/java/util/Calendar/GenericTimeZoneNamesTest.sh - test/jdk/java/util/Calendar/NarrowNamesTest.sh - test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.sh - test/jdk/java/util/PluggableLocale/BreakIteratorProviderTest.sh - test/jdk/java/util/PluggableLocale/CalendarDataProviderTest.sh - test/jdk/java/util/PluggableLocale/CalendarNameProviderTest.sh - test/jdk/java/util/PluggableLocale/ClasspathTest.sh - test/jdk/java/util/PluggableLocale/CollatorProviderTest.sh - test/jdk/java/util/PluggableLocale/CurrencyNameProviderTest.sh - test/jdk/java/util/PluggableLocale/DateFormatProviderTest.sh - test/jdk/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.sh - test/jdk/java/util/PluggableLocale/ExecTest.sh - test/jdk/java/util/PluggableLocale/GenericTest.sh - test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.sh - test/jdk/java/util/PluggableLocale/NumberFormatProviderTest.sh - test/jdk/java/util/PluggableLocale/PermissionTest.sh - test/jdk/java/util/PluggableLocale/TimeZoneNameProviderTest.sh - test/jdk/java/util/PluggableLocale/barprovider.jar - test/jdk/java/util/PluggableLocale/fooprovider.jar - test/jdk/java/util/PluggableLocale/providersrc/BreakIteratorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CollatorProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/DecimalFormatSymbolsProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/FooDateFormat.java - test/jdk/java/util/PluggableLocale/providersrc/FooNumberFormat.java - test/jdk/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_kyoto.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_ja_JP_osaka.properties - test/jdk/java/util/PluggableLocale/providersrc/LocaleNames_xx.properties - test/jdk/java/util/PluggableLocale/providersrc/Makefile - test/jdk/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/TimeZoneNameProviderImpl.java - test/jdk/java/util/PluggableLocale/providersrc/Utils.java - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.BreakIteratorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.CollatorProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DateFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.DecimalFormatSymbolsProvider - test/jdk/java/util/PluggableLocale/providersrc/java.text.spi.NumberFormatProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.LocaleNameProvider - test/jdk/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider - test/jdk/java/util/prefs/CheckUserPrefsStorage.sh - test/jdk/java/util/prefs/PrefsSpi.sh - test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: c7f60fde30ff Author: vlivanov Date: 2018-10-31 15:33 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/c7f60fde30ff Fix compilation issues after merge ! src/hotspot/share/classfile/systemDictionary.hpp From henry.jen at oracle.com Wed Oct 31 23:53:51 2018 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Wed, 31 Oct 2018 23:53:51 +0000 Subject: hg: panama/dev: Adapt changes for JDK-8207146 Message-ID: <201810312353.w9VNrpSp004395@aojmv0008.oracle.com> Changeset: 67030e8d5437 Author: henryjen Date: 2018-10-31 16:39 -0700 URL: http://hg.openjdk.java.net/panama/dev/rev/67030e8d5437 Adapt changes for JDK-8207146 ! src/java.base/share/classes/jdk/internal/foreign/Util.java