Why can't MM:S be unloaded in VSP mode ?

Mani · **Author**

I'm doing some experimentation with a bootstrap loader that loads engine specific libraries for core functionality, similar to how the Loader works for MM:S but without requiring SourceHook in the loader.

My question is, what is the technical reason behind not being able to unload when in VSP mode?

Mani

Chrisber · 09-08-2010 , 19:04 Re: Why can't MM:S be unloaded in VSP mode ?

Quote:

Originally Posted by http://wiki.alliedmods.net/Gameinfo_Deprecation#Can_I_unload_Metamod:Sou rce_now.3F

No. Don't try; you will get an error message and then MM:S will force your server to quit to avoid a delayed crash. Metamod:Source cannot be unloaded for technical reasons, and if you're interested why, I can write an entry on my blog. This feature will never be added so do not ask for it. You can simply use "meta unload" to unload individual plugins.

Yes, now I'm interested as Mani and ask myself why this can't work

An explanation would be nice.

Chris

Keeper · *Last edited by Keeper; 09-08-2010 at 22:39.*

I'd love to say this is my answer, but here is "an" answer:

Quote:

Originally Posted by Alfred

Unloading plugins isn't something our engine would work well with, it is designed with global singletons and has (unfortunate) implicit assumptions about object lifetimes. Things like command registering and convars would not be happy with an unload.

VALVe could fix this, but they have other fish to fry...like getting rid of (I hope) EP1 engine soon.

BAILOPAN · *Last edited by BAILOPAN; 09-10-2010 at 04:00.*

Valve's answer is lazy. These problems are solvable and that's why MM:S plugins can unload. It fixes up the linked list of Con* (all engines included, even those without explicit cvar removal).

MM:S itself is different, since someone brought it up. Plugins, and MM:S included, create hooks on ConCommand::Dispatch. When you type "plugin_unload", this hook is active, so unloading the plugin from memory would crash. The callstack unwinds back to garbage. This is solvable, but not a priority - MM:S doesn't need to be unloaded.

Chrisber · *Last edited by Chrisber; 09-17-2010 at 14:09.*

Hey.
Thanks for explanation.

One question: is it possible to reload a VSP plugin that implements SourceHook? Currently, when I try to unload my plugin, it works fine. But when I want to reload it then (even without any hooks set up), the server crashes. Is this caused by SourceHook, or is there another source?

Thanks!

Edit: Mhh. I've found the answer to my own question, just commenting out anything related to SourceHook, and it doesn't work again.
Does anybody has an idea why the reload fails?

Edit 2: Found it out. Forgot to call ConVar_UnRegister.

Thanks!

API · 09-21-2010 , 14:17 Re: Why can't MM:S be unloaded in VSP mode ?

Just as a side note, I think it would be possible to create a simple VSP for unloading VSP plugins. If I understand BAILOPAN correctly, you just need to clean up the list of ConVars. If you took the unload code for MM:S and adapted the code to fix the ConVar list, there is no reason this couldn't be standalone. Another solution would be building it in for your plugin. It would be cool if someone could at the very least go... yourplugin_unload

Mani · *Last edited by Mani; 09-22-2010 at 07:27.*

As it turns out the JavaVM I'm loading within my plugin can't be unloaded without issues (unless the whole srcds process is killed) so unloading my plugin is a moot point now anyway whether it's via MM : S or VSP.

BAILOPAN · 09-22-2010 , 20:51 Re: Why can't MM:S be unloaded in VSP mode ?

Which JavaVM? (Also, OT, what's it for? ;)

Mani · *Last edited by Mani; 09-23-2010 at 05:37.*

Quote:

Originally Posted by BAILOPAN

Which JavaVM?

It is Sun's JavaVM (technically now Oracle though).

Quote:

Originally Posted by BAILOPAN

(Also, OT, what's it for? ;)

I'm trying to write a plugin architecture where plugins are written purely in Java (similar to SourceMod/VSP). This is a personal and private project at the moment which I'm doing when I feel I actually have some motivation to go back into the hell hole that is Valve. It's a technical challenge more than anything just to see if it can be done.

I should add that this is not MAP2.0, that is a separate development project that is ongoing.

Some thought on Java and how it fits in with the Source engine.
Pros: -

Well proven and mature VM that is extremely fast.
Java is an OO language
Lots of cool tools for developing/debugging Java (Eclipse/Netbeans)
Lots of libraries available for doing more or less anything you can think of

Cons: -

Cannot unload the VM unless the whole process is unloaded.
VM is a bit of a heavyweight in terms of memory footprint.
The Sun JNI interface (C++ -> Java and Java -> C++) sucks to implement and potentially can have high overhead.
Not sure how Garbage collection is going to affect performance although there are a ton of different operating modes.
Relies on the Java Runtime being installed on the server (Think GSPs)

BAILOPAN · 09-23-2010 , 18:45 Re: Why can't MM:S be unloaded in VSP mode ?

You hit the cons on the head - you want realtime collection & no distribution problems. Though I assume there's tons of VMs out there you can pick from.

native interfaces seem to universally suck. if you get can something like ctypes/COM where you define the SDK interfaces in Java (and even better, have the VM JIT through them), it'll be potentially faster, and more maintainable.

this (though not Java) is ultimately the plan for SourceMod 2 if such a thing ever sees the light of day. it's already there, a little, with SDKCall() and gameinfo files. they even get JIT'd. it's just too verbose to reasonably self-host SourceMod itself. this is where an OO language could really win.

Good luck with the project!