Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: 216.86.168.179 is neither permitted
 nor denied by domain of geir@pobox.com)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <e29119980609272141u7c867093kb2567c192df4e045@mail.gmail.com>
References: <79F58F0A-803A-41CD-B6FF-6E92124BD8AB@pobox.com>
 <e29119980609260639m7343c88lafa12e37fed0a087@mail.gmail.com>
 <8F465C98-3CC9-41C4-B7D0-278E431CC289@pobox.com>
 <e29119980609260652u387f1301o13b4ebb8302c33d8@mail.gmail.com>
 <e29119980609260707n31161dd8k59c440ad06c820cf@mail.gmail.com>
 <6928c5160609261024w71006efet3dd613b8b9cd2efc@mail.gmail.com>
 <e29119980609262338n44444c5bvecfc7e04e4320e92@mail.gmail.com>
 <4dd1f3f00609271304s553b30f4k93bf9fdbe60b425e@mail.gmail.com>
 <e29119980609272141u7c867093kb2567c192df4e045@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CA6BC2A6-19B1-43CA-A79A-967F4FFD1B38@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: [drlvm] HARMONY-1582 - invocation API for DRLVM  CHECKPOINT
Date: Thu, 28 Sep 2006 09:02:10 -0400
To: harmony-dev@incubator.apache.org

So where are we here?

On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov wrote:

> On 9/28/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>> On 9/26/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
>> >
>> > On 9/27/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
>> > > (3)
>> > > One more lock is added - hythread_lib_lock. How is that differ  
>> from
>> > > the hythread_global_lock that we already have? Each extra lock  
>> to the
>> > > system may add more possibilities for deadlocks, as well as can
>> > > negatively impact the scalability (unless some of the existing  
>> locks
>> > > are split).
>> > hythread_lib_lock acquires exactly the same lock as
>> > hythread_global_lock. Probably I miss something but we need to be
>> > compatible with IBM threading library now. This library has such
>> > function. That's why I added it. Sounds right?
>>
>>
>> Well,  this sort of, kind of sounds right but not quite.  Its a  
>> little more
>> subtle than being compatible with IBM threading library.  The  
>> first goal is
>> to identify the parts of IBM threading library that are JVM  
>> independent.  It
>> makes sense for DRLVM to be compatible with the independent  
>> parts.   This
>> should be a nobrainer.
>>
>> The parts of IBM threading library that assume a specific JVM  
>> implementation
>> will be a problem.  We will need to find a solution that is  
>> endorsed by all
>> the stakeholders (including J9 folks).  The hythread_global_lock  
>> falls into
>> this category.  For starts, I would like to see a concise  
>> description from
>> the portlib owners on what hythread_global_lock protects, which  
>> locks have
>> to be held before grabbing this lock, are there any restrictions  
>> on what
>> system calls can be made while holding this lock (like sleep or  
>> wait), etc.
>
> Weldon, I completely agree with what your are saying. It's common
> problem of current hythread that should be resolved some how. I just
> go inline with current implementation and added two missing functions.
> Missing these can lead to the same problems as with hythread_exit
> discussed  in another thread "[drlvm] [launcher] Executable hangs".
>
>>
>> To get a better idea what's in the patch.diff, I printed it out.   
>> Its 120+
>> pages.  Quite a big patch!  Most of it looks like straight forward  
>> JNI
>> interface glue.  There are some tricky parts.  I would like to  
>> know the
>> design review process for these parts.  Using grep, I found 20  
>> locations
>> where ...suspend_enable... and ...suspend_disable... have been  
>> added.  And
>> 25 locations where enable/disable have been removed.  Failure in  
>> this logic
>> can lead to incorrect reference pointer enumeration.  These are  
>> probably the
>> hardest bugs to find.  Please tell us who has looked at this code  
>> in depth.
> Only me and you :-) Honetsly I think it happpens now....
>
>> Are there any known design flaws in it?
> I can think of two possible problems we may want to discuss.
> 1) Should native threads have "daemon" status or its completely java
> notion? This is TM related thing.
> 2) Should we attach thread to VM before attaching it to TM by calling
> jthread_atatch OR jthread_attach should callback VM to attach a thread
> to it? I didn't change original design of TM here ...... it implements
> second choice.
>
>>
>> I also notice APIs called tmn_suspend_enable(),  
>> hythread_suspend_enable()
>> -- are these simply different names for the same binary  
>> executible.  Or
>> different binaries that do the same thing??
>
> No, this is not just different names. tm_suspend_enable asserts that
> thread is in disabled state before calling hythread_suspend_enable (in
> debug mode only).
>
> Thanks
> Evgueni
>>
>>
>> --
>> > Weldon Washburn
>> > Intel Middleware Products Division
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org