Не очень понятно. Как Вы куда-то в PL/SQL собираетесь передавать "нечто", что даже не является объектом типа Oracle.

Хотя, в принципе и в данном случае проблем нет (можно обойти): Экземпляр любого объекта это просто последовательность битиков и байтиков, т.ч. передавайте RAW и будет Вам счастье (нет).

IMHO

Подозреваю, что для "мельких объектов" (сотни и даже тысячи байт), накладные расходы на сериализацию/десериализацию при передачи будет ничтожно малы, по сравнению с затратами на САМ ВЫЗОВ и соответственно передачу управления межу PL/SQL Engine и Java Engine.

В общем, в большинстве случаев, экономия памяти и времени будет чисто мифической. Тут скорее надо оптимизировать кол-во вызовов (переключений) между PL/SQL и Java

Для java object никто не мешает реализовать "ссылки" самому. Создать какой нибудь array или HashMap<Integer, Object>, сохранять туда объекты присваивая им уникальный Id/Handle. А дальше при вызове своих get'ов / set'ов уже вместо сереализации/десериалиации просто передавать свой Id/Handle

Для каких нибудь сложных структур (например развесистое дерево) на PL/SQL, смотреть как они реализованы.

Если сотня-другая полей одного объекта - для современного процессора это "ни о чем". Затраты на тупую сериализацию (если конечно прикладные программисты не сделали ее особо извращенным способом) по сравнению с переключением контекста будут малозаметны.

Проблемы могут быть, если в один объект кто-то "жестко" захардкодил развесистое дерево, не подумав, дать интерфейс доступа к частям. Например XML DOM. Нормальные реализации не выполняют передачу всего дерева одним целым, а дают отдельные ссылки/handle для доступа к каждой конкретной node, attribute и так далее. Т.е. дерево большое, но вот в любой момент времени работать/передавать нужно достаточно компактные структуры.