[External] : Re: Generational ZGC issue
Johannes Lichtenberger
lichtenberger.johannes at gmail.com
Sat Feb 17 23:01:29 UTC 2024
Rerun the test with `johannes at luna:~/IdeaProjects/sirix$ time ./gradlew
:sirix-core:test --tests
io.sirix.service.json.shredder.JsonShredderTest.testChicagoDescendantAxis`
and -XX:MaxDirectMemorySize=1g
...
real 5m8,135s
user 0m1,799s
sys 0m0,374s
I've attached the log. Stuff like this may be strange, or normal?
[183,700s][debug ][gc,remset ] GC(57) y: scan_forwarding failed
retain safe 0x00000001dbe00000
[183,700s][debug ][gc,remset ] GC(57) y: scan_forwarding failed
retain safe 0x00000001dc200000
[183,700s][debug ][gc,remset ] GC(57) y: scan_forwarding failed
retain safe 0x00000001e2600000
[183,700s][debug ][gc,remset ] GC(57) y: scan_forwarding failed
retain safe 0x00000001e3e00000
[183,700s][debug ][gc,remset ] GC(57) y: scan_forwarding failed
retain safe 0x00000001f2400000
[183,700s][debug ][gc,remset ] GC(57) y: scan_forwarding failed
retain safe 0x00000001f9200000
[183,700s][debug ][gc,remset ] GC(57) y: Scan_Forwarding Failed
Retain Safe 0x00000001fac00000
kind regards
Johannes
Am Sa., 17. Feb. 2024 um 21:46 Uhr schrieb Johannes Lichtenberger <
lichtenberger.johannes at gmail.com>:
> With setting the max direct memory to 2Gb (-XX:MaxDirectMemorySize=2g) and
> using DirectByteBuffers under the hood using Chronicle Bytes, the test runs
> on my laptop, but as said way slower than with non generational ZGC or G1
> (and with G1 it's even fastest).
>
> real 4m58,836s
> user 0m1,849s
> sys 0m0,297s
>
> It caps at around 20Gb RAM usage and I think swapping somehow occurred at
> some point (452MB of 2GB).
>
> Before, setting MaxDIrectMemorySize to 5g (too high), the memory usage
> (watching `htop`) went to around 25Gb before heavy swapping occurred and
> the test failed at some point...
>
> kind regards
> Johannes
>
> Am Sa., 17. Feb. 2024 um 19:13 Uhr schrieb Erik Osterlund <
> erik.osterlund at oracle.com>:
>
>> Could you check how much is user time vs system time? It smells like you
>> are swapping. When swapping starts, performance goes out of the window.
>>
>> /Erik
>>
>> On 17 Feb 2024, at 16:21, Johannes Lichtenberger <
>> lichtenberger.johannes at gmail.com> wrote:
>>
>>
>> I'll check later on if the test doesn't fail with the 2g max and I'll
>> have to check as well if it's still the OutOfMemoryError (as I'm not at
>> home currently). But everytime everything freezes for a couple of seconds.
>>
>> In any case isn't it strange that with G1 and ZGC the runtime is very
>> close to each other with G1 having the upper hand slightly, when switching
>> to on heap ByteBuffers, but with Generational ZGC the runtime almost
>> exactly doubles? I thought at some point the generational version should
>> make the non generational obsolet and as almost every object dies young the
>> generational ZGC should be better as you wrote!?
>>
>> Kind regards and have a nice weekend (and kind of feel sorry for
>> bothering that much)
>> Johannes
>>
>> Stefan Johansson <stefan.johansson at oracle.com> schrieb am Sa., 17. Feb.
>> 2024, 15:54:
>>
>>> Ok, when you say crashes, what do you mean. Are you still seeing the
>>> same OutOfMemoryError or are we talking about an actual JVM crash. Or is
>>> it the Linux OOM killer stepping in because of high memory pressure?
>>>
>>> If this is with the new setting of 5g for direct memory it could be that
>>> these 3 extra gigs of memory is pushing you over the limit for what can
>>> be handle by you laptop. Generally, if you start swapping, the
>>> performance is out the door and you need to look at the configuration.
>>> Maybe the 2g for direct memory is reasonable on this setup to avoid
>>> swapping. I looked a bit at the total memory usage for the process here
>>> and it seem to be around 20G.
>>>
>>> Stefan
>>>
>>> On 2024-02-17 12:24, Johannes Lichtenberger wrote:
>>> > So, switching back to DirectByteBuffers, and removing the disabling of
>>> > explicit GCs still crashes on my laptop (swapping + close to 32 Gb RAM
>>> > used)...
>>> >
>>> > kind regards
>>> > Johannes
>>> >
>>> > Am Sa., 17. Feb. 2024 um 10:22 Uhr schrieb Stefan Johansson
>>> > <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>:
>>> >
>>> >
>>> >
>>> > On 2024-02-17 00:36, Johannes Lichtenberger wrote:
>>> > > I just removed "-XX+DisableExplizitGC", increased max direct
>>> > memory size
>>> > > to 5g (-XX:MaxDirectMemorySize=5g), but also changed
>>> > > Bytes::elasticByteBuffer to Bytes.elasticHeapByteBuffer(60_000);
>>> > > to use on heap ByteBuffers.
>>> > >
>>> >
>>> > Just for clarity, when using HeapByteBuffers the
>>> MaxDirectMemorySize
>>> > has
>>> > no effect since the ByteBuffers will be stored on the heap. But if
>>> you
>>> > keep going with DirectByteBuffers, this might make sense to give
>>> some
>>> > more head room.
>>> >
>>> > > However, the performance seems to be way worse. I've repeated
>>> the
>>> > test
>>> > > several times, but with both G1 and non generational ZGC it's
>>> > ~50s for
>>> > > importing the JSON file in the first case vs ~100s using
>>> > generational
>>> > > ZGC, using Temurin 21.0.2 with similar values for the actual
>>> > traversals.
>>> > >
>>> >
>>> > Ok, sounds like using DirectByteBuffers is a performance win here.
>>> > If so
>>> > I would just continue testing using DirectByteBuffers and allowing
>>> > explicit GCs to ensure they are cleaned out properly.
>>> >
>>> > > From the log on STDOUT, I can see this (meaning 0,319s and
>>> > 0,440s...
>>> > > pause times?)
>>> > >
>>> >
>>> > No, with ZGC the time here is not the pause time, it's the time to
>>> > complete the whole GC. ZGC is a concurrent GC, meaning that most
>>> of the
>>> > GC work is done concurrently with the Java application still
>>> running.
>>> > There are still a some very short pauses, all way below 1ms. You
>>> can
>>> > see
>>> > them if you look at the detailed log:
>>> >
>>> > [30,938s][info][gc ] GC(3) Minor Collection (Allocation
>>> Rate)
>>> > [30,938s][info][gc,phases ] GC(3) y: Young Generation
>>> > [30,938s][info][gc,phases ] GC(3) y: Pause Mark Start 0,060ms
>>> > [31,322s][info][gc,phases ] GC(3) y: Concurrent Mark 383,563ms
>>> > [31,322s][info][gc,phases ] GC(3) y: Pause Mark End 0,046ms
>>> > [31,322s][info][gc,phases ] GC(3) y: Concurrent Mark Free 0,009ms
>>> > [31,322s][info][gc,phases ] GC(3) y: Concurrent Reset Relocation
>>> Set
>>> > 0,201ms
>>> > [31,335s][info][gc,phases ] GC(3) y: Concurrent Select
>>> Relocation Set
>>> > 13,228ms
>>> > [31,335s][info][gc,phases ] GC(3) y: Pause Relocate Start 0,019ms
>>> > [31,381s][info][gc,phases ] GC(3) y: Concurrent Relocate 45,967ms
>>> > [31,382s][info][gc,phases ] GC(3) y: Young Generation
>>> > 9726M(63%)->518M(3%) 0,444s
>>> > [31,382s][info][gc ] GC(3) Minor Collection (Allocation
>>> Rate)
>>> > 9726M(63%)->518M(3%) 0,444s
>>> >
>>> > Here I included the phase-logs for a single GC of the young
>>> generation,
>>> > where you can clearly see how much time was spent in which part of
>>> the
>>> > GC and as you can see the three pauses are all very very short.
>>> >
>>> > Stefan
>>> >
>>> > > [35,718s][info ][gc ] GC(9) Minor Collection (Allocation
>>> > Rate)
>>> > > 12462M(81%)->1556M(10%) 0,319s
>>> > > [40,871s][info ][gc ] GC(10) Minor Collection (Allocation
>>> > Rate)
>>> > > [41,311s][info ][gc ] GC(10) Minor Collection (Allocation
>>> > Rate)
>>> > > 13088M(85%)->1432M(9%) 0,440s
>>> > > [46,236s][info ][gc ] GC(11) Minor Collection (Allocation
>>> > Rate)
>>> > > [46,603s][info ][gc ] GC(11) Minor Collection (Allocation
>>> > Rate)
>>> > > 12406M(81%)->1676M(11%) 0,367s
>>> > > [51,445s][info ][gc ] GC(12) Minor Collection (Allocation
>>> > Rate)
>>> > > [51,846s][info ][gc ] GC(12) Minor Collection (Allocation
>>> > Rate)
>>> > > 12848M(84%)->1556M(10%) 0,401s
>>> > > [56,203s][info ][gc ] GC(13) Major Collection (Proactive)
>>> > > [56,368s][info ][gc ] GC(13) Major Collection (Proactive)
>>> > > 11684M(76%)->484M(3%) 0,166s
>>> > >
>>> > > kind regards
>>> > > Johannes
>>> > >
>>> > > Am Fr., 16. Feb. 2024 um 22:39 Uhr schrieb Erik Osterlund
>>> > > <erik.osterlund at oracle.com <mailto:erik.osterlund at oracle.com>
>>> > <mailto:erik.osterlund at oracle.com <mailto:
>>> erik.osterlund at oracle.com>>>:
>>> > >
>>> > > It’s worth noting that when using ZGC, calling System.gc
>>> does not
>>> > > invoke a classic disastrously long GC pause. Instead, a
>>> > concurrent
>>> > > GC is triggered, which should be not that noticeable to the
>>> > > application. The thread calling System.gc is blocked until
>>> > the GC is
>>> > > done, but the other threads can run freely.
>>> > >
>>> > > /Erik
>>> > >
>>> > > > On 16 Feb 2024, at 21:55, Stefan Johansson
>>> > > <stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>
>>> > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>>>
>>> > > wrote:
>>> > > >
>>> > > >
>>> > > >
>>> > > >> On 2024-02-16 18:04, Johannes Lichtenberger wrote:
>>> > > >> Thanks a lot, I wasn't even aware of the fact, that
>>> > > DirectByteBuffers use System.gc() and I always had in mind
>>> that
>>> > > calling System.gc() at least in application code is bad
>>> > practice (or
>>> > > at least we shouldn't rely on it) and I think I read
>>> somewhere a
>>> > > while ago, that it's recommended to even disable this, but
>>> may be
>>> > > completely wrong, of course.
>>> > > > In most cases callling System.gc() is bad practice, in
>>> some
>>> > > special cases it might be needed.
>>> > > >
>>> > > >> I'll change it to on-heap byte buffers tomorrow :-)
>>> > > >> I think your GC log entries were from G1, right? It
>>> seems ZGC
>>> > > always tries to use the full heap :-)
>>> > > >
>>> > > > Yes, the snippet was G1, it was mostly to show that the
>>> > pressure
>>> > > isn't high. You are correct that ZGC uses more of the given
>>> > heap but
>>> > > the collections are pretty far apart and I'm certian it
>>> would
>>> > > function well with a smaller heap as well. Maybe in that
>>> case
>>> > some
>>> > > Major collections would be triggered.
>>> > > >
>>> > > >> Kind regards and thanks for sharing your insights.
>>> > > >
>>> > > > No problem. We appriciate the feedback,
>>> > > > StefanJ
>>> > > >
>>> > > >> Have a nice weekend as well
>>> > > >> Johannes
>>> > > >> Stefan Johansson <stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>
>>> > > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>>
>>> > > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>
>>> > > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>>>> schrieb am Fr., 16. Feb.
>>> > > 2024, 17:38:
>>> > > >> Hi,
>>> > > >> Some comments inline.
>>> > > >> On 2024-02-16 16:47, Johannes Lichtenberger wrote:
>>> > > >> > Thanks a lot for looking into it, I've added
>>> > > >> > `-XX:MaxDirectMemorySize=2g` only recently, but
>>> > without it
>>> > > failed as
>>> > > >> > well, so not sure what the default is. Will
>>> definitely
>>> > > check your
>>> > > >> > suggestions :-)
>>> > > >> >
>>> > > >> If you don't set a limit it will be set to:
>>> > > >> Runtime.getRuntime().maxMemory()
>>> > > >> So likely a good idea to set a reasonable limit, but
>>> the
>>> > > smaller the
>>> > > >> limit is the more frequent we need to run reference
>>> > > processing to allow
>>> > > >> memory to be freed up.
>>> > > >> > Sadly I'm currently working alone on the project
>>> in my
>>> > > spare time
>>> > > >> > (besides professionally switched from Java/Kotlin
>>> > stuff to the
>>> > > >> embedded
>>> > > >> > software world) and I'm not sure if the current
>>> > > architecture of
>>> > > >> Sirix is
>>> > > >> > limited by too much GC pressure. I'd probably have
>>> > to check
>>> > > >> Cassandra at
>>> > > >> > some point and look into flame graphs and stuff
>>> for
>>> > their
>>> > > >> integration
>>> > > >> > tests, but maybe you can give some general
>>> > insights/advice...
>>> > > >> >
>>> > > >> > Yesterday evening I switched to other JDKs (also I
>>> > want to
>>> > > test with
>>> > > >> > Shenandoah in particular), but I think especially
>>> the
>>> > > better escape
>>> > > >> > analysis of the GraalVM is a huge plus in the
>>> case of
>>> > > SirixDB (for
>>> > > >> > insertion on my laptop it's ~90s vs ~60s), but I
>>> > think it
>>> > > should be
>>> > > >> > faster and currently my suspicion is that garbage
>>> > is a major
>>> > > >> performance
>>> > > >> > issue.
>>> > > >> >
>>> > > >> > Maybe the GC pressure in general is a major issue,
>>> > as in
>>> > > the CPU
>>> > > >> Flame
>>> > > >> > graph IIRC the G1 had about 20% stack frames
>>> > allocated and non
>>> > > >> > generational ZGC even around 40% taking all
>>> threads
>>> > into
>>> > > account.
>>> > > >> >
>>> > > >> From what I/we see, the GC pressure in the given
>>> test is
>>> > > not high.
>>> > > >> The
>>> > > >> allocation rate is below 1GB/s and since most of it
>>> > die young
>>> > > the GCs
>>> > > >> are fairly cheap. In this log snippet G1 shows a GC
>>> > every 5s
>>> > > and the
>>> > > >> pause time is below 50ms:
>>> > > >> [296,016s][info ][gc ] GC(90) Pause Young
>>> > (Normal) (G1
>>> > > >> Evacuation
>>> > > >> Pause) 5413M->1849M(6456M) 35,577ms
>>> > > >> [301,103s][info ][gc ] GC(91) Pause Young
>>> > (Normal) (G1
>>> > > >> Evacuation
>>> > > >> Pause) 5417M->1848M(6456M) 33,357ms
>>> > > >> [306,041s][info ][gc ] GC(92) Pause Young
>>> > (Normal) (G1
>>> > > >> Evacuation
>>> > > >> Pause) 5416M->1848M(6456M) 32,763ms
>>> > > >> [310,849s][info ][gc ] GC(93) Pause Young
>>> > (Normal) (G1
>>> > > >> Evacuation
>>> > > >> Pause) 5416M->1847M(6456M) 33,086ms
>>> > > >> I also see that the heap never expands to more the
>>> > ~6.5GB even
>>> > > >> though it
>>> > > >> is allow to be 15GB and this also suggest that the GC
>>> > is not
>>> > > under much
>>> > > >> pressure. As I said in the previous mail, the reason
>>> > > Generational ZGC
>>> > > >> don't free up the direct memory without the
>>> > System.gc() calls
>>> > > is that
>>> > > >> the GC pressure is not high enough to trigger any
>>> Major
>>> > > cycles. So I
>>> > > >> would strongly recommend you to not run with
>>> > > -XX+DisableExplicitGC
>>> > > >> unless you really have to. Since you are using
>>> > > DirectByteBuffers and
>>> > > >> they use System.gc() to help free memory when the
>>> limit is
>>> > > reached.
>>> > > >> > So in general I'm thinking about backing the
>>> > > KeyValueLeafPages with
>>> > > >> > MemorySegments, but I think due to variable sized
>>> pages
>>> > > it's getting
>>> > > >> > tricky, plus I currently don't have the time for
>>> > changing
>>> > > >> fundamental
>>> > > >> > stuff and I'm even not sure if it'll bring a
>>> > performance
>>> > > boost, as I
>>> > > >> > have to adapt neighbour relationships of the nodes
>>> > often and
>>> > > >> off-heap
>>> > > >> > memory access might be slightly worse performance
>>> wise.
>>> > > >> >
>>> > > >> > What do you think?
>>> > > >> >
>>> > > >> I know to little about the application to be able to
>>> give
>>> > > advice here,
>>> > > >> but I would first start with having most memory on
>>> > heap. Only
>>> > > large
>>> > > >> long
>>> > > >> lived stuff off-heap, if really needed. Looking at
>>> the
>>> > test
>>> > > at hand, it
>>> > > >> really doesn't look like it is long lived stuff that
>>> is
>>> > > placed off heap.
>>> > > >> > I've attached a memory flame graph and there it
>>> > seems the
>>> > > byte array
>>> > > >> > from deserializing each page is prominent, but
>>> that
>>> > might be
>>> > > >> something I
>>> > > >> > can't even avoid (after decompression via Snappy
>>> or via
>>> > > another
>>> > > >> lib and
>>> > > >> > maybe also decryption in the future).
>>> > > >> >
>>> > > >> > As of now G1 with GraalVM seems to perform best (a
>>> > little
>>> > > bit better
>>> > > >> > than with non generational ZGC, but I thought ZGC
>>> > or maybe
>>> > > >> Shenandoah
>>> > > >> > would improve the situation). But as said I may
>>> have to
>>> > > generate way
>>> > > >> > less garbage after all in general for good
>>> > performance!?
>>> > > >> >
>>> > > >> > All in all maybe due to most objects die young
>>> > maybe also the
>>> > > >> > generational GCs are not needed (that said if
>>> > enough RAM is
>>> > > >> available
>>> > > >> > and the Caffeine Caches are sized accordingly most
>>> > objects may
>>> > > >> die old).
>>> > > >> > But apparently the byte arrays holding the page
>>> > data still die
>>> > > >> young (in
>>> > > >> > AbstractReader::deserialize). In fact I'm not
>>> even sure
>>> > > why they
>>> > > >> escape,
>>> > > >> > but currently I'm on my phone.
>>> > > >> >
>>> > > >> It's when most objects die young the Generational GC
>>> > really
>>> > > shines,
>>> > > >> because it can handle the short lived objects without
>>> > having
>>> > > to look at
>>> > > >> the long lived objects. So I would say Generational
>>> > ZGC is a
>>> > > good fit
>>> > > >> here, but we need to let the System.gc() run to allow
>>> > reference
>>> > > >> processing or slightly re-design and use
>>> HeapByteBuffers.
>>> > > >> Have a nice weekend,
>>> > > >> Stefan
>>> > > >> > Kind regards
>>> > > >> > Johannes
>>> > > >> >
>>> > > >> > Stefan Johansson <stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>
>>> > > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>>
>>> > > >> <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>
>>> > > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>>>
>>> > > >> > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>
>>> > > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>>
>>> > > >> <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>
>>> > > <mailto:stefan.johansson at oracle.com
>>> > <mailto:stefan.johansson at oracle.com>>>>> schrieb am Fr., 16. Feb.
>>> > > >> 2024, 13:43:
>>> > > >> >
>>> > > >> > Hi Johannes,
>>> > > >> >
>>> > > >> > We've spent some more time looking at this and
>>> > getting the
>>> > > >> json-file to
>>> > > >> > reproduced it made it easy to verify our
>>> > suspicions.
>>> > > Thanks for
>>> > > >> > uploading it.
>>> > > >> >
>>> > > >> > There are a few things playing together here.
>>> > The test is
>>> > > >> making quite
>>> > > >> > heavy use of DirectByteBuffers and you limit
>>> > the usage
>>> > > to 2G
>>> > > >> > (-XX:MaxDirectMemorySize=2g). The life cycle
>>> and
>>> > > freeing of
>>> > > >> the native
>>> > > >> > memory part of the DirectByteBuffer rely on
>>> > reference
>>> > > >> processing. In
>>> > > >> > generational ZGC reference processing is only
>>> done
>>> > > during Major
>>> > > >> > collections and since the general GC preassure
>>> > in this
>>> > > >> benchmark is
>>> > > >> > very
>>> > > >> > low (most objects die young), we do not
>>> trigger
>>> > that
>>> > > many Major
>>> > > >> > collections.
>>> > > >> >
>>> > > >> > Normaly this would not be a problem. To avoid
>>> > throwing
>>> > > an out
>>> > > >> of memory
>>> > > >> > error (due to hitting the direct buffer memory
>>> > limit) too
>>> > > >> early the JDK
>>> > > >> > triggers a System.gc(). This should trigger
>>> > reference
>>> > > >> procesing and all
>>> > > >> > buffers that are no longer in use would be
>>> freed.
>>> > > Since you
>>> > > >> specify the
>>> > > >> > option -XX:+DisableExplicitGC all these calls
>>> to
>>> > > trigger GCs are
>>> > > >> > ignored
>>> > > >> > and no direct memory will be freed. So in our
>>> > testing,
>>> > > just
>>> > > >> removing
>>> > > >> > this flags makes the test pass.
>>> > > >> >
>>> > > >> > Another solution is to look at using
>>> > HeapByteBuffers
>>> > > instead
>>> > > >> and don't
>>> > > >> > have to worry about the direct memory usage.
>>> The
>>> > > OpenHFT lib
>>> > > >> seems to
>>> > > >> > have support for this by just using
>>> > > >> elasticHeapByteBuffer(...) instead
>>> > > >> > of elasticByteBuffer().
>>> > > >> >
>>> > > >> > Lastly, the reason for this working with
>>> > > non-generational ZGC is
>>> > > >> > that it
>>> > > >> > does reference processing for every GC.
>>> > > >> >
>>> > > >> > Hope this helps,
>>> > > >> > StefanJ
>>> > > >> >
>>> > > >> >
>>> > > >> > On 2024-02-15 21:53, Johannes Lichtenberger
>>> wrote:
>>> > > >> > > It's a laptop, I've attached some details.
>>> > > >> > >
>>> > > >> > > Furthermore, if it seems worth digging
>>> > deeper into the
>>> > > >> issue, the
>>> > > >> > JSON
>>> > > >> > > file is here for one week:
>>> > > >> > >
>>> > https://www.transfernow.net/dl/20240215j9NaPTc0
>>> <https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!LO8iMrNtVuMHM0elGqimqgkyKip3sUQtngpyEvIeEXo_ydu21QQ0KfHymFrv5r3aiNLd_8GiYZJTq_TmlUIg_mVrq6cVng$>
>>> > <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!Oy8M_MVHordSb4P3bQK7FIsjr7OUWYsKxpJWW-5Hsq4QmU-5utLsNbRRM5kiyoHWE92dAWA7n38XpX68XvdBhd0HudjOaY-y$
>>> >
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!M33-mkbNfIFidOtIRYJLrdt970BIn5XjvmSvgBg0Ip6zkm5Zk7w6OG6FunFxjzDpUZju_f7FbEua8sTaS9Q3SnufNTFwuk6i$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!M33-mkbNfIFidOtIRYJLrdt970BIn5XjvmSvgBg0Ip6zkm5Zk7w6OG6FunFxjzDpUZju_f7FbEua8sTaS9Q3SnufNTFwuk6i$
>>> >>
>>> > > >>
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybJynYpht$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybJynYpht$>
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybJynYpht$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybJynYpht$
>>> >>>
>>> > > >> >
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$>
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$>>
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$>
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> >>>>
>>> > > >> > >
>>> > <https://www.transfernow.net/dl/20240215j9NaPTc0
>>> <https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!LO8iMrNtVuMHM0elGqimqgkyKip3sUQtngpyEvIeEXo_ydu21QQ0KfHymFrv5r3aiNLd_8GiYZJTq_TmlUIg_mVrq6cVng$>
>>> > <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!Oy8M_MVHordSb4P3bQK7FIsjr7OUWYsKxpJWW-5Hsq4QmU-5utLsNbRRM5kiyoHWE92dAWA7n38XpX68XvdBhd0HudjOaY-y$
>>> >
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!M33-mkbNfIFidOtIRYJLrdt970BIn5XjvmSvgBg0Ip6zkm5Zk7w6OG6FunFxjzDpUZju_f7FbEua8sTaS9Q3SnufNTFwuk6i$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!M33-mkbNfIFidOtIRYJLrdt970BIn5XjvmSvgBg0Ip6zkm5Zk7w6OG6FunFxjzDpUZju_f7FbEua8sTaS9Q3SnufNTFwuk6i$
>>> >>
>>> > > >>
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybJynYpht$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybJynYpht$>
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybJynYpht$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybJynYpht$
>>> >>>
>>> > > >> >
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$>
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$>>
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$>
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> <
>>> https://urldefense.com/v3/__https://www.transfernow.net/dl/20240215j9NaPTc0__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFeDXD5_-$
>>> >>>>>
>>> > > >> > >
>>> > > >> > > You'd have to unzip into
>>> > > >> bundles/sirix-core/src/test/resources/json,
>>> > > >> > > remove the @Disabled annotation and run
>>> the test
>>> > > >> > > JsonShredderTest::testChicagoDescendantAxis
>>> > > >> > >
>>> > > >> > > The test JVM parameters are specified in
>>> the
>>> > parent
>>> > > >> build.gradle
>>> > > >> > in the
>>> > > >> > > project root folder.
>>> > > >> > >
>>> > > >> > > The GitHub repo:
>>> > https://github.com/sirixdb/sirix
>>> <https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!LO8iMrNtVuMHM0elGqimqgkyKip3sUQtngpyEvIeEXo_ydu21QQ0KfHymFrv5r3aiNLd_8GiYZJTq_TmlUIg_mWLTIcvdA$>
>>> > <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!Oy8M_MVHordSb4P3bQK7FIsjr7OUWYsKxpJWW-5Hsq4QmU-5utLsNbRRM5kiyoHWE92dAWA7n38XpX68XvdBhd0HuVPfuWFY$
>>> >
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!M33-mkbNfIFidOtIRYJLrdt970BIn5XjvmSvgBg0Ip6zkm5Zk7w6OG6FunFxjzDpUZju_f7FbEua8sTaS9Q3SnufNbw9BBhL$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!M33-mkbNfIFidOtIRYJLrdt970BIn5XjvmSvgBg0Ip6zkm5Zk7w6OG6FunFxjzDpUZju_f7FbEua8sTaS9Q3SnufNbw9BBhL$
>>> >>
>>> > > >>
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybALU2RDy$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybALU2RDy$>
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybALU2RDy$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybALU2RDy$
>>> >>>
>>> > > >> >
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$>
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$>>
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$>
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> >>>>
>>> > > >> > > <https://github.com/sirixdb/sirix
>>> <https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!LO8iMrNtVuMHM0elGqimqgkyKip3sUQtngpyEvIeEXo_ydu21QQ0KfHymFrv5r3aiNLd_8GiYZJTq_TmlUIg_mWLTIcvdA$>
>>> > <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!Oy8M_MVHordSb4P3bQK7FIsjr7OUWYsKxpJWW-5Hsq4QmU-5utLsNbRRM5kiyoHWE92dAWA7n38XpX68XvdBhd0HuVPfuWFY$
>>> >
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!M33-mkbNfIFidOtIRYJLrdt970BIn5XjvmSvgBg0Ip6zkm5Zk7w6OG6FunFxjzDpUZju_f7FbEua8sTaS9Q3SnufNbw9BBhL$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!M33-mkbNfIFidOtIRYJLrdt970BIn5XjvmSvgBg0Ip6zkm5Zk7w6OG6FunFxjzDpUZju_f7FbEua8sTaS9Q3SnufNbw9BBhL$
>>> >>
>>> > > >>
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybALU2RDy$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybALU2RDy$>
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybALU2RDy$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!O5j6Ri-Ostqq68q1zm71CEhSQ4CE7DqBfHZNq7cDAhU7b7CwqrnIA-ddZFaQDbOMAkgHkFriNeIrXJdRofVuv1UybALU2RDy$
>>> >>>
>>> > > >> >
>>> > >
>>> > <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$>
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$>>
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$>
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> <
>>> https://urldefense.com/v3/__https://github.com/sirixdb/sirix__;!!ACWV5N9M2RV99hQ!MWZDuvCBsbZSYul-HLDtF_j1IBD6osBF4cBVE_bg0yM5zCqYFwzLLp7nKN3b1hq1XVFRreqUVaXiKuXjUwGbxpjjFUUPdeUD$
>>> >>>>>
>>> > > >> > >
>>> > > >> > > Screenshot from 2024-02-15 21-43-33.png
>>> > > >> > >
>>> > > >> > > kind regards
>>> > > >> > > Johannes
>>> > > >> > >
>>> > > >> > > Am Do., 15. Feb. 2024 um 20:01 Uhr schrieb
>>> > Peter Booth
>>> > > >> > > <peter_booth at me.com
>>> > <mailto:peter_booth at me.com> <mailto:peter_booth at me.com
>>> > <mailto:peter_booth at me.com>>
>>> > > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>
>>> > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>>>
>>> > > >> <mailto:peter_booth at me.com <mailto:
>>> peter_booth at me.com>
>>> > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>>
>>> > > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>
>>> > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>>>>
>>> > > >> > <mailto:peter_booth at me.com
>>> > <mailto:peter_booth at me.com> <mailto:peter_booth at me.com
>>> > <mailto:peter_booth at me.com>>
>>> > > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>
>>> > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>>>
>>> > > >> <mailto:peter_booth at me.com <mailto:
>>> peter_booth at me.com>
>>> > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>>
>>> > > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>
>>> > <mailto:peter_booth at me.com <mailto:peter_booth at me.com>>>>>>:
>>> > > >> > >
>>> > > >> > > Just curious - what CPU, physical
>>> memory
>>> > and OS are
>>> > > >> you using?
>>> > > >> > > Sent from my iPhone
>>> > > >> > >
>>> > > >> > >> On Feb 15, 2024, at 12:23 PM, Johannes
>>> > > Lichtenberger
>>> > > >> > >> <lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>
>>> > > >> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>>
>>> > > >> > >>
>>> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>
>>> > > >> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>>>> wrote:
>>> > > >> > >>
>>> > > >> > >>
>>> > > >> > >> I guess I don't know which JDK it
>>> picks
>>> > for the
>>> > > >> tests, but I
>>> > > >> > guess
>>> > > >> > >> OpenJDK
>>> > > >> > >>
>>> > > >> > >> Johannes Lichtenberger
>>> > > >> <lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>
>>> > > >> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>>
>>> > > >> > >>
>>> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>
>>> > > >> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>>>> schrieb am Do., 15.
>>> > > >> > >> Feb. 2024, 17:58:
>>> > > >> > >>
>>> > > >> > >> However, it's the same with:
>>> ./gradlew
>>> > > >> > >>
>>> > > -Dorg.gradle.java.home=/home/johannes/.jdks/openjdk-21.0.2
>>> > > >> > >> :sirix-core:test --tests
>>> > > >> > >>
>>> > > >> >
>>> > >
>>> >
>>> io.sirix.service.json.shredder.JsonShredderTest.testChicagoDescendantAxis
>>> using OpenJDK hopefully
>>> > > >> > >>
>>> > > >> > >> Am Do., 15. Feb. 2024 um 17:54 Uhr
>>> > schrieb
>>> > > Johannes
>>> > > >> > >> Lichtenberger
>>> > > <lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>
>>> > > >> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>>
>>> > > >> > >>
>>> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>
>>> > > >> > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>
>>> > > >> <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>
>>> > > <mailto:lichtenberger.johannes at gmail.com
>>> > <mailto:lichtenberger.johannes at gmail.com>>>>>>:
>>> > > >> > >>
>>> > > >> > >> I've attached two logs, the
>>> > first one
>>> > > without
>>> > > >> > >> -XX:+Generational, the second
>>> > one with the
>>> > > >> option set,
>>> > > >> > >> even though I also saw, that
>>> > > generational ZGC is
>>> > > >> > going to
>>> > > >> > >> be supported in GraalVM 24.1
>>> in
>>> > > September...
>>> > > >> so not sure
>>> > > >> > >> what this does :)
>>> > > >> > >>
>>> > > >> > >> Am Do., 15. Feb. 2024 um 17:52
>>> > Uhr schrieb
>>> > > >> Johannes
>>> > > >> > >> Lichtenberger
>>> > > >> <lichtenberger.johannes at gmail.com
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20240218/c74fd429/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zgc-generational-very-new.log.tar.gz
Type: application/gzip
Size: 985874 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20240218/c74fd429/zgc-generational-very-new.log.tar-0001.gz>
More information about the zgc-dev
mailing list