Add less-allocating args variants

[steveklabnik]

Issue by mahkoh
Monday Oct 13, 2014 at 23:55 GMT

For earlier discussion, see rust-lang/rust#18021

This issue was labelled with: A-libs in the Rust repository

---

fn argv() -> CVec<*mut u8>

fn argv() -> Vec<&'static u8>

[frangio]

I'd like to take a stab at fixing this. Here are some thoughts.

What we want is probably an ArgsOsRef struct that implements Iterator<Item=&'static OsStr> and does no allocations. I'm not entirely confident this makes sense in all platforms but it might still be nice to have.

On Windows, the API to access command line arguments (GetCommandLineW and CommandLineToArgvW) necessarily puts them on the heap, so we would have to store them in a global variable to achieve a 'static lifetime.

The real opportunity to achieve zero allocation is on the unixes. But things are not so clear there either. The way Rust gets hold of command line arguments is different from the rest on OS X and iOS. For these two, they're obtained via system calls. On the rest they are copied onto the heap at program initialization. I'm not sure why this is so, and why not just the argv pointer is stored in a global variable. (Also see rust-lang/rust Issue #7756.)

However, for that to work we need to be sure that the strings passed to the program entry point by the operating system (argv) really do have a 'static lifetime in the Rust sense. As far as I can tell this is true since 'static is defined as "the lifetime of the program" and indeed the contents of argv should be valid throughout the program. I just want to be sure this is correct regarding Rust's lifetime semantics and for all concerned platforms.

I'd like to get some opinions on the matter.

[nagisa]

I'm not sure why this is so, and why not just the argv pointer is stored in a global variable.

Nobody prevents somebody from mutating memory containing the arguments. I guess we’re just being safe and putting arguments into a location we’re sure to own.

[frangio]

Right. Does anything prevent that from happening in OS X or iOS, though? As far as I understand the syscalls used return pointers to the original argument strings, not copies of them.

[nagisa]

Does anything prevent that from happening in OS X or iOS, though?

Not sure. They could be put into a read-only page or something. Speaking of that, we certainly could just mark the relevant page(s) of stack as read only on linux as well.

In my experience, however, finding the beginning of the stack is a pretty hard problem if you don’t control the _start (and we usually do not, because AFAIR there’s no other way to initialise C runtime without giving up _start to libc).

On Windows, the API to access command line arguments (GetCommandLineW and CommandLineToArgvW) necessarily puts them on the heap

I believe GetCommandLineW does not allocate and without much digging it seems to me that we could implement CommandLineToArgvW in a non-allocating and streaming manner as well, because rust string slices needn’t be null-terminated.

[alexcrichton]

@frangio this may be a relatively difficult API to add given the constraints here (and it's also not 100% clear how beneficial it would be). Some thoughts on this from me are:

• I don't think this can be exposed on Windows because any conversion from UCS2 to OsStr requires an allocation and/or conversion. In that sense this is already a Unix-specific API.
• I'm unsure what the lifetime of arguments passed to main are, but it's possible for threads to continue running for a small window after the main thread exits (e.g. while the main thread is tearing down TLS dtors and such). I would not personally be confident in saying that the arguments pointer is valid for this entire time, but it may be so!
• I, like @nagisa, am not sure if iOS or OSX guarantee the arguments won't be changed after they've been returned.

Overall I feel like this is a mirco-optimization which doesn't give us much bang for our buck. This is probably only called once in a program so in that sense moving all allocation out of the way isn't really buying us much in terms of performance. It may shed a dependency on the allocator, but it's pretty unlikely that the only call to allocation in the entire program is this one function.

[codyps]

• I don't think this can be exposed on Windows because any conversion from UCS2 to OsStr requires an allocation and/or conversion. In that sense this is already a Unix-specific API.

Does something prevent us from doing the conversion once and instead of returning copies of the converted values returning references to the converted values?

I'm unsure what the lifetime of arguments passed to main are, but it's possible for threads to continue running for a small window after the main thread exits (e.g. while the main thread is tearing down TLS dtors and such). I would not personally be confident in saying that the arguments pointer is valid for this entire time, but it may be so!

At the very least, on linux arguments are found in the initial process image. Allocation of memory for them is not in any way controlled by the main thread. They only will go away once the whole process is dead.

Nobody prevents somebody from mutating memory containing the arguments. I guess we’re just being safe and putting arguments into a location we’re sure to own.

If we're main, who else has a reference to the arguments?

The only thing I can think of is some non-standard libc access which grabs a pointer to it before main is called (program_name/program_invocation_name/__prognam_full in glibc).

I guess we need to be explicit about how far rust should go to workaround libc exposing references to data.

[alexcrichton]

It might be possible, yeah to do a one-time conversion on Windows, but at that point it doesn't seem to give any benefit over what we have today.

In terms of others having access to the data, I was thinking that various other threads (or native code) could be running and perhaps mutating. This sounds incredibly rare and broken anyway, but these worries continue to push me over to the side of "this probably isn't worth it"

[codyps]

It might be possible, yeah to do a one-time conversion on Windows, but at that point it doesn't seem to give any benefit over what we have today.

Well, it means that we avoid allocating and copying memory as much (assuming more than one call in rust is made to retrieve the args.

As this issue mentions, it also lets us be nicer to other non-windows (potentially avoiding all allocation) without exposing anything os specific.

In terms of others having access to the data, I was thinking that various other threads (or native code) could be running and perhaps mutating.

They would either need to be:

• rust threads abusing unsafe (and breaking it's contract) or using a some libc calls (also needing unsafe) to non-standard interfaces.
• c threads using those non-standard interfaces.

In both cases, we still need to define how far rust should go to workaround libc exposing references to data.

That said, even if we still require a single allocation+copy of the args, that is much better than having an allocation+copy of the args for every function that requests them. Adjusting the API also allows us to be more efficient in the future (by dropping the single alloc+copy).

[frangio]

At the very least, on linux arguments are found in the initial process image. Allocation of memory for them is not in any way controlled by the main thread. They only will go away once the whole process is dead.

Is this documented anywhere? Preferably in POSIX?

@alexcrichton I have to agree that this is probably only called once in a program, so yes the only benefit would be the ability to write programs that completely forgo dynamic memory. This sounds appealing to me coming from a C background where it's certainly possible, and I think it would be nice to have in Rust, but I understand the worry.

[codyps]

@frangio reading some specs now. C11 states that argv's lifetime is program duration, which makes it sound like we'll be fine on any conforming C11 implementation.

Text from n1570 (a c11 draft), in 5.1.2.2.1 Program startup paragraph 2:

— The parameters argc and argv and the strings pointed to by the argv array shall
be modifiable by the program, and retain their last-stored values between program
startup and program termination.

Edit: and program termination is defined as (in 5.1.2 Execution environments)

Program termination returns control to the execution
environment.

Which makes me almost certain we'll be fine. I suppose the real question is whether implementations conform to this portion of the standard.

Edit: the same language around argv exists all the way back in c89

[alexcrichton]

@frangio unfortunately I don't think this is the only point at which memory is dynamically allocated when a Rust program starts up typically. The normal startup routines in libc do various dynamic bits around dynamic loading and such, and we've got a few other locations for allocating memory here and there on the way into fn main.

[codyps]

Yep, I'd expect this to be one of a few steps in reducing and removing allocations at a rust program's startup.

[sfackler]

What are the concrete use cases that would be helped calling allocating 0 times in an executable?