Releases: ponylang/ponyc
0.61.0
Fix pony-lsp inability to find the standard library
Previously, pony-lsp was unable to locate the Pony standard library on its own. It relied entirely on the PONYPATH environment variable to find packages like builtin. This meant that while the VS Code extension could work around the issue by configuring the path explicitly, other editors using pony-lsp would fail with errors like "couldn't locate this path in file builtin".
pony-lsp now automatically discovers the standard library by finding its own executable directory and searching for packages relative to it — the same approach that ponyc uses. Since pony-lsp is installed alongside ponyc, the standard library is found without any manual configuration, making pony-lsp work out of the box with any editor.
Fix persistent HashMap returning incorrect results for None values
The persistent HashMap used None as an internal sentinel to signal "key not found" in its lookup methods. This collided with user value types that include None (e.g., Map[String, (String | None)]). Using HashMap with a None value could lead to errors in user code as "it was none" and "it wasn't present" were impossible to distinguish.
The internal lookup methods now use error instead of None to signal a missing key, so all value types work correctly.
This is a breaking change for any code that was depending on the previous (incorrect) behavior. For example, code that expected apply to raise for keys mapped to None, or that relied on contains returning false for None-valued entries, will now see correct results instead.
Add pony-lint to the ponyc distribution
pony-lint is a text-based linter for Pony source files that checks for style guide violations. It was previously a standalone project and is now distributed with ponyc. This means the linter will track changes in ponyc and will always be up-to-date with the compiler's version of the standard library. pony-lint currently checks for line length, trailing whitespace, hard tabs, and comment spacing violations.
Fix stack overflow in reachability pass on deeply nested ASTs
The reachability pass traversed AST trees using unbounded recursion, adding a stack frame for each child node. On Windows x86-64, which has a default stack size of 1MB, this could overflow when compiling programs with large type graphs that produce deeply nested ASTs (200+ frames deep).
The recursive child traversal is now iterative, using an explicit worklist. This removes the dependency on call stack depth for AST traversal in the reachability pass.
Add pony-doc tool
We've added an experimental new tool, pony-doc, that is intended to replace the --docs pass in ponyc. The docs pass will remain in ponyc for now but will eventually be removed.
The most notable difference from the existing --docs flag is that pony-doc generates documentation for public items only by default. To include private types and methods in the output, use the --include-private flag. This replaces the old --docs-public flag which worked in reverse — generating everything by default and requiring a flag to restrict to public items only.
Usage:
pony-doc [options] <package-directory>Options:
-o,--output: Output directory (default: current directory)--include-private: Include private types and methods-V,--version: Print version and exit
Add Support for Settings to pony-lsp
pony-lsp can now be provided with settings from the lsp-client (most of the time this is the editor).
It supports two settings, which are both optional:
- defines: A list of strings that will be defined during compilation and can be checked for with
ifdef. Those defines are usually provided toponycwith the-Dflag. - ponypath: A string, containing a path or list of paths (like used e.g. in the
$PATHenvironment variable) that will be used to tellpony-lspabout additional entries to its package search path.
Example settings as JSON:
{
"defines": ["FOO", "BAR"],
"ponypath": "/path/to/pony-package:/another/path"
}Improve pony-lsp diagnostics
pony-lsp only relayed the main message from errors provided by ponyc. Now, it also passes the additional information to help explain the error.
Make pony-lsp version dynamic to match ponyc version
Previously, the version of pony-lsp was hardcoded in the source code. Now it is dynamically generated from the ponyc version.
Add \exhaustive\ annotation for match expressions
A new \exhaustive\ annotation can be applied to match expressions to assert that all cases are explicitly handled. When present, the compiler will emit an error if the match is not exhaustive and no else clause is provided, instead of silently injecting an else None.
Without the annotation, a non-exhaustive match silently compiles with an implicit else None, which changes the result type to (T | None) and produces an indirect type error like "function body isn't the result type." With the annotation, the error message directly identifies the problem.
type Choices is (T1 | T2 | T3)
primitive Foo
fun apply(p: Choices): String =>
match \exhaustive\ p
| T1 => "t1"
| T2 => "t2"
endThe above produces: match marked \exhaustive\ is not exhaustive
Adding the missing case or an explicit else clause resolves the error. The annotation is also useful on matches that are already exhaustive as a future-proofing measure. Without it, if a new member is later added to the union type and the match isn't updated, the compiler silently injects else None. You'll only get an error if the match result is assigned to a variable whose type doesn't include None -- otherwise the bug is completely silent. With \exhaustive\, the compiler catches the missing case immediately.
Update Docker image base to Alpine 3.23
The ponylang/ponyc:nightly and ponylang/ponyc:release Docker images now use Alpine 3.23 as their base image, updated from Alpine 3.21.
[0.61.0] - 2026-02-28
Fixed
- Fix pony-lsp inability to find the standard library (PR #4829)
- Make pony-lsp version dynamic to match ponyc version (PR #4830)
- Fix persistent HashMap returning incorrect results for None values (PR #4839)
- Fix stack overflow in reachability pass on deeply nested ASTs (PR #4858)
Added
- Add pony-lint to the ponyc distribution (PR #4842)
- Add configuration from lsp-client and improve diagnostics handling (PR #4837)
- Add
\exhaustive\annotation for match expressions (PR #4863)
Changed
0.60.6
Add Alpine 3.23 support
We've added support for Alpine 3.23. Builds will be available for both arm64 and amd64.
Fix crash when ephemeral type used in parameter with default argument
We've fixed an error where attempting to assign an ephemeral type to a variable caused an assertion failure in the compiler.
The following code will now cause the pony compiler to emit a helpful error message:
class Foo
actor Main
fun apply(x: Foo iso^ = Foo) => None
new create(env: Env) => NoneError:
main.pony:4:16: invalid parameter type for a parameter with a default argument: Foo iso^
fun apply(x: Foo iso^ = Foo) => None
^
Update Docker Image Base to Alpine 3.23
We've updated the base image for our ponyc images from Alpine 3.21 to Alpine 3.23.
Fix incorrect array element type inference for union types
Due to a small bug in the type system implementation, the following correct code would fail to compile. We have fixed this bug so it will now compiler.
type Foo is (Bar box | Baz box | Bool)
class Bar
embed _items: Array[Foo] = _items.create()
new create(items: ReadSeq[Foo]) =>
for item in items.values() do
_items.push(item)
end
class Baz
actor Main
new create(env: Env) =>
let bar = Bar([
true
Bar([ false ])
])
env.out.print("done")Fix segfault when lambda captures uninitialized field
Previously, the following illegal code would successfully compile, but produce a segfault on execution.
class Foo
let n: USize
new create(n': USize) =>
n = n'
class Bar
let _foo: Foo
let lazy: {(): USize} = {() => _foo.n }
new create() =>
_foo = Foo(123)
actor Main
let _bar: Bar = Bar
new create(env: Env) =>
env.out.print(_bar.lazy().string())Now it correctly refuses to compile with an appropriate error message.
Error:
main.pony:9:34: can't use an undefined variable in an expression
let lazy: {(): USize} = {() => _foo.n }
^
Fix compiler crash when assigning ephemeral capability types
Assigning ephemeral capability to a variable was causing the compiler to crash. We've updated to provide a descriptive error message.
Where previously code like:
actor Main
new create(env: Env) =>
let c: String iso^ = Stringcaused a segfault, you will now get a helpful error message instead:
Error:
/tmp/main.pony:3:24: Invalid type for field of assignment: String iso^
let c: String iso^ = String
[0.60.6] - 2026-02-06
Fixed
- Fix crash when ephemeral type used in parameter with default argument (PR #4796)
- Fix incorrect array element type inference for union types (PR #4794)
- Fix segfault when lambda captures uninitialized field (PR #4791)
- Fix compiler crash when assigning to ephemeral capability type (PR #4790)
Added
- Add Alpine 3.23 support (PR #4803)
Changed
- Update Docker Image Base to Alpine 3.23 (PR #4804)
0.60.5
Add Pony Language Server to the Ponyc distribution
We've moved the Pony Language Server that previously was distributed as it's own project to the standard ponyc distribution. This means that the language server will track changes in ponyc. Going forward, the language server that ships with a given ponyc will be fully up-to-date with the compiler and most importantly, it's version of the standard library.
Handle Bool with exhaustive match
Previously, this function would fail to compile, as true and false were not seen as exhaustive, resulting in the match block exiting and the function attempting to return None.
fun fourty_two(err: Bool): USize =>
match err
| true => return 50
| false => return 42
endWe have modified the compiler to recognize that if we have clauses for both true and false, that the match is exhaustive.
Consequently, you can expect the following to now fail to compile with unreachable code:
fun forty_three(err: Bool): USize =>
match err
| true => return 50
| false => return 43
else
return 44 // Unreachable
endFix ponyc crash when partially applying constructors
We've fixed a compilation assertion error that would result in a compiler crash when utilizing partial constructors.
Previously, this would fail to compile:
class A
let n: USize
new create(n': USize) =>
n = n'
actor Main
new create(env: Env) =>
let ctor = A~create(2)
let a: A = ctor()Add support for complex type formatting in LSP hover
The Pony Language Server now properly formats complex types in hover information. Previously, hovering over variables with union types, tuple types, intersection types, or arrow types would display internal token names like TK_UNIONTYPE instead of the actual type signature.
Now, the language server correctly displays formatted types such as:
- Union types:
(String | U32 | None) - Tuple types:
(String, U32, Bool) - Intersection types:
(ReadSeq[U8] & Hashable) - Arrow types: function signatures
Add hover support for generic types in LSP
The LSP server now provides hover information for generic types, including type parameters, type arguments, and capabilities.
Hover displays:
- Type parameters on classes and traits (e.g.,
class Container[T: Any val]) - Type parameters on methods (e.g.,
fun map[U: Any val](f: {(T): U} val): U) - Type arguments in instantiated types (e.g.,
let items: Array[String val] ref) - Capabilities on all types (val, ref, box, iso, trn, tag)
- Nested generic types (e.g.,
Array[Array[String val] ref] ref) - Viewpoint adaptation/arrow types (e.g.,
fun compare(that: box->T): I32) - Constructor calls with type arguments (e.g.,
GenericPair[String, U32](...))
When hovering on variable declarations, the full inferred type is now shown including all generic type arguments and capabilities, making it easier to understand the exact types in your code.
Add extra hover support to LSP
The Pony Language Server Protocol (LSP) implementation now provides improved hover capabilities with the following fixes.
Hover on field usages
When hovering over a field reference like field_name in the expression field_name.size(), the LSP now displays:
let field_name: String valclass Example
let field_name: String
fun get_length(): USize =>
field_name.size() // Hovering over 'field_name' here shows: let field_name: String valPreviously, hovering over field usages did not show any information.
Hover on local variable usages
When hovering over a local variable reference like count in the expression count + 1, the LSP now displays:
var count: U32 valfun increment(): U32 =>
var count: U32 = 0
count = count + 1 // Hovering over 'count' here shows: var count: U32 val
countPreviously, hovering over variable usages did not show type information.
Hover on parameter usages
When hovering over a parameter reference like name in the expression name.size(), the LSP now displays:
param name: String valfun get_name_length(name: String): USize =>
name.size() // Hovering over 'name' here shows: param name: String valPreviously, hovering over parameter usages did not show any information.
Hover on parameter declarations
When hovering over a parameter declaration like x: U32 in a function signature, the LSP now displays:
param x: U32 valfun calculate(x: U32, y: U32): U32 =>
// Hovering over 'x' in the signature shows: param x: U32 val
x + yPreviously, hovering over parameter declarations provided no information.
Hover on method calls
When hovering over a method name in a call expression like my_object.get_value(42), the LSP now correctly highlights only the method name and displays:
fun get_value(x: U32): String valclass MyObject
fun get_value(x: U32): String val =>
x.string()
actor Main
new create(env: Env) =>
let my_object = MyObject
let result = my_object.get_value(42) // Hovering over 'get_value' highlights only the method namePreviously, both the method name and receiver name were highlighted.
Fix crash when using bare integer literals in array match patterns
Array does not implement the Equatable interface, which queries for structural equality. Previous to this fix, an error in the type inference logic resulted in the code below resulting in a compiler crash instead of the expected helpful error message:
actor Main
new create(env: Env) =>
let arr: Array[U8 val] = [4; 5]
match arr
| [2; 3] => None
else
None
endNow, the correct helpful error message is provided:
Error:
main.pony:5:7: couldn't find 'eq' in 'Array'
| [2; 3] => None
^
Error:
main.pony:5:7: this pattern element doesn't support structural equality
| [2; 3] => None
^
Add support for go to definition for arrow types in LSP
The LSP server now correctly handles "go to definition" for method calls on arrow types (viewpoint-adapted types like this->Type).
Previously, go-to-definition would fail on method calls where the receiver had an arrow type, such as calling methods on this (which has type this->MyClass rather than just MyClass).
Add hover support for receiver capability to LSP
The Language Server Protocol (LSP) hover feature now displays receiver capabilities in method signatures.
When hovering over a method reference, the hover information will now show the receiver capability (e.g., box, val, ref, iso, trn, tag) in the method signature. This provides more complete type information at a glance.
Examples
Previously, hovering over a method would show:
fun boxed_method(): StringNow, it correctly displays:
fun box boxed_method(): StringThis applies to all receiver capabilities:
fun box method()- read-only accessfun ref method()- mutable reference accessfun val method()- immutable value accessfun iso method()- isolated reference accessfun trn method()- transition reference accessfun tag method()- opaque reference access
[0.60.5] - 2026-01-31
Fixed
- Fix crash when partially applying constructors (PR #4783)
- Fix crash when using bare integer literals in array match patterns (PR #4797)
Added
- Add Pony Language Server to the ponyc distribution (PR #4777)
- Handle Bool with exhaustive match (PR #4782)
- Add support for complex type formatting in LSP hover (PR #4785)
- Add hover support for generic types in LSP (PR #4793)
- Add extra hover support to LSP (PR #4795)
- Add hover support for receiver capability to LSP (PR #4798)
- Add support for go to definition for arrow types in LSP (PR #4792)
0.60.4
Add Alpine 3.22 as a supported platform
We've added arm64 and amd64 builds for Alpine Linux 3.22. We'll be building ponyc releases for it until it stops receiving security updates in 2027. At that point, we'll stop building releases for it.
Stop creating Fedora 41 builds
We are no longer creating Fedora 41 builds of Pony. Fedora 41 is about to reach its end of life. If you need Pony support on Fedora 41, you will need to build from source.
[0.60.4] - 2025-10-31
Added
- Add Alpine 3.22 as a supported platform (PR #4760)
Changed
- Stop creating Fedora 41 builds (PR #4763)
0.60.3
Stop building versioned "-alpine" images
We used to release images for ponyc like ponyc:0.38.0-alpine that were based on Alpine Linux.However, we now just have those as ponyc:0.38.0 as we don't have any glibc based images anymore.
Stop Creating Generic musl Builds
We previously created releases for a generic "musl" build of ponyc. This was done to provide a build that would run on any Linux distribution that used musl as its C standard library. However, these could easily break if the OS they were built on changed.
We now provide specific Alpine version builds instead.
Stop Creating "alpine" Docker Image
We previously were creating Docker images with a musl C standard library Ponyc under the tag alpine. We are no longer creating those images. You should switch to our new equivalent images tagged nightly.
Add Multiplatform Versioned Release Docker Images
We've added multiplatform versioned release Docker images for Ponyc. These images are built for both amd64 and arm64 architectures and are tagged with the current Ponyc version. For example, ponyc:0.60.3.
Previously, the versioned release images were only available for the amd64 architecture.
nightly and release tags were already avaialble as multiplatform images. This update extends that support to versioned images as well. With this change, we now provide consistent multiplatform support across all our Docker image tags.
[0.60.3] - 2025-10-20
Added
- Add Multiplatform Versioned Release Docker Images (PR #4754)
Changed
0.60.2
Add Multiplatform Release Docker Images
We've added new release images with support multiple architectures. The images support both arm64 and amd64. The images will be available with the tag release. They will be available for GitHub Container Registry the same as our other ponyc images.
The images are based on Alpine 3.21. Every few months, we will be updating the base image to a newer version of Alpine Linux. At the moment, we generally add support for new Alpine version about 2 times a year.
Note, at this time, the release images that are tagged with the release version like 0.60.2 are still only amd64. Multiplatform images tagged with the version will be coming soon.
[0.60.2] - 2025-10-18
Changed
- Add Multiplatform Release Docker Images (PR #4749)
0.60.1
0.60.0
Drop Ubuntu 20.04 support
Ubuntu 20.04 has reached its end of life date. We've dropped it as a supported platform. That means, we no longer test against it when doing CI and we no longer create prebuilt binaries for installation via ponyup for Ubuntu 20.04.
We will maintain best effort to keep Ubuntu 20.04 continuing to work for anyone who wants to use it and builds ponyc from source.
Don't set ld.gold as the default Linux linker
Previously, we were setting ld.gold as our default linker on Linux. If you wanted to use a different linker, you had to override it using the ponyc option --link-ldcmd.
ld.gold was contributed to the GNU project many years ago by Google. Over the years, Google has moved away from supporting it and to investing in LLVM and other tools. ld.gold has no active maintainers at this point in time and has been removed from the most recent version of binutils.
It is no longer reasonable going forward to set gold as the default Linux linker as many Linux distributions will not have it easily available. We have switched to using the default Linux linker on the given system. On most systems, that is ld.bfd unless it has been configured otherwise. If you would like to use a different linker you can do the following as part of ponyc command line:
Use gold:
ponyc --link-ldcmd=gold
Use mold:
ponyc --link-ldcmd=mold
Alpine 3.20 added as a supported platform
We've added Alpine 3.20 as a supported platform. We'll be building ponyc releases for it until it stops receiving security updates in 2026. At that point, we'll stop building releases for it.
Alpine 3.21 added as a supported platform
We've added Alpine 3.21 as a supported platform. We'll be building ponyc releases for it until it stops receiving security updates in 2026. At that point, we'll stop building releases for it.
Ubuntu 24.04 on arm64 added as a supported platform
We've added Ubuntu 24.04 on arm64 as a supported platform. We'll be building ponyc releases for it until it stops receiving security updates in 2029. At that point, we'll stop building releases for it.
Alpine 3.21 on arm64 added as a supported platform
We've added Alpine 3.21 on arm64 as a supported platform. We'll be building ponyc releases for it until it stops receiving security updates in 2026. At that point, we'll stop building releases for it.
Update to LLVM 18.1.8
We've updated the LLVM version used to build Pony to 18.1.8.
Support building ponyc natively on arm64 Windows
We've added support for building Pony for arm64 Windows.
Arm64 Windows added as a supported platform
We've added arm64 Windows as a supported platform. Builds for it are available in Cloudsmith. Corral and ponyup support will be coming soon.
Make finding Visual Studio more robust
Ponyc will now ignore applications other than Visual Studio itself which use the Visual Studio installation system (e.g. SQL Server Management Studio) when looking for link.exe.
Fix linking on Linux arm64 when using musl libc
On arm64-based Linux systems using musl libc, program linking could fail due to missing libgcc symbols. We've now added linking against libgcc on all arm-based Linux systems to resolve this issue.
Update nightly Pony musl Docker image to Alpine 3.21
We've updated our ponylang/ponyc:alpine image to be based on Alpine 3.21. Previously, we were using Alpine 3.20 as the base. The release images are still based on Alpine 3.20 for now.
Stop building Windows container images
We've stopped building Windows container images as of Pony 0.60.0. As far as we know, the Windows images were not being used. We've simplified our CI by removing them.
Stop building glibc based ponyc images
We have stopped building nightly and release ponyc Docker images that are based on glibc. The glibc based images that we were building were based on an ever changing version of Ubuntu (most recent LTS release). These images had minimal utility.
They could only be used to link for Linux distros that had the same libraries installed as the build environment. Whereas the musl images could be used to statically link using musl and create binaries that could be used on any Linux.
Given the lack of utility for a wide variety of people, we have stopped building the glibc based images and will only have a single nightly and release image going forward. Those images will be using musl via Alpine Linux.
If you were using the glibc based images, we can point you to the Dockerfiles we were using as they are quite straightfoward and should be easy for anyone to incorporate the creation of into their own CI process. You can find the Dockerfiles in the pull request that removed them.
Add Multiplatform Nightly Docker Images
We've added new nightly images with support multiple architectures. The images support both arm64 and amd64. The images will be available with the tag nightly. They will be available for GitHub Container Registry the same as our other ponyc images.
The images are based on Alpine 3.21. Every few months, we will be updating the base image to a newer version of Alpine Linux. At the moment, we generally add support for new Alpine version about 2 times a year.
We will be dropping the alpine tag in favor of the new nightly tag. However, that isn't happening now but will in the not so distant future. You should switch any usage you have of those tags to nightly now to avoid disruption later.
[0.60.0] - 2025-10-15
Fixed
- Make the check for Visual Studio more robust (PR #4722)
- Fix linking on Linux arm64 when using musl libc (PR #4726)
Added
- Add Alpine 3.20 as a supported platform (PR #4709)
- Add Alpine 3.21 as a supported platform (PR #4710)
- Add Ubuntu 24.04 on arm64 as a supported platform (PR #4714)
- Add Alpine 3.21 on arm64 as a supported platform (PR #4716)
- Support building ponyc natively on arm64 Windows machines (PR #4689)
- Add arm64 Windows as a supported platform (PR #4721)
- Add Multiplatform Nightly Docker Image (PR #4731)
Changed
0.59.0
Add ability to trace runtime events in chromium json format #4649
We have added the ability to trace runtime events for pony applications. Runtime tracing is helpful in understanding how the runtime works and for debugging issues with the runtime.
The tracing can either write to file in the background or work in a "flight recorder" mode where events are stored into in memory circular buffers and written to stderr in case of abnormal program behavior (SIGILL, SIGSEGV, SIGBUS, etc).
Traces are written in chromium json format and trace files can be viewed with the perfetto trace viewer.
Links:
Chromium json format
perfetto trace viewer
Prevent memory explosion when using ponynoblock in some programs
We have enhanced the runtime to prevent memory explosion in some programs when --ponynnoblock is used.
The following is an example of such a program:
use "collections"
use "random"
use "time"
class Notify is TimerNotify
let _a: A
var _m: Main
new iso create(a: A, m: Main) =>
_a = a
_m = m
fun ref apply(timer: Timer, count: U64): Bool =>
_a.done(_m)
// returning false from apply in a TimerNotify
// instructs the runtime that the timer should be
// cancelled which allows for the owning Timers
// actor to potentially be reaped if there are no
// references to it and/or if the cycle detector
// decides it is safe to be reaped
false
actor A
// acquires a reference to the Main actor via an ORCA
// message to prevent the Main actor from being reaped
// until after this actor is done with the reference to
// it. This reference will be released the next time GC
// runs for this actor since this actor doesn't keep a
// reference to it
new create(m: Main, n: USize) =>
// acquires a reference to the Timers actor implicitly
// because this actor creates it. The reference will
// be freed after the next GC of this actor since this
// actor doesn't keep a reference to it
let timers = Timers
// passing a reference to the Main and A actors via the
// Notify class delays/prevents them from being reaped
// until after the references are no longer used either
// because the Notify object is destroyed or the Timers
// actor is reaped
let timer = Timer(Notify(this, m), n.u64() * 1_000_000)
timers(consume timer)
// acquires a reference to the Main actor via an ORCA
// message (if the previous reference has already been
// released) to prevent the Main actor from being reaped
// until after this actor is done with the reference to
// it. This reference will be released the next time GC
// runs for this actor since this actor doesn't keep a
// reference to it
// After this behavior completes, this actor can
// potentially be reaped if there are no references to it
// and/or if the cycle detector decides it is safe to be
// reaped
be done(m: Main) =>
m.done(this)
actor Main
let n: USize = 100000
var e: USize = 0
let max_num_oustanding: USize = 13
var num_outstanding: USize = 0
let s: SetIs[A] = s.create()
let rand: Random
new create(env: Env) =>
let t = Time.seconds()
rand = Rand(t.u64())
spawn()
be spawn() =>
if e < n then
while num_outstanding < max_num_oustanding do
let i = rand.int[USize](2)
// passing a reference to the Main actor
// delays/prevents it from being reaped
// until after the reference is no longer
// used
let a = A(this, i)
// saving references to A actors in the set
// delays/prevents them from being reaped
// until after the reference has been deleted
s.set(a)
e = e + 1
num_outstanding = num_outstanding + 1
end
end
be done(a: A) =>
// deletes a reference to an A actor but the actor
// can only be reaped after GC is run for the Main
// actor as that is when the ORCA message releasing
// the reference is sent
s.unset(a)
num_outstanding = num_outstanding - 1
spawn()before:
root@5babe01f566f:/workspaces/ponyc# /usr/bin/time ./before --ponynoblock
35.91user 7.08system 0:05.91elapsed 727%CPU (0avgtext+0avgdata 1716480maxresident)k
0inputs+0outputs (3major+428831minor)pagefaults 0swaps
after:
root@5babe01f566f:/workspaces/ponyc# /usr/bin/time ./after --ponynoblock
41.16user 2.73system 0:05.89elapsed 744%CPU (0avgtext+0avgdata 13440maxresident)k
0inputs+0outputs (3major+3137minor)pagefaults 0swaps
Make GC for an actor more aggressive if an actor GC frees many actor references
We have enhanced the runtime to make actor GC more aggressive if an actor GC cycle deleted many references to other actors (> 100). This could be due to a program design where an actor creates many other actors and keeps references to them for a bit before replacing those references with ones for other newly created actors. This change will make GC for these actors more aggressive in order to try and limit memory explosion that could potentially occur otherwise.
Update to LLVM 17.0.1
We've updated the LLVM version used to build Pony to 17.0.1.
[0.59.0] - 2025-04-26
Fixed
- Prevent memory explosion when using ponynoblock in some programs (PR #4666)
- Make GC for an actor more aggressive if an actor GC frees many refs (PR #4662)
Added
- Add ability to trace runtime events in chromium json format (PR #4649)
Changed
0.58.13
Make sure systematic testing doesn't switch to suspended thread
Previously, the systematic testing next thread logic would consider switching to the pinned actor thread even if it was suspended. This was very wasteful since the suspended pinned actor thread would not do any meaningful work and almost immediately re-suspend itself.
We have changed things so that the next thread logic properly takes into account whether the pinned actor thread is suspended or not when selecting the next thread to activate.
Fix race condition in epoll ASIO system
We've fixed a race condition in the epoll ASIO subsystem that could result in "unexpected behavior" when using one-shot epoll events. At the time the bug was fixed, this means that only the TCPConnection actor was impacted part of the standard library.