On Fri, 8 Apr 2022 17:00:19 GMT, Thomas Stuefe wrote:
> > > We must call new on it somewhere. I am not opposed to making this an
> > > mtFlags template then. This is a small point in this improvement.
> >
> >
> > Yes, at some point we need to allocate the fragments and fragments table.
> >
On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote:
> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
> JDK version to target.
>
> We will refresh this PR periodically to pick up changes and fixes from the
> loom repo.
>
> Most of the new mechanisms in the
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> constants, such as
On Fri, 8 Apr 2022 08:34:24 GMT, Yasumasa Suenaga wrote:
>> jcmd uses
>> src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java
>> to scan temporary directories to find out processes in the container. It
>> checks inode to ensure the temp directory is not conflicted.
On Fri, 8 Apr 2022 15:00:22 GMT, Coleen Phillimore wrote:
> We must call new on it somewhere. I am not opposed to making this an mtFlags
> template then. This is a small point in this improvement.
Yes, at some point we need to allocate the fragments and fragments table. We
could *perhaps*
On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>>
> JVMTI heap walking marks objects in order to track which have been visited
> already. In order to do that, it uses bits in the object header. Those are
> the same bits that are also used by some GCs to mark objects (the lowest two
> bits, also used by locking code). Some GCs also use the bits
This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK
version to target.
We will refresh this PR periodically to pick up changes and fixes from the loom
repo.
Most of the new mechanisms in the HotSpot VM are disabled by default and
require running with
On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>>
On Fri, 8 Apr 2022 08:34:24 GMT, Yasumasa Suenaga wrote:
>> jcmd uses
>> src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java
>> to scan temporary directories to find out processes in the container. It
>> checks inode to ensure the temp directory is not conflicted.
On Thu, 7 Apr 2022 23:29:41 GMT, Leonid Mesnik wrote:
> Tests are updated to ensure that classes are alive while test checks them.
> Actually, fixed by @AlanBateman in repo-loom.
This pull request has now been integrated.
Changeset: a8c87526
Author:Leonid Mesnik
URL:
The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with
CNFE like "java.lang.NoClassDefFoundError:
jdk/test/lib/compiler/InMemoryJavaCompiler"
It is not a loom specific bug, it might happen in jdk/jdk also.
The workaround is to build some classes explicitly. The fix was
On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote:
> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
> with CNFE like "java.lang.NoClassDefFoundError:
> jdk/test/lib/compiler/InMemoryJavaCompiler"
>
> It is not a loom specific bug, it might happen in jdk/jdk also.
On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote:
> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
> with CNFE like "java.lang.NoClassDefFoundError:
> jdk/test/lib/compiler/InMemoryJavaCompiler"
>
> It is not a loom specific bug, it might happen in jdk/jdk also.
On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote:
> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
> with CNFE like "java.lang.NoClassDefFoundError:
> jdk/test/lib/compiler/InMemoryJavaCompiler"
>
> It is not a loom specific bug, it might happen in jdk/jdk also.
On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote:
> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
> with CNFE like "java.lang.NoClassDefFoundError:
> jdk/test/lib/compiler/InMemoryJavaCompiler"
>
> It is not a loom specific bug, it might happen in jdk/jdk also.
> jcmd uses
> src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java
> to scan temporary directories to find out processes in the container. It
> checks inode to ensure the temp directory is not conflicted. However inode
> maybe same value between the container and others.
On Fri, 8 Apr 2022 03:50:10 GMT, Ioi Lam wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comments
>
> The code changes look good, but I think the comment should be cleaned up.
Thanks @iklam and @tstuefe !
On Thu, 7 Apr 2022 15:11:54 GMT, Roman Kennke wrote:
> A general thought, maybe for a future RFE:
>
>We now have BitMap and BitSet, which do almost the same thing. Instead of
>having a new class BitSet, whose job is to be sparse, we could give BitMap the
>ability to be sparse. We'd save code,
On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>>
On Fri, 8 Apr 2022 03:40:41 GMT, Thomas Stuefe wrote:
> > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be
> > > exactly right. Should I templatize BitSet and make JVMTI use
> > > mtServiceability and JRF use mtTracing as it did before?
> >
> >
> > Yes, I think
On Fri, 8 Apr 2022 14:17:06 GMT, Roman Kennke wrote:
> > Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty
> > of bits in mt flags.
>
> Naa, I don't think this is justified. It isn't used as widely or frequently
> to warrant its own flag.
Plus, it would muddy the
On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>>
On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>>
On Fri, 8 Apr 2022 12:59:26 GMT, Coleen Phillimore wrote:
> Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty of
> bits in mt flags.
Naa, I don't think this is justified. It isn't used as widely or frequently to
warrant its own flag.
-
PR:
25 matches
Mail list logo
