From coppa at di.uniroma1.it Tue Jul 2 08:47:22 2019 From: coppa at di.uniroma1.it (Emilio Coppa) Date: Tue, 2 Jul 2019 10:47:22 +0200 Subject: MPLR 2019 - Deadline Extension Message-ID: =============================================== MPLR 2019 16th International Conference on Managed Programming Languages & Runtimes Co-located with SPLASH 2019 Athens, Greece, Oct 20-25, 2019 https://conf.researchr.org/home/mplr-2019 =============================================== The 16th International Conference on Managed Programming Languages & Runtimes (MPLR, formerly ManLang) is a premier forum for presenting and discussing novel results in all aspects of managed programming languages and runtime systems, which serve as building blocks for some of the most important computing systems around, ranging from small-scale (embedded and real-time systems) to large-scale (cloud-computing and big-data platforms) and anything in between (mobile, IoT, and wearable applications). This year, MPLR is co-located with SPLASH 2019 and sponsored by ACM. For more information, check out the conference website: https://conf.researchr.org/home/mplr-2019 # Topics Topics of interest include but are not limited to: * Languages and Compilers - Managed languages (e.g., Java, Scala, JavaScript, Python, Ruby, C#, F#, Clojure, Groovy, Kotlin, R, Smalltalk, Racket, Rust, Go, etc.) - Domain-specific languages - Language design - Compilers and interpreters - Type systems and program logics - Language interoperability - Parallelism, distribution, and concurrency * Virtual Machines - Managed runtime systems (e.g., JVM, Dalvik VM, Android Runtime (ART), LLVM, .NET CLR, RPython, etc.) - VM design and optimization - VMs for mobile and embedded devices - VMs for real-time applications - Memory management - Hardware/software co-design * Techniques, Tools, and Applications - Static and dynamic program analysis - Testing and debugging - Refactoring - Program understanding - Program synthesis - Security and privacy - Performance analysis and monitoring - Compiler and program verification # Submission Categories MPLR accepts four types of submissions: 1. Regular research papers, which describe novel contributions involving managed language platforms (up to 12 pages excluding bibliography and appendix). Research papers will be evaluated based on their relevance, novelty, technical rigor, and contribution to the state-of-the-art. 2. Work-in-progress research papers, which describe promising new ideas but yet have less maturity than full papers (up to 6 pages excluding bibliography and appendix). When evaluating work-in-progress papers, more emphasis will be placed on novelty and the potential of the new ideas than on technical rigor and experimental results. 3. Industry and tool papers, which present technical challenges and solutions for managed language platforms in the context of deployed applications and systems (up to 6 pages excluding bibliography and appendix). Industry and tool papers will be evaluated on their relevance, usefulness, and results. Suitability for demonstration and availability will also be considered for tool papers. 4. Posters, which can be accompanied by a one-page abstract and will be evaluated on similar criteria as Work-in-progress papers. Posters can accompany any submission as a way to provide additional demonstration and discussion opportunities. MPLR 2019 submissions must conform to the ACM Policy on Prior Publication and Simultaneous Submissions and to the SIGPLAN Republication Policy. # Important Dates and Organization Submission Deadline: ***Jul 15, 2019*** (extended) Author Notification: Aug 24, 2019 Camera Ready: Sep 12, 2019 Conference Dates: Oct 20-25, 2019 General Chair: Tony Hosking, Australian National University / Data61, Australia Program Chair: Irene Finocchi, Sapienza University of Rome, Italy Program Committee: * Edd Barrett, King's College London, United Kingdom * Steve Blackburn, Australian National University, Australia * Lubomir Bulej, Charles University, Czech Republic * Shigeru Chiba, University of Tokyo, Japan * Daniele Cono D'Elia, Sapienza University of Rome, Italy * Ana Lucia de Moura, Pontifical Catholic University of Rio de Janeiro, Brazil * Erik Ernst, Google, Denmark * Matthew Hertz, University at Buffalo, United States * Vivek Kumar, Indraprastha Institute of Information Technology, Delhi * Doug Lea, State University of New York (SUNY) Oswego, United States * Magnus Madsen, Aarhus University, Denmark * Hidehiko Masuhara, Tokyo Institute of Technology, Japan * Ana Milanova, Rensselaer Polytechnic Institute, United States * Matthew Parkinson, Microsoft Research, United Kingdom * Gregor Richards, University of Waterloo, Canada * Manuel Rigger, ETH Zurich, Switzerland * Andrea Rosa, University of Lugano, Switzerland * Guido Salvaneschi, TU Darmstadt, Germany * Lukas Stadler, Oracle Labs, Austria * Ben L. Titzer, Google, Germany From nvangerow at twitter.com Tue Jul 2 15:14:24 2019 From: nvangerow at twitter.com (Niklas Vangerow) Date: Tue, 2 Jul 2019 08:14:24 -0700 Subject: WIP: auto-vectorization for Graal Message-ID: Hello graal-dev, Twitter has been using Graal in production for several years. Being a Scala shop, Graal has allowed us to more easily create optimizations that are targeted at our specific stack. If you?re curious about how and why we use Graal, check out Chris Thalinger?s talk from Scala Days New York 2018: https://www.youtube.com/watch?v=PtgKmzgIh4c. Despite Graal's success at Twitter, one way in which it lacks feature parity with C2 is automatic vectorization. We anticipate improved performance for some of our internal customers by implementing it. As a result, we?ve decided to implement automatic vectorization ourselves. We have produced a prototype implementation that is available here https://github.com/nvgrw/graal/tree/feature/autovec. We?re continuously iterating and are open to feedback and suggestions on the design! Our current approach is largely based on the algorithm described in the SLP paper (http://groups.csail.mit.edu/cag/slp/SLP-PLDI-2000.pdf), similar to what C2 does. Any basic block with isomorphic statements is considered for vectorization, and loops are partially unrolled to produce straight-line code with isomorphic instructions. We?re hoping to improve the current implementation with SLP extensions published in academia and a better heuristic once we have a complete implementation for the basic algorithm. Due to its prevalence we are currently targeting just AMD64, but we hope to support all Graal backends in the future. In addition to hearing the community?s thoughts on our general approach to the autovectorization problem, we have several outstanding questions for specifics relating to the current approach. We introduced a new phase to the LowTier to perform packing, which runs just after the FixReadsPhase. We were wondering whether this was necessarily the best location to put a packing phase. Since we added specific stamps to represent vector packs of integers and floating point numbers, one reason for packing so late was to avoid having to modify earlier phases in order to support vectors. Some phases use the JavaKind/JavaConstant types from JVMCI, which don?t currently support vector types and would probably require several workarounds to get working. We also wish to perform partial unrolling of loops in order to expose more superword-level parallelism. The LoopPartialUnrollPhase seemed like a perfect candidate, but runs after a LoweringPhase that introduces several new blocks to loop bodies. The unroll phase is limited to unrolling loops containing fewer than 3 blocks ( https://mail.openjdk.java.net/pipermail/graal-dev/2019-May/005794.html), which means that loops containing any form of array access do not get unrolled at all due to guard lowering. We initially decided to tackle the problem by adding another loop phase before guards get lowered, which, unsurprisingly, results in excessive bounds checking. If you have any ideas for tackling this issue please let us know! Regards, @nvgrw and the rest of Twitter?s VM team From yunxing.cyx at alibaba-inc.com Tue Jul 2 23:50:22 2019 From: yunxing.cyx at alibaba-inc.com (=?UTF-8?B?6ZmI5LqR5pifKOS6keaDuik=?=) Date: Wed, 03 Jul 2019 07:50:22 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaV0lQOiBhdXRvLXZlY3Rvcml6YXRpb24gZm9yIEdyYWFs?= In-Reply-To: References: Message-ID: <62a041ee-deef-456b-8ef4-dedaddf02484.yunxing.cyx@alibaba-inc.com> jdk has supported vectorize in Panama can that be ported to graalVM? ??????????------------------------------------------------------------------ ????Niklas Vangerow ????2019?07?02? 23:14:24 ???? ????WIP: auto-vectorization for Graal Hello graal-dev, Twitter has been using Graal in production for several years. Being a Scala shop, Graal has allowed us to more easily create optimizations that are targeted at our specific stack. If you?re curious about how and why we use Graal, check out Chris Thalinger?s talk from Scala Days New York 2018: https://www.youtube.com/watch?v=PtgKmzgIh4c. Despite Graal's success at Twitter, one way in which it lacks feature parity with C2 is automatic vectorization. We anticipate improved performance for some of our internal customers by implementing it. As a result, we?ve decided to implement automatic vectorization ourselves. We have produced a prototype implementation that is available here https://github.com/nvgrw/graal/tree/feature/autovec. We?re continuously iterating and are open to feedback and suggestions on the design! Our current approach is largely based on the algorithm described in the SLP paper (http://groups.csail.mit.edu/cag/slp/SLP-PLDI-2000.pdf), similar to what C2 does. Any basic block with isomorphic statements is considered for vectorization, and loops are partially unrolled to produce straight-line code with isomorphic instructions. We?re hoping to improve the current implementation with SLP extensions published in academia and a better heuristic once we have a complete implementation for the basic algorithm. Due to its prevalence we are currently targeting just AMD64, but we hope to support all Graal backends in the future. In addition to hearing the community?s thoughts on our general approach to the autovectorization problem, we have several outstanding questions for specifics relating to the current approach. We introduced a new phase to the LowTier to perform packing, which runs just after the FixReadsPhase. We were wondering whether this was necessarily the best location to put a packing phase. Since we added specific stamps to represent vector packs of integers and floating point numbers, one reason for packing so late was to avoid having to modify earlier phases in order to support vectors. Some phases use the JavaKind/JavaConstant types from JVMCI, which don?t currently support vector types and would probably require several workarounds to get working. We also wish to perform partial unrolling of loops in order to expose more superword-level parallelism. The LoopPartialUnrollPhase seemed like a perfect candidate, but runs after a LoweringPhase that introduces several new blocks to loop bodies. The unroll phase is limited to unrolling loops containing fewer than 3 blocks ( https://mail.openjdk.java.net/pipermail/graal-dev/2019-May/005794.html), which means that loops containing any form of array access do not get unrolled at all due to guard lowering. We initially decided to tackle the problem by adding another loop phase before guards get lowered, which, unsurprisingly, results in excessive bounds checking. If you have any ideas for tackling this issue please let us know! Regards, @nvgrw and the rest of Twitter?s VM team From kuaiwei.kw at alibaba-inc.com Thu Jul 4 02:24:17 2019 From: kuaiwei.kw at alibaba-inc.com (Kuai Wei) Date: Thu, 04 Jul 2019 10:24:17 +0800 Subject: =?UTF-8?B?UmU6IFdJUDogYXV0by12ZWN0b3JpemF0aW9uIGZvciBHcmFhbA==?= In-Reply-To: References: Message-ID: Hi Niklas, It's great to have auto vectorization in Graal. Recently we also find graal-ce is lack of vector support and it slow down performance in some benchmarks. We will like to use graalvm with vector support. Thanks for the contribution. Regards ------------------------------------------------------------------ From:Niklas Vangerow Send Time:2019?7?2?(???) 23:15 To:graal-dev Subject:WIP: auto-vectorization for Graal Hello graal-dev, Twitter has been using Graal in production for several years. Being a Scala shop, Graal has allowed us to more easily create optimizations that are targeted at our specific stack. If you?re curious about how and why we use Graal, check out Chris Thalinger?s talk from Scala Days New York 2018: https://www.youtube.com/watch?v=PtgKmzgIh4c. Despite Graal's success at Twitter, one way in which it lacks feature parity with C2 is automatic vectorization. We anticipate improved performance for some of our internal customers by implementing it. As a result, we?ve decided to implement automatic vectorization ourselves. We have produced a prototype implementation that is available here https://github.com/nvgrw/graal/tree/feature/autovec. We?re continuously iterating and are open to feedback and suggestions on the design! Our current approach is largely based on the algorithm described in the SLP paper (http://groups.csail.mit.edu/cag/slp/SLP-PLDI-2000.pdf), similar to what C2 does. Any basic block with isomorphic statements is considered for vectorization, and loops are partially unrolled to produce straight-line code with isomorphic instructions. We?re hoping to improve the current implementation with SLP extensions published in academia and a better heuristic once we have a complete implementation for the basic algorithm. Due to its prevalence we are currently targeting just AMD64, but we hope to support all Graal backends in the future. In addition to hearing the community?s thoughts on our general approach to the autovectorization problem, we have several outstanding questions for specifics relating to the current approach. We introduced a new phase to the LowTier to perform packing, which runs just after the FixReadsPhase. We were wondering whether this was necessarily the best location to put a packing phase. Since we added specific stamps to represent vector packs of integers and floating point numbers, one reason for packing so late was to avoid having to modify earlier phases in order to support vectors. Some phases use the JavaKind/JavaConstant types from JVMCI, which don?t currently support vector types and would probably require several workarounds to get working. We also wish to perform partial unrolling of loops in order to expose more superword-level parallelism. The LoopPartialUnrollPhase seemed like a perfect candidate, but runs after a LoweringPhase that introduces several new blocks to loop bodies. The unroll phase is limited to unrolling loops containing fewer than 3 blocks ( https://mail.openjdk.java.net/pipermail/graal-dev/2019-May/005794.html), which means that loops containing any form of array access do not get unrolled at all due to guard lowering. We initially decided to tackle the problem by adding another loop phase before guards get lowered, which, unsurprisingly, results in excessive bounds checking. If you have any ideas for tackling this issue please let us know! Regards, @nvgrw and the rest of Twitter?s VM team From doug.simon at oracle.com Thu Jul 4 20:33:20 2019 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 4 Jul 2019 22:33:20 +0200 Subject: JVMCI 19.2-b01 released Message-ID: <494E3ADA-8A7E-43A7-B4FC-72AE9537426D@oracle.com> To clarify the relationship between JVMCI and GraalVM releases, we?ve changed the versioning scheme of JVMCI to better align with GraalVM versioning. The new JVMCI version format is ".-b? (e.g., 19.2-b01). Every GraalVM . release will now be based on a JVMCI release with the same . prefix. In addition to this versioning scheme change, the 19.2-b01 release includes: ? GR-16687: Correct endianness in get_cached_box. The binaries are available at: https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-19.2-b01 -Doug From thomas.wuerthinger at oracle.com Sat Jul 6 17:01:24 2019 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sat, 6 Jul 2019 19:01:24 +0200 Subject: WIP: auto-vectorization for Graal In-Reply-To: References: Message-ID: <54B3EC1B-C8BE-41D3-8E96-10FB381ED02F@oracle.com> Hi Niklas, Thanks for sharing your prototype! Are there some measurement of Twitter?s workloads that improve with this patch? Generally, given Twitter?s large production deployment of the GraalVM compiler, one main contribution from the side of #TwitterVMTeam could be sharing JFR data and/or compiler graphs from test runs. For larger additions of general optimisations to the GraalVM compiler, there needs to be an assessment of: * Peak performance impact * Compilation time impact * Compiled code size impact * Overall complexity and maintenance overhead Our preference on the first three metrics is to use https://renaissance.dev, https://dacapobench.org, and for reference also SPECjvm2008. Our latest 19.1 release shows how much impact compilation time can have on medium length workloads (https://medium.com/graalvm/graalvm-19-1-compiling-faster-a0041066dee4). One relevant question on the last point is whether this is intended as a one time contribution or whether #TwitterVMTeam will be committed to help maintaining the optimisation moving forward. Regarding the general approach: Yes, removing bounds check is a general prerequisite for good vectorisation opportunities. I think there should probably be a lightweight array bounds check elimination algorithm that targets array accesses in loops. This itself might have quite some positive impact on array-heavy workloads. For longer discussions on larger patches, our preference is to use either GitHub pull requests or GitHub issues. So feel encouraged to create those for the topic. Regards, thomas > On 2 Jul 2019, at 17:14, Niklas Vangerow wrote: > > Hello graal-dev, > > Twitter has been using Graal in production for several years. Being a Scala > shop, Graal has allowed us to more easily create optimizations that are > targeted at our specific stack. If you?re curious about how and why we use > Graal, check out Chris Thalinger?s talk from Scala Days New York 2018: > https://www.youtube.com/watch?v=PtgKmzgIh4c. Despite Graal's success at > Twitter, one way in which it lacks feature parity with C2 is automatic > vectorization. We anticipate improved performance for some of our internal > customers by implementing it. > > As a result, we?ve decided to implement automatic vectorization ourselves. > We have produced a prototype implementation that is available here > https://github.com/nvgrw/graal/tree/feature/autovec. We?re continuously > iterating and are open to feedback and suggestions on the design! > > Our current approach is largely based on the algorithm described in the SLP > paper (http://groups.csail.mit.edu/cag/slp/SLP-PLDI-2000.pdf), similar to > what C2 does. Any basic block with isomorphic statements is considered for > vectorization, and loops are partially unrolled to produce straight-line > code with isomorphic instructions. We?re hoping to improve the current > implementation with SLP extensions published in academia and a better > heuristic once we have a complete implementation for the basic algorithm. > Due to its prevalence we are currently targeting just AMD64, but we hope to > support all Graal backends in the future. > > In addition to hearing the community?s thoughts on our general approach to > the autovectorization problem, we have several outstanding questions for > specifics relating to the current approach. > > > > We introduced a new phase to the LowTier to perform packing, which runs > just after the FixReadsPhase. We were wondering whether this was > necessarily the best location to put a packing phase. Since we added > specific stamps to represent vector packs of integers and floating point > numbers, one reason for packing so late was to avoid having to modify > earlier phases in order to support vectors. Some phases use the > JavaKind/JavaConstant types from JVMCI, which don?t currently support > vector types and would probably require several workarounds to get working. > > We also wish to perform partial unrolling of loops in order to expose more > superword-level parallelism. The LoopPartialUnrollPhase seemed like a > perfect candidate, but runs after a LoweringPhase that introduces several > new blocks to loop bodies. The unroll phase is limited to unrolling loops > containing fewer than 3 blocks ( > https://mail.openjdk.java.net/pipermail/graal-dev/2019-May/005794.html), > which means that loops containing any form of array access do not get > unrolled at all due to guard lowering. We initially decided to tackle the > problem by adding another loop phase before guards get lowered, which, > unsurprisingly, results in excessive bounds checking. If you have any ideas > for tackling this issue please let us know! > > Regards, > > @nvgrw and the rest of Twitter?s VM team From dean.long at oracle.com Tue Jul 9 17:28:30 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 9 Jul 2019 10:28:30 -0700 Subject: [13] RFR(XS) 8227237: [Graal] org.graalvm.compiler.api.directives.test.ProbabilityDirectiveTest fails with -Xcomp Message-ID: <56ae3c00-c34c-a961-d972-9dfe74eef409@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8227237 http://cr.openjdk.java.net/~dlong/8227237/webrev/ Clean backport of test bug fix [1] that is already in 14. dl [1] https://github.com/oracle/graal/commit/99312f22864d463a5914e8f39282c5d16cdbde3f#diff-54199cec9a9973ab272261db88acf936 From vladimir.kozlov at oracle.com Tue Jul 9 17:35:42 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Jul 2019 10:35:42 -0700 Subject: [13] RFR(XS) 8227237: [Graal] org.graalvm.compiler.api.directives.test.ProbabilityDirectiveTest fails with -Xcomp In-Reply-To: <56ae3c00-c34c-a961-d972-9dfe74eef409@oracle.com> References: <56ae3c00-c34c-a961-d972-9dfe74eef409@oracle.com> Message-ID: Good. Thanks, Vladimir On 7/9/19 10:28 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8227237 > http://cr.openjdk.java.net/~dlong/8227237/webrev/ > > Clean backport of test bug fix [1] that is already in 14. > > dl > > [1] https://github.com/oracle/graal/commit/99312f22864d463a5914e8f39282c5d16cdbde3f#diff-54199cec9a9973ab272261db88acf936 From dean.long at oracle.com Tue Jul 9 17:51:43 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 9 Jul 2019 10:51:43 -0700 Subject: [13] RFR(XS) 8227237: [Graal] org.graalvm.compiler.api.directives.test.ProbabilityDirectiveTest fails with -Xcomp In-Reply-To: References: <56ae3c00-c34c-a961-d972-9dfe74eef409@oracle.com> Message-ID: <1548acce-087f-bd46-89b0-7c3e3d45512a@oracle.com> Thanks Vladimir. dl On 7/9/19 10:35 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 7/9/19 10:28 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8227237 >> http://cr.openjdk.java.net/~dlong/8227237/webrev/ >> >> Clean backport of test bug fix [1] that is already in 14. >> >> dl >> >> [1] >> https://github.com/oracle/graal/commit/99312f22864d463a5914e8f39282c5d16cdbde3f#diff-54199cec9a9973ab272261db88acf936 From Xiaohong.Gong at arm.com Mon Jul 15 08:40:56 2019 From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China)) Date: Mon, 15 Jul 2019 08:40:56 +0000 Subject: RFR: 8227574: Fix jtreg access denied failure with graal mode. Message-ID: Hi, Please help to review the following patch that fixes two jtreg tests failure with graal mode due to the access denied issue. Webrev: http://cr.openjdk.java.net/~pli/rfr/8227574/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8227574 JTReg tests: jdk/java/net/URLPermission/URLTest.java jdk/javax/sql/testng/test/rowset/spi/SyncFactoryPermissionsTests.java fail due to losing permission of the JVMCI runtime. This patch fixes the two tests by making their policy extending the default system policy which grants the permissions to jdk.internal.vm.compiler module and its dependencies. Thanks, Xiaohong Gong From Xiaohong.Gong at arm.com Mon Jul 15 09:32:08 2019 From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China)) Date: Mon, 15 Jul 2019 09:32:08 +0000 Subject: RFR: 8227615: [TESTBUG] Fix jtreg "jdk/sun/security/util/FilePermCompat/CompatImpact.java" failing with graal issue. Message-ID: Hi, Please help to review this small patch: Webrev: http://cr.openjdk.java.net/~pli/rfr/8227615/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8227615 Jtreg test "jdk/sun/security/util/FilePermCompat/CompatImpact.java" fails due to access denied to JVMCI runtime with graal mode. This patch fixes the permission issue by making the application's own policy extending the default system policy. Besides it also fixes the stderr file couldn't be found issue by renaming the file name to the right one. Thanks, Xiaohong Gong From vladimir.kozlov at oracle.com Mon Jul 15 16:27:38 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2019 09:27:38 -0700 Subject: RFR: 8227574: Fix jtreg access denied failure with graal mode. In-Reply-To: References: Message-ID: Looks good to me. Thanks, Vladimir On 7/15/19 1:40 AM, Xiaohong Gong (Arm Technology China) wrote: > Hi, > > Please help to review the following patch that fixes two jtreg tests failure with graal mode due to the access denied issue. > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227574/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227574 > > JTReg tests: > jdk/java/net/URLPermission/URLTest.java > jdk/javax/sql/testng/test/rowset/spi/SyncFactoryPermissionsTests.java > fail due to losing permission of the JVMCI runtime. > This patch fixes the two tests by making their policy extending the default system policy which grants the permissions to jdk.internal.vm.compiler module and its dependencies. > > Thanks, > Xiaohong Gong > From vladimir.kozlov at oracle.com Mon Jul 15 16:30:14 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2019 09:30:14 -0700 Subject: RFR: 8227615: [TESTBUG] Fix jtreg "jdk/sun/security/util/FilePermCompat/CompatImpact.java" failing with graal issue. In-Reply-To: References: Message-ID: <2a08e281-0f6f-d993-8213-c62f3e573559@oracle.com> Good. Thanks, Vladimir On 7/15/19 2:32 AM, Xiaohong Gong (Arm Technology China) wrote: > Hi, > > Please help to review this small patch: > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227615/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227615 > > Jtreg test "jdk/sun/security/util/FilePermCompat/CompatImpact.java" fails due to access denied to JVMCI runtime with graal mode. > This patch fixes the permission issue by making the application's own policy extending the default system policy. Besides it also fixes > the stderr file couldn't be found issue by renaming the file name to the right one. > > Thanks, > Xiaohong Gong > From dean.long at oracle.com Wed Jul 24 19:51:32 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 24 Jul 2019 12:51:32 -0700 Subject: RFR(XL) 8226771: Update Graal Message-ID: <85eb597a-d3b1-a60b-a059-576ab0ca7365@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8226771 http://cr.openjdk.java.net/~dlong/8226771/webrev/ This is a Graal update.? Please see the bug description for the complete list of upstream changes included. dl