Даже если вы этого и добьетесь (или уже добились путем memcpy), то все равно такое решение будет иметь кучу потенциальных проблем, ведь контекст бибилиотеки в общем случае это не только сегмент данных:
1) DllMain(DLL_PROCESS/THREAD_ATTACH/DETACH) и прочие там FLS callback-и будут исполнятся с текущим "контекстом" — альтернативные "контексты" могут оказаться недоинициализированными или напротив — могут вызвать утечку памяти и прочих ресурсов. Впрочем, учитывая что у вас там java, последним наверное можно пренебресь
2) если длл использует именовынные объекты привязанные к PID текущего процесса (зачем — отдальный вопрос, но такое бывает) — с ними будут проблемы
3) если длл создает окна/классы окон — опять же возможны проблемы, так как HINSTANCE общий, а классы — разные. Не факт что все срастеться.
4) если длл юзается из разных потоков или сама порождает потоки (возможно даже неявно) — будут редкие рандомные проблемы.
..) ...

Даже если вы этого и добьетесь (или уже добились путем memcpy), то все равно такое решение будет иметь кучу потенциальных проблем, ведь контекст бибилиотеки в общем случае это не только сегмент данных:
1) DllMain(DLL_PROCESS/THREAD_ATTACH/DETACH) и прочие там FLS callback-и будут исполняться с текущим "контекстом" — альтернативные "контексты" могут оказаться недоинициализированными или напротив — могут вызвать утечку памяти и прочих ресурсов. Впрочем, учитывая что у вас там java, последним наверное можно пренебречь
2) если длл использует именованные объекты, привязанные к PID текущего процесса (зачем — отдальный вопрос, но такое бывает) — с ними будут проблемы
3) если длл создает окна/классы окон — опять же возможны проблемы, так как HINSTANCE общий, а классы — разные. Не факт что все срастется.
4) если длл юзается из разных потоков или сама порождает потоки (возможно даже неявно) — будут редкие рандомные проблемы.
..) ...
Вобщем, или делать реально отдельные инстансы длл, или (если во-взрослому) переписывать код длл на возможность использования многих устройств с одной длл.