When the length of the array exceeds 1073741824, it will cause the current thread to be in a blocked state about v HOT 8 OPEN

The main difference is that Java has a runtime, so extra checks like this can be done at runtime. If you want this with V, you will need to do the checks yourself, since V doesn't have a runtime.

If you really need to work with huge arrays like this, it would be best to declare a struct, with the @[heap] attribute on it to ensure it's never created on the stack. Put the array in the struct and always access it from there.

Otherwise, you can try increasing values with the V command line option -thread-stack-size <number of bytes> when you build/run your code, until you give a large enough value to make it work.

from v.

The main difference is that Java has a runtime, so extra checks like this can be done at runtime. If you want this with V, you will need to do the checks yourself, since V doesn't have a runtime.

If you really need to work with huge arrays like this, it would be best to declare a struct, with the @[heap] attribute on it to ensure it's never created on the stack. Put the array in the struct and always access it from there.

Otherwise, you can try increasing values with the V command line option -thread-stack-size <number of bytes> when you build/run your code, until you give a large enough value to make it work.

A brief description of my usage scenario at that time may help to understand. I tried to write a file transfer tool, using the API about network IO in the v standard library. I have implemented the file transfer function, and tested the transfer of files from several Mb to hundreds of Mb in size. Everything is normal. But when I tested a movie file transfer of about 2Gb in size, I waited about 30 minutes and still did not complete the transfer. I realized that there may be a problem, because using the operating system's Ctrl + V only takes about 30 seconds. At first I thought my code was not efficient, but after several hours of investigation, I found that the cause was the thread blocking caused by the addition of element code to the v array.
In addition, I also made a new discovery:
Extract part of the code:

...
file_path := 'C:\\Users\\TZ\\Desktop\\星际穿越.rmvb'
mut file := os.open( file_path ) or { eprintln( err.str() ) return }
defer { file.close() }
bytes := file.read_bytes( int( os.file_size( file_path ) ) )  //Module: os  method signature：`pub fn (f &File) read_bytes(size int) []u8`
println('file bytes len=${bytes.len}') //file bytes len=1911250979
...

The array length of the final printout is 1911250979, which obviously exceeds 1073741824. pub fn (f & File) read_bytes (size int) [] u8 in Module: os completely reads all the data and put a u8 [], and there are no blocking threads or out of memory or other problems. Prove that the array length is allowed to exceed 1073741824. As for the question I raised, it is most likely due to a bug in the implementation of the add element method (arr < < element) of the array.

from v.

It seems that the array length can't exceed 1073741824, #17958

from v.

Yes, it is a known problem, caused by V using 32 bit integers for the .len and .cap fields of its dynamic arrays, and the default strategy, for growing a dynamic array (doubling the allocated memory, when the capacity is reached).

from v.

In the read_bytes's case, the resulting array's capacity is known beforehand (by the file size), thus it is allocated right away, without needing to reallocate anything after that, and so the array can reach up to 2^31 - 1 = 2147483647 bytes in that way, without overflowing its .cap and .len .

from v.

As for the behavior, it should indeed better panic in that case, with a stacktrace, instead of looping indefinitely due to the overflow of the .cap field.
I have a local patch to do it, but I have to run more tests before making a PR:

from v.

I'm making int 64 bit on 64 bit systems right now. So this issue will be fixed soon.

from v.

Okay, I see.

from v.