Panama Update
summary
Project Panama now ships a workflow: run jextract on C headers to produce Java bindings and use the VM’s linkToNative backend for up to 4x–5x faster Java↔native calls. The core deliverable is a memory segment API with spatial and temporal bounds, memory layouts for deriving offsets, and verified bounds checks to avoid VM crashes. Current tradeoffs: deterministic close semantics, thread confinement to avoid access-vs-close races, and ongoing JIT/escape-analysis work to reach unsafe-level performance across patterns.
AI-written summary · about
chapters (31)
- 0:00Introduction
- 0:50Where does Panama start
- 2:05How do we solve this
- 2:53Example tensorflow
- 4:41Advantages
- 6:00Are we there yet
- 6:25Who will benefit from Panama
- 7:19Frameworks
- 8:13Missing Opportunities
- 9:16Building Blocks
- 10:58By Buffer
- 11:49Unsafe
- 12:37Pointer API
- 14:00Moving data
- 15:18Memory API
- 17:00Segments
- 18:33Memory Access
- 21:48Temporal Bounds
- 22:53Memory Segments
- 24:43Memory Layouts
- 25:51Layout Terminology
- 26:55Layout Paths
- 27:38Example
- 29:45Constants
- 30:15Safety
- 31:23Usability
- 32:22Performance
- 36:00What does that mean
- 37:19ScopeByBuffer
- 38:02Concurrency
- 39:09Static thread confinement
related talks
01h 04mProject Panama Unleashing Native Libraries
43mProject Panama’s Foreign API
36mA Promising Future for using Native Libraries in the Java World
29mEasily Leverage Native Functions with Project Panama from Java
45mProject Panama - Foreign Function & Memory API
55mBare metal Java
46mBare Metal Java
33mFrom native code gems to Java treasures with jextract