Monitor destructor...

Tom Rodriguez Thomas.Rodriguez at Sun.COM
Wed Nov 14 12:12:12 PST 2007


The fact that the names were being lost was recently noticed and a fix 
is coming for it along with some other locking related changes.  I 
believe the fix declares a 64 byte char array in the monitor class and 
copies the name into that.  It's being done that way since the monitors 
want padding around them anyway to reduce false sharing.  I don't know 
what's wrong with your changes but fixing it this way would side step 
your malloc woes.

tom


Peter Helfer wrote:
> Hi all
> 
> I've got some funny error I'm running into: In order to see what 
> deadlocks I'm creating, I extended the Monitor (Mutex) constructor to 
> copy the "name" parameter, instead of keeping it at "UNKNOWN" (as of 
> ClearMonitor).
> 
> class Monitor{
> ...
> char * _name;                    // Name of mutex REMOVED const!
> ..
> };
> static const char* Monitor::_default = "UNKNOWN";
> 
> 
> void Monitor::ClearMonitor (Monitor * m) {
>   m->_owner             = NULL ;
>   m->_snuck             = false ;
>   m->_name              = (char*) Monitor::_default;
>   m->_LockWord.FullWord = 0 ;
>   m->_EntryList         = NULL ;
>   m->_OnDeck            = NULL ;
>   m->_WaitSet           = NULL ;
>   m->_WaitLock[0]       = 0 ;
> }
> 
> Monitor::Monitor() { ClearMonitor(this); }
> 
> Monitor::Monitor (int Rank, const char * name, bool allow_vm_block) {
>   ClearMonitor (this) ;
> #ifdef ASSERT
>   if(name){
>         int len            = strnlen(name,63);
>         _name              = NEW_C_HEAP_ARRAY(char,len+1);
>         assert(_name, "Not enough mem");
>         strncpy(_name, name, len+1);
>   }
>   _allow_vm_block  = allow_vm_block;
>   _rank            = Rank ;
> #endif
> }
> 
> Monitor::~Monitor() {
>   assert 
> ((UNS(_owner)|UNS(_LockWord.FullWord)|UNS(_EntryList)|UNS(_WaitSet)|UNS(_OnDeck)) 
> == 0, "") ;
>   #ifdef ASSERT
>   if(_name != _default){
>         FreeHeap(_name);
>   }
>   #endif
> }
> 
> This is what I am seeing: it only doesnt work in this situation.. The 
> easy work around is to remove the code again, but thats actually not the 
> idea.. :-)
> 
> /home/peterh/workspace/openjdk/control/build/linux-i586-debug/bin/java 
> -client -Xmx881m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m 
> -classpath 
> /home/peterh/workspace/openjdk/control/build/linux-i586-debug/tmp/meta-index 
> BuildMetaIndex -o meta-index *.jar
> VM option 'PermSize=32m'
> VM option 'MaxPermSize=160m'
> ## nof_mallocs = 19744, nof_frees = 12802
> ## memory stomp: byte at 0x8189648 in front of object 0x8189660
> ### previous object (not sure if correct): 0x8189648 (73 bytes)
> ### next object (not sure if correct): 0x8189694 (1700358998 bytes)
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/os.cpp:544
> #
> # An unexpected error has been detected by Java Runtime Environment:
> #
> #  Internal Error 
> (/home/peterh/workspace/openjdk/hotspot/src/share/vm/runtime/os.cpp:544), 
> pid=7146, tid=2209852304
> #  Error: memory stomping error
> #
> 



More information about the hotspot-runtime-dev mailing list