Re: Next questions

Hi Etienne

A new question:
1) Is there a big/little-endian test in the sablevm configure script, 
which will set a definition?
Because sending jdouble, jfloat over JDWP needs little->big-endian 
conversation on a little-endian
machine. But on a powerpc, no conversation is needed. So we have to look 
on that
in ./src/libjdwp/bytes_conversation.m4.c

>>2) I try to implement the JDWP command 1/5 (VirtualMachine Command Set /
>>TopLevelThreadGroups).
>>Because InelliJ IDEA ask for it. I'll implement it in the same style as
>>CMD_THREAD_GROUP_REFERENCE.
>>Sending only two group id's 1 for system and 2 for user. So I didn't
>>need GetTopThreadGroups in JVMDI.
>>Is that ok like that?
>>    
>>
>
>I think you should as this question to Nizar.  I am not sure if he is
>reading this list, though.  [You have his email, yes?]
>
>  
>
We've always used this email "ahmouda.nizar at courrier.uqam.ca". Is 
that ok?
The last mail we've sent to him was on 30. Sept. 2005. With no reply. Do 
you know
if he've got our mail? Pheraps you could give him a hint to take a look 
on this list?

>>4) If in ./src/libjdwp/transport.c in method 'dt_socket_client(...)' a
>>call to
>>'vm_proper_exit (jdwp, EXIT_FAILURE);' occur, sablevm will cause a
>>deadlock and I have to kill sablevm. vm_proper_exit calls DestroyJavaVM
>>(in ./src/libsablvm/invoke_interface.c) and there is the following code:
>>
>>/* wait for all non-deamon threads to die */
>>while (vm->threads.user != NULL)
>>   {
>>     _svmm_cond_wait (vm->threads.vm_destruction_cond, vm->global_mutex);
>>   }
>>
>>which waits on other threads end. But what's if the other threads are in
>>the following state
>>SVM_THREAD_STATUS_HALTED? On my last debug session it was the
>>StartAppHelper thread.
>>    
>>
>
>Good question.  I have no quick answer.  In the "normal" (i.e.
>non-debugging) mode of  execution, the vm is not responsible of user
>program deadlocks.  In debugging mode, maybe SableVM should simply call
>"exit(some_code)"?  This all depends on the specification of
>"vm_proper_exit" of course.
>
>  
>
It's not a user-program-deadlock, because if we start this program in 
normal mode
(not debug mode), sablevm exit correctly!

Thanks
Martin