Recent posts

#71

Lightweight Java Gaming Library / Re: Buffer is not freed - OutO...

Last post by spasi - May 10, 2024, 12:15:10

The log shows that the JVM itself is trying to allocate some memory and fails. Are you maybe running too many programs and the system as a whole runs OOM?

In any case, this doesn't look like an issue with LWJGL.

#72

Lightweight Java Gaming Library / Re: Buffer is not freed - OutO...

Last post by fireinwinterfell - May 10, 2024, 11:44:46

Btw, do you mean a java.lang.OutOfMemoryError or a process-OOM error followed by a JVM crash?

Now I got the log (first chunk):

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 1048576 bytes. Error detail: AllocateHeap
# Possible reasons:
#   The system is out of physical RAM or swap space
#   This process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
#   JVM is running with Unscaled Compressed Oops mode in which the Java heap is
#     placed in the first 4GB address space. The Java Heap base address is the
#     maximum limit for the native heap growth. Please use -XX:HeapBaseMinAddress
#     to set the Java Heap base and to place the Java Heap above 4GB virtual address.
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (allocation.cpp:44), pid=19920, tid=10312
#
# JRE version: Java(TM) SE Runtime Environment Oracle GraalVM 22+36.1 (22.0+36) (build 22+36-jvmci-b02)
# Java VM: Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 22+36.1 (22+36-jvmci-b02, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#

---------------  S U M M A R Y ------------

Command Line: -XX:ThreadPriorityPolicy=1 -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProduct -XX:-UnlockExperimentalVMOptions -Xmx128m -javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2023.1.5\lib\idea_rt.jar=65095:C:\Program Files\JetBrains\IntelliJ IDEA 2023.1.5\bin -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 gridx.lightning.RenderPDFApp -Xmx128m

Host: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 8 cores, 7G,  Windows 11 , 64 bit Build 22621 (10.0.22621.3374)
Time: Fri May 10 17:46:57 2024 SE Asia Standard Time elapsed time: 136.733497 seconds (0d 0h 2m 16s)

---------------  T H R E A D  ---------------

Current thread (0x000002c9d6f237f0):  VMThread "VM Thread"          [id=10312, stack(0x000000dd85300000,0x000000dd85400000) (1024K)]

Stack: [0x000000dd85300000,0x000000dd85400000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x6e2349]  (no source info available)
V  [jvm.dll+0x874ed3]  (no source info available)
V  [jvm.dll+0x8772fe]  (no source info available)
V  [jvm.dll+0x8779d3]  (no source info available)
V  [jvm.dll+0x27fcb6]  (no source info available)
V  [jvm.dll+0xbe877]  (no source info available)
V  [jvm.dll+0x348d4f]  (no source info available)
V  [jvm.dll+0x3436fe]  (no source info available)
V  [jvm.dll+0x32bf1c]  (no source info available)
V  [jvm.dll+0x370134]  (no source info available)
V  [jvm.dll+0x87d870]  (no source info available)
V  [jvm.dll+0x87ebf7]  (no source info available)
V  [jvm.dll+0x87f170]  (no source info available)
V  [jvm.dll+0x87f413]  (no source info available)
V  [jvm.dll+0x81d50b]  (no source info available)
V  [jvm.dll+0x6e09e5]  (no source info available)
C  [ucrtbase.dll+0x29333]  (no source info available)
C  [KERNEL32.DLL+0x1257d]  (no source info available)
C  [ntdll.dll+0x5aa48]  (no source info available)

VM_Operation (0x000000dd84cff370): G1CollectFull, mode: safepoint, requested by thread 0x000002c9bb39fb90


---------------  P R O C E S S  ---------------

Threads class SMR info:
_java_thread_list=0x000002c986feabb0, length=15, elements={
0x000002c9bb39fb90, 0x000002c9d6f3e250, 0x000002c9d6f3ed80, 0x000002c9d6f48c20,
0x000002c9d6f4b700, 0x000002c9d6f52930, 0x000002c9d6f53740, 0x000002c9d6f575e0,
0x000002c9d6f59bf0, 0x000002ca1c12acd0, 0x000002ca1c4377b0, 0x000002ca1c43a1a0,
0x000002c986913010, 0x000002c986f22900, 0x000002c986f1c760
}

Java Threads: ( => current thread )
  0x000002c9bb39fb90 JavaThread "main"                              [_thread_blocked, id=9540, stack(0x000000dd84c00000,0x000000dd84d00000) (1024K)]
  0x000002c9d6f3e250 JavaThread "Reference Handler"          daemon [_thread_blocked, id=9416, stack(0x000000dd85400000,0x000000dd85500000) (1024K)]
  0x000002c9d6f3ed80 JavaThread "Finalizer"                  daemon [_thread_blocked, id=21680, stack(0x000000dd85500000,0x000000dd85600000) (1024K)]
  0x000002c9d6f48c20 JavaThread "Signal Dispatcher"          daemon [_thread_blocked, id=13612, stack(0x000000dd85600000,0x000000dd85700000) (1024K)]
  0x000002c9d6f4b700 JavaThread "Attach Listener"            daemon [_thread_blocked, id=772, stack(0x000000dd85700000,0x000000dd85800000) (1024K)]
  0x000002c9d6f52930 JavaThread "Service Thread"             daemon [_thread_blocked, id=20400, stack(0x000000dd85800000,0x000000dd85900000) (1024K)]
  0x000002c9d6f53740 JavaThread "Monitor Deflation Thread"   daemon [_thread_blocked, id=20476, stack(0x000000dd85900000,0x000000dd85a00000) (1024K)]
  0x000002c9d6f575e0 JavaThread "JVMCI-native CompilerThread0" daemon [_thread_blocked, id=2716, stack(0x000000dd85a00000,0x000000dd85b00000) (1024K)]
  0x000002c9d6f59bf0 JavaThread "C1 CompilerThread0"         daemon [_thread_blocked, id=9012, stack(0x000000dd85b00000,0x000000dd85c00000) (1024K)]
  0x000002ca1c12acd0 JavaThread "Common-Cleaner"             daemon [_thread_blocked, id=11452, stack(0x000000dd85c00000,0x000000dd85d00000) (1024K)]
  0x000002ca1c4377b0 JavaThread "Monitor Ctrl-Break"         daemon [_thread_in_native, id=19160, stack(0x000000dd85f00000,0x000000dd86000000) (1024K)]
  0x000002ca1c43a1a0 JavaThread "Notification Thread"        daemon [_thread_blocked, id=12584, stack(0x000000dd86000000,0x000000dd86100000) (1024K)]
  0x000002c986913010 JavaThread "Cleaner-0"                  daemon [_thread_blocked, id=7280, stack(0x000000dd86a00000,0x000000dd86b00000) (1024K)]
  0x000002c986f22900 JavaThread "Java2D Disposer"            daemon [_thread_blocked, id=12664, stack(0x000000dd87200000,0x000000dd87300000) (1024K)]
  0x000002c986f1c760 JavaThread "AWT-Windows"                daemon [_thread_in_native, id=8200, stack(0x000000dd87400000,0x000000dd87500000) (1024K)]
Total: 15

Other Threads:
=>0x000002c9d6f237f0 VMThread "VM Thread"                           [id=10312, stack(0x000000dd85300000,0x000000dd85400000) (1024K)]
  0x000002c9d6f0ac00 WatcherThread "VM Periodic Task Thread"        [id=16800, stack(0x000000dd85200000,0x000000dd85300000) (1024K)]
  0x000002c9bb3beba0 WorkerThread "GC Thread#0"                     [id=10944, stack(0x000000dd84d00000,0x000000dd84e00000) (1024K)]
  0x000002c986ed7a40 WorkerThread "GC Thread#1"                     [id=4672, stack(0x000000dd86b00000,0x000000dd86c00000) (1024K)]
  0x000002c986ed7df0 WorkerThread "GC Thread#2"                     [id=22468, stack(0x000000dd86c00000,0x000000dd86d00000) (1024K)]
  0x000002c986ee0490 WorkerThread "GC Thread#3"                     [id=12832, stack(0x000000dd86d00000,0x000000dd86e00000) (1024K)]
  0x000002c986ee0ca0 WorkerThread "GC Thread#4"                     [id=11124, stack(0x000000dd86e00000,0x000000dd86f00000) (1024K)]
  0x000002c986ee1860 WorkerThread "GC Thread#5"                     [id=22836, stack(0x000000dd86f00000,0x000000dd87000000) (1024K)]
  0x000002c986ee1c10 WorkerThread "GC Thread#6"                     [id=2976, stack(0x000000dd87000000,0x000000dd87100000) (1024K)]
  0x000002c986ee4a90 WorkerThread "GC Thread#7"                     [id=16996, stack(0x000000dd87100000,0x000000dd87200000) (1024K)]
  0x000002c9bb3c0b90 ConcurrentGCThread "G1 Main Marker"            [id=22072, stack(0x000000dd84e00000,0x000000dd84f00000) (1024K)]
  0x000002c9bb3c2860 WorkerThread "G1 Conc#0"                       [id=9748, stack(0x000000dd84f00000,0x000000dd85000000) (1024K)]
  0x000002c986f06290 WorkerThread "G1 Conc#1"                       [id=5188, stack(0x000000dd87300000,0x000000dd87400000) (1024K)]
  0x000002c9bb45d0a0 ConcurrentGCThread "G1 Refine#0"               [id=16136, stack(0x000000dd85000000,0x000000dd85100000) (1024K)]
  0x000002c9bb45d830 ConcurrentGCThread "G1 Service"                [id=15272, stack(0x000000dd85100000,0x000000dd85200000) (1024K)]
Total: 15

Threads with active compile tasks:
Total: 0

VM state: at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x00007ffa29e0cbc8] Threads_lock - owner thread: 0x000002c9d6f237f0
[0x00007ffa29e0ccc8] Heap_lock - owner thread: 0x000002c9bb39fb90

Heap address: 0x00000000f8000000, size: 128 MB, Compressed Oops mode: 32-bit

CDS archive(s) mapped at: [0x000002c9d7000000-0x000002c9d7c60000-0x000002c9d7c60000), size 12976128, SharedBaseAddress: 0x000002c9d7000000, ArchiveRelocationMode: 1.
Compressed class space mapped at: 0x000002c9d8000000-0x000002ca18000000, reserved size: 1073741824
Narrow klass base: 0x000002c9d7000000, Narrow klass shift: 0, Narrow klass range: 0x41000000

GC Precious Log:
 CardTable entry size: 512
 Card Set container configuration: InlinePtr #cards 5 size 8 Array Of Cards #cards 12 size 40 Howl #buckets 4 coarsen threshold 1843 Howl Bitmap #cards 512 size 80 coarsen threshold 460 Card regions per heap region 1 cards per card region 2048
 CPUs: 8 total, 8 available
 Memory: 8108M
 Large Page Support: Disabled
 NUMA Support: Disabled
 Compressed Oops: Enabled (32-bit)
 Heap Region Size: 1M
 Heap Min Capacity: 8M
 Heap Initial Capacity: 128M
 Heap Max Capacity: 128M
 Pre-touch: Disabled
 Parallel Workers: 8
 Concurrent Workers: 2
 Concurrent Refinement Workers: 8
 Periodic GC: Disabled

Heap:
 garbage-first heap   total reserved 131072K, committed 131072K, used 102751K [0x00000000f8000000, 0x0000000100000000)
  region size 1024K, 10 young (10240K), 4 survivors (4096K)
 Metaspace       used 14982K, committed 15360K, reserved 1114112K
  class space    used 1175K, committed 1344K, reserved 1048576K

Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts)

#73

Lightweight Java Gaming Library / Re: Buffer is not freed - OutO...

Last post by spasi - May 10, 2024, 09:48:53

Sounds like there's no problem with the buffer alloc/free then, the memory is consumed elsewhere. Probably in the OpenGL driver, which copies (and holds on to) the data passed to glBufferData.

usually hits error "OutOfMemory"

Btw, do you mean a java.lang.OutOfMemoryError or a process-OOM error followed by a JVM crash?

#74

Lightweight Java Gaming Library / Re: Buffer is not freed - OutO...

Last post by fireinwinterfell - May 10, 2024, 06:31:46

Hi spasi
Thanks for your ideas.

- Run the code as is, but do not call glBufferData.

->
Without glBufferData, memory consumption showing in Windows TaskManager is about X2 instead of X5-X10.I left indices, texture as is (still call glBufferData).

- Replace the temporary FloatBuffer with a single, fixed buffer that is being reused between calls.

->Memory consumption is a about 20 % lower (fixed FloatBuffer is 1024).

#75

Lightweight Java Gaming Library / Re: Buffer is not freed - OutO...

Last post by fireinwinterfell - May 09, 2024, 11:18:52

Thank God, you are in !!
I will try everyone of your ideas.

How many times do you call storeDataInAttributeList and with how much data?

thousands -> a few hundred thousand, a few 2d vertices (lines) to  about a few hundred (polylines).

#76

Lightweight Java Gaming Library / Re: Buffer is not freed - OutO...

Last post by spasi - May 09, 2024, 11:02:06

Hey fireinwinterfell,

The code above looks fine. The memory allocated in storeDataInFloatBuffer will always be freed by memFree. You could to isolate what exactly causes the apparent increase in memory usage, two ideas:

- Run the code as is, but do not call glBufferData.
- Replace the temporary FloatBuffer with a single, fixed buffer that is being reused between calls.

How many times do you call storeDataInAttributeList and with how much data?

#77

Lightweight Java Gaming Library / Re: Buffer is not freed - OutO...

Last post by fireinwinterfell - May 09, 2024, 09:43:35

Someone please help!
The heap showing in Visualvm is just fine but the Windows TaskManager shows that it consumes a lot.
If I use glVertex2f() to set vertex by vertex at rendering time it is just fine (200mb for my program) but when using buffers, it consumes about more than 2GB.

I knew that data goes off-heap but could you give me some hints to explicitly, effectively free it once it has been loaded GPU? I seem to be failed with MemoryUtil.memfree() and MemoryStack, too. Is it possibly a problem with machine with an integrated intel GPU?

#78

Lightweight Java Gaming Library / Buffer is not freed - OutOfMem...

Last post by fireinwinterfell - May 08, 2024, 02:41:20

Hi,
I am sorry if question is too naive, I am learning Opengl and lwjgl as well. When I try to load data using Buffer, the memory consumption is crazy too much it usually hits error "OutOfMemory". What is wrong with my code here:

private  void storeDataInAttributeList(int attributeNum, int size, float[] vertices) {
        int vboId = glGenBuffers();
        vbos.add(vboId);
        glBindBuffer(GL_ARRAY_BUFFER, vboId);

        FloatBuffer vertexBuffer = storeDataInFloatBuffer(vertices);
        glBufferData(GL_ARRAY_BUFFER, vertexBuffer, GL_STATIC_DRAW);
        MemoryUtil.memFree(vertexBuffer);

        GL30.glVertexAttribPointer(attributeNum, size, GL_FLOAT, false, 0, 0);
        glBindBuffer(GL_ARRAY_BUFFER, 0);


    }

    private FloatBuffer storeDataInFloatBuffer(float[] vertices) {
        FloatBuffer vertexBuffer =  MemoryUtil.memAllocFloat(vertices.length);
        vertexBuffer.put(vertices).flip();
        return vertexBuffer;
    }

#79

Lightweight Java Gaming Library / Re: Indie Fighting Game using ...

Last post by cpope9141 - April 02, 2024, 16:52:05

The March release of Area Zero (v0.10.0) is now available for download: https://ephemeraltechnicalarts.com/area-zero

Release Notes:
0.10.0 (3/19/2024)
  1. Adjustments made to all characters after 03/12 competitive bracket (v0.9.6)
     including frame data and hit/hurt/collision boxes.
    a. Niven's "Respecatable Lariat" is now fully vunerable, but hurt boxes are recessed.
    b. Niven's super no longer hits off the ground and only hits mid and high.
    c. Victor's "Gore" attack is no longer fully invulnerable on start up. Can now be hit low.
    d. B.P.V.'s "Frustrated Fists" start up increased.
    e. B.P.V.'s meter gain rate reduced to 90% (where it should have been).
    f. B.P.V.'s super damage reduced to 510 (down from 580).
    g. Violet's super projectile now has wider hit box.
    h. Richard's super whiff animation has longer duration.
  2. All hit pause durations increased by one frame.
  3. Any special attack can now be canceled into a super attack. Results vary, but more options available.
  4. In the case of a trade, the hit pause duration is now the maximum of the two trading attacks.

0.9.6 (03/10/2024)
  1. Add recovery to BPV's Ill Wheel Kick to prevent infinite.
  2. Fix typos in tutorials.
  3. Restore OTG for Richards regular Curb Stomp.
 
0.9.5 (03/07/2024)
  1. All of Niven's animations are color mapped.
  2. Round structure implemented.
  3. Taunt reworked to give each character unique bonuses. Bonuses listed in move lists.
  4. Improvements to audio code.
  5. Red/blue meter gain systems revised.
  6. Iteration on all character's moves and frame data.
  7. Iteration on run/dash velocities.
  8. Updated tutorials.

#80

Lightweight Java Gaming Library / Re: LWJGL <--> Renderdoc - No ...

Last post by bmcclint - April 02, 2024, 00:59:35

Found it...

TLDR...import org.lwjgl.opengl.ARBShaderObjects;

Apparently 'years' ago I created the shader logic and used the ARB imports and methods.  Not sure why...older LWJGL versions?  Anyway...for whatever reason, then iterating the list of shaders to compile using a stream lamba call, the context is NOT visible to the shader programs trying to compile.  I started by converting the lamba from a .stream().foreach() to a for(x : y) type operation and the exception moved into the abstract class where I called the ARBShaderObjects.glCreateProgramObjectARB() was executed.  That clued my off.  I remember thinking the logic was odd when I wrote it so...converted the logic to GL20.glCreateProgram() and the application loads now in RenderDoc.  I can capture frames, etc...

If anyone reads this and has an idea why the lambda caused what seemed like a new thread I'd love to hear.  Or why the ARB methods and the lambda did not play nice BUT only when trying to connect to RendeDoc, also please chime in.