*Mike · September 16, 2026*

**Tags:** Project Ceylon, Workshop, Microkernel, Virtual Memory, Systems Engineering

---

Ceylon is learning how to become dynamic without abandoning a static, bounded and predictable foundation: leased execution workers, mirrored VSpace cohorts, bounded page capabilities, and a capability-pool question still open.

## Project Ceylon Nightly: Static Foundations, Dynamic Systems

Today was one of those days where the most important progress was not a new screen, a new driver, or another user-facing feature.

It was figuring out what the machine underneath all of those things needs to become.

Over the last several development cycles, Ceylon has been moving onto an updated microkernel foundation and a newer generation of its surrounding system-construction tooling. That upgrade brought substantial capabilities with it, but it also invalidated a few assumptions that had quietly worked their way into the earlier architecture.

That forced us to stop and answer a more fundamental question:

How dynamic can Ceylon become while preserving a system that is deliberately static, bounded, isolated and predictable at its foundation?

The answer is turning out to be: surprisingly dynamic.

## The execution problem

One of the first challenges was application execution.

Traditional operating systems tend to build processes and threads dynamically. Ceylon's underlying platform is intentionally different. Much of the system is constructed ahead of time, with explicit resources, explicit authority and tightly controlled relationships between components.

Initially, that looked like it might become an obstacle.

Instead of fighting that design, we tried a different approach.

We built a bounded pool of isolated execution workers ahead of time, then allowed Ceylon to lease those workers dynamically.

The underlying execution resources remain static.

Their use becomes dynamic.

That means an execution worker can move through a lifecycle resembling:

FREE
  ↓
LEASED
  ↓
ACTIVE
  ↓
QUIESCING
  ↓
RESETTING
  ↓
FREE

Each lease carries generation information so stale references can be rejected rather than accidentally referring to a newly reused resource.

More importantly, multiple isolated workers can participate in one logical application environment while retaining separate protection domains.

That has some useful security properties of its own: sharing memory does not automatically mean sharing authority.

## Making isolated workers feel like one address space

That led directly to the next problem.

If two workers are supposed to behave somewhat like threads in one application, they need to agree about memory.

We proved that two—and later four—isolated workers can map the same backing memory at the same virtual address and successfully exchange actual pointers.

Not offsets.

Not handles pretending to be pointers.

The same numeric address.

One worker can create an object in shared memory, publish a pointer to it, and another worker can dereference that pointer directly.

That was an important result because it suggested that Ceylon could build a logical shared application address space across independently isolated execution contexts.

There are caveats.

Ordinary writable program globals remain private to each worker unless we deliberately place them into shared backing memory. Private stacks and thread-local state also need to remain private.

But that is an architectural problem we can define clearly rather than an indication that the model is impossible.

## The virtual-memory problem

The next step was harder.

Static shared mappings are useful, but a modern workstation eventually needs runtime memory behavior:

mapping and unmapping memory;
shared heaps;
guard pages;
permission changes;
executable-code transitions;
sparse reservations;
deterministic cleanup;
controlled reuse.

At first, the upgraded platform appeared not to expose enough authority for that.

The obvious response would have been to start modifying the microkernel or turn Ceylon into something the underlying platform was never intended to be.

We resisted that.

Instead, we asked whether the capacity could remain static while the mappings themselves became dynamic.

That produced one of today's most useful findings.

We can preconstruct bounded virtual-memory arenas during system construction. A tiny reserved page placed at regular intervals causes the required paging hierarchy to exist before the operating system starts.

Once those structures exist, runtime memory operations do not need the ability to dynamically manufacture page tables.

They only need authority over the individual physical pages being mapped.

That greatly simplified the problem.

Instead of needing a general-purpose runtime memory-object allocator inside the kernel, the problem reduced to:

Safely provide the memory manager with bounded authority over an explicitly approved pool of pages.

That is a dramatically smaller requirement.

## A tiny platform addition

We built an isolated validation extension to test exactly that.

It does not modify the microkernel.

It does not create new kernel behavior.

It simply allows the system-construction layer to expose carefully selected page capabilities to the memory manager.

The first target proof succeeded.

The manager could take a page from a bounded provider pool and map it at runtime into a worker's preconstructed virtual-memory arena.

The same physical page could also be mapped into multiple isolated workers at the same address.

We verified four independent address spaces sharing the same backing page while preserving pointer transparency.

We also confirmed that mappings outside the preconstructed arena fail as expected.

That distinction matters.

The system is not secretly turning itself into an unlimited dynamic virtual-memory manager.

It remains bounded.

## Stressing it

Once the mechanism worked, the next job was trying to break it.

The current stress campaign has reached a partial qualification result.

Among the completed tests:

four isolated workers sharing one physical page;
identical pointer use across those workers;
repeated map/unmap lifecycle testing;
virtual-address rotation;
physical-frame rotation;
10,000 target lifecycle cycles;
three repeatable hardware-accelerated virtualization runs;
more than 500,000 randomized model operations across several deterministic seeds;
zero resource drift in the executed scope.

That is encouraging.

It is not yet enough to call the entire virtual-memory system qualified.

Several advanced cases remain open, including complete rights transitions, guard-page stress, sparse commit/decommit, cohort rollback, stale target mapping rejection and fault-time cleanup.

Those should eventually be tested against the architecture we actually intend to ship rather than against a temporary proof configuration.

## The next bottleneck: capability scale

The stress work also found the next important architectural issue.

Each simultaneous mapping needs its own capability instance.

For a small proof, those can simply be provisioned ahead of time.

For a large application-memory pool, that becomes expensive.

So the next question is no longer whether dynamic mapping works.

It does.

The next question is:

How do we build a bounded capability pool that can efficiently create and recycle mapping authority without giving the memory manager broad system authority?

The direction we are investigating is another example of the same principle that has been emerging throughout Ceylon:

static capacity
dynamic use
explicit ownership
deterministic exhaustion

The likely model is a dedicated capability pool owned by the memory manager.

A small number of master page capabilities would exist within that pool. Individual mapping capabilities could then be copied into bounded slots when needed, used for a mapping, retired, deleted and recycled.

No unrestricted kernel-object allocator.

No unlimited memory growth.

No requirement to share another process's complete capability space.

Just a purpose-built pool with explicit limits.

## Research is becoming part of the development process

A significant portion of today's work was research rather than implementation, and that is intentional.

Ceylon has reached a point where blindly writing everything ourselves would be wasteful.

We have been studying modern componentized operating-system designs, device-driver frameworks, real-time systems, memory-management approaches, multimedia architectures and older workstation designs to identify ideas that can accelerate development without compromising the architecture.

Some of that research is already paying off.

One modern driver framework we reviewed has several characteristics very close to decisions Ceylon has independently been moving toward:

small isolated hardware drivers;
shared-memory data paths;
bounded single-producer/single-consumer queues;
asynchronous notifications rather than synchronous bulk IPC;
separate components for device sharing and address translation;
explicit handling of DMA-visible buffers.

It also contains working implementations for several device classes directly relevant to our development path, including virtual block devices, virtual networking, high-performance storage, timers and serial hardware.

That does not mean Ceylon is simply going to import another project's driver stack.

It does mean we would be foolish not to study working implementations before reinventing every queue, reset path, interrupt sequence and DMA rule ourselves.

We are therefore preparing a systematic driver-reuse audit.

For each candidate component we will decide whether the right answer is:

direct reuse
port
wrap
reuse the protocol
reuse the algorithm
reuse the tests
reference only
reject

The highest-value targets initially are storage, networking, PCI, timers, serial devices and the shared-memory transport architecture surrounding them.

The goal is not to make Ceylon dependent on someone else's operating system.

The goal is to avoid spending six weeks rediscovering something another engineering team has already spent six months validating.

## Research does not mean architectural drift

There is an important distinction here.

Ceylon has accumulated a fairly strong architectural identity:

capability-based authority;
bounded resources;
generation-safe reuse;
isolation by default;
small control messages;
shared and registered bulk-data paths;
predictable real-time behavior where required;
hardware-shaped interfaces that can move from virtualization to bare metal.

Any external idea has to fit those rules.

We are not changing the architecture every time we find an interesting project.

We are using research to ask better questions before freezing our own interfaces.

That is especially important now because several major pieces are beginning to intersect:

execution workers
virtual memory
physical memory ownership
buffer sharing
DMA
device drivers
real-time scheduling
audio
graphics
storage
networking

A bad decision in one layer can create unnecessary copies, authority leaks, reset problems or performance ceilings throughout the rest of the machine.

This is the point where slowing down long enough to study good prior work can actually make development move faster.

## The larger pattern

The most interesting lesson from the last several days is that the supposed conflict between a static microkernel architecture and a dynamic workstation may not really be a conflict.

Ceylon does not need to make its foundation behave like a conventional desktop operating system.

Instead, we can provision resources deliberately and then build dynamic behavior above them.

Static worker inventory.

Dynamic execution leases.

Static virtual-address capacity.

Dynamic page mappings.

Static physical-page pools.

Dynamic ownership.

Static capability capacity.

Dynamic capability leases.

The lower layers remain understandable and bounded.

The upper layers gain the flexibility applications expect.

That combination is starting to look like one of Ceylon's defining architectural ideas.

## Next

Before the next major implementation push, we are going to close out the current development cycle properly.

That means cleaning the validation and source trees, preserving the evidence that matters, reconciling the architecture handoffs, updating the project's durable engineering records, and making sure the next development session begins from a known state.

After that, two research tracks move to the front:

designing and proving the bounded capability pool needed for larger dynamic-memory workloads;
performing a systematic driver and data-path reuse audit to determine where existing work can accelerate Ceylon's storage, networking, timing and device architecture.

Neither is particularly glamorous.

Both could save an enormous amount of development time.

And both move us toward the same goal:

a machine that is dynamic where users need it to be, but predictable where engineering demands it.

---

*Originally published on The Weekend Report: https://theweekendersproject.com/report/ceylon-development-log-september-16-2026-static-foundations-dynamic-systems*