phantomuserland
phantomuserland copied to clipboard
Published
20 hours ago •
dzavalishin
dzavalishin
(userland) class loader execution
Class loader is started from kernel and locks up everything (namely -
snaps) while is working.
One possible solution is to replace VM command 'summon class' with direct
access to userland class loader - but then what we have to do if kernel
itself will need some class?
Other possible hack is:
- after 'summon class' is called and class is not found in fast kernel hash
(which we need to implement as well) user code IP is stepped back to the
beginning of 'summon class' instruction and thread is put asleep. After the
finish of userland class loader thread is awaken and restarts its class
request, wchich is finished quickly this time, because requested class is
already in the fast kernel hash (which...;).
Original issue reported on code.google.com by [email protected] on 5 Sep 2009 at 10:34
exec.c:2061 - make sure this is called from kernel only. Userland must come through connection blocking call.
Simulate a call to user class loader, instead of running it in a separate thread - NO! We need result to be stored in persistent class hash.
Sleep on VM cond, run thread which will trigger that cond on success. Class loader queue?
Put thread asleep on cond waiting for class to load.
- Don't restart instruction - cond is persistent
- Setup wait on cond - cond_wait code returns, so we can continue
- Start class loader thread passing cond to broadcast on load
- Note that loader can run concurrently - other thread can start the same load.
- Use directory as multiple mutex? Make directory put() to be atomic and tell if key we put was in dir before?