throw LightBoundsError instead of BoundsError#345
throw LightBoundsError instead of BoundsError#345nsajko wants to merge 2 commits intoJuliaArrays:masterfrom
LightBoundsError instead of BoundsError#345Conversation
Context: While `BoundsError` is common in the Julia world, its use is problematic for compiler optimizations. More specifically, Julia is gaining the ability to eliminate heap allocations as of recently, even for code that is not eliminated by dead code elimination or eliminated by constant folding. After the compiler gains interprocedural escape analysis capabilities, elimination of heap allocations should become applicable more often. The problem with `BoundsError` is that a `BoundsError` value holds a reference to the array that was attempted to be indexed out-of-bounds. Thus a `BoundsError` throw escapes the value of the array. Thus a `BoundsError` throw makes the elimination of the underlying heap allocation impossible, unless the throw is first eliminated by `@inbounds` or by other compiler optimizations. The `LightBoundsError` exception from package [LightBoundsErrors.jl](https://github.com/JuliaArrays/LightBoundsErrors.jl) addresses this by storing `typeof(array)` and `axes(array)` instead of storing `array`. The new package is already being adopted as a dependency by [FixedSizeArrays.jl](https://github.com/JuliaArrays/FixedSizeArrays.jl) and by [MemoryViews.jl](https://github.com/BioJulia/MemoryViews.jl). Switching from `BoundsError` to `LightBoundsError` could hypothetically break a dependent package, in case the dependent branches on something like `exception isa BoundsError` while error handling in a `catch` block.
|
The noalloc test failure on Julia v1.13 is unrelated. |
|
I understand the motivation, but switching to an exception type from another package (not Base) is a non-starter for such a foundational and hugely popular package IMO... |
I do not see why, when the time comes for a breaking release. StructArrays.jl already has three strong deps, why not add a fourth one?
I suppose after a few months or years it would be good to make a PR to JuliaLang/julia, then make the LightBoundsErrors.jl package just export the functionality provided by |
This presupposes that |
2 participants
Context: While
BoundsErroris common in the Julia world, its use is problematic for compiler optimizations. More specifically, Julia is gaining the ability to eliminate heap allocations as of recently, even for code that is not eliminated by dead code elimination or eliminated by constant folding. After the compiler gains interprocedural escape analysis capabilities, elimination of heap allocations should become applicable more often. The problem withBoundsErroris that aBoundsErrorvalue holds a reference to the array that was attempted to be indexed out-of-bounds. Thus aBoundsErrorthrow escapes the value of the array. Thus aBoundsErrorthrow makes the elimination of the underlying heap allocation impossible, unless the throw is first eliminated by@inboundsor by other compiler optimizations.The
LightBoundsErrorexception from package LightBoundsErrors.jl addresses this by storingtypeof(array)andaxes(array)instead of storingarray. The new package is already being adopted as a dependency by FixedSizeArrays.jl and by MemoryViews.jl.Switching from
BoundsErrortoLightBoundsErrorcould hypothetically break a dependent package, in case the dependent branches on something likeexception isa BoundsErrorwhile error handling in acatchblock.