Project Panama: Interconnecting JVM and native code
5791 단어 JDK
To this end, Project Panama will include most or all of these components:
native function calling from JVM (C, C++), specifically per JEP 191
native data access from JVM or inside JVM heap
new data layouts in JVM heap
native metadata definition for JVM
header file API extraction tools (see below)
native library management APIs
native-oriented interpreter and runtime “hooks”
class and method resolution “hooks”
native-oriented JIT optimizations
tooling or wrapper interposition for safety
exploratory work with difficult-to-integrate native libraries
Community
This Project is sponsored by the Hotspot Group.
Mailing lists
panama-dev — the usual developer list
panama-spec-experts — moderated, restricted to specification discussions only
Bloggers
Charles Nutter
John Rose
Links
Panama bindings/jextract tutorial
design document: State of the Isthmus
new project CFV for Panama
JEP 191: Foreign Function Interface
JNR example code: Java Native Runtime
early problem space overview: the isthmus in the VM
Repository organization
Project Panama is designed to incubate a series of components for eventual inclusion in the JDK, via curated merge. Following the experience of Project Amber, and Project Valhalla, we have our sanbox-like repository, whose default branch is kept in sync with jdk/jdk, and where each experimental feature is developed in its own branch.
Here’s a list of the branches under active development:
foreign, this branch provides a native binder which greatly reduces the impedence mismatch between native libraries and the JVM;
foreign-memaccess, this branch adds support for foreign memory access;
vectorIntrinsics, this branch adds vectorization support in Java through JVM intriniscs.
When first cloning the panama repository, it is necessary to update it to the desired experimental branch; this can be achieved using the hg update ${branch} command.
For an up-to-date list of the available branches, you might also want to run the hg branches command. For more information regarding each branch, please refer to the README.${branch} file in that branch (if that file does not exist, usual OpenJDK build instruction apply).
The legacy Panama repository is also available here, although we do not expect to carry out further work there; as such this repository should not be used (and in the future we might make this more explicit by marking the legacy repository as read-only). Repository workflow
The repository will be managed as follows (note, this process is local and subject to change):
No changes will be pushed to the default branch of the Panama repository. This branch should in fact always be in sync with the upstream repository (jdk/jdk) to facilitate automatic integration of upstream changes, as well as to allow developers to generate diffs against upstream in an easy and predictable fashion (see below).
Create and update JIRA issues to informally describe chunks of work, using repo-panama as the value of the Fix Version field. Additionally, labels are used to identify the branch to which the issue refers to, as shown here;
Commit rough changesets to JDK and/or JVM code, with ad hoc review, change set format, and testing. A typical example of review process for Panama changesets can be found here
Automated infrastructure will take care of performing regular test runs when new changes are pushed to any of the Panama branches; additionally, the infrastructure might automatically propagate changesets from the default branch to other experimental branches (not all branches might opt in on this feature given the subtlety of some of the changes involved).
Infrequently, create a “curated” change set targeted at the upstream JDK repository; properly review, test, integrate. For an example of how this integration process might work, see here. Developers can easily generate a diff against upstream using the hg diff --rev default command from any experimental branch.
OpenJDK logo Workshop OpenJDK FAQ Installing Contributing Sponsoring Developers’ Guide Vulnerabilities Mailing lists IRC · Wiki Bylaws · Census Legal JEP Process Source code Mercurial Bundles (6) Groups (overview) 2D Graphics Adoption AWT Build Compatibility & Specification Review Compiler Conformance Core Libraries Governing Board HotSpot IDE Tooling & Support Internationalization JMX Members Networking Porters Quality Security Serviceability Sound Swing Vulnerability Web Projects (overview) Amber Annotations Pipeline 2.0 Audio Engine Build Infrastructure Caciocavallo Closures Code Tools Coin Common VM Interface Compiler Grammar Detroit Device I/O Duke Font Scaler Framebuffer Toolkit Graal Graphics Rasterizer HarfBuzz Integration IcedTea JDK 6 JDK 7 JDK 7 Updates JDK 8 JDK 8 Updates JDK 9 JDK (… 13, 14, 15) JDK Updates JavaDoc.Next Jigsaw Kona Kulla Lambda Lanai Locale Enhancement Loom Memory Model Update Metropolis Mission Control Mobile Modules Multi-Language VM Nashorn New I/O OpenJFX Panama Penrose Port: AArch32 Port: AArch64 Port: BSD Port: Haiku Port: Mac OS X Port: MIPS Port: PowerPC/AIX Port: s390x Portola SCTP Skara Shenandoah Sumatra ThreeTen Tiered Attribution Tsan Type Annotations XRender Pipeline Valhalla Verona VisualVM Zero ZGC Tools Java SE Mercurial jtreg harness Related java.sun.com Java Community Process JDK GA/EA Builds Oracle logo © 2020 Oracle Corporation and/or its affiliates Terms of Use · License: GPLv2 · Privacy · Trademarks
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
【Java】 STS (Eclipse)에 AdoptOpen JDK 설정· Eclipse를 2020-09로 업데이트하면 jre로 Eclipse를 움직이고 있습니다! 라는 메시지가 나온다. ・메모리 상태의 파악을 위해 MissionControl 넣으려고 하면 JDK로 움직이지 않으면 안 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.