MVM (Was: AttachCurrentThread Crash)

Thu Aug 9 07:28:01 PDT 2007

David Holmes - Sun Microsystems wrote:
> Markus,
>
> There was past on work on hosting multiple VM's within a single VM 
> (with both in process and out-of-process variants). This was based 
> around Isolates and the experimental MVM system.
>
> http://java.sun.com/developer/technicalArticles/Programming/mvm/
>
> I don't know the end result of this work, nor whether some aspect of 
> it is still being developed. (The sunlabs site seems to be having 
> problems right now.)

Yes, I know about MVM quite well, but I also know that the project was 
stopped by Sun. I will not further speculate about the circumstances 
since actually it is off-topic, but since you (as a Sun employee) 
started this thread, here is what it looks like to me (as a non-Sun 
employee and Senior Architect). As ever, I mixed the facts with pure 
fantasy (in lack of Sun telling the truth about it), irony and sarcasm. :-)

<conspiracy-theory>

* Some Sun PhDs of Sun Labs, including Dr. Grzegorz Czajkowski 
(http://research.sun.com/people/czajk/), after several years finally did 
the unbelievable and found the holy desktop grail -- and where naive 
enough to tell the world about it, despite better knowing of that it 
will make the Java Pontifex really, really angry (For what shall someone 
need Solaris if the JVM becomes an OS, and what to tell Bill Gates now 
that finally there is that secret contract between the Windows Company 
and Sun, which I think could read like: "We give you money for not 
making Java better than dotnet"?). 
(http://java.sun.com/developer/technicalArticles/Programming/mvm/ )

* So the Java Church sent its best secret agent, Chet Haase, to convince 
the peoples of the world that Doc Greg did not really find the holy 
desktop grail but in fact is just a heretic and his ideas are all just 
blasphemous lies 
(http://weblogs.java.net/blog/chet/archive/2005/06/mmmmmm_vm.html).

* But People didn't believe Agent Chet. They still (and even more) 
trusted in Doc Greg. Actually they started to lapidate Agent Chet in his 
own blog (See Comments section on 
http://weblogs.java.net/blog/chet/archive/2005/06/mmmmmm_vm.html).

* Since the people still wanted to have the holy desktop grail getting 
added as a new essential part of the next release of the Java Bible 
(http://www.jcp.org/en/jsr/detail?id=121 and 
http://www.jcp.org/en/jsr/detail?id=284), the pope wrote a bull of 
excommunication: Doc Greg had to leave the church and now works for some 
Java sect, called "The Googleans".

* Will the same happen to Project Looking Glass 
(http://www.sun.com/software/looking_glass), since it is a possible 
thread to the Solaris Desktop and Microsoft's Areo...? Maybe that is the 
reason why we didn't hear about Looking Glass for so long...?

* Also I now fear for my own life, since I want to reanimate the JDIC 
project (that seems to be some kind of dead, see the "Is this project 
dead?" discussion thread in the JDIC mailing list) with some essential 
contributions like this one, which might be a thorn in the eyes of some 
Java Cardinals...

* Actually now that the revolution by the Java community was successful 
and Java is open sourced finally, and all power is by the democratic 
organization of JCP.org., it keeps beeing a thrilling item how this 
story ends.

</conspiracy-theory>

But back to truth, in fact the Isolation API would be a wonderful 
solution to my problem. But since there is no Isolation API in the JRE 
right now, and it is not even planned to be part of JDK 7 or 8 (at least 
I did not read about that somewhere), it is not helping me much. Either 
I have to change my product to be no more in-process, or some hotspot 
programmers fix that ugly bug. So, we are where we still had been. :-)

Have Fun
Markus
>
> Regards,
> David Holmes
>
> Markus KARG said the following on  9/08/07 07:12 PM:
>> Steve Bohne wrote:
>>> Very interesting project.
>> Thank you. In fact, the target of the project is to provide a general 
>> solution that allows to write Shell Extensions in pure Java (without 
>> further knowledge of the native desktop API), and add it to either 
>> JDIC and / or OpenJDK. The Java peer of that shall be a simple API 
>> that can not only be implemented for Windows (as I do it right now) 
>> but hopefully will be implemented by others (or Sun?) for KDE, Gnome, 
>> MacOS etc. Integrating Java deeply into the desktop is one of my key 
>> interests and I wonder why there is not yet something like that already.
>>> When your DLL gets unloaded, does jvm.dll also get unloaded? As you 
>>> mentioned, if jvm.dll is getting loaded twice, even sequentially, 
>>> this might cause problems.  (Yes, it's a known limitation of 
>>> embedding a JVM in another application. Don't know of any current 
>>> activity to work on a solution for this issue, but submitted patches 
>>> will be carefully considered. :))
>> Unfortunately I am not understanding the jvm.dll source code well 
>> enough to provide a patch, but that limitation really is a huge 
>> problem for embedding projects like this one (which, BTW, are needed 
>> for better acceptance of Java by the end users of the applications).
>>
>> I tried three things: (a) Keep the JavaVM* pointer and do not load a 
>> second time, (b) Always LoadLibrary but never unload, (c) Always 
>> LoadLibrary and FreeLibrary even in the same single method. In fact, 
>> all three ways of handling procude the same problem: Everything works 
>> well (since Windows kindly maps the DLL to the same memory region 
>> ever as it seems), but AttachCurrentThread crashs down.
>>> Did you try using explicit linking (use LoadLibrary, GetProcAddress, 
>>> etc) for jvm.dll so it won't automatically get unloaded when your 
>>> DLL does?
>> Yes, see above.
>>> Are you able to catch the crash in a debugger and provide a symbolic 
>>> stack trace? I have a feeling it will reflect the limitation 
>>> mentioned above, so it may not lead to a solution, but it might be 
>>> educational.
>> Unfortunately I do not know how. I have no full C++ development 
>> environment but just work with the free Microsoft Compiler plus a 
>> text editor.
>>> Steve
>>>
>>> P.S. Be careful embedding Java (or any single instance runtime) in a 
>>> shell extension: 
>>> http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx.  Many 
>>> of the limitations mentioned here for CLR will also apply to Java.
>> Yes I thought about that right from the start. Maybe I will change my 
>> architecture to not use JNI in the Shell Extension, but to instead 
>> call an out-of-process COM server implementation (a server EXE) that 
>> drives JNI instead, but I did not yet do it because I feared for the 
>> performance penalties of crossing process borders.
>>
>> It is really a pity that JNI does not allow to create more than one 
>> VM actually, and I think a lot of JNI users would be really happy 
>> when fixing that. Maybe one day some kind programmer provides that. :-)
>>
>> Thanks a lot
>> Markus
>>>
>>> Markus KARG wrote:
>>>
>>>> Hello Hotspot Community,
>>>>
>>>> I experienced a problem when using JNI and since nobody else was 
>>>> able to help me since months, and since it looks like a bug in the 
>>>> jvm.dll, you are my last chance. :-)
>>>>
>>>> In fact I am an experienced JNI user so my question is not about 
>>>> JNI itself but about a very complex case that makes jvm.dll crash 
>>>> down. So I want to discuss with you how we can solve it -- either 
>>>> by working around it in my code, or by adding a fix to the Hotspot 
>>>> VM (which seems to be the cause of the problems).
>>>>
>>>> I am writing a DLL in Windows XP that itself is a plugin to the 
>>>> desktop, a.k.a "Shell Extension". The DLL itself runs really stable 
>>>> (in fact I have drilled down so far that it actually does nothing 
>>>> anymore now, so I am pretty sure there is no bug in it since there 
>>>> is no more "real" code in it besides creating the Java VM). 
>>>> explorer.exe (i. e. the desktop process of Windows) loads the DLL, 
>>>> executes my code, and unloads the DLL then. So far, so good, works 
>>>> pretty well.
>>>>
>>>> But the same Windows process then loads my DLL once more, and 
>>>> executes it again (just as it did before). My DLL, you can imagine, 
>>>> is using JNI to call some Java code. Certainly I was clever enough 
>>>> not to create a VM twice, since I certainly know that both is 
>>>> impossible, either creating two VMs in the same process, or to try 
>>>> to create a VM after the previous VM was deleted (which I think is 
>>>> a bug, but anyways, that is not the point here).
>>>>
>>>> So I am checking first wheter there is a VM already using 
>>>> JNI_GetCreatedJavaVMs which returns the number of 1 and a pointer 
>>>> to the JavaVM. Great. That works pretty well. But if I now try to 
>>>> call AttachCurrentThread to get a pointer to the Env, then the 
>>>> desktop totally crashs down, telling me that I tried to execute 
>>>> code that actually is data (I switched off Data Execution 
>>>> Prevention then, but now it crashs down without ANY further note, 
>>>> so it is not a real help). So why did that happen?
>>>>
>>>> I looked at the source code of the JVM and it seems as if it uses 
>>>> global variables very heavily in the JNI source files. I could 
>>>> imagine that in fact one of those pointers now (after explorer 
>>>> unloaded and reloaded my DLL in the same process) point to a memory 
>>>> page that is marked as "data" but not as "code", so when using the 
>>>> function pointer, windows crashs down (since the memory pointed to 
>>>> is presumably no more part of the process's memory map).
>>>>
>>>> Please help me. I do not have any idea how to fix that. As a 
>>>> workaround I told Windows not to ever unload my DLL (what is 
>>>> working), but that certainly is just a bad hack. The real solution 
>>>> must be to convince jvm.dll to attach the thread without crashing 
>>>> down.
>>>>
>>>> If needed, I can provide an "at most simple" project that proofs 
>>>> the behaviour on any Windows machine (without seriously damaging it).
>>>>
>>>> Thanks!
>>>> Markus
>>>>
>>>
>>
>>
>

-- 
http://www.xing.com/go/invita/58469

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3505 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20070809/c742f205/attachment.bin 