harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Date Mon, 09 Oct 2006 14:05:40 GMT
yes I see them too. I see them even w/o my patch :-( sure, it need to
be fixed...

On 10/9/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> 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
>
>

---------------------------------------------------------------------
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