DI container with auto-wiring feature
Naming

class Rosa tells me nothing. The name should scream out that it is a dependency injection container.

PSR

There is a standard interface for DI containers.
https://github.com/php-fig/container/blob/master/src/ContainerInterface.php

You might want to have you container implement it.

Exit vs. Exception

Implementing the PSR interface would automatically answer your question about exit vs. exception. In short, yes throw exception. Don't call exit generaly from anywhere.

Shared vs one-time services

Your container keeps references of services that you have registered but will instantiate a new one every time if not registered explicitly.

This is rather unintuitive. Consumers of the container should either be able to choose whether a service is shared or should get new instance every time. Or they should always receive consitent behaviour for all services (only one of them is supported).

On demand instantiation

Assuming you have chosen to support shared services, it is common that only a recipe for the service is provided and the actual service object is instantiated on first demand.

Configuration of Services

It would be more precise to say that your container does not just have autowiring feature, but that the autowiring is almost unevitable. You either register instantiated service (for which you have had to resolve dependencies manually) or it autowires all constructor arguments (potentialy recursively).

This is somewhat related to the previous section. If you had recipes for service instantiation, you could define which values parameters should be autowired and which should receive value defined by the consumer.

Services Dependant on Interfaces

You assume that a constructor parameter is a class or a primitive type with default value. Recipes could again help with primitives without default.

If it is not a primitive it still does not mean it is a class, it can be an interface. But you dont have any mechanism autowire interfaces because you dont keep track of interfaces implemented by services.

Service Identification

You save services by class name, making it impossible to have multiple services of the same class. It is common that it is possible to set a name for a service. Again this could be property of a service recipe.

Single Responsibility Principle

Autowiring is quite a big topic and it could be useful in conjunction with other things that a DI container. Therefore it makes sense to separate the autowiring mechanism to a separate class and have the container just depend on it.