[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8300575: JVMTI support when using alternative virtual thread implementation [v7]
From:       Patricio Chilano Mateo <pchilanomate () openjdk ! org>
Date:       2023-02-21 18:02:26
Message-ID: 44LBvvPOCCF4QAbRg6ZPbjAy8aQg-PL7sYQ-xTWmQgo=.f4424e4a-c9fd-4599-8e07-211d0ed23581 () github ! com
[Download RAW message or body]

On Sat, 18 Feb 2023 07:56:25 GMT, Alan Bateman <alanb@openjdk.org> wrote:

> > > Thanks for dropping is_bound_vthread, I think it's much better now. What would \
> > > you think about changing it to test the thread type is_a \
> > > vmClasses::BaseVirtualThread_klass() so the VM doesn't need to know about \
> > > ThreadBuilders$BoundVirtualThread. 
> > Yes, we could do that. Although I think that checking for \
> > BoundVirtualThread_klass is more descriptive of what we are trying to do and will \
> > be less confusing when reading the code. How about checking for \
> > `(!VMContinuations && x->is_a(vmClasses::BaseVirtualThread_klass()))`?
> 
> > Yes, we could do that. Although I think that checking for \
> > BoundVirtualThread_klass is more descriptive of what we are trying to do and will \
> > be less confusing when reading the code. How about checking for \
> > `(!VMContinuations && x->is_a(vmClasses::BaseVirtualThread_klass()))`?
> 
> We can go with what you have for now and re-visit again if it becomes an issue. The \
> main thing I had hoped is that the VM won't get too coupled to BoundVirtualThread \
> as that may move or be refactored soon.

Thanks for the reviews @AlanBateman, @lmesnik and @sspitsyn!

-------------

PR: https://git.openjdk.org/jdk/pull/12512


[prev in list] [next in list] [prev in thread] [next in thread]