ScopedValue.runWhere not returning scope
Andrew Haley
aph-open at littlepinkcloud.com
Wed Jun 19 16:20:46 UTC 2024
On 6/19/24 16:50, Pedro Lamarão wrote:
>
> Consider this about ScopedValues.
> One of the optimizations that the proposed design allows is caching.
> Because, from the perspective of a "call scope", the result of ScopedValue.get is idempotent, the implementation is allowed to cache this value.
> One may even hope that the VM would optimize out getter calls in hot code, if not this day then some day.
We mostly do this, but can do more.
Consider this example, where we map some native memory, do stuff, then
unmap the memory:
public void runWithMappedRegion(Runnable r) {
MemoryRegion mappedRegion = mmapNewMemoryRegion(1_000_000);
// m now contains a handle to 1 megabyte of mapped memory
where(CURRENT_REGION, mappedRegion).run(r);
// Within the dynamic scope of r
mappedRegion.unmap();
}
class MemoryRegionAccess {
public static Something readMemoryAt(long index) {
MemoryRegion mappedRegion = CURRENT_REGION.get();
// ... Do stuff with mappedRegion ...
}
// more accessors
}
CURRENT_REGION is static final.
Any code running when there is a current mapped region can use the static
accessors in MemoryRegionAccess to access the memory. Any threads forked
from stuctured concurrency inside a runWithMappedRegion can access the
region too. We know, for certain, that we will never unmap that region
unless all of its users have finished with it.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the loom-dev
mailing list