harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Date Mon, 09 Oct 2006 14:02:18 GMT
btw, why are there so many warnings?  I'm not comfortable with having  
to suppress them - I'd rather fix them...

On Oct 9, 2006, at 9:49 AM, Geir Magnusson Jr. wrote:

> sure - I'll redo the whole thing from clean...
>
>
> On Oct 9, 2006, at 9:45 AM, Evgueni Brevnov wrote:
>
>> BTW, could you verify the right patch for tests was used? It  
>> should be
>> tests.final.2.patch...... Sorry for the mess with patches....
>>
>> Evgueni
>>
>> On 10/9/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
>>> I put debug printing into test_ti_instrum.c and attached it to JIRA.
>>> Could you run it on your machine and send me console output.
>>>
>>> Evgueni
>>>
>>> On 10/9/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>> > I keep getting a failure when running the tests -
>>> >
>>> > test_jthread_get_all-threads failling the assertion at
>>> > test_ti_instrum.c:80
>>> >
>>> > geir
>>> >
>>> > On Oct 8, 2006, at 7:19 AM, Evgueni Brevnov wrote:
>>> >
>>> > > While running cunit on Linux it turned out one test case  
>>> fails some
>>> > > time. The fix is in tests.final.2.patch.
>>> > >
>>> > > So the last versions to be committed:
>>> > > invocation_api.final.patch
>>> > > build.final.2.patch
>>> > > tests.final.2.patch
>>> > >
>>> > > Evgueni
>>> > >
>>> > >
>>> > > On 10/8/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
>>> > >> I mahaged to resolve the problem on Linux.... will update
>>> > >> build.final.patch with build.final.2.patch in a while
>>> > >>
>>> > >> On 10/8/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
>>> > >> > Hi,
>>> > >> >
>>> > >> > Oh! Ooh! I did that..... I passed cunit, somke, kernel  
>>> tests on
>>> > >> > Windows and smoke, kernel tests on Linux. Unfortunately I  
>>> failed to
>>> > >> > link cunit tests on Linux so far. So I disabled cunit on  
>>> Linux
>>> > >> until
>>> > >> > the problem is solved. I believe it is acceptable as short  
>>> term
>>> > >> > solution. I found several problems in cunit tests. I will  
>>> come
>>> > >> up with
>>> > >> > my findings later (not today).
>>> > >> >
>>> > >> > Use latest patches from HARMONY-1582. They are marked as  
>>> final.
>>> > >> There
>>> > >> > are three patches. One for build module, one for cunit  
>>> tests and
>>> > >> one
>>> > >> > for VM itself.
>>> > >> >
>>> > >> > Thanks
>>> > >> > Evgueni
>>> > >> >
>>> > >> >
>>> > >> > On 10/6/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>> > >> > > Nooooooo!  LOL
>>> > >> > >
>>> > >> > > I'm here waiting - This will unblock a whole bunch of  
>>> things :)
>>> > >> > >
>>> > >> > > Thanks for the effort
>>> > >> > >
>>> > >> > > Evgueni Brevnov wrote:
>>> > >> > > > Geir,
>>> > >> > > >
>>> > >> > > > That's terrible. We have power outage....servers are  
>>> down. I
>>> > >> can't
>>> > >> > > > send the patches now.... will do it tomorrow
>>> > >> > > >
>>> > >> > > > Evgueni
>>> > >> > > > On 10/5/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>> > >> > > >> woo hoo!  here we go...
>>> > >> > > >>
>>> > >> > > >>
>>> > >> > > >> Andrey Chernyshev wrote:
>>> > >> > > >> > Hi Evgueni,
>>> > >> > > >> >
>>> > >> > > >> > On 10/4/06, Evgueni Brevnov  
>>> <evgueni.brevnov@gmail.com>
>>> > >> wrote:
>>> > >> > > >> >> Hi All,
>>> > >> > > >> >>
>>> > >> > > >> >> I have attached updated patch to the JIRA. It should
>>> > >> resolve remain
>>> > >> > > >> >> concerns. Andrey, could you give a green light now?
>>> > >> > > >> >
>>> > >> > > >> > Thanks for updating the patch! I agree it it can be
>>> > >> committed, at
>>> > >> > > >> > least signatures look good. 5 revisions seem like more
>>> > >> than enough :).
>>> > >> > > >> > Anyways, I think the remaining issues can be resolved
>>> > >> with additional
>>> > >> > > >> > patches. Thanks again for the good work and your  
>>> patience.
>>> > >> > > >> >
>>> > >> > > >> > Thanks,
>>> > >> > > >> > Andrey.
>>> > >> > > >> >
>>> > >> > > >> >>
>>> > >> > > >> >> Thanks
>>> > >> > > >> >> Evgueni
>>> > >> > > >> >>
>>> > >> > > >> >> On 10/4/06, Evgueni Brevnov  
>>> <evgueni.brevnov@gmail.com>
>>> > >> wrote:
>>> > >> > > >> >> > Andrey,
>>> > >> > > >> >> >
>>> > >> > > >> >> > I see your points. I think both approaches have
>>> > >> advantages and
>>> > >> > > >> >> > disadvantages. I think it is quite hard to say  
>>> which
>>> > >> approach is
>>> > >> > > >> >> > better until we play with one VM only. I still feel
>>> > >> like introducing
>>> > >> > > >> >> > one more dependence is better than spreading code
>>> > >> which deals with
>>> > >> > > >> >> > attachment among VM and TM. We really get stuck.  
>>> OK,
>>> > >> just because I
>>> > >> > > >> >> > want to move forward I will do required changes  
>>> to remove
>>> > >> > > >> >> > vm_create_jthread from TM. I believe that will  
>>> resolve
>>> > >> all our
>>> > >> > > >> >> > disagreements and the patch will be applied soon.
>>> > >> > > >> >> >
>>> > >> > > >> >> >
>>> > >> > > >> >> > Thanks
>>> > >> > > >> >> > Evgueni.
>>> > >> > > >> >> >
>>> > >> > > >> >> > On 10/4/06, Andrey Chernyshev
>>> > >> <a.y.chernyshev@gmail.com> wrote:
>>> > >> > > >> >> > > On 10/3/06, Evgueni Brevnov
>>> > >> <evgueni.brevnov@gmail.com> wrote:
>>> > >> > > >> >> > > > On 10/3/06, Andrey Chernyshev
>>> > >> <a.y.chernyshev@gmail.com> wrote:
>>> > >> > > >> >> > > > > On 10/2/06, Evgueni Brevnov
>>> > >> <evgueni.brevnov@gmail.com> wrote:
>>> > >> > > >> >> > > > > > Andrey,
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > > > Just to be clear.... I agree with you it  
>>> is more
>>> > >> > > >> convenient if
>>> > >> > > >> >> > > > > > jthread_create takes JNIEnv instead of  
>>> JavaVM. It
>>> > >> > > >> reflects that
>>> > >> > > >> >> > > > > > current thread has been attached  
>>> already. Do
>>> > >> you think it
>>> > >> > > >> >> makes sense
>>> > >> > > >> >> > > > > > to get rid of JNIEnv and use
>>> > >> jthread_get_JNI_env in that
>>> > >> > > >> case?
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > The jthread_* layer is designed like if it  
>>> were
>>> > >> a regular JNI
>>> > >> > > >> >> > > > > application which is meant to be called  
>>> from the
>>> > >> Java code,
>>> > >> > > >> hence
>>> > >> > > >> >> > > > > every function on that layer receives  
>>> JNIenv. We
>>> > >> can probably
>>> > >> > > >> >> get rid
>>> > >> > > >> >> > > > > of the JNEnv parameter for jthread_*  
>>> functions,
>>> > >> assuming that
>>> > >> > > >> >> TM can
>>> > >> > > >> >> > > > > always extract JNIenv for the current  
>>> thread with
>>> > >> > > >> >> > > > > jthread_get_JNI_env().
>>> > >> > > >> >> > > > > My only concern  would be the performance  
>>> - once
>>> > >> the JNIenv is
>>> > >> > > >> >> already
>>> > >> > > >> >> > > > > known for the native part of the kernel  
>>> classes
>>> > >> impl, it
>>> > >> > > >> must be
>>> > >> > > >> >> > > > > cheaper to pass JNIEnv to TM as an extra
>>> > >> parameter rather than
>>> > >> > > >> >> extract
>>> > >> > > >> >> > > > > it from the TLS again.
>>> > >> > > >> >> > > > > Other than that, I see no strong  
>>> advantages in
>>> > >> keeping JNIEnv
>>> > >> > > >> >> parameter.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > > Regarding jthread_attach. I still didn't  
>>> get
>>> > >> your point....
>>> > >> > > >> >> Clarify it
>>> > >> > > >> >> > > > > > please if you think jhread_attach should be
>>> > >> modified.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > Sorry for being not clear: I think for
>>> > >> jthread_attach, we have
>>> > >> > > >> >> two options:
>>> > >> > > >> >> > > > > 1) Make JNIEnv input parameter - it must  
>>> be new
>>> > >> JNIEnv that VM
>>> > >> > > >> >> > > > > pre-allocates for the new Java thread.
>>> > >> jthread_attach
>>> > >> > > >> would just
>>> > >> > > >> >> > > > > associate it with the current thread.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > 2) Obtain JNIEnv via vm_attach() callback. In
>>> > >> this case, if
>>> > >> > > >> >> > > > > vm_attach() callback implementation needs to
>>> > >> know for which
>>> > >> > > >> >> JavaVM new
>>> > >> > > >> >> > > > > JNIenv has to be allocated, then we'll  
>>> need to
>>> > >> add JavaVM as
>>> > >> > > >> >> input
>>> > >> > > >> >> > > > > parameter for jthread_attach().
>>> > >> > > >> >> > > > > I think both options should be fine, (1)  
>>> would
>>> > >> probably
>>> > >> > > >> keep TM
>>> > >> > > >> >> > > > > interface a bit lighter, though (2) may look
>>> > >> more closer to
>>> > >> > > >> >> the JNI
>>> > >> > > >> >> > > > > invocation API idea.
>>> > >> > > >> >> > > > > So I think adding JavaVM specifically for
>>> > >> jthread_attach
>>> > >> > > >> may make
>>> > >> > > >> >> > > > > sense given the explanation you provided  
>>> earlier.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > The concern I would have regarding the  
>>> proposed
>>> > >> jthread_attach
>>> > >> > > >> >> > > > > implementation is a call to  
>>> vm_create_jthread()
>>> > >> - this call
>>> > >> > > >> >> introduces
>>> > >> > > >> >> > > > > an extra dependency of TM on vmcore that I'd
>>> > >> prefer to be
>>> > >> > > >> >> avoided. In
>>> > >> > > >> >> > > > > the original version, jthread_attach() was
>>> > >> taking jthread
>>> > >> > > >> >> argument of
>>> > >> > > >> >> > > > > the already prepared j.l.Thread.
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > I understand your concern. Unfortunately I  
>>> don't
>>> > >> see what we
>>> > >> > > >> can do
>>> > >> > > >> >> > > > here. Let me explain. In the beginning you  
>>> have an
>>> > >> unattached
>>> > >> > > >> >> native
>>> > >> > > >> >> > > > thread. To be able to call java code (which is
>>> > >> required for
>>> > >> > > >> >> > > > constructing j.l.Thread instance) the thread
>>> > >> should be attached
>>> > >> > > >> >> first.
>>> > >> > > >> >> > > > To be specific it should be attached to VM by
>>> > >> calling vm_attach
>>> > >> > > >> >> which
>>> > >> > > >> >> > > > will return a valid JNIEnv It is valid to  
>>> use JNI
>>> > >> from that
>>> > >> > > >> moment.
>>> > >> > > >> >> > > > Obtained JNIEnv can be used to execute java  
>>> code
>>> > >> and create
>>> > >> > > >> >> j.l.Thread
>>> > >> > > >> >> > > > instance. Since we do vm_attach in  
>>> jthread_attach
>>> > >> we need to do
>>> > >> > > >> >> > > > vm_create_jthread inside jthread_atach as well.
>>> > >> > > >> >> > > > Of course it can be an alternative to do  
>>> vm_attach
>>> > >> and
>>> > >> > > >> >> > > > vm_create_jthread outside of TM right before
>>> > >> jthread_attach.
>>> > >> > > >> >> Sure it
>>> > >> > > >> >> > > > will reduce one dependence between VM and  
>>> TM. But
>>> > >> it seems like
>>> > >> > > >> >> > > > artificial action for me just because of
>>> > >> dependency....
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > Why do you think it is artificial? I would rather
>>> > >> prefer not to
>>> > >> > > >> throw
>>> > >> > > >> >> > > vm_attach event from the jthread_attach() call at
>>> > >> all than to add
>>> > >> > > >> >> > > extra dependency. The idea of jthread layer is a
>>> > >> Java face to
>>> > >> > > >> >> > > hythread, it is meant to know either a little or
>>> > >> nothing about the
>>> > >> > > >> >> > > rest of VM. It may be logical to throw vm_attach
>>> > >> call from the
>>> > >> > > >> newly
>>> > >> > > >> >> > > created thread, because there is no other way  
>>> to let
>>> > >> know VM
>>> > >> > > >> the new
>>> > >> > > >> >> > > thread is created. VM attach is a different  
>>> case -
>>> > >> VM already
>>> > >> > > >> knows
>>> > >> > > >> >> > > about new Java thread at the time of the
>>> > >> AttachCurrentThread call.
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > > Do you think it makes sense to replace a  
>>> single
>>> > >> jthread
>>> > >> > > >> >> parameter with
>>> > >> > > >> >> > > > > a variety of stuff (like thread group,  
>>> name)? It
>>> > >> seems the
>>> > >> > > >> only
>>> > >> > > >> >> > > > > purpose of at these args is to be passed  
>>> back to
>>> > >> VM for
>>> > >> > > >> >> > > > > vm_jthread_create(). I would suggest to  
>>> change
>>> > >> this and try
>>> > >> > > >> doing
>>> > >> > > >> >> > > > > either of:
>>> > >> > > >> >> > > > > 1) Make signature of jthread_attach with 3  
>>> args,
>>> > >> JavaVM,
>>> > >> > > >> >> jthread and the daemon.
>>> > >> > > >> >> > > > Why do you want to pass daemon to TM but  
>>> thread's
>>> > >> name and
>>> > >> > > >> >> group. Just
>>> > >> > > >> >> > > > because current TM doesn't need such  
>>> information?
>>> > >> What if it is
>>> > >> > > >> >> > > > required to get thread name later? Say by  
>>> introducing
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > I imagine you need a daemon attribute since  
>>> the TM
>>> > >> is still
>>> > >> > > >> managing
>>> > >> > > >> >> > > the thread daemonality. TM is not managing thread
>>> > >> name and group -
>>> > >> > > >> >> > > they are all kept on the Java level, hence  
>>> passing
>>> > >> them may be
>>> > >> > > >> >> > > excessive.
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > > jthread_get_name... What will you do in that  
>>> case?
>>> > >> Let me
>>> > >> > > >> guess you
>>> > >> > > >> >> > > > will call j.l.Thread.getName. Right. Ok! In  
>>> that
>>> > >> case I see no
>>> > >> > > >> >> > > > problems to call j.l.Thread.isDaemon. Do you
>>> > >> agree? So it
>>> > >> > > >> doesn't
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > As I suggested earlier, the best way to handle
>>> > >> daemonality would
>>> > >> > > >> >> > > probably be in pure Java - in j.l.Thread (or
>>> > >> > > >> j.l.VMThreadManager) or
>>> > >> > > >> >> > > whatever. You already lifted it up to the jthread
>>> > >> level, but
>>> > >> > > >> what if
>>> > >> > > >> >> > > we can go a little bit higher...
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > > seems to be a good design to pass only part  
>>> of the
>>> > >> > > >> information to
>>> > >> > > >> >> > > > jthread_atach. Lets look at the signature of
>>> > >> > > >> >> AttachCurrentThread. It
>>> > >> > > >> >> > > > takes exactly these three parameters (daemon,
>>> > >> name, group)
>>> > >> > > >> >> passed as a
>>> > >> > > >> >> > > > structure. I was thinking about having  
>>> exactly the
>>> > >> same
>>> > >> > > >> >> structure as
>>> > >> > > >> >> > > > third parameter of jthread_attach but it  
>>> occured
>>> > >> to be more
>>> > >> > > >> >> convinient
>>> > >> > > >> >> > > > to pass them seperatly. Although I don't see
>>> > >> strong reasons
>>> > >> > > >> against
>>> > >> > > >> >> > > > having a structure a third parameter.
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > I see. Acually, I would love to keep the
>>> > >> jthread_attach func-ty at
>>> > >> > > >> >> the
>>> > >> > > >> >> > > minimum level which will be needed to handle the
>>> > >> only data that TM
>>> > >> > > >> >> > > should be aware of. We need a formal boundary
>>> > >> between jthread
>>> > >> > > >> layer
>>> > >> > > >> >> > > and vmcore (otherwise jthread won't have a  
>>> much of
>>> > >> sense, one may
>>> > >> > > >> >> > > consider it just as a convenience set of  
>>> functions
>>> > >> in vmcore which
>>> > >> > > >> >> are
>>> > >> > > >> >> > > doing something with threading).
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > > 2) Move the implementation of  
>>> vm_create_jtrhead
>>> > >> () to
>>> > >> > > >> >> > > > > thread_java_basic.c - could it be written in
>>> > >> pure JNI without
>>> > >> > > >> >> using
>>> > >> > > >> >> > > > > internal VM API like class_alloc_new_object 
>>> ()?
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > Yes, this can be done but it doesn't fix the
>>> > >> problem. You still
>>> > >> > > >> >> need
>>> > >> > > >> >> > > > to know about internal constructor of  
>>> j.l.Thread
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > That's bad. Given what you said, now it seems  
>>> that
>>> > >> the most
>>> > >> > > >> >> preferable
>>> > >> > > >> >> > > sequence for AttachCurrentThread impl still  
>>> would be
>>> > >> like:
>>> > >> > > >> >> > > JNIEnv = vm_attach();
>>> > >> > > >> >> > > jthread = create_jthread(JNIenv)
>>> > >> > > >> >> > > jthread_attach(JNIEnv, jthread) // stores  
>>> JNIEnv and
>>> > >> Hythread into
>>> > >> > > >> >> > > TLS, doesn't call vm_attach any longer.
>>> > >> > > >> >> > > - this is almost what we had from the  
>>> beginning...
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > Thanks,
>>> > >> > > >> >> > > Andrey.
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > > Thanks
>>> > >> > > >> >> > > > Evgueni
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > Thanks,
>>> > >> > > >> >> > > > > Andrey.
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > > > Thank you
>>> > >> > > >> >> > > > > > Evgueni
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > > > On 10/2/06, Evgueni Brevnov
>>> > >> <evgueni.brevnov@gmail.com>
>>> > >> > > >> wrote:
>>> > >> > > >> >> > > > > > > On 9/29/06, Andrey Chernyshev
>>> > >> <a.y.chernyshev@gmail.com>
>>> > >> > > >> >> wrote:
>>> > >> > > >> >> > > > > > > > On 9/29/06, Evgueni Brevnov
>>> > >> <evgueni.brevnov@gmail.com>
>>> > >> > > >> >> wrote:
>>> > >> > > >> >> > > > > > > > > Artem,
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Thank you for your feedback....  
>>> find my
>>> > >> inlined.....
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > On 9/29/06, Artem Aliev
>>> > >> <artem.aliev@gmail.com> wrote:
>>> > >> > > >> >> > > > > > > > > > Evgueni,
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > I got most of your changes, but  
>>> still
>>> > >> disagree
>>> > >> > > >> with all
>>> > >> > > >> >> > > > > > > > > > hythread/jthread interface changes.
>>> > >> Could leave
>>> > >> > > >> >> interface unchanged.
>>> > >> > > >> >> > > > > > > > > > See following possible  
>>> solutions, that
>>> > >> could solve
>>> > >> > > >> >> the same problems
>>> > >> > > >> >> > > > > > > > > > without interface changes.
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 1) daemon attribute is a java
>>> > >> specific. (Andrey
>>> > >> > > >> >> mentioned this already).
>>> > >> > > >> >> > > > > > > > > >   Could you please move it back. to
>>> > >> the jthread
>>> > >> > > >> >> layer. It is better
>>> > >> > > >> >> > > > > > > > > > to rename
>>> > >> > > >> >> > > > > > > > > >
>>> > >> hythread_wait_for_all_nondaemon_threads() to
>>> > >> > > >> >> > > > > > > > > >  
>>> jthread_wait_for_all_nondaemon_threads().
>>> > >> > > >> >> > > > > > > > > Ok, I see no problems to move  
>>> "daemon"
>>> > >> to java layer.
>>> > >> > > >> >> In that case:
>>> > >> > > >> >> > > > > > > > > 1) I will move
>>> > >> > > >> >> hythread_wait_for_all_nondaemon_threads() from
>>> > >> > > >> >> > > > > > > > > thread_init.c to one which implements
>>> > >> java layer.
>>> > >> > > >> >> > > > > > > > > 2) I will move daemon field from
>>> > >> HyThread structure.
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Agree?
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > Sounds good to me.
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > OK, will do that.
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 2)  JavaVM could be retrieved  from
>>> > >> JNIEnv by
>>> > >> > > >> >> jni_get_java_vm(). So
>>> > >> > > >> >> > > > > > > > > > let the jthread_create() and  
>>> others to
>>> > >> use JNIEnv
>>> > >> > > >> >> (that is passed from
>>> > >> > > >> >> > > > > > > > > > java native method).
>>> > >> > > >> >> > > > > > > > > > The vm_attach could get old JNI env
>>> > >> and create new
>>> > >> > > >> >> one for the new thread.
>>> > >> > > >> >> > > > > > > > > > The first JNIEnv is created in
>>> > >> CreateVM call and
>>> > >> > > >> >> could be passed to
>>> > >> > > >> >> > > > > > > > > > the first thread at startup.
>>> > >> > > >> >> > > > > > > > > No, no, no. I completely disagree  
>>> with
>>> > >> that!!! Why do
>>> > >> > > >> >> you like JNIEnv
>>> > >> > > >> >> > > > > > > > > but JavaVM. Why do you think that
>>> > >> passing JavaVM
>>> > >> > > >> >> instead of JNIEnv
>>> > >> > > >> >> > > > > > > > > makes TM less modular? I don't see  
>>> any
>>> > >> difference
>>> > >> > > >> >> here.... It seems
>>> > >> > > >> >> > > > > > > > > for me like a big big hack to grab
>>> > >> JNIEnv from another
>>> > >> > > >> >> thread and pass
>>> > >> > > >> >> > > > > > > > > it to jthread_attach to perform
>>> > >> operations in the
>>> > >> > > >> >> current thread.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > TM needs to know JNIEnv, mainly for
>>> > >> managing the
>>> > >> > > >> >> references to
>>> > >> > > >> >> > > > > > > > objects, throwing exceptions and  
>>> calling
>>> > >> run() method of
>>> > >> > > >> >> a new thread.
>>> > >> > > >> >> > > > > > > > JNI spec proposes that JNIEnv is valid
>>> > >> within the given
>>> > >> > > >> >> thread, this
>>> > >> > > >> >> > > > > > > > is why TM holds the JNIEnv pointer  
>>> at the
>>> > >> moment. This
>>> > >> > > >> >> is why TM likes
>>> > >> > > >> >> > > > > > > > the JNIEnv.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > Having the JNIEnv, one is able to get
>>> > >> JavaVM but not
>>> > >> > > >> >> vise versa. This
>>> > >> > > >> >> > > > > > > > is why TM doesn't like the JavaVM :)
>>> > >> > > >> >> > > > > > > I see your point. Only one note this  
>>> is true
>>> > >> for already
>>> > >> > > >> >> attached threads...
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > I agree with you that there is a design
>>> > >> flaw that the
>>> > >> > > >> >> JNIEnv is copied
>>> > >> > > >> >> > > > > > > > from the parent thread to a child  
>>> thread
>>> > >> during thread
>>> > >> > > >> >> creation. I
>>> > >> > > >> >> > > > > > > > think it could be resolved via  
>>> vm_attach()
>>> > >> hook - with
>>> > >> > > >> >> this event, VM
>>> > >> > > >> >> > > > > > > > might tell the TM what the JNIEnv  
>>> pointer
>>> > >> for new thread
>>> > >> > > >> >> should be. I
>>> > >> > > >> >> > > > > > > > think you did that by extending the
>>> > >> vm_attach() call
>>> > >> > > >> >> with the JNIEnv**
>>> > >> > > >> >> > > > > > > > argument.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > What is not completely clear is, why do
>>> > >> you have to pass
>>> > >> > > >> >> the JavaVM
>>> > >> > > >> >> > > > > > > > forth and back, once from VM to TM, and
>>> > >> then back from
>>> > >> > > >> >> TM to VM again?
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > If you need to know in jthread_attach,
>>> > >> which particular
>>> > >> > > >> >> VM vm_attach()
>>> > >> > > >> >> > > > > > > > event is coming from, you could have
>>> > >> vm_attach like
>>> > >> > > >> >> > > > > > > > vm_attach(JNIEnv* currentThreadEnv,   
>>> JNIEnv**
>>> > >> > > >> >> newThreadEnv).
>>> > >> > > >> >> > > > > > > I'm a little bit confused.....Current  
>>> thread
>>> > >> hasn't been
>>> > >> > > >> >> attached yet.
>>> > >> > > >> >> > > > > > > So there is no JNIEnv for it yet. How  
>>> it can
>>> > >> be passed as
>>> > >> > > >> >> the first
>>> > >> > > >> >> > > > > > > parameter to vm_attach()?
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > > Then you will be always able to get the
>>> > >> JavaVM from the
>>> > >> > > >> >> JNIEnv.
>>> > >> > > >> >> > > > > > > > The only difference is that you are
>>> > >> currently doing
>>> > >> > > >> >> JNIEnv->JavaVM
>>> > >> > > >> >> > > > > > > > conversion in the VMThreadManager,  
>>> but why
>>> > >> can't you
>>> > >> > > >> >> just do this in
>>> > >> > > >> >> > > > > > > > vm_attach() without changing the  
>>> interface
>>> > >> of the TM?
>>> > >> > > >> >> > > > > > > > So far JavaVM really looks like an  
>>> extra
>>> > >> knowledge that
>>> > >> > > >> >> TM doesn't
>>> > >> > > >> >> > > > > > > > have to be aware of.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > > Moreover there is no JNIEnv when main
>>> > >> thread attaches
>>> > >> > > >> >> to VM. So we
>>> > >> > > >> >> > > > > > > > > should either keep it as is or change
>>> > >> original design
>>> > >> > > >> >> of TM and attach
>>> > >> > > >> >> > > > > > > > > thread to VM before attaching it  
>>> to TM.
>>> > >> In that case
>>> > >> > > >> >> we will have
>>> > >> > > >> >> > > > > > > > > valid JNIEnv which can be passed to
>>> > >> jthread_atatch. We
>>> > >> > > >> >> need to think
>>> > >> > > >> >> > > > > > > > > over it twice before changing  
>>> something....
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > Right. For jthread_attach, JNIenv  
>>> needs to
>>> > >> be changed
>>> > >> > > >> >> from being input
>>> > >> > > >> >> > > > > > > > parameter to being the output  
>>> parameter.
>>> > >> The way how
>>> > >> > > >> >> JNIenv is
>>> > >> > > >> >> > > > > > > > obtained by TM should be vm_attach()  
>>> event.
>>> > >> > > >> >> > > > > > > OK, JNIEnv is output parameter. And it
>>> > >> obtained by
>>> > >> > > >> >> vm_attach(). This
>>> > >> > > >> >> > > > > > > is exactly like I do in the patch. What I
>>> > >> don't understand
>>> > >> > > >> >> is how
>>> > >> > > >> >> > > > > > > jthread_attach knows to which VM the  
>>> thread
>>> > >> should be
>>> > >> > > >> >> attached? Do you
>>> > >> > > >> >> > > > > > > suggest calling vm_attach first to create
>>> > >> JNIEnv it pass
>>> > >> > > >> >> it to
>>> > >> > > >> >> > > > > > > jthread_attach?
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 4) Original classlib hythread do  
>>> not use
>>> > >> > > >> >> hythread_library_t in arguments,
>>> > >> > > >> >> > > > > > > > > > It uses following code:
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >  hythread_library_t lib =  
>>> GLOBAL_DATA
>>> > >> > > >> >> (default_library);
>>> > >> > > >> >> > > > > > > > > > or
>>> > >> > > >> >> > > > > > > > > >  hythread_library_t library =  
>>> thread-
>>> > >> >library;
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > So could you please use the same
>>> > >> mechanism and
>>> > >> > > >> >> remove hythread_*_ex >functions.
>>> > >> > > >> >> > > > > > > > > Let's see if classlib's hythread  
>>> needs
>>> > >> changing first.
>>> > >> > > >> >> It seems for me
>>> > >> > > >> >> > > > > > > > > such code prevents us from having  
>>> multi VM.
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 5. You introduce more then one jni
>>> > >> env, but still
>>> > >> > > >> >> use global variable for it.
>>> > >> > > >> >> > > > > > > > > > So all changes like following:
>>> > >> > > >> >> > > > > > > > > > -    JNIEnv *jenv = (JNIEnv*)
>>> > >> jni_native_intf;
>>> > >> > > >> >> > > > > > > > > > +    JNIEnv *jenv =  
>>> jni_native_intf;
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > should be like:
>>> > >> > > >> >> > > > > > > > > > -    JNIEnv *jenv = (JNIEnv*)
>>> > >> jni_native_intf;
>>> > >> > > >> >> > > > > > > > > > +    JNIEnv *jenv = get_jni_env
>>> > >> (jthread_self());
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Ok, I see. I agree that global
>>> > >> jni_native_intf should
>>> > >> > > >> >> not be used.
>>> > >> > > >> >> > > > > > > > > There was simple reason why I altered
>>> > >> such lines.
>>> > >> > > >> >> Because I changed
>>> > >> > > >> >> > > > > > > > > the type of  jni_native_intf and no
>>> > >> casting operator
>>> > >> > > >> >> is needed now. To
>>> > >> > > >> >> > > > > > > > > be honest I think get_jni_env
>>> > >> (jthread_self()) can be
>>> > >> > > >> >> good as temporary
>>> > >> > > >> >> > > > > > > > > solution only. Lets wait for  
>>> design of
>>> > >> multi VM and
>>> > >> > > >> >> fix it according
>>> > >> > > >> >> > > > > > > > > to it.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > While we are in JNI code, we always  
>>> have
>>> > >> the JNIenv (at
>>> > >> > > >> >> least
>>> > >> > > >> >> > > > > > > > initially it comes from Java code).  
>>> If we
>>> > >> consider VM
>>> > >> > > >> >> code as if it
>>> > >> > > >> >> > > > > > > > was a JNI application, then it seems  
>>> like
>>> > >> we should be
>>> > >> > > >> >> just passing
>>> > >> > > >> >> > > > > > > > JNIEnv as a parameter to all  
>>> functions in
>>> > >> VM. Or, we can
>>> > >> > > >> >> be taking it
>>> > >> > > >> >> > > > > > > > from TLS (via jthread_self()),  
>>> depending
>>> > >> on which way is
>>> > >> > > >> >> faster...
>>> > >> > > >> >> > > > > > > Agree.
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > 6). And small remarks:
>>> > >> > > >> >> > > > > > > > > > +jint vm_init1(JavaVM_Internal *  
>>> java_vm,
>>> > >> > > >> >> JavaVMInitArgs * vm_arguments);
>>> > >> > > >> >> > > > > > > > > > +jint vm_init2(JNIEnv_Internal *
>>> > >> jni_env);
>>> > >> > > >> >> > > > > > > > > > Could you make names more  
>>> meaningful,
>>> > >> then 1,2,3...?
>>> > >> > > >> >> > > > > > > > > Ok, will do that.
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > class VM_thread {
>>> > >> > > >> >> > > > > > > > > > ...
>>> > >> > > >> >> > > > > > > > > > +    JNIEnv_Internal * jni_env;
>>> > >> > > >> >> > > > > > > > > > The jthread already has the jni_env
>>> > >> pointer, you do
>>> > >> > > >> >> not need to
>>> > >> > > >> >> > > > > > > > > > duplicate it here.
>>> > >> > > >> >> > > > > > > > > > forexample by using
>>> > >> > > >> >> jthread_get_JNI_env(jthread_self());
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Yes I know. I don't see any problems
>>> > >> here. Some times
>>> > >> > > >> >> it is much more
>>> > >> > > >> >> > > > > > > > > convenient to get JNIEnv from  
>>> VM_thread
>>> > >> structure (and
>>> > >> > > >> >> faster) instead
>>> > >> > > >> >> > > > > > > > > of doing jthread_get_JNI_env 
>>> (jthread_self
>>> > >> ()). So I
>>> > >> > > >> >> need strong
>>> > >> > > >> >> > > > > > > > > arguments for removing it. Again it
>>> > >> seems that should
>>> > >> > > >> >> be addressed in
>>> > >> > > >> >> > > > > > > > > design of multi VM. So lets forget  
>>> about
>>> > >> it for a
>>> > >> > > >> >> while...
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > I think that the data duplication would
>>> > >> always serve as
>>> > >> > > >> >> a potential
>>> > >> > > >> >> > > > > > > > source of errors - while updating  
>>> one copy
>>> > >> of object,
>>> > >> > > >> >> you may forget
>>> > >> > > >> >> > > > > > > > to update the other, often resulting  
>>> into
>>> > >> a strange
>>> > >> > > >> >> behavior of the
>>> > >> > > >> >> > > > > > > > whole application. Let's see what  
>>> are the
>>> > >> specific
>>> > >> > > >> >> performance
>>> > >> > > >> >> > > > > > > > concerns that have to be addressed.  
>>> To get
>>> > >> VM_thread
>>> > >> > > >> >> structure, you
>>> > >> > > >> >> > > > > > > > would eventually go to the TLS, just  
>>> like
>>> > >> > > >> >> > > > > > > > jthread_get_JNI_env(jthread_self()  
>>> would do.
>>> > >> > > >> >> > > > > > > If there is already VM_thread  
>>> structure for
>>> > >> some reasons
>>> > >> > > >> >> then there
>>> > >> > > >> >> > > > > > > will be no extra access to TLS. It is
>>> > >> definitely much
>>> > >> > > >> more in
>>> > >> > > >> >> > > > > > > jthread_get_JNI_env(jthread_self()  
>>> than just
>>> > >> one TLS
>>> > >> > > >> >> access and one
>>> > >> > > >> >> > > > > > > dereferncing. I don't think it is a  
>>> really
>>> > >> big problem
>>> > >> > > >> >> now. Do you
>>> > >> > > >> >> > > > > > > agree to look at this later. I guess  
>>> multi VM
>>> > >> > > >> >> implementation will
>>> > >> > > >> >> > > > > > > alter it in any case.
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > Thanks
>>> > >> > > >> >> > > > > > > Evgueni
>>> > >> > > >> >> > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > Thanks,
>>> > >> > > >> >> > > > > > > > Andrey.
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > > Evgueni
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > Thanks
>>> > >> > > >> >> > > > > > > > > > Artem
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > On 9/28/06, Evgueni Brevnov
>>> > >> > > >> >> <evgueni.brevnov@gmail.com> wrote:
>>> > >> > > >> >> > > > > > > > > > > I suppose two days silence means
>>> > >> that there is no
>>> > >> > > >> >> objects (maybe
>>> > >> > > >> >> > > > > > > > > > > interest) against proposed  
>>> patch. I
>>> > >> would suggest
>>> > >> > > >> >> to commit it ASAP.
>>> > >> > > >> >> > > > > > > > > > > It really works! There are some
>>> > >> cases when current
>>> > >> > > >> >> VM crashes but the
>>> > >> > > >> >> > > > > > > > > > > patch fixes it. I can work on
>>> > >> bringing cunit tests
>>> > >> > > >> >> to live as soon as
>>> > >> > > >> >> > > > > > > > > > > the patch is committed....  
>>> This is
>>> > >> just my
>>> > >> > > >> >> understanding.
>>> > >> > > >> >> > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > > Thanks
>>> > >> > > >> >> > > > > > > > > > > Evgueni
>>> > >> > > >> >> > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > > On 9/28/06, Geir Magnusson Jr.
>>> > >> <geir@pobox.com>
>>> > >> > > >> >> wrote:
>>> > >> > > >> >> > > > > > > > > > > > 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
>>> > >> > > >> >> > > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > > >
>>> > >> > > >> >>
>>> > >>  
>>> -------------------------------------------------------------------- 
>>> -
>>> > >> > > >> >> > > > > > > > > > > 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
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >>
>>> > >>  
>>> -------------------------------------------------------------------- 
>>> -
>>> > >> > > >> >> > > > > > > > > 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
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > >
>>> > >> > > >> >> > > > > > > > --
>>> > >> > > >> >> > > > > > > > Andrey Chernyshev
>>> > >> > > >> >> > > > > > > > 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
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > > >
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > >
>>> > >> > > >> >> > > > > --
>>> > >> > > >> >> > > > > Andrey Chernyshev
>>> > >> > > >> >> > > > > 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
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > > >
>>> > >> > > >> >> > >
>>> > >> > > >> >> > >
>>> > >> > > >> >> > > --
>>> > >> > > >> >> > > Andrey Chernyshev
>>> > >> > > >> >> > > 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
>>> > >> > > >> >>
>>> > >> > > >> >>
>>> > >> > > >> >
>>> > >> > > >> >
>>> > >> > > >>
>>> > >> > > >>
>>> > >>  
>>> -------------------------------------------------------------------- 
>>> -
>>> > >> > > >> 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
>>> > >> > > >
>>> > >> > >
>>> > >> > >
>>> > >>  
>>> -------------------------------------------------------------------- 
>>> -
>>> > >> > > 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
>>> > >
>>> >
>>> >
>>> >  
>>> -------------------------------------------------------------------- 
>>> -
>>> > 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
>>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message