AOT Compatibility: Fix Trim Analysis and Dynamic Code Warnings (56 warnings)

[Aaronontheweb]

Overview

This issue tracks the resolution of AOT compilation warnings discovered during Native AOT compatibility testing. Currently, the AOT test app produces 56 warnings and fails at runtime.

Related Epic: #7246

Current Status

• Warning Count: 56 (Target: 0)
• Runtime Status: ❌ Fails with ConfigurationException for actor provider type resolution

Error Categories

1. Trim Analysis Warnings - Type.GetType() (IL2057)

These occur when using Type.GetType(string) with dynamic type names from configuration, making it impossible for the trimmer to guarantee type availability.

Affected Files:

• ActorSystemImpl.cs:300 - LoadExtensions()
• ActorSystemImpl.cs:285 - ConfigureScheduler()
• ActorSystemImpl.cs:447 - ConfigureProvider()
• Mailboxes.cs:66 - Constructor
• Serialization.cs:183 - Constructor (serializers)
• Serialization.cs:210 - Constructor (serialization bindings)
• Settings.cs:104 - Constructor (LoggerType)
• Settings.cs:142 - Constructor (StdoutLogger)
• Settings.cs:174 - Constructor (LoggerStartTimeout)
• Dispatchers.cs:607 - ConfiguratorFrom()
• Serializer.cs:200 - GetSerializerIdentifierFromConfig()
• AbstractDispatcher.cs:343 - MessageDispatcherConfigurator.ConfigureExecutor()

2. Trim Analysis Warnings - Activator.CreateInstance (IL2067, IL2087)

These occur when creating instances without proper DynamicallyAccessedMembers annotations.

Affected Files:

• Props.cs:587 - CreateProducer() - Missing PublicConstructors annotation
• Extensions.cs:136 - WithExtension<T,TI>() - Missing PublicParameterlessConstructor annotation
• Extensions.cs:116 - WithExtension() - Missing PublicParameterlessConstructor annotation

3. AOT Analysis Warnings - System.Linq.Expressions (IL3050)

These are from BCL code using Type.MakeGenericType() which requires dynamic code generation. These may be acceptable if expression compilation isn't used in AOT scenarios.

Files: DelegateHelpers.Generated.cs (40 warnings in BCL code)

Action Items

High Priority

• Add DynamicDependency and UnconditionalSuppressMessage attributes for known-safe type resolutions
• Implement AOT-compatible type registration system (potentially using source generators)
• Add DynamicallyAccessedMembers annotations to Props.CreateProducer() parameter
• Add DynamicallyAccessedMembers annotations to extension methods in Extensions.cs
• Fix runtime error: ConfigurationException for 'Akka.Actor.LocalActorRefProvider'

Medium Priority

• Investigate expression compilation usage - determine if we can avoid it in AOT scenarios
• Create AOT-specific configuration validator to catch type resolution issues at build time
• Document which Akka.NET features are/aren't AOT compatible

Low Priority

• Evaluate if System.Linq.Expressions warnings can be suppressed (if not used in AOT paths)
• Add AOT compatibility tests to CI pipeline

Runtime Error Details

Unhandled Exception: Akka.Configuration.ConfigurationException: 
'akka.actor.provider' is not a valid type name : 'Akka.Actor.LocalActorRefProvider'
   at Akka.Actor.Settings..ctor(ActorSystem, Config, ActorSystemSetup)

This suggests the type resolution mechanism fails completely in AOT scenarios. The provider type cannot be loaded dynamically.

Technical Approach

Option 1: Source Generator for Type Registration

• Create a source generator that scans configuration and generates static type mappings
• Eliminates runtime Type.GetType() calls

Option 2: Explicit Type Registration API

• Add ActorSystemSetup builders that accept concrete types instead of type names
• Provides AOT-friendly configuration path

Option 3: Hybrid Approach

• Keep existing API for non-AOT scenarios
• Add AOT-specific setup path with compile-time type registration
• Use #if directives or feature detection

Success Criteria

• All 56 warnings resolved or properly suppressed with justification
• AOT test app runs successfully without runtime exceptions
• Core actor system functionality works in AOT scenarios
• Documentation updated with AOT compatibility guidelines

[Aaronontheweb]

Root Cause Analysis: HOCON-based Type Loading

After analyzing src/core/Akka/Configuration/akka.conf, I've identified 10 major categories of types that are dynamically loaded from HOCON configuration. This is the fundamental source of all AOT compatibility issues.

Categories of Dynamically-Loaded Types

1. Core Actor System Components (2 types)

akka.actor {
  provider = "Akka.Actor.LocalActorRefProvider"                    # Line 100
  guardian-supervisor-strategy = "Akka.Actor.DefaultSupervisorStrategy"  # Line 105
}

Code: ActorSystemImpl.cs:447, Settings.cs:104

2. Logging Infrastructure (3 types)

akka {
  loggers = ["Akka.Event.DefaultLogger"]                          # Line 18
  logger-formatter = "Akka.Event.DefaultLogMessageFormatter, Akka"  # Line 35
  stdout-logger-class = ""                                         # Line 53 (optional)
}

Code: Settings.cs:142, Settings.cs:174

3. Extensions (user-extensible array)

akka {
  extensions = []  # Line 85 - Array of extension FQCNs
}

Code: ActorSystemImpl.cs:300

4. Routers (13+ types)

akka.actor.router.type-mapping {
  from-code = "Akka.Routing.NoRouter"
  round-robin-pool = "Akka.Routing.RoundRobinPool"
  round-robin-group = "Akka.Routing.RoundRobinGroup"
  random-pool = "Akka.Routing.RandomPool"
  random-group = "Akka.Routing.RandomGroup"
  smallest-mailbox-pool = "Akka.Routing.SmallestMailboxPool"
  broadcast-pool = "Akka.Routing.BroadcastPool"
  broadcast-group = "Akka.Routing.BroadcastGroup"
  scatter-gather-pool = "Akka.Routing.ScatterGatherFirstCompletedPool"
  scatter-gather-group = "Akka.Routing.ScatterGatherFirstCompletedGroup"
  consistent-hashing-pool = "Akka.Routing.ConsistentHashingPool"
  consistent-hashing-group = "Akka.Routing.ConsistentHashingGroup"
  tail-chopping-pool = "Akka.Routing.TailChoppingPool"
  tail-chopping-group = "Akka.Routing.TailChoppingGroup"
  cluster-metrics-adaptive-pool = "Akka.Cluster.Metrics.AdaptiveLoadBalancingPool, Akka.Cluster.Metrics"
  cluster-metrics-adaptive-group = "Akka.Cluster.Metrics.AdaptiveLoadBalancingGroup, Akka.Cluster.Metrics"
}

5. Dispatchers & Executors (4+ types)

akka.actor {
  default-dispatcher {
    type = "Dispatcher"           # Can be FQCN of MessageDispatcherConfigurator
    executor = "default-executor" # Can be FQCN of ExecutorServiceConfigurator
  }
  synchronized-dispatcher { type = "SynchronizedDispatcher" }
  task-dispatcher { type = "TaskDispatcher" }
  default-fork-join-dispatcher { type = "ForkJoinDispatcher" }
}

Code: Dispatchers.cs:607, AbstractDispatcher.cs:343

6. Mailboxes (5 types)

akka.actor {
  default-mailbox {
    mailbox-type = "Akka.Dispatch.UnboundedMailbox"
  }
  mailbox.requirements {
    "Akka.Dispatch.IUnboundedMessageQueueSemantics" = akka.actor.mailbox.unbounded-queue-based
    "Akka.Dispatch.IBoundedMessageQueueSemantics" = akka.actor.mailbox.bounded-queue-based
    "Akka.Dispatch.IDequeBasedMessageQueueSemantics" = akka.actor.mailbox.unbounded-deque-based
    "Akka.Dispatch.IUnboundedDequeBasedMessageQueueSemantics" = akka.actor.mailbox.unbounded-deque-based
    "Akka.Dispatch.IBoundedDequeBasedMessageQueueSemantics" = akka.actor.mailbox.bounded-deque-based
    "Akka.Dispatch.IMultipleConsumerSemantics" = akka.actor.mailbox.unbounded-queue-based
    "Akka.Event.ILoggerMessageQueueSemantics" = akka.actor.mailbox.logger-queue
  }
}

Code: Mailboxes.cs:66

7. Serialization System (2+ serializers + bindings)

akka.actor {
  serializers {
    json = "Akka.Serialization.NewtonSoftJsonSerializer, Akka"
    bytes = "Akka.Serialization.ByteArraySerializer, Akka"
  }
  serialization-bindings {
    "System.Byte[]" = bytes
    "System.Object" = json
  }
  serialization-identifiers {
    "Akka.Serialization.ByteArraySerializer, Akka" = 4
    "Akka.Serialization.NewtonSoftJsonSerializer, Akka" = 1
  }
}

Code: Serialization.cs:183, Serialization.cs:210, Serializer.cs:200

8. Scheduler (1 type)

akka.scheduler {
  implementation = "Akka.Actor.HashedWheelTimerScheduler"
}

Code: ActorSystemImpl.cs:285

9. IO Buffer Pools (6 instances)

akka.io {
  tcp.direct-buffer-pool.class = "Akka.IO.Buffers.DirectBufferPool, Akka"
  tcp.disabled-buffer-pool.class = "Akka.IO.Buffers.DisabledBufferPool, Akka"
  udp.direct-buffer-pool.class = "Akka.IO.Buffers.DirectBufferPool, Akka"
  udp.disabled-buffer-pool.class = "Akka.IO.Buffers.DisabledBufferPool, Akka"
  udp-connected.direct-buffer-pool.class = "Akka.IO.Buffers.DirectBufferPool, Akka"
  udp-connected.disabled-buffer-pool.class = "Akka.IO.Buffers.DisabledBufferPool, Akka"
}

10. DNS Provider (1 type)

akka.io.dns.inet-address {
  provider-object = "Akka.IO.InetAddressDnsProvider"
}

---

Total Impact

• 10 major categories of dynamic type loading
• 40-50+ distinct types loaded via Type.GetType() from HOCON
• 12 IL2057 trim warnings reported in compilation

Related Issue

This analysis supports the solution approach outlined in #7431 - we need to:

1. For default implementations: Skip HOCON-based Type loading and use direct type references (as already done for Dispatchers)
2. For custom user types: Introduce Setup classes that accept type references instead of string FQCNs
3. Maintain backward compatibility: Keep HOCON config working for non-AOT scenarios with appropriate feature detection

The Dispatcher implementation in Dispatchers.cs:587-616 shows the pattern we need to replicate across all 10 categories.