Rust: 할당 자 특성 및 std :: heap

불행히도 RFC 토론에서 이것을 언급 할만큼 충분히주의를 기울이지 않았지만 realloc_in_place 는 grow_in_place 및 shrink_in_place 두 함수로 대체되어야한다고 생각합니다. 원인:

• 할당 크기가 증가하는지 감소하는지 여부를 알 수없는 단일 사용 사례 ( realloc 또는 realloc_in_place 구현 부족)는 생각할 수 없습니다. 더 전문화 된 방법을 사용하면 무슨 일이 일어나고 있는지 약간 더 명확하게 알 수 있습니다.
• 할당을 늘리고 줄이는 코드 경로는 근본적으로 다른 경향이 있습니다. 성장에는 인접한 메모리 블록이 사용 가능한지 여부를 테스트하고이를 요구하는 것이 포함되며 축소에는 적절한 크기의 하위 블록을 잘라 내고 해제하는 것이 포함됩니다. realloc_in_place 내부 분기 비용은 매우 적지 grow 및 shrink 를 사용하면 할당자가 수행해야하는 고유 한 작업을 더 잘 포착 할 수 있습니다.

이것들은 realloc_in_place 옆에 역 호환 적으로 추가 될 수 있지만, 이것은 기본적으로 어떤 함수가 다른 함수와 관련하여 구현되는지를 제한합니다.

일관성을 위해 realloc 는 grow 및 split 로 분할되기를 원할 수도 있지만, 제가 알고있는 오버로드 가능한 realloc 함수를 갖는 유일한 이점은 mmap 의 리맵 옵션을 사용할 수 있다는 것입니다.

또한 realloc 및 realloc_in_place 의 기본 구현을 약간 조정해야한다고 생각합니다. usable_size 를 확인하는 대신 realloc 먼저 시도해야합니다. realloc_in_place 차례로 realloc_in_place 는 기본적으로 사용 가능한 크기에 대해 확인하고 일반적으로 실패를 반환하는 대신 작은 변경의 경우 성공을 반환해야합니다.

이렇게하면 realloc 의 고성능 구현을 더 쉽게 생성 할 수 있습니다. 필요한 것은 realloc_in_place 개선하는 것뿐입니다. 그러나 usable_size 에 대한 검사가 계속 수행되므로 realloc 의 기본 성능은 저하되지 않습니다.

또 다른 문제 : fn realloc_in_place 의 문서에 따르면 Ok가 반환되면 ptr 이제 new_layout "적합"된다고 확신합니다.

나에게 이것은 주어진 주소의 정렬이 new_layout 암시하는 모든 제약 조건과 일치하는지 확인해야 함을 의미합니다.

그러나 기본 fn reallocate_inplace 함수에 대한 사양이 _it_가 이러한 검사를 수행한다는 것을 의미하지는 않습니다.

• 또한 fn realloc_in_place 를 사용하는 모든 클라이언트가 스스로 정렬이 작동하는지 확인하는 것이 합리적으로 보입니다 (실제로는 주어진 사용 사례에 대해 모든 곳에서 동일한 정렬이 필요하다는 것을 의미합니다 ...).

그래서의 구현한다 fn realloc_in_place 정말 주어진의 정렬 것을 확인하는 부담 할 ptr 그와 호환 new_layout ? _이 경우에 _ (이 방법 중) 해당 요구 사항을 호출자에게 다시 푸시하는 것이 좋습니다.

@gereeter 당신은 좋은 지적을합니다; 이슈 설명에 누적 된 체크리스트에 추가하겠습니다.

(이 시점에서 나는 할당 자 통합의 일부로 표준 컬렉션에 사용할 수 있도록 #[may_dangle] 지원이 beta 채널로 기차를 탈 때까지 기다리고 있습니다)

저는 Rust를 처음 사용하므로 다른 곳에서 논의 된 적이 있다면 용서하세요.

객체 별 할당자를 지원하는 방법에 대한 생각이 있습니까? 슬래브 할당 자 및 매거진 할당 자 와 같은 일부 할당자는 특정 유형에 바인딩되어 있으며, 새 객체를 생성하고, "해제 된"생성 된 객체를 캐싱하고 (실제로 삭제하지 않고) 이미 생성 된 캐시 된 객체를 반환하는 작업을 수행합니다. 필요한 경우 기본 메모리를 기본 할당 자에 해제하기 전에 개체를 삭제합니다.

현재,이 제안은 ObjectAllocator<T> 라인을 따라 아무것도 포함하지 않지만 매우 도움이 될 것입니다. 특히 매거진 할당 자 객체 캐싱 레이어 (위 링크)의 구현을 작업 중이며, Allocator 만 래핑하고 캐싱에서 객체를 생성하고 삭제하는 작업을 수행 할 수 있습니다. 다른 객체 할당 자 (예 : 슬래브 할당 자)를 래핑하고 진정으로 일반 캐싱 레이어가 될 수 있다면 좋을 것입니다.

객체 할당 자 유형 또는 특성이이 제안에 적합한 위치는 어디입니까? 향후 RFC를 위해 남겨 둘까요? 다른 것?

나는 이것이 아직 논의되지 않았다고 생각합니다.

자신의 ObjectAllocator<T> 작성한 다음 impl<T: Allocator, U> ObjectAllocator<U> for T { .. } 을 수행하여 모든 일반 할당자가 모든 객체에 대한 객체 별 할당 자 역할을 할 수 있습니다.

향후 작업은 일반 ole '(일반) 할당 자 대신 노드에 대한 특성을 사용하도록 컬렉션을 수정하는 것입니다.

뿡뿡

(이 시점에서 나는 할당 자 통합의 일부로 std 컬렉션에 사용할 수 있도록 베타 채널로 기차를 탈 수 있도록 # [may_dangle] 지원을 기다리고 있습니다)

이런 일이 일어난 것 같아요?

@ Ericson2314 예, 직접 작성하는 것은 실험적인 목적을위한 옵션이지만 상호 운용성 측면에서 표준화하면 훨씬 더 많은 이점이 있다고 생각합니다 (예를 들어 슬랩 할당 자도 구현할 계획이지만 내 코드의 타사 사용자가 내 잡지 캐싱 레이어와 함께 누군가 _else's_ slab 할당자를 사용할 수 있다면 좋습니다). 내 질문은 단순히 ObjectAllocator<T> 특성이나 그와 유사한 것이 논의 할 가치가 있는지 여부입니다. 다른 RFC에 가장 적합한 것 같지만? 단일 RFC에 얼마나 많은 것이 속하는지, 그리고 어떤 것이 별도의 RFC에 속하는 지에 대한 지침에별로 익숙하지 않습니다.

헉

객체 할당 자 유형 또는 특성이이 제안에 적합한 위치는 어디입니까? 향후 RFC를 위해 남겨 둘까요? 다른 것?

예, 또 다른 RFC입니다.

단일 RFC에 얼마나 많은 것이 속하는지, 그리고 어떤 것이 별도의 RFC에 속하는 지에 대한 지침에별로 익숙하지 않습니다.

RFC 자체의 범위에 따라 다르며, 작성자가 결정한 다음 모든 사람이 피드백을 제공합니다.

그러나 실제로 이것은 이미 승인 된 RFC에 대한 추적 문제이므로 확장 및 디자인 변경에 대해 생각하는 것은이 스레드에 대한 것이 아닙니다. RFC 저장소에서 새 항목을 열어야합니다.

@joshlf 아, ObjectAllocator<T> 이 (가) 특성이라고 생각했습니다. 특정 할당자가 아닌 특성의 프로토 타입을 의미했습니다. 예, 그 특성은 @steveklabnik이 말한 것처럼 자체 RFC의 장점이 있습니다.

@steveklabnik 그래 이제 토론은 다른 곳에서 더 좋을 것입니다. 그러나 @joshlf 는 허용되었지만 구현되지 않은 API 디자인에서 지금까지 예상치 못한 결함이

@ Ericson2314 네, 당신이 의미하는

@steveklabnik 좋네요. 내 자신의 구현을 살펴보고 좋은 아이디어처럼 보이면 RFC를 제출할 것입니다.

@joshlf 사용자 지정 할당자가 컴파일러 또는 표준 라이브러리에 들어갈 이유가 없습니다. 이 RFC가 도착하면 임의의 종류의 할당을 수행하는 자신의 크레이트를 쉽게 게시 할 수 있습니다 (jemalloc과 같은 완전한 할당 자도 맞춤 구현할 수 있습니다!).

@alexreg 이것은 특정 사용자 지정 할당 자에 관한 것이 아니라 특정 유형에 대해 매개 변수 인 모든 할당 자의 유형을 지정하는 특성입니다. 따라서 RFC 1398이 모든 저수준 할당 자의 유형 인 특성 ( Allocator )을 정의하는 것처럼, 모든 할당 자의 유형 인 특성 ( ObjectAllocator<T> )에 대해 묻습니다. T 유형의 객체를 할당 / 할당 해제하고 구성 / 삭제할 수 있습니다.

@alexreg 사용자 지정 개체 별 할당 자와 함께 표준 라이브러리 컬렉션 을 사용하는 것에 대한 초기 요점을 참조하십시오.

물론입니다.하지만 그것이 표준 라이브러리에 속할지는 모르겠습니다. 기능이나 유용성의 손실없이 다른 상자에 쉽게 들어갈 수 있습니다.

2017 년 1 월 4 일 21:59에 Joshua Liebow-Feeser [email protected] 은 다음과 같이 썼습니다.

@alexreg https://github.com/alexreg 이것은 특정 사용자 지정 할당 자에 관한 것이 아니라 특정 유형에 대해 매개 변수 인 모든 할당 자의 유형을 지정하는 특성입니다. 따라서 RFC 1398이 하위 수준 할당 자의 유형 인 특성 (할당 자)을 정의하는 것처럼 특성 (ObjectAllocator)에 대해 묻습니다.) 이는 T 유형의 객체를 할당 / 할당 해제하고 구성 / 삭제할 수있는 모든 할당 자의 유형입니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270499064 에서 보거나 https://github.com/notifications/unsubscribe-auth/ 스레드를 음소거합니다.

임의의 사용자 지정 할당 자와 함께 표준 라이브러리 컬렉션 (모든 힙 할당 값)을 사용하고 싶다고 생각합니다. 즉, 특정 객체에 국한되지 않습니다.

2017 년 1 월 4 일 22:01에 John Ericson [email protected] 은 다음과 같이 썼습니다.

@alexreg https://github.com/alexreg 사용자 지정 개체 별 할당 자와 함께 표준 라이브러리 컬렉션을 사용하는 것에 대한 초기 요점을 참조하십시오.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270499628 에서 보거나 https://github.com/notifications/unsubscribe-auth/ 스레드를 음소거합니다.

물론입니다.하지만 그것이 표준 라이브러리에 속할지는 모르겠습니다. 기능이나 유용성의 손실없이 다른 상자에 쉽게 들어갈 수 있습니다.

예,하지만 일부 표준 라이브러리 기능을 사용하고 싶을 것입니다 (예 : @ Ericson2314가 제안한 것).

임의의 사용자 지정 할당 자와 함께 표준 라이브러리 컬렉션 (모든 힙 할당 값)을 사용하고 싶다고 생각합니다. 즉, 특정 객체에 국한되지 않습니다.

이상적으로는 두 가지 유형을 모두 허용하는 것이 좋습니다. 개체 별 캐싱을 사용하면 매우 큰 이점이 있습니다. 예를 들어, 슬래브 할당과 매거진 캐싱은 모두 매우 중요한 성능 이점을 제공합니다. 궁금한 점이 있으면 위에서 링크 한 문서를 참조하십시오.

그러나 객체 할당 자 특성은 단순히 일반 할당 자 특성의 하위 특성 일 수 있습니다. 제가 생각하는 한 간단합니다. 물론 특정 유형의 할당자는 범용 할당 자보다 더 효율적일 수 있지만 컴파일러 나 표준은이 사실을 알 필요가 없습니다 (실제로는 알 필요가 없습니다).

2017 년 1 월 4 일 22:13에 Joshua Liebow-Feeser [email protected] 은 다음과 같이 썼습니다.

물론입니다.하지만 그것이 표준 라이브러리에 속할지는 모르겠습니다. 기능이나 유용성의 손실없이 다른 상자에 쉽게 들어갈 수 있습니다.

예,하지만 일부 표준 라이브러리 기능을 사용하고 싶을 것입니다 (예 : @ Ericson2314 https://github.com/Ericson2314 제안).

임의의 사용자 지정 할당 자와 함께 표준 라이브러리 컬렉션 (모든 힙 할당 값)을 사용하고 싶다고 생각합니다. 즉, 특정 객체에 국한되지 않습니다.

이상적으로는 두 가지 유형을 모두 허용하는 것이 좋습니다. 개체 별 캐싱을 사용하면 매우 큰 이점이 있습니다. 예를 들어, 슬래브 할당과 매거진 캐싱은 모두 매우 중요한 성능 이점을 제공합니다. 궁금한 점이 있으면 위에서 링크 한 문서를 참조하십시오.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270502231 에서 보거나 https://github.com/notifications/unsubscribe-auth/ 스레드를 음소거합니다.

그러나 객체 할당 자 특성은 단순히 일반 할당 자 특성의 하위 특성 일 수 있습니다. 제가 생각하는 한 간단합니다. 물론 특정 유형의 할당자는 범용 할당 자보다 더 효율적일 수 있지만 컴파일러 나 표준은이 사실을 알 필요가 없습니다 (실제로는 알 필요가 없습니다).

아, 문제는 의미가 다르다는 것입니다. Allocator 는 원시 바이트 Blob을 할당하고 해제합니다. 반면에 ObjectAllocator<T> 는 이미 생성 된 객체를 할당하고 이러한 객체를 삭제하는 역할도합니다 (새로 할당 된 객체를 생성하는 과정에서 나중에 전달 될 수있는 생성 된 객체를 캐시 할 수있는 기능 포함). , 비싸다). 특성은 다음과 같습니다.

trait ObjectAllocator<T> {
    fn alloc() -> T;
    fn free(t T);
}

이것은 메서드가 원시 포인터를 처리하고 유형 개념이없는 Allocator 와 호환되지 않습니다. 또한 Allocator s를 사용하면 먼저 drop 개체를 해제하는 것은 호출자의 책임입니다. 이것은 정말 중요합니다. T 유형에 대해 알면 ObjectAllocator<T> 에서 T 의 drop 메서드 호출과 같은 작업을 수행 할 수 있으며 free(t) 는 t 를 free 하고, 호출자는 먼저 t _cannot_ 드롭합니다. 대신 ObjectAllocator<T> 의 책임입니다. 기본적으로이 두 가지 특성은 서로 호환되지 않습니다.

아 맞다. 나는이 제안이 이미 이와 같은 것을 포함한다고 생각했다. 즉, 바이트 수준에 대한“상위 수준”할당 자이다. 이 경우 완벽하게 공정한 제안!

2017 년 1 월 4 일 22:29에 Joshua Liebow-Feeser [email protected] 은 다음과 같이 썼습니다.

그러나 객체 할당 자 특성은 단순히 일반 할당 자 특성의 하위 특성 일 수 있습니다. 제가 생각하는 한 간단합니다. 물론 특정 유형의 할당자는 범용 할당 자보다 더 효율적일 수 있지만 컴파일러 나 표준은이 사실을 알 필요가 없습니다 (실제로는 알 필요가 없습니다).

아, 문제는 의미가 다르다는 것입니다. Allocator는 원시 바이트 Blob을 할당하고 해제합니다. ObjectAllocator반면에는 이미 생성 된 객체를 할당하고 이러한 객체를 삭제하는 역할도합니다 (비용이 많이 드는 새로 할당 된 객체를 생성하는 과정에서 나중에 전달 될 수있는 생성 된 객체를 캐시 할 수있는 기능 포함). 특성은 다음과 같습니다.

특성 ObjectAllocator{
fn alloc ()-> T;
fn free (t T);
}
이것은 메서드가 원시 포인터를 처리하고 유형 개념이없는 Allocator와 호환되지 않습니다. 또한 Allocator를 사용하면 먼저 해제되는 객체를 삭제하는 것은 호출자의 책임입니다. 이것은 정말 중요합니다-T 타입에 대해 아는 것은 ObjectAllocator를 허용합니다call T의 drop 메소드와 같은 작업을 수행하고 free (t)가 t를 free로 이동하기 때문에 호출자는 t를 먼저 드롭 할 수 없습니다. 대신 ObjectAllocator입니다.의 책임. 기본적으로이 두 가지 특성은 서로 호환되지 않습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270505704 에서 보거나 https://github.com/notifications/unsubscribe-auth/ 스레드를 음소거합니다.

@alexreg 아 예, 저도 그렇게 바랬습니다 :) 아 글쎄-다른 RFC를 기다려야 할 것입니다.

예, RFC를 시작하면 많은 지원을받을 수 있습니다! 그리고 설명해 주셔서 감사합니다 (이 RFC의 세부 사항을 전혀 파악하지 못했습니다).

2017 년 1 월 5 일 00:53에 Joshua Liebow-Feeser [email protected] 은 다음과 같이 썼습니다.

@alexreg https://github.com/alexreg 아 예, 저도 그렇게 바랬습니다. :) 아 글쎄-다른 RFC를 기다려야 할 것입니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270531535 에서 보거나 https://github.com/notifications/unsubscribe-auth/ 스레드를 음소거합니다.

사용자 지정 할당자를 테스트하기위한 상자가 유용합니다.

내가 명백한 것을 놓친다면 용서하십시오. 그러나이 RFC에 설명 된 Layout 특성이 Copy 뿐만 아니라 Clone 를 구현하지 않는 이유가 있습니까? 현물 상환 지불?

나는 아무것도 생각할 수 없다.

프로세스 후반에이 문제를 제기하게되어 죄송 합니다만 ...

메서드가 아니라 함수 인 dealloc -like 함수에 대한 지원을 추가 할 가치가 있습니까? 아이디어는 메모리에서 부모 할당자가있는 포인터에서 추론 할 수 있도록 정렬을 사용하여 명시적인 할당 자 참조 없이도 해제 할 수있는 것입니다.

이것은 사용자 지정 할당자를 사용하는 데이터 구조에 큰 도움이 될 수 있습니다. 이렇게하면 할당 자 자체에 대한 참조를 유지하지 않고 올바른 dealloc 함수를 호출 할 수 있도록 할당 자의 _type_에 대한 매개 변수 만 있으면됩니다. 예를 들어, Box 가 결국 사용자 지정 할당자를 지원하도록 수정되면 참조를 저장하기 위해 두 단어로 확장해야하는 것과는 반대로 단일 단어 (포인터 만) 만 유지할 수 있습니다. 할당 자에게도.

관련 메모에서 전역 할당자를 허용하기 위해 비 메서드 alloc 함수를 지원하는 것도 유용 할 수 있습니다. 이것은 메서드가 아닌 dealloc 함수로 멋지게 구성됩니다. 전역 할당 자의 경우 단일 정적 인스턴스 만 있기 때문에 할당 자에 대한 포인터 추론을 수행 할 필요가 없습니다. 전체 프로그램에 대한 할당 자.

@joshlf 현재 디자인에서는 할당자가 (크기가 0 인) 단위 유형 (예 : struct MyAlloc; 을 사용하여 Allocator 특성을 구현할 수 있습니다.
항상 참조 또는 아무것도 저장하지 않는 것은 할당자를 값으로 저장하는 것보다 덜 일반적 입니다.

직접 포함 된 유형의 경우 사실임을 알 수 있지만 데이터 구조가 대신 참조를 유지하기로 결정하면 어떨까요? 크기가 0 인 유형에 대한 참조가 공백을 차지합니까? 즉, 다음이있는 경우 :

struct Foo()

struct Blah{
    foo: &Foo,
}

Blah 크기가 0입니까?

실제로 가능하더라도 할당 자의 크기가 0이되는 것을 원하지 않을 수 있습니다. 예를 들어, _from_을 할당하는 크기가 0이 아닌 할당자가있을 수 있지만 원래 할당 자에 대해 알지 못하는 상태에서 객체를 해제 할 수있는 기능이 있습니다. 이것은 Box 가 한 단어 만 사용하도록 만드는 데 여전히 유용합니다. 할당자를 인수로 취해야하는 Box::new_from_allocator 와 같은 것이 있습니다.-크기가 0이 아닌 할당 자일 수 있습니다.하지만 할당자가 원래 할당 자 참조없이 해제를 지원하면 반환 된 Box<T> 는 원래 Box::new_from_allocator 호출에서 전달 된 할당 자에 대한 참조를 저장하지 않을 수 있습니다.

예를 들어, 할당 한 크기가 0이 아닌 할당자가 있지만 원래 할당 자에 대해 알지 못하는 상태에서 객체를 해제 할 수있는 기능이있을 수 있습니다.

나는 기본적으로 이러한 이유로 인해 (둘을 연결하는 연관 유형과 함께) 분리 된 할당 자 및 할당 해제 자 특성을 인수 분해하는 것을 오래 전에 제안했던 것을 기억합니다.

컴파일러가 이러한 할당자를 사용하여 할당을 최적화하도록 허용해야합니까?

컴파일러가 이러한 할당자를 사용하여 할당을 최적화하도록 허용해야합니까?

@Zoxc 무슨 뜻이야?

나는 기본적으로 이러한 이유로 인해 (둘을 연결하는 연관 유형과 함께) 분리 된 할당 자 및 할당 해제 자 특성을 인수 분해하는 것을 오래 전에 제안했던 것을 기억합니다.

후손을 위해이 진술을 명확히하겠습니다 (오프라인에서 @ Ericson2314 에 대해 이야기했습니다). 아이디어는 Box 가 할당 해제 자에서만 매개 변수가 될 수 있다는 것입니다. 따라서 다음 구현을 가질 수 있습니다.

trait Allocator {
    type D: Deallocator;

    fn get_deallocator(&self) -> Self::D;
}

trait Deallocator {}

struct Box<T, D: Deallocator> {
    ptr: *mut T,
    d: D,
}

impl<T, D: Deallocator> Box<T, D> {
    fn new_from_allocator<A: Allocator>(x: T, a: A) -> Box<T, A::D> {
        ...
        Box {
            ptr: ptr,
            d: a.get_deallocator()
        }
    }
}

이렇게하면 new_from_allocator 호출 할 때 A::D 이 크기가 0 인 유형이면 Box<T, A::D> 의 d 필드가 0 크기를 차지하므로 결과 Box<T, A::D> 는 단일 단어입니다.

이것이 언제 착륙 할 것인지에 대한 타임 라인이 있습니까? 나는 할당 자 관련 작업을하고 있는데,이 물건이 내가 구축 할 수 있다면 좋을 것입니다.

관심이 있다면 몇 가지주기를 빌려 주면 좋겠지 만, 상대적으로 Rust를 처음 접해 보았 기 때문에 초보자의 코드를 검토해야한다는 점에서 관리자에게 더 많은 작업을 할 수 있습니다. 나는 누구의 발끝을 밟고 싶지도 않고 사람들을 위해 더 많은 일을하고 싶지도 않습니다.

좋아, 우리는 최근 에 할당 자의 상태를 평가하기 위해 만났고 이것에 대한 좋은 소식도 있다고 생각합니다! 이러한 API에 대한 지원이 아직 libstd에 포함되지 않은 것 같습니다.하지만 모든 사람들은 여전히 ​​언제라도 이러한 API에 만족하고 있습니다!

우리가 논의한 한 가지는 가능한 추론 문제로 인해 모든 libstd 유형을 변경하는 것이 약간 시기상조 일 수 있지만 그에 관계없이 Allocator 트레이 트와 Layout 하는 것이 좋은 생각처럼 보입니다 std::heap 모듈의 Layout 유형!

@joshlf 여기에서 돕고 싶다면 환영 이상이 될 것이라고 생각합니다! 첫 번째 조각은이 RFC의 기본 유형 / 특성을 표준 라이브러리로 가져 와서 libstd에서 컬렉션을 실험하고 가지고 놀 수 있습니다.

@alexcrichton 링크가 깨진 것 같아요? 여기를 다시 가리 킵니다.

우리가 논의한 한 가지는 가능한 추론 문제로 인해 모든 libstd 유형을 변경하는 것이 약간 시기적 일 수 있다는 것입니다.

특성을 추가하는 것은 좋은 첫 번째 단계이지만 기존 API를 사용하여 리팩토링하지 않으면 사용량이 많지 않습니다. https://github.com/rust-lang/rust/issues/27336#issuecomment -300721558에서 즉시 파사드 뒤의 상자를 리팩터링 할 수 있지만 std 에 newtype 래퍼를 추가 할 수 있다고 제안합니다. 성가신 일이지만 진전을 이룰 수 있습니다.

@alexcrichton 객체 할당자를 가져 오는 프로세스는 무엇입니까? 지금까지의 내 실험 (곧 공개 될 예정입니다. 호기심이 있으시면 비공개 GH 저장소에 추가 할 수 있습니다). 그리고 여기 에서 논의한 결과 할당 자 특성과 객체 사이에 거의 완벽한 대칭이있을 것이라고 믿게되었습니다. 할당 자 특성. 예, 당신은 (I 변경과 같이해야합니다 Address 로를 *mut u8 와 대칭을 위해 *mut T 에서 ObjectAllocator<T> 우리는 아마로 끝날 것 Address<T> 또는 이와 유사한 것) :

unsafe trait Allocator {
    unsafe fn alloc(&mut self, layout: Layout) -> Result<*mut u8, AllocErr>;
    unsafe fn dealloc(&mut self, ptr: *mut u8, layout: Layout);
}

unsafe trait ObjectAllocator<T> {
    unsafe fn alloc(&mut self) -> Result<*mut T, AllocErr>;
    unsafe fn dealloc(&mut self, ptr: *mut T);
}

따라서 할당 자와 개체 할당자를 동시에 실험하는 것이 유용 할 수 있다고 생각합니다. 그래도 이것이 적절한 장소인지 또는 다른 RFC가 있어야하는지, 아니면 최소한 별도의 PR이 있어야하는지 확실하지 않습니다.

오, 여기 에 글로벌 할당 자에 대한 정보도있는 링크를 의미했습니다. @joshlf 는 당신이 생각하는 것입니까?

@alexcrichton 이 Allocator 특성 및 Layout 유형을 제공하는 PR을 원하는 것처럼 들립니다 . libstd 컬렉션에 통합되지 않은 경우에도 마찬가지입니다.

제대로 이해하면 PR을 올릴 수 있습니다. 적어도 RawVec 및 Vec 프로토 타입과의 통합을 계속 시도했기 때문에 그렇게하지 않았습니다. (이 시점에서 RawVec 작업을 완료했지만 Drain 및 IntoIter 와 같은 다른 많은 구조로 인해 Vec 이 (가) 조금 더 어렵습니다. IntoIter 등 ...)

실제로 내 현재 브랜치는 실제로 빌드 할 수있는 것처럼 보이므로 (그리고 RawVec 와의 통합 테스트를 통과했습니다) 그래서 계속해서 게시했습니다. # 42313

@hawkw가 물었습니다.

내가 명백한 것을 놓친다면 용서하십시오. 그러나이 RFC에 설명 된 레이아웃 특성이 단지 POD이기 때문에 복제와 복제를 구현하지 않는 이유가 있습니까?

Layout Copy 가 아닌 Clone Layout 만 구현하도록 만든 이유는 Layout 유형에 더 많은 구조를 추가 할 수있는 가능성을 열어두고 싶었 기 때문입니다. 특히, 할당자가 다음 옵션을 가질 수 있도록 Layout 구성에 사용 된 유형 구조 (예 : struct { x: u8, y: [char; 215] } 의 16 배열)를 추적하려고 시도하는 데 여전히 관심이 있습니다. 현재 콘텐츠가 어떤 유형에서 작성되는지보고하는 계측 루틴을 노출합니다.

이것은 거의 확실하게 선택적 기능이어야합니다. 즉, 조수가 개발자가 유형이 풍부한 Layout 생성자를 사용하도록 강요하는 것에 반대하는 것처럼 보입니다. 따라서이 형식의 모든 계측은 유형 정보가없는 할당을 처리하기 위해 "알 수없는 메모리 블록"범주와 같은 것을 포함해야합니다.

그럼에도 불구하고 이와 같은 기능이 제가 Layout Copy 구현하도록 선택하지 않은 주된 이유 Copy 구현이 Layout 자체에 대한 조기 제약이 될 것이라고 생각했습니다.

트윗 담아 가기

@pnkfelix 가 이것을 다루고 있고 PR이 견인을 받고있는 것처럼 보입니다. 지금 살펴보고 댓글을 달고 있는데 멋지네요!

현재 Allocator::oom 의 서명은 다음과 같습니다.

    fn oom(&mut self, _: AllocErr) -> ! {
        unsafe { ::core::intrinsics::abort() }
    }

그것은 한 내 관심을 끌게 게코이 적어도 잘 OOM에로 할당 크기를 알고 좋아하는,하지만. OOM이 발생하는 이유에 대해 Option<Layout> 와 같은 컨텍스트를 추가하기 위해 안정화 할 때이를 고려할 수 있습니다.

뿡 빵뀨
여러 oom_xxx 변형이나 다른 인수 유형의 열거 형을 갖는 것이 가치가 있을까요? 실패 할 수있는 메서드에 대한 몇 가지 다른 서명이 있습니다 (예 : alloc 는 레이아웃, realloc 은 포인터, 원본 레이아웃, 새 레이아웃 등). oom -like 메소드가 이들 모두에 대해 알고 싶어하는 경우입니다.

@joshlf 맞습니다 , 예,하지만 그것이 유용한 지 확실하지 않습니다. 기능을 추가하고 싶지는 않습니다. 기능을 추가 할 수 있기 때문에 계속해서 동기를 부여 받아야합니다.

여기서 안정화의 요점은 " fn dealloc 제공된 정렬에 대한 요구 사항을 확인"하는 것입니다. Windows에서 dealloc 의 현재 구현 은 align 를 사용하여 방법을 결정합니다. 올바르게 무료입니다. @ruuda 이 사실에 관심이있을 수 있습니다.

여기서 안정화의 요점은 " fn dealloc 제공된 정렬에 대한 요구 사항을 확인"하는 것입니다. Windows에서 dealloc 의 현재 구현은 align 를 사용하여 방법을 결정합니다. 올바르게 무료입니다.

예, 이것이 제가 처음에 이런 일을 겪은 방법이라고 생각합니다. 이 때문에 내 프로그램이 Windows에서 충돌했습니다. HeapAlloc 는 정렬을 보장하지 않기 때문에 allocate 는 더 큰 영역을 할당하고 헤더에 원래 포인터를 저장하지만 최적화로 정렬 요구 사항이 충족된다면 피할 수 있습니다. 이 최적화를 잃지 않고 HeapAlloc 를 정렬을 필요로하지 않는 정렬 인식 할당 자로 변환하는 방법이 있는지 궁금합니다.

루다

HeapAlloc 은 정렬을 보장하지 않습니다.

32 비트의 경우 8 바이트 또는 64 비트의 경우 16 바이트의 최소 정렬 보장을 제공하지만 그보다 높은 정렬을 보장하는 방법은 제공하지 않습니다.

Windows의 CRT에서 제공하는 _aligned_malloc 는 더 높은 정렬의 할당을 제공 할 수 있지만 특히 _aligned_free 를 사용하여 free _aligned_free 와 쌍을 이루어야합니다 . 따라서 할당이 malloc 또는 _aligned_malloc 를 통해 수행되었는지 여부를 모르는 경우 Windows에서 alloc_system 이 (가) 수행 된 것과 동일한 수수께끼에 갇히게됩니다. deallocate 대한 정렬을 알고 있습니다. CRT는 free 와 쌍을 이룰 수있는 표준 aligned_alloc 기능을 제공하지 않으므로 Microsoft조차도이 문제를 해결할 수 없었습니다. (비록 그것이 C11 기능이며, 그 약한 인수 그래서 마이크로 소프트는 C11를 지원하지 않습니다.)

deallocate 은 (는) 정렬에만 신경을 써서 정렬이 과도하게 정렬되었는지 여부를 알기 때문에 실제 값 자체는 관련이 없습니다. 진정으로 정렬에 독립적 인 deallocate 을 원한다면 모든 할당을 과도하게 정렬 할 수 있지만 작은 할당에 많은 메모리를 낭비하게됩니다.

@alexcrichton 은 다음 과 같이 썼습니다 .

현재 Allocator::oom 의 서명은 다음과 같습니다.

    fn oom(&mut self, _: AllocErr) -> ! {
        unsafe { ::core::intrinsics::abort() }
    }

그것은 한 내 관심을 끌게 게코이 적어도 잘 OOM에로 할당 크기를 알고 좋아하는,하지만. OOM이 발생하는 이유에 대해 Option<Layout> 와 같은 컨텍스트를 추가하기 위해 안정화 할 때이를 고려할 수 있습니다.

AllocErr 에는 AllocErr::Exhausted 변형의 Layout 가 이미 포함 되어 있습니다. Layout 를 AllocErr::Unsupported 변형에도 추가 할 수 있는데, 이는 고객의 기대치 측면에서 가장 간단 할 것이라고 생각합니다. ( AllocErr 열거 형 자체의 측면을 어리석게 늘리는 단점이 있지만, 걱정할 필요는 없습니다 ...)

오, 그게 전부라고 생각합니다. @pnkfelix를 수정 해 주셔서 감사합니다!

https://github.com/rust-lang/rust/pull/42727 토지 이후에 발생하므로 일반적으로 std::heap 에 대한 추적 문제에 대해이 문제의 용도를 변경하기 시작합니다. 이를 위해 몇 가지 다른 관련 문제를 마무리하겠습니다.

컬렉션 변환에 대한 추적 문제가 있습니까? 이제 PR이 병합되었으므로

• 관련 오류 유형에 대해 논의
• 컬렉션을 로컬 할당자를 사용하도록 변환하는 방법에 대해 논의합니다 (특히 관련 오류 유형 활용).

https://github.com/rust-lang/rust/issues/42774 를 열어 Alloc 표준 컬렉션 통합을 추적했습니다. std::heap 모듈의 초기 패스와는 별도의 안정화 트랙에있을 가능성이있는 libs 팀의 역사적 논의를 통해.

할당 관련 문제를 검토하는 동안 나는 또한 우연히 https://github.com/rust-lang/rust/issues/30170 다시 잠시 @pnkfelix있다. OSX 시스템 할당자가 높은 정렬로 버그가있는 것처럼 보이며 jemalloc으로 해당 프로그램을 실행할 때 적어도 Linux에서 할당 해제 중에 segfaulting이 발생합니다. 안정화 중에 고려할 가치가 있습니다!

0 크기 할당이 요청 된 정렬과 일치해야하는지 여부에 대한 구체적인 질문을 논의하기 위해 # 42794를 열었습니다.

(오 잠깐, 크기가 0 인 할당은 사용자 할당 자에서 불법 입니다!)

alloc::heap::allocate 함수와 친구들이 이제 Nightly에서 사라졌기 때문에이 새로운 API를 사용하도록 Servo를 업데이트했습니다. 이것은 diff의 일부입니다.

-use alloc::heap;
+use alloc::allocator::{Alloc, Layout};
+use alloc::heap::Heap;

-        let ptr = heap::allocate(req_size as usize, FT_ALIGNMENT) as *mut c_void;
+        let layout = Layout::from_size_align(req_size as usize, FT_ALIGNMENT).unwrap();
+        let ptr = Heap.alloc(layout).unwrap() as *mut c_void;

저는 인체 공학이 좋지 않다고 생각합니다. 우리는 하나의 항목을 가져 오는 것에서 두 개의 다른 모듈에서 3 개의 항목을 가져 왔습니다.

• allocator.alloc(Layout::from_size_align(…)) 대한 편리한 방법을 사용하는 것이 합리적입니까?
• <Heap as Alloc>::_ 메서드를 무료 함수 또는 고유 메서드로 사용할 수 있도록하는 것이 합리적일까요? (가져올 항목을 하나 줄이려면 Alloc 트레이 트가 필요합니다.)

또는 Alloc 특성이 전주곡에 포함될 수 있습니까? 아니면 사용 사례의 틈새 시장입니까?

@SimonSapin IMO는 이러한 저수준 API의 인체 공학을 최적화하는 데 별 의미가 없습니다.

뿡 빵뀨

저는 인체 공학이 좋지 않다고 생각합니다. 우리는 하나의 항목을 가져 오는 것에서 두 개의 다른 모듈에서 3 개의 항목을 가져 왔습니다.

나는 내 코드베이스에서 똑같은 느낌을 받았다. 지금은 꽤 투박하다.

allocator.alloc(Layout::from_size_align(…))? 대한 편리한 방법이있는 것이 합리적일까요?

Alloc 특성을 의미합니까, 아니면 Heap 만을 의미합니까? 여기서 고려해야 할 한 가지는 이제 세 번째 오류 조건이 있다는 것입니다. Layout::from_size_align 는 Option 반환하므로 할당 할 때 얻을 수있는 일반 오류에 추가하여 None 를 반환 할 수 있습니다. .

또는 Alloc 특성이 전주곡에 포함될 수 있습니까? 아니면 사용 사례의 틈새 시장입니까?

IMO는 이러한 저수준 API의 인체 공학을 최적화하는 데 별 의미가 없습니다.

나는 그것이 서곡에 넣기에는 너무 낮은 수준이라는 데 동의하지만 여전히 인체 공학을 최적화하는 데 가치가 있다고 생각합니다 (적어도 이기적으로, 그것은 정말 성가신 리 팩터 😝).

@SimonSapin 전에 OOM을 std 에서는 std::heap 모듈에서 세 가지 유형을 모두 사용할 수 있습니다 (하나의 모듈에 있어야 함). 또한 이전에는 크기가 넘친 경우를 처리하지 않았습니까? 아니면 제로 크기 유형?

전에 OOM을 다루지 않았습니까?

alloc::heap::allocate 함수는 Result 없이 포인터를 반환했으며 OOM 처리에서 선택 사항을 남기지 않았습니다. 나는 그것이 프로세스를 중단했다고 생각합니다. 이제 스레드를 당황시키기 위해 .unwrap() 를 추가했습니다.

하나의 모듈에 있어야합니다.

이제 heap.rs 에 pub use allocator::*; 포함되어 있습니다. 내가 클릭 할 때 Alloc 위한 rustdoc 페이지에 나와있는 IMPL에 Heap I가 전송 된 alloc::allocator::Alloc .

나머지는 조사하지 않았습니다. 몇 년 전에 작성된 코드 더미를 새로운 컴파일러로 이식하고 있습니다. 저는 이것이 C 라이브러리 인 FreeType의 콜백이라고 생각합니다.

존재했을 때 alloc :: heap :: allocate 함수는 결과없이 포인터를 반환하고 OOM 처리에 선택 사항을 남기지 않았습니다.

그것은 당신에게 선택권을주었습니다. 반환 된 포인터는 힙 할당자가 할당에 실패했음을 나타내는 널 포인터 일 수 있습니다. 이것이 제가 Result 로 전환하여 사람들이 그 사건을 처리하는 것을 잊지 않도록 기뻐하는 이유입니다.

오 글쎄요, 아마도 FreeType이 결국 null 검사를했을 수도 있습니다. 어쨌든, 예, 결과를 반환하는 것은 좋습니다.

# 30170 및 # 43097을 감안할 때 사용자 가 정렬을 요청할 1 << 32 지정하여 엄청나게 큰 정렬로 OS X 문제를 해결하고 싶습니다.

이 시행 한 아주 쉬운 방법 : 변경 Layout 인터페이스 그래서 align a로 표시된다 u32 대신의 usize .

@alexcrichton에 대한 생각이 있습니까? 이 일을하는 PR을해야합니까?

@pnkfelix Layout::from_size_align 은 여전히 usize 취하고 u32 오버플로시 오류를 반환합니다.

@SimonSapin 정적 전제 조건이> = 1 << 32 값을 전달하는 것이 안전하지 않은 경우 usize 정렬을 계속 사용하는 이유는 무엇입니까?

그리고 대답이 "일부 할당자가 정렬을 지원할 수 있습니다> = 1 << 32 "이면 현재 상태로 돌아가서 제 제안을 무시할 수 있습니다. 내 제안의 요점은 같은 의견에 기본적으로 "1"인 이 하나

std::mem::align_of 는 usize 반환하기 때문에

@SimonSapin 아, 좋은 오래된 안정적인 API ... 한숨.

@pnkfelix 를 1 << 32 제한하는 것이 합리적으로 보입니다!

@rfcbot fcp 병합

좋아,이 특성과 그 유형은 한동안 구워졌고 또한 처음부터 표준 컬렉션의 기본 구현이었습니다. 저는 특히 보수적 인 초기 오퍼링으로 시작하는 것을 제안합니다. 즉, 다음 인터페이스 만 안정화하는 것입니다.

pub struct Layout { /* ... */ }

extern {
    pub type void;
}

impl Layout {
    pub fn from_size_align(size: usize, align: usize) -> Option<Layout>;
    pub unsafe fn from_size_align_unchecked(size: usize, align: usize) -> Layout;

    pub fn size(&self) -> usize;
    pub fn align(&self) -> usize;
}

pub unsafe trait Alloc {
    unsafe fn alloc(&mut self, layout: Layout) -> *mut void;
    unsafe fn alloc_zeroed(&mut self, layout: Layout) -> *mut void;
    unsafe fn dealloc(&mut self, ptr: *mut void, layout: Layout);

    // all other methods are default and unstable
}

/// The global default allocator
pub struct Heap;

impl Alloc for Heap {
    // ...
}

impl<'a> Alloc for &'a Heap {
    // ...
}

/// The "system" allocator
pub struct System;

impl Alloc for System {
    // ...
}

impl<'a> Alloc for &'a System {
    // ...
}

pub struct Layout { /* ... */ }

impl Layout {
    pub fn from_size_align(size: usize, align: usize) -> Option<Layout>;
    pub unsafe fn from_size_align_unchecked(size: usize, align: usize) -> Layout;

    pub fn size(&self) -> usize;
    pub fn align(&self) -> usize;
}

// renamed from AllocErr today
pub struct Error {
    // ...
}

impl Error {
    pub fn oom() -> Self;
}

pub unsafe trait Alloc {
    unsafe fn alloc(&mut self, layout: Layout) -> Result<*mut u8, Error>;
    unsafe fn dealloc(&mut self, ptr: *mut u8, layout: Layout);

    // all other methods are default and unstable
}

/// The global default allocator
pub struct Heap;

impl Alloc for Heap {
    // ...
}

impl<'a> Alloc for &'a Heap {
    // ...
}

/// The "system" allocator
pub struct System;

impl Alloc for System {
    // ...
}

impl<'a> Alloc for &'a System {
    // ...
}

특히 :

• 만 안정화 alloc , alloc_zeroed 및 dealloc 온 방법 Alloc 지금 특성을. 이것이 오늘날 우리가 가지고있는 가장 시급한 문제를 해결하고 커스텀 글로벌 할당자를 정의한다고 생각합니다.
• 원시 포인터를 사용하기 위해 Error 유형을 제거하십시오.
• 인터페이스에서 u8 유형을 void
• Layout 유형의 제거 된 버전입니다.

dealloc 및 정렬 (정확한 정렬? 적합? 확실하지 않음)으로 무엇을해야하는지에 대한 질문이 아직 남아 있지만 API가 아닐 가능성이 높으므로 FCP 중에 해결할 수 있기를 바랍니다. 브레이킹 체인지.

무언가를 안정시키는 데 +1!

AllocErr 을 Error 로 바꾸고 인터페이스를 좀 더 보수적으로 이동합니다.

할당자가 Unsupported 를 지정하는 옵션을 제거합니까? 내가 많이 하르 핑해온 것에 대해 더 많이 하르 핑 할 위험이 있지만, 나는 # 44557이 여전히 문제라고 생각합니다.

Layout

Layout 에서 일부 메소드를 제거한 것 같습니다. 당신이 빠뜨린 것들을 실제로 제거하려고 했습니까, 아니면 그냥 불안정하게 두었습니까?

impl Error {
    pub fn oom() -> Self;
}

이것이 오늘 AllocErr::Exhausted 의 생성자입니까? 그렇다면 Layout 매개 변수가 있어야하지 않습니까?

@alexcrichton 팀원 이이를 병합 할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀의 검토입니다.

• [x] @BurntSushi
• [x] @Kimundi
• [x] @alexcrichton
• [x] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @sfackler
• [x] @withoutboats

우려 사항 :

• * mut u8 은 https://github.com/rust-lang/rust/issues/32838#issuecomment -342622672에 의해 해결되었습니다.

이러한 검토자가 합의에 도달하면 최종 의견 기간이 시작됩니다. 이 과정에서 아직 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그 된 팀원이 나에게 줄 수있는 명령에 대한 정보는 이 문서 를 참조하십시오.

이 작업의 일부를 안정화하게되어 정말 기쁩니다!

한 가지 질문 : 위의 스레드에서 @joshlf 및 @ Ericson2314 는 alloc 사례를 최적화하기 위해 Alloc 및 Dealloc 특성을 분리 할 가능성에 대해 흥미로운 점을 제기했습니다 alloc 에는 일부 데이터가 필요하지만 dealloc 에는 추가 정보가 필요하지 않으므로 Dealloc 유형은 0 크기가 될 수 있습니다.

이 질문이 해결 되었습니까? 두 특성을 분리 할 때의 단점은 무엇입니까?

헉

할당자가 지원되지 않음을 지정하는 옵션이 제거됩니까?

예, 아니오, 이러한 작업은 안정된 녹에서 즉시 지원되지 않지만 불안정한 Rust에서 계속 지원할 수 있음을 의미합니다.

당신이 빠뜨린 것들을 실제로 제거하려고 했습니까, 아니면 그냥 불안정하게 두었습니까?

과연! 다시 한 번 안정적인 API 표면적을 제안하고 있지만 다른 모든 메서드는 불안정한 상태로 둘 수 있습니다. 시간이 지남에 따라 더 많은 기능을 계속 안정화 할 수 있습니다. 최대한 보수적으로 시작하는 것이 최선이라고 생각합니다.

뿡 빵뀨

이것이 오늘 AllocErr :: Exhausted의 생성자입니까? 그렇다면 레이아웃 매개 변수가 있어야하지 않습니까?

아하 좋은 지적! 나는 우리가 정말로 필요하다면 Error 크기를 제로로 만들 수있는 가능성을 남겨두고 싶었지만, 물론 레이아웃-취득 방법을 불안정하게 유지하고 필요한 경우 안정화시킬 수 있습니다. 아니면 레이아웃을 유지하는 Error 이 첫 번째 패스에서 안정화되어야한다고 생각하십니까?

뿡 빵뀨

나는 개인적으로 아직 그런 질문 / 우려 사항을 보지 못했지만 (나는 그것을 놓친 것 같다!), 개인적으로 그만한 가치가 있다고 보지 않을 것이다. 예를 들어 모든 사람이 컬렉션에 Alloc + Dealloc 를 입력해야하므로 두 가지 특성은 일반적으로 상용구의 두 배입니다. 나는 그러한 특수한 사용이 다른 모든 사용자가 개인적으로 사용하게되는 인터페이스에 알리고 싶지 않을 것이라고 기대합니다.

트윗 담아 가기

나는 개인적으로 아직 그런 질문 / 우려 사항을 보지 못했지만 (나는 그것을 놓친 것 같다!), 개인적으로 그만한 가치가 있다고 보지 않을 것이다.

일반적으로 나는 Box 한 가지 예외를 가지고 그만한 가치가 없다는 데 동의합니다. Box<T, A: Alloc> 는 Alloc 의 현재 정의를 고려할 때 최소한 두 단어 이상이어야합니다 (이미 가지고있는 포인터와 최소한 Alloc 에 대한 참조). ) 글로벌 싱글 톤 (ZST로 구현 될 수 있음)의 경우를 제외하고. 이러한 공통적이고 기본적인 유형을 저장하는 데 필요한 공간에서 2x (또는 그 이상) 폭발이 저에게 우려됩니다.

헉헉

이제 모든 사람이 컬렉션에 Alloc + Dealloc을 입력해야하므로

다음과 같이 추가 할 수 있습니다.

trait Allocator: Alloc + Dealloc {}
impl<T> Allocator for T where T: Alloc + Dealloc {}

이러한 공통적이고 기본적인 유형을 저장하는 데 필요한 공간에서 2x (또는 그 이상) 폭발

프로세스 전역이 아닌 사용자 지정 할당자를 사용할 때만 해당됩니다. std::heap::Heap (기본값)은 크기가 0입니다.

아니면 레이아웃 보존 오류가 첫 번째 패스에서 안정화되어야한다고 생각하십니까?

@alexcrichton 이 제안 된 첫 번째 패스가 왜 그런지 이해하지 못합니다. Vec 를 남용하여 이미 할 수있는 것보다 겨우 많으며, 예를 들어 https://crates.io/crates/jemallocator 를 사용하기에 충분하지 않습니다

전체를 안정시키기 위해 여전히 해결해야 할 것은 무엇입니까?

프로세스 전역이 아닌 사용자 지정 할당자를 사용할 때만 해당됩니다. std :: heap :: Heap (기본값)은 크기가 0입니다.

그것은 파라 메트릭 할당자를 갖는 주요 사용 사례처럼 보입니다. 나무에 대한 다음과 같은 간단한 정의를 상상해보십시오.

struct Node<T, A: Alloc> {
    t: T,
    left: Option<Box<Node<T, A>>>,
    right: Option<Box<Node<T, A>>>,
}

1 단어 Alloc 로 구성된 트리는 ZST Alloc 비해 전체 데이터 구조에 대해 ~ 1.7 배 크기가 확대됩니다. 그것은 나에게 꽤 나쁘게 보이며, 이러한 종류의 응용 프로그램은 Alloc 이 특성이되는 요점입니다.

뿡 빵뀨

다음과 같이 추가 할 수 있습니다.

우리는 또한 실제 특성 별칭을 가질 것입니다 :) https://github.com/rust-lang/rust/issues/41517

@glaebhoerl 예, 그러나 아직 구현이 없기 때문에 안정화는 여전히 Allocator 의 수동 impls를 비활성화하면 트레이 트 별칭이 도착했을 때 역 호환 적으로 전환 할 수 있다고 생각합니다;)

헉

이러한 공통적이고 기본적인 유형을 저장하는 데 필요한 공간에서 2x (또는 그 이상) 폭발이 저에게 우려됩니다.

오늘날의 모든 구현은 크기가 0 인 유형 또는 큰 포인터라고 생각합니다. 일부 포인터 크기 유형이 0 크기가 될 수있는 가능한 최적화가 아닌가요? (또는 그런 것?)

뿡 빵뀨

다음과 같이 추가 할 수 있습니다.

과연! 하지만 우리는 하나의 특성을 세 가지 로 가져 왔습니다. 과거에 우리는 그러한 특성에 대해 좋은 경험을 한 적이 없습니다. 예를 들어 Box<Both> 는 Box<OnlyOneTrait> 캐스트되지 않습니다. 나는 우리가 언어 기능이이 모든 것을 부드럽게하기를 기다릴 수 있다고 확신하지만, 기껏해야 먼 길인 것 같습니다.

뿡 빵뀨

전체를 안정시키기 위해 여전히 해결해야 할 것은 무엇입니까?

모르겠어요. 저는 가장 작은 것부터 시작하고 싶었습니다.

오늘날의 모든 구현은 크기가 0 인 유형 또는 큰 포인터라고 생각합니다. 일부 포인터 크기 유형이 0 크기가 될 수있는 가능한 최적화가 아닌가요? (또는 그런 것?)

예, 아이디어는 할당 자 유형에서 할당 된 객체에 대한 포인터가 주어지면 어떤 인스턴스에서 왔는지 알아낼 수 있다는 것입니다 (예 : 인라인 메타 데이터 사용). 따라서 할당을 해제해야하는 유일한 정보는 런타임 정보가 아닌 유형 정보입니다.

할당 해제에 대한 정렬로 돌아가려면 두 가지 방법이 있습니다.

• 제안 된대로 안정화합니다 (할당 해제시 정렬). Layout 가 포함되지 않으면 수동으로 할당 된 메모리의 소유권을 포기하는 것은 불가능합니다. 특히 Vec 또는 Box 또는 String 또는 기타 std 컨테이너를 필요보다 더 엄격한 정렬로 구축하는 것은 불가능합니다 (예 : 나중에 수동으로 해체하고 할당 해제하지 않고 (항상 옵션은 아님) 박스형 요소가 캐시 라인에 걸쳐있는 것을 원하지 않습니다. 불가능한 또 다른 예는 simd 연산을 사용하여 Vec 를 채운 다음이를 포기하는 것입니다.

• 할당 해제시 정렬을 요구하지 않고 Windows의 HeapAlloc 기반 alloc_system 에서 소규모 할당 최적화 를 제거 @alexcrichton , 그 코드를 커밋했을 때 왜 처음에 거기에 넣었는지 기억하십니까? 실제 응용 프로그램에서 상당한 양의 메모리를 절약한다는 증거가 있습니까? (마이크로 벤치 마크를 사용하면 할당 크기에 따라 결과가 나오도록 할 수 있습니다. HeapAlloc 가 크기를 반올림하지 않는 한)

어쨌든 이것은 매우 어려운 트레이드 오프입니다. 메모리 및 성능에 미치는 영향은 애플리케이션 유형에 따라 크게 달라지며 최적화 할 항목도 애플리케이션별로 다릅니다.

나는 우리가 실제로 Just Fine (TM)이라고 생각합니다. Alloc 문서 인용 :

일부 방법에서는 레이아웃이 메모리 블록에 맞아야 합니다.
레이아웃이 메모리 블록에 "적합"한다는 의미 (또는
마찬가지로, 메모리 블록이 레이아웃에 "적합"하려면)
다음 두 가지 조건이 유지되어야합니다.

1. 블록의 시작 주소는 layout.align() 정렬되어야합니다.

2. 블록의 크기는 [use_min, use_max] 범위에 있어야합니다. 여기서 :

   • use_min 은 self.usable_size(layout).0 이고

   • use_max 은 (또는 있었을) 용량입니다.
     (if)에 대한 호출을 통해 블록이 할당되었을 때 반환
     alloc_excess 또는 realloc_excess .

참고 :

• 가장 최근에 블록을 할당하는 데 사용 된 레이아웃의 크기
  [use_min, use_max] 범위에 있어야하며

• use_max 의 하한선은 다음을 호출하여 안전하게 추정 할 수 있습니다.
  usable_size

• 레이아웃 k 이 메모리 블록에 맞는 경우 ( ptr 표시됨)
  현재 할당 자 a 를 통해 할당 된 경우
  해당 레이아웃을 사용하여 할당을 해제하십시오. 예 : a.dealloc(ptr, k); .

마지막 글 머리 기호에 유의하십시오. 내가 배치와 레이아웃을 할당 할 경우 a 나 정렬에 할당을 해제하는, 그것은 법적해야 b < a 에 정렬되는 객체 때문에 a 도에 정렬 b , 따라서 정렬이 b 레이아웃은 정렬이 a (동일한 크기) 레이아웃으로 할당 된 객체에 맞습니다.

이것이 의미하는 바는 특정 유형에 필요한 최소 정렬보다 큰 정렬을 할당 한 다음 다른 코드가 최소 정렬로 할당을 해제하도록 허용해야한다는 것입니다.

일부 포인터 크기 유형이 0 크기가 될 수있는 가능한 최적화가 아닌가요? (또는 그런 것?)

최근에 이에 대한 RFC가 있었고 호환성 문제로 인해 수행 할 수있을 것 같지 않습니다 : https://github.com/rust-lang/rfcs/pull/2040

예를 들어 Box<Both> 는 Box<OnlyOneTrait> 캐스트되지 않습니다. 나는 우리가 언어 기능이이 모든 것을 부드럽게하기를 기다릴 수 있다고 확신하지만, 기껏해야 먼 길인 것 같습니다.

반면에 특성 객체 업 캐스팅은 논란의 여지가없이 바람직한 것으로 보이며 대부분이를 구현하기위한 노력 / 대역폭 / 의지의 문제입니다. 최근 스레드가 있습니다 : https://internals.rust-lang.org/t/trait-upcasting/5970

@ruuda 나는 원래 alloc_system 구현을 작성한 사람이었습니다. alexcrichton은 단지 <time period> 의 위대한 할당 자 리팩터링 동안에 그것을 이동했습니다.

현재 구현 에서는 주어진 메모리 블록을 할당 할 때 지정한 것과 동일한 정렬로 할당을 해제 alloc_system 가 변경 될 때까지 모든 사람이 준수해야하는 현재 현실입니다.

Windows의 할당은 항상 MEMORY_ALLOCATION_ALIGNMENT 의 배수를 사용합니다 (바이트에 할당 한 크기를 기억하지만). MEMORY_ALLOCATION_ALIGNMENT 는 32 비트에서 8이고 64 비트에서 16입니다. 정렬이보다 크기 때문에 overaligned 유형, MEMORY_ALLOCATION_ALIGNMENT 상기 오버 헤드로 인한 alloc_system 64 바이트 정렬 할당 오버 헤드의 64 바이트 것이다되도록 지정 정렬의 양은 지속적이다.

과도하게 정렬 된 트릭을 모든 할당으로 확장하기로 결정한 경우 (할당 할 때 지정한 것과 동일한 정렬로 할당을 해제해야하는 요구 사항이 제거됨) 더 많은 할당에 오버 헤드가 발생합니다. 정렬이 MEMORY_ALLOCATION_ALIGNMENT 동일한 할당은 MEMORY_ALLOCATION_ALIGNMENT 바이트의 상수 오버 헤드를 겪습니다. 정렬이 MEMORY_ALLOCATION_ALIGNMENT 미만인 할당은 대략 절반 의 시간 MEMORY_ALLOCATION_ALIGNMENT 바이트의 오버 헤드가 발생합니다. MEMORY_ALLOCATION_ALIGNMENT 로 반올림 된 할당 크기가 할당 크기에 포인터 크기를 더한 값보다 크거나 같으면 오버 헤드가 없습니다. 그렇지 않으면 오버 헤드가 없습니다. 할당의 99.99 %가 과도하게 정렬되지 않는다는 점을 고려할 때 이러한 모든 할당에 대해 이러한 종류의 오버 헤드를 발생시키고 싶습니까?

루다

개인적으로 Windows에서 alloc_system 구현하는 것이 Vec 와 같은 다른 컨테이너에 대한 할당 소유권을 양도하는 것보다 더 큰 이점이라고 생각합니다. AFAIK는 항상 정렬로 패딩하고 할당 해제에 대한 정렬을 요구하지 않는 영향을 측정 할 데이터가 없습니다.

헉

Windows에서 alloc_system 는 할당시 전달 된 것과 동일한 정렬이 할당 해제에 전달된다는 점에서 지적했듯이 주석이 잘못되었다고 생각합니다.

할당의 99.99 %가 과도하게 정렬되지 않는다는 점을 고려할 때 이러한 모든 할당에 대해 이러한 종류의 오버 헤드를 발생시키고 싶습니까?

오버 헤드가 중요한지 여부와 메모리 또는 성능 최적화 여부는 애플리케이션에 따라 다릅니다. 내 의심은 대부분의 응용 프로그램에서 괜찮지 만 소수의 소수가 메모리에 대해 깊이 관심을 갖고 있으며 실제로 추가 바이트를 감당할 수 없다는 것입니다. 그리고 또 다른 소수의 소수는 정렬을 제어해야하는데 정말 필요합니다.

헉헉

Windows에서 alloc_system 는 할당시 전달 된 것과 동일한 정렬이 할당 해제에 전달된다는 점에서 지적했듯이 주석이 잘못되었다고 생각합니다.

Windows에서 alloc_system 이 실제로 Alloc 특성을 제대로 구현하지 않는다는 의미가 아닙니까 (따라서 Alloc 특성의 요구 사항을 변경해야 할 수도 있습니다)?

뿡뿡

귀하의 의견을 올바르게 읽고 있다면 다른 정렬로 할당을 취소 할 수 있는지 여부에 관계없이 모든 할당에 대해 정렬 오버 헤드가 존재하지 않습니까? 즉, 64 바이트 정렬로 64 바이트를 할당하고 64 바이트 정렬로도 할당을 해제하면 설명한 오버 헤드가 여전히 존재합니다. 따라서 보통보다 큰 정렬을 요청하는 기능이므로 다른 정렬로 할당을 해제 할 수있는 기능이 아닙니다.

@joshlf alloc_system 인한 오버 헤드는 현재 정상보다 큰 정렬을 요청하기 때문입니다. 정렬이 MEMORY_ALLOCATION_ALIGNMENT 보다 작거나 같으면 alloc_system 인한 오버 헤드가 없습니다.

그러나 다른 정렬로 할당 해제를 허용하도록 구현을 변경하면 정렬에 관계없이 거의 모든 할당에 오버 헤드가 적용됩니다.

아 알겠습니다. 말이된다.

힙과 힙 모두에 대해 Alloc을 구현한다는 의미는 무엇입니까? 어떤 경우에 사용자가 이러한 impls 중 하나를 사용합니까?

*mut u8 가 "무엇이든에 대한 포인터"를 의미하는 최초의 표준 라이브러리 API입니까? String :: from_raw_parts가 있지만 실제로는 바이트에 대한 포인터를 의미합니다. 나는 "무엇이든에 대한 포인터"를 의미하는 *mut u8 의 팬이 아닙니다. C조차도 더 좋습니다. 다른 옵션은 무엇입니까? 불투명 한 유형에 대한 포인터가 더 의미가있을 수 있습니다.

@rfcbot 우려 * mut u8

@dtolnay Alloc for Heap 일종의 "표준"및입니다 Alloc for &Heap 처럼 Write for &T 형질이 요구하는 경우 &mut self 하지만 구현하지 않습니다. 특히 Heap 및 System 와 같은 유형은 스레드로부터 안전하며 할당 할 때 동기화 할 필요가 없음을 의미합니다.

하지만 더 중요한 것은 #[global_allocator] 하려면 T 유형을 가진 연결된 정적에 Alloc for &T 가 있어야합니다. (일명 모든 글로벌 할당자는 스레드 세이프 여야 함)

*mut u8 *mut () 가 흥미로울 수 있다고 생각하지만 개인적으로 "이 문제를 바로 잡기"자체적으로 너무 강요하지는 않습니다.

*mut u8 의 가장 큰 장점은 바이트 오프셋과 함께 .offset 를 사용하는 것이 매우 편리하다는 것입니다.

*mut u8 *mut () 이 (가) 흥미로울 수 있다고 생각하지만 개인적으로 "이 문제를 바로 잡기"자체적으로 너무 강요하지는 않습니다.

안정된 인터페이스에서 *mut u8 를 사용한다면, 우리 자신을 고정하지 않습니까? 다시 말해서 우리가 이것을 안정화하면 미래에 "이것을 바로 잡을"기회가 없을 것입니다.

또한 앞으로 RFC 2040 과 같은 최적화를 수행 할 경우 *mut () 는 저에게 약간 위험 해 보입니다.

*mut u8 의 가장 큰 장점은 .offset을 바이트 오프셋과 함께 사용하는 것이 매우 편리하다는 것입니다.

사실이지만 let ptr = (foo as *mut u8) 쉽게 수행 한 다음 즐거운 길을 갈 수 있습니다. 설득력있는 대안이있는 경우 API에서 *mut u8 를 고수하려는 동기가 충분하지 않은 것 같습니다 (공정하게 말하면 확실하지 않음).

또한 * mut ()은 향후 RFC 2040과 같은 최적화를 수행 할 경우 나에게 약간 위험 해 보입니다.

이러한 최적화는 이미 발생하지 않을 것입니다. 기존 코드가 너무 많이 손상 될 것입니다. 그렇게하더라도 *mut () 아니라 &() 및 &mut () *mut () 됩니다.

RFC 1861 이 구현 / 안정화에 가까웠다면 사용하는 것이 좋습니다.

extern { pub type void; }

pub unsafe trait Alloc {
    unsafe fn alloc(&mut self, layout: Layout) -> Result<*mut void, Error>;
    unsafe fn dealloc(&mut self, ptr: *mut void, layout: Layout);
    // ...
}

그래도 아마 너무 멀 겠죠?

@joshlf 나는 그들에 대한 PR이 열려 있다고 생각했는데, 나머지는 DynSized 입니다.

이것은 객체와 같은 구조체 해킹에 대해 작동합니까? 다음과 같은 Node<T> 있다고 가정 해 보겠습니다.

struct Node<T> {
   size: u32,
   data: T,
   // followed by `size` bytes
}

및 값 유형 :

struct V {
  a: u32,
  b: bool,
}

이제 단일 할당에서 크기 7의 문자열로 Node<V> 을 할당하려고합니다. 이상적으로는 크기 16 할당을 4로 맞추고 그 안에 모든 것을 맞추고 싶습니다 : u32 경우 4, V 경우 V 의 마지막 멤버가 정렬 1을 갖고 문자열 바이트도 정렬 1을 갖기 때문에 작동합니다.

패킹 된 스토리지에 쓰기는 정의되지 않은 동작이므로 위와 같이 유형이 구성된 경우 C / C ++에서는 허용되지 않습니다. 안타깝게도 수정할 수없는 C / C ++ 표준의 구멍이라고 생각합니다. 왜 이것이 깨 졌는지 확장 할 수 있지만 대신 Rust에 집중하겠습니다. 작동 할 수 있습니까? :-)

Node<V> 구조 자체의 크기와 정렬과 관련하여, Rust 컴파일러의 변덕에 상당히 가깝습니다. Rust가 Node<V> 객체 (스택, 힙, 참조 뒤 등)에 대한 가정을 기반으로 최적화를 수행 할 수 있기 때문에 Rust가 요구하는 것보다 작은 크기 또는 정렬로 할당하는 것은 UB (정의되지 않은 동작)입니다. -컴파일 시간에 예상되는 것과 일치하는 크기와 정렬이 있습니다.

실제로 답은 안타깝게도 아니오 인 것 같습니다. 이 프로그램을 실행 한 결과 적어도 Rust Playground에서 Node<V> 에 크기가 12이고 정렬이 4라는 것을 알았습니다. Node<V> 는 최소 12 바이트만큼 오프셋되어야합니다. Node<V> 내 data.b 필드의 오프셋이 8 바이트 인 것처럼 보입니다. 이는 9-11 바이트가 후행 패딩임을 의미합니다. 안타깝게도 패딩 바이트가 어떤 의미에서 "사용되지 않더라도"컴파일러는 여전히 해당 바이트를 Node<V> 일부로 취급하고 원하는 모든 작업을 수행 할 권리를 보유합니다 (가장 중요한 것은 쓰기 포함). Node<V> 할당하면 추가 데이터를 가져 오려고하면 덮어 쓸 수 있음을 의미합니다.)

(참고, btw : Rust 컴파일러가 패킹되지 않는다고 생각하는 타입을 패킹 된 것으로 취급 할 수는 없습니다. 그러나 다음을 사용하여 Rust 컴파일러에게 무언가가 패킹되었음을 알릴 수 있습니다. 그러면 타입의 레이아웃이 변경됩니다 (패딩 제거).) repr(packed) )

그러나 둘 다 동일한 Rust 유형의 일부가되지 않고 하나의 오브젝트를 차례로 배치하는 것과 관련하여, 이것이 유효하다고 거의 100 % 확신합니다. 결국 Vec 는 일입니다. Layout 유형 의 메소드를 사용하여 총 할당에 필요한 공간을 동적으로 계산할 수 있습니다.

let node_layout = Layout::new::<Node<V>>();
// NOTE: This is only valid if the node_layout.align() is at least as large as mem::align_of_val("a")!
// NOTE: I'm assuming that the alignment of all strings is the same (since str is unsized, you can't do mem::align_of::<str>())
let padding = node_layout.padding_needed_for(mem::align_of_val("a"));
let total_size = node_layout.size() + padding + 7;
let total_layout = Layout::from_size_align(total_size, node_layout.align()).unwrap();

이 작품이 좋을까요?

#[repr(C)]
struct Node<T> {
   size: u32,
   data: T,
   bytes: [u8; 0],
}

… 그런 다음 더 큰 크기로 할당하고 slice::from_raw_parts_mut(node.bytes.as_mut_ptr(), size) ?

자세한 답변에 대해 @joshlf 에게 감사드립니다! 내 사용 사례의 TLDR은 크기가 16 인 Node<V> 를 얻을 수 있지만 V가 repr(packed) 경우에만 가능하다는 것입니다. 그렇지 않으면 내가 할 수있는 최선은 크기 19 (12 + 7)입니다.

@SimonSapin 확실하지 않습니다. 노력하겠습니다.

이 정말이 스레드를 잡았지만 아직 아무것도 안정화에 대한 죽은 세트를 아니에요. 우리는 아직 어려운 문제를 구현하지 못했습니다.

1. 할당 자 다형성 컬렉션
   
   
   
   • 부 풀지 않은 상자도 아닙니다!
   
   
2. 잘못된 컬렉션

나는 기본적인 특성의 디자인은 사람들의 솔루션에 영향을 미칠 것이라고 생각 : 나는 지난 몇 달 동안 녹에 대한 약간의 시간이 있었다했지만, 시간이 주장했다. 여기에서도 제 주장을 완전히 할 시간이 있을지 의심 스럽습니다. 그래서 저는 우리가 최소한 그 모든 것에 대한 완전한 해결책을 먼저 작성하기를 바랄뿐입니다. 누군가는 엄격하고 (올바른 사용법을 강요하여) 유연하게하는 것이 불가능하다는 것을 저에게 틀 렸습니다. , 현재 특성에 인체 공학적입니다. 또는 상단의 체크 박스를 완료해도됩니다.

Re : @ Ericson2314 의 코멘트

그 관점과 @alexcrichton 의 무언가를 안정화하려는 욕망 사이의 갈등과 관련된 관련 질문은 다음과 같습니다. 최소 인터페이스를 안정화하면 얼마나 많은 이점을 얻을 수 있습니까? 특히, Alloc 메서드를 직접 호출하는 소비자가 거의 없기 때문에 (대부분의 컬렉션에서도 Box 또는 다른 유사한 컨테이너를 사용할 것임) 실제 질문은 다음과 같습니다. Alloc 메서드를 직접 호출하지 않습니까? 솔직히 내가 생각할 수있는 유일한 심각한 사용 사례는 할당 자 다형성 컬렉션 (훨씬 더 광범위한 사용자가 사용할 가능성이 높음)을위한 경로를 제공한다는 것입니다.하지만 # 27336에서 차단 된 것처럼 보입니다. 해결되고 있습니다. 내가 놓친 다른 대규모 사용 사례가있을 수 있지만 빠른 분석을 기반으로 볼 때 나중에 차선책이 될 수있는 설계에 우리를 고정시키는 대가로 미미한 이점 만 제공하므로 안정화에서 벗어나는 경향이 있습니다. .

@joshlf 는 사람들이 자신의 글로벌 할당자를 정의하고 사용할 수 있도록합니다.

흠 좋은 지적입니다. Alloc 를 안정화하지 않고 전역 할당 자 지정을 안정화 할 수 있습니까? 즉, Alloc 를 구현하는 코드는 불안정해야하지만 자체 크레이트에 캡슐화 될 수 있으며 해당 할당자를 글로벌 할당 자로 표시하는 메커니즘 자체가 안정적입니다. 아니면 안정적인 / 불안정하고 안정적인 컴파일러 / 야간 컴파일러가 상호 작용하는 방식을 오해하고 있습니까?

아 @joshlf 는 https://github.com/rust-lang/rust/issues/42774#issuecomment -317279035에 따라 # 27336이 산만 하다는 것을 기억 하십시오 . 나는 우리가 다른 문제들에 부딪 힐 것이라고 확신합니다. --- 존재하는 특성들과 관련된 문제들입니다. 그래서 지금 작업을 시작하기 위해 노력하고 싶습니다. # 27336 이후 예측 된 미래에 대해 토론하는 것보다 모든 사람들이 볼 수 있도록 도착하면 이러한 문제를 논의하는 것이 훨씬 쉽습니다.

@joshlf 하지만 안정적인 컴파일러로 전역 할당자를 정의하는 상자를 컴파일 할 수 없습니다.

@sfackler 아 예, 제가 두려워했던 오해가 있습니다 : P

usize 가 요청 된 할당 크기 (할당 된 추가 크기에서와 같이)가 excess 가 아니기 때문에 Excess(ptr, usize) 라는 이름이 약간 헷갈 리지만 total 할당 크기.

IMO Total , Real , Usable 또는 할당의 총 크기 또는 실제 크기가 "초과"보다 낫다는 것을 전달하는 이름 오해의 소지가 있습니다. _excess 메서드에도 동일하게 적용됩니다.

위의 @gnzlbg에 동의하며 일반 (ptr, usize) 튜플이 괜찮을 것이라고 생각합니다.

Excess 는 첫 번째 패스에서 안정화되도록 제안되지 않습니다.

우려하는 사람들이있는 reddit에 대한 토론을 위해이 스레드를 게시했습니다. https://www.reddit.com/r/rust/comments/78dabn/custom_allocators_are_on_the_verge_of_being/

오늘 @ rust-lang / libs와 추가 논의를 마친 후 다음과 같이 요약 할 수있는 안정화 제안을 몇 가지 수정하고 싶습니다.

• 안정화 된 메서드 집합에 alloc_zeroed 를 추가합니다. 그렇지 않으면 alloc 와 동일한 서명이 있습니다.
• extern { type void; } 지원을 사용하여 API에서 *mut u8 를 *mut void 로 변경하고 @dtolnay 의 문제를 해결하고 생태계 전체에서 c_void 를 통합 할 수있는 방법을 제공합니다.
• alloc 의 반환 유형을 *mut void 로 변경하여 Result 및 Error

아마도 가장 논란이되는 것은 마지막 요점 일 것이므로 이에 대해서도 자세히 설명하고 싶습니다. 이것은 오늘 libs 팀과의 논의에서 나왔고 특히 (a) Result 기반 인터페이스가 포인터 반환 인터페이스보다 덜 효율적인 ABI를 갖고 (b) 오늘날 "프로덕션"할당자가 거의없는 방식을 중심으로 진행되었습니다. "이것 만 OOM'd"이상의 것을 배울 수있는 능력을 제공합니다. 성능을 위해 우리는 대부분 인라인 등으로 덮어 쓸 수 있지만 Error 는 가장 낮은 레이어에서 제거하기 어려운 추가 페이로드입니다.

오류 페이로드 반환에 대한 생각은 할당자가 할당이 실패한 이유를 알기 위해 구현 별 인트로 스펙 션을 제공 할 수 있으며 그렇지 않으면 거의 모든 소비자가 할당이 성공했는지 실패했는지 만 알면된다는 것입니다. 추가적으로 이것은 실제로 그렇게 자주 호출되지 않는 매우 낮은 수준의 API를위한 것입니다 (대신 잘 정리 된 형식화 된 API가 대신 호출되어야합니다). 그런 의미에서이 위치에서 가장 유용하고 인체 공학적인 API를 보유하는 것이 가장 중요하지는 않지만 성능 저하없이 사용 사례를 활성화하는 것이 더 중요합니다.

*mut u8 의 가장 큰 장점은 바이트 오프셋과 함께 .offset 를 사용하는 것이 매우 편리하다는 것입니다.

회의 라이브러리들에서 우리는 또한 제안 impl *mut void { fn offset } 와 충돌하지 않는를 기존 offset 에 대해 정의 T: Sized . byte_offset 수도 있습니다.

*mut void 및 byte_offset 사용에 대한 +1. extern 유형 기능의 안정화에 문제가 있습니까, 아니면 정의 만 불안정하고 (그리고 liballoc은 내부적으로 불안정한 일을 할 수 있음) 사용이 아니기 때문에 (예 : let a: *mut void = ... 불안정하지 않음)?

예, 우리는 외부 유형 안정화를 차단할 필요가 없습니다. extern 유형 지원이 삭제 되더라도 이에 대해 정의한 void 는 항상 마법 유형의 최악의 경우가 될 수 있습니다.

libs 회의에서 Alloc 와 Dealloc 가 별개의 특성이어야하는지 여부에 대한 추가 논의가 있었습니까?

우리는 그것에 대해 구체적으로 다루지 않았지만 일반적으로 우리가 그렇게 할 특별한 이유가 있지 않는 한 선행 기술에서 전환해서는 안된다고 느꼈습니다. 특히 C ++의 Allocator 개념은 유사한 분할이 없습니다.

이 경우에 이것이 적절한 비교인지 확신 할 수 없습니다. C ++에서는 모든 것이 명시 적으로 해제되므로 자체 할당 자의 복사본 (또는 참조)을 저장해야하는 Box 해당하는 항목이 없습니다. 그것이 우리에게 큰 폭발의 원인입니다.

std::unique_ptr 는 "삭제 자"에서 일반적입니다 .

@joshlf unique_ptr 는 Box , vector 는 Vec , unordered_map 는 HashMap 등

@cramertj 아, 흥미 롭습니다. 저는 컬렉션 유형

블랭킷 impl 접근 방식은 실제로 더 깔끔 할 수 있습니다.

pub trait Dealloc {
    fn dealloc(&self, ptr: *mut void, layout: Layout);
}

impl<T> Dealloc for T
where
    T: Alloc
{
    fn dealloc(&self, ptr: *mut void, layout: Layout) {
        <T as Alloc>::dealloc(self, ptr, layout)
    }
}

대부분의 사용 사례에서 걱정할 특성이 하나 적습니다.

• alloc의 반환 유형을 * mut void로 변경하여 결과와 오류를 제거합니다.

아마도 가장 논란이되는 것은 마지막 요점 일 것이므로 이에 대해서도 자세히 설명하고 싶습니다. 이것은 오늘 libs 팀과의 논의에서 나왔고, 특히 (a) 결과 기반 인터페이스가 포인터 반환 인터페이스보다 덜 효율적인 ABI를 갖고 (b) 오늘날 "프로덕션"할당자가 학습 능력을 제공하지 않는 방법을 중심으로 진행되었습니다. "이것 만 OOM'd"이상입니다. 성능을 위해 우리는 대부분 인라인 등을 사용하여 문서를 작성할 수 있지만 오류는 가장 낮은 계층에서 제거하기 어려운 추가 페이로드입니다.

이것은 null을 확인하지 않고 반환 된 포인터를 사용하는 것을 매우 쉽게 만들 것이라고 우려합니다. Result<NonZeroPtr<void>, AllocErr> 를 반환하고 AllocErr 크기를 0으로 만들어 이러한 위험을 추가하지 않고 오버 헤드를 제거 할 수도있는 것 같습니다.

( NonZeroPtr 는 https://github.com/rust-lang/rust/issues/27730#issuecomment-316236397에 제안 된대로 ptr::Shared 및 ptr::Unique 가 병합 된 것입니다.)

@SimonSapin Result<NonZeroPtr<void>, AllocErr> 와 같은 것은 안정화를 위해 세 가지 유형이 필요합니다.이 void 와 같은 것은 필요하지도 않고 가지고 있어도 좋다 (제 생각에는).

"null을 확인하지 않고 사용하기 쉽다"는 점에 동의합니다. 그러나 이것은 다시 한 번 과도하게 사용되도록 의도되지 않은 매우 낮은 수준의 API이므로 호출자 인체 공학에 최적화해서는 안된다고 생각합니다.

사람들은 Result<NonZeroPtr<void>, AllocErr> 와 같이 더 복잡한 반환 유형을 가질 수있는 낮은 수준의 alloc 위에 alloc_one 과 같은 더 높은 수준의 추상화를 구축 할 수도 있습니다.

나는 AllocErr 이 실제로 유용하지 않다는 데 동의하지만 Option<NonZeroPtr<void>> 어떻습니까? 오버 헤드없이 우발적으로 오용 할 수없는 API는 Rust를 C와 차별화하는 요소 중 하나이며 C 스타일의 널 포인터로 돌아가는 것은 저에게 한 걸음 뒤로 물러나는 느낌입니다. "많이 사용하지 않는 매우 낮은 수준의 API"라고 말하는 것은 일반적이지 않은 마이크로 컨트롤러 아키텍처의 메모리 안전성이 매우 낮고 많이 사용되지 않기 때문에 신경 쓰지 말아야한다고 말하는 것과 같습니다.

할당 자와의 모든 상호 작용에는이 함수의 반환 유형에 관계없이 안전하지 않은 코드가 포함됩니다. 반환 유형이 Option<NonZeroPtr<void>> 인지 *mut void 인지 낮은 수준의 할당 API는 오용 할 수 있습니다.

Alloc::alloc 특히 낮은 수준이며, 많이 사용할 수 없습니다 API를이다. Alloc::alloc_one<T> 또는 Alloc::alloc_array<T> 와 같은 메서드는 더 많이 사용되며 "더 좋은"반환 유형을 갖는 대안입니다.

상태 저장 AllocError 는 그만한 가치가 없지만 오류를 구현하고 Display 의 allocation failure Display 을 (를) 갖는 크기가 0 인 유형이 있으면 좋습니다. 우리가 갈 경우 NonZeroPtr<void> 길을, 나는 볼 Result<NonZeroPtr<void>, AllocError> 것이 바람직으로 Option<NonZeroPtr<void>> .

안정을 위해 서두르는 이유 :( !! Result<NonZeroPtr<void>, AllocErr> 는 클라이언트가 사용하기에 더할 나위없이 좋은 것입니다. 이것이 좋을 필요가없는 "매우 낮은 수준의 API"라고 말하는 것은 우울할 정도로 야심이 없습니다. 모든 수준의 코드는 다음과 같아야합니다. 가능한 한 안전하고 유지 관리 할 수 ​​있습니다. 계속 편집되지 않는 (따라서 사람들의 단기 기억에 페이지가 표시되는) 모호한 코드는 더욱 그렇습니다!

게다가 사용자가 작성한 할당 다형성 컬렉션을 가지려면 할당자를 직접 사용하는 상당히 복잡한 코드가 필요합니다.

재 처리, 운영상 우리는 트리 기반 컬렉션 당 한 번만 alloactor를 참조 / 복제하기를 원합니다. 즉, 파괴되는 각 custom-allocator-box에 할당자를 전달하는 것을 의미합니다. 그러나 선형 유형없이 Rust에서이를 가장 잘 수행하는 방법에 대한 열린 문제입니다. 이전 의견과는 달리, 이상적인 사용 사례가 분할 할당 자 및 할당 해제 특성의 구현이 아닌 Box 구현을 변경하기 때문에 컬렉션 구현에서 안전하지 않은 코드에 대해 괜찮습니다. 즉, 선형성을 차단하지 않고도 안정적인 진행을 할 수 있습니다.

@sfackler 저는 할당 자와 할당자를 연결하는 몇 가지 관련 유형이 필요하다고 생각합니다. 개장이 불가능할 수 있습니다.

@ Ericson2314 사람들이 현실 세계의 실제 사물에 할당자를 사용하기를 원하기 때문에 안정화를위한 "서두르 기"가 있습니다. 이것은 과학 프로젝트가 아닙니다.

관련 유형은 무엇에 사용됩니까?

@sfackler 사람들은 여전히 ​​야간에 핀을 고정 할 수 있으며 이러한 종류의 고급 기능에 관심이있는 유형의 사람들은 그렇게하는 것이 편안해야합니다. [문제가 불안정한 rustc 대 불안정한 Rust라면, 정책 수정이 필요한 다른 문제입니다.] 반대로 형편없는 API로 베이킹하면 생태계를 새로운 2.0 표준으로 분할하고 싶지 않은 한 우리를 영원히 괴롭 힙니다.

관련 유형은 할당 해제 자와 할당자를 관련시킵니다. 이것이 작동하려면 각자가 서로에 대해 알아야합니다. [올바른 유형의 잘못된 (비) 할당자를 사용하는 문제는 여전히 있지만 아무도 이에 대한 해결책을 원격으로 제안하지 않았 음을 인정합니다.]

사람들이 야간에만 고정 할 수 있다면 왜 우리는 안정적인 빌드를 가지고 있습니까? 할당 자 API와 직접 상호 작용하는 사람들은 예를 들어 글로벌 할당자를 교체하여 이러한 API를 활용하려는 사람들보다 훨씬 적습니다.

할당 해제자가 연결된 할당 자의 유형을 알아야하는 이유를 보여주는 코드를 작성할 수 있습니까? C ++의 할당 자 API에 유사한 매핑이 필요한 이유는 무엇입니까?

사람들이 야간에만 고정 할 수 있다면 왜 우리는 안정적인 빌드를 가지고 있습니까?

언어 안정성을 나타냅니다. 이 버전에 대해 작성한 코드는 절대로 깨지지 않습니다. 최신 컴파일러에서. 너무 나쁜 것이 필요할 때 야간에 고정하므로 보증할만한 품질로 간주되는 기능의 최종 반복을 기다릴 가치가 없습니다.

할당 자 API와 직접 상호 작용하는 사람들은 예를 들어 글로벌 할당자를 교체하여 이러한 API를 활용하려는 사람들보다 훨씬 적습니다.

아하! 이것은 jemalloc을 나무에서 옮기기위한 것일까 요? 아무도 전역 할당자를 선택할 수있는 끔찍한 해킹을 안정화하는 방법을 제안하지 않았습니다. 아니면 제안을 잘못 읽었습니까?

글로벌 할당자를 선택할 수있는 끔찍한 해킹이 안정화되도록 제안되었습니다. 이는 우리가 jemalloc을 트리에서 옮길 수있는 것의 절반입니다. 이 문제는 나머지 절반입니다.

#[global_allocator] 속성 안정화 : https://github.com/rust-lang/rust/issues/27389#issuecomment -336955367

Yikes

@ Ericson2314 글로벌 할당자를 선택하는 끔찍하지 않은 방법은 무엇이라고 생각하십니까?

(https://github.com/rust-lang/rust/issues/27389#issuecomment-342285805에 응답)

제안은 * mut void를 사용하도록 수정되었습니다.

@rfcbot 해결 * mut u8

@rfcbot 검토

IRC에 대해 논의한 후 Alloc 에서 Box 제네릭을 안정화 할 의도가 _ 아님 _이 아니라 일부 Dealloc 특성에 대해 여기 @sfackler가 제안한 적절한 담요 impl. 의도를 오해 한 경우 알려주세요.

@cramertj 명확히하기 위해, 우리가 여기서 안정화하고있는 Alloc 정의를 깨뜨리지 않고 그 블랭킷 impl을 사실 뒤에 추가하는 것이 가능합니까?

@joshlf 예, 다음과 같이 보일 것입니다 : https://github.com/rust-lang/rust/issues/32838#issuecomment -340959804

주어진 Alloc 대해 Dealloc 을 어떻게 지정합니까? 이런 걸 상상할까요?

pub unsafe trait Alloc {
    type Dealloc: Dealloc = Self;
    ...
}

나는 그것이 우리를 가시 영역 WRT https://github.com/rust-lang/rust/issues/29661 에 놓을 것이라고 생각합니다

예, Dealloc 의 추가가 기본값없이 Alloc 의 기존 정의 (관련 유형이 없음)와 역 호환되도록하는 방법이 없다고 생각합니다.

할당 자에 해당하는 할당 해제자를 자동으로 확보하려면 연결된 유형 이상이 필요하지만 할당 해제 값을 생성하는 함수가 필요합니다.

그러나 이것은 Alloc 라는 별도의 하위 특성에 해당 항목을 첨부하여 향후 처리 할 수 ​​있습니다.

@sfackler 내가 이해하는지 잘 모르겠습니다. 디자인에 Box::new 의 서명을 쓸 수 있습니까?

이것은 배치 구문과 모든 것을 무시하는 것이지만 할 수있는 한 가지 방법은

pub struct Box<T, D>(NonZeroPtr<T>, D);

impl<T, D> Box<T, D>
where
    D: Dealloc
{
    fn new<A>(alloc: A, value: T) -> Box<T, D>
    where
        A: Alloc<Dealloc = D>
    {
        let ptr = alloc.alloc_one().unwrap_or_else(|_| alloc.oom());
        ptr::write(&value, ptr);
        let deallocator = alloc.deallocator();
        Box(ptr, deallocator)
    }
}

특히, 우리는 그 유형을 아는 것이 아니라 실제로 할당 해제 자의 인스턴스를 생성 할 수 있어야합니다. 또한 매개 변수화 할 수 Box 이상을 Alloc 및 저장 A::Dealloc 대신, 타입 추론에있는 힘의 도움을. Dealloc 및 deallocator 를 별도의 트레이 트로 이동하여 안정화 후에이 작업을 수행 할 수 있습니다.

pub trait SplitAlloc: Alloc {
    type Dealloc;

    fn deallocator(&self) -> Self::Dealloc;
}

하지만 Drop 의 impl은 어떻게 생겼을까 요?

impl<T, D> Drop for Box<T, D>
where
    D: Dealloc
{
    fn drop(&mut self) {
        unsafe {
            ptr::drop_in_place(self.0);
            self.1.dealloc_one(self.0);
        }
    }
}

하지만 먼저 Alloc 안정화한다고 가정하면 모든 Alloc 가 Dealloc 구현하지는 않습니다. 그리고 나는 impl 전문화가 여전히 벗어난 것이라고 생각 했습니까? 즉, 이론적으로 다음과 같은 작업을하고 싶지만 아직 작동하지 않는 것 같습니다.

impl<T, D> Drop for Box<T, D> where D: Dealloc { ... }
impl<T, A> Drop for Box<T, A> where A: Alloc { ... }

무엇이든, 우리는

default impl<T> SplitAlloc for T
where
    T: Alloc { ... }

그러나 나는 그것이 정말로 필요하다고 생각하지 않습니다. 사용자 지정 할당 자와 전역 할당 자의 사용 사례는 충분히 구별되어서 둘 사이에 많은 겹침이있을 것이라고 생각하지 않습니다.

그게 효과가 있다고 생각합니다. 그러나 더 간단한 인터페이스를 가질 수 있도록 Dealloc 즉시 사용하는 것이 훨씬 더 깔끔해 보입니다. 이미 Alloc 구현하는 기존 코드를 변경할 필요가없는 매우 간단하고 논란의 여지가없는 인터페이스를 가질 수 있다고 생각합니다.

unsafe trait Dealloc {
    fn dealloc(&mut self, ptr: *mut void, layout: Layout);
}

impl<T> Dealloc for T
where
    T: Alloc
{
    fn dealloc(&self, ptr: *mut void, layout: Layout) {
        <T as Alloc>::dealloc(self, ptr, layout)
    }
}

unsafe trait Alloc {
    type Dealloc: Dealloc = &mut Self;
    fn deallocator(&mut self) -> Self::Dealloc { self }
    ...
}

연관된 유형 기본값이 문제가 되었습니까?

할당 자에 대한 변경 가능한 참조 인 Dealloc 는 그다지 유용하지 않은 것 같습니다. 한 번에 하나만 할당 할 수 있습니다.

연관된 유형 기본값이 문제가 되었습니까?

오, 관련 유형 기본값은 우리가 신뢰할 수 없을만큼 멀리 떨어져 있다고 생각합니다.

그래도 더 간단 할 수 있습니다.

unsafe trait Dealloc {
    fn dealloc(&mut self, ptr: *mut void, layout: Layout);
}

impl<T> Dealloc for T
where
    T: Alloc
{
    fn dealloc(&self, ptr: *mut void, layout: Layout) {
        <T as Alloc>::dealloc(self, ptr, layout)
    }
}

unsafe trait Alloc {
    type Dealloc: Dealloc;
    fn deallocator(&mut self) -> Self::Dealloc;
    ...
}

구현자가 약간의 상용구를 작성하도록 요구합니다.

할당 자에 대한 변경 가능한 참조 인 Dealloc 는 그다지 유용하지 않은 것 같습니다. 한 번에 하나만 할당 할 수 있습니다.

네, 좋은 지적입니다. 어쨌든 다른 의견을 감안할 때 아마도 논쟁의 여지가 있습니다.

deallocator 가 self , &self 또는 &mut self 가져 가야합니까?

아마도 &mut self 는 다른 방법과 일치합니다.

예를 들어 상태를 복제 할 필요가 없도록 자신을 가치로 취하는 것을 선호하는 할당자가 있습니까?

self 를 값으로 가져가는 문제는 Dealloc 얻은 다음 계속 할당 할 수 없다는 것입니다.

나는 가상의 "원샷"할당자를 생각하고 있지만 그것이 얼마나 실제적인 것인지는 모르겠습니다.

이러한 할당자는 존재할 수 있지만 self 값을 사용하려면 _all_ 할당자가 그런 방식으로 작동해야하며 deallocator 가 호출 된 후 할당을 허용하는 할당자를 배제합니다.

안정화에 대해 생각하기 전에이 중 일부가 컬렉션에 구현되고 사용되는 것을보고 싶습니다.

https://github.com/rust-lang/rust/issues/27336 또는 https://github.com/rust-lang/rust/issues/32838#issuecomment -339066870에 설명 된 요점을 통해 컬렉션을 진행 하시겠습니까?

유형 별칭 접근 방식이 문서 가독성에 미치는 영향에 대해 걱정됩니다. 진행을 허용하는 (매우 장황한) 방법은 유형을 래핑하는 것입니다.

pub struct Vec<T>(alloc::Vec<T, Heap>);

impl<T> Vec<T> {
    // forwarding impls for everything
}

고통 스럽다는 것을 알고 있지만 여기서 논의하는 변경 사항은 분할 할당 / 할당 특성으로 진행하기로 결정한 경우 먼저 표준에서 시도한 다음 다시 FCP를 시도해야 할만큼 충분히 큰 것 같습니다.

이 항목이 구현되기를 기다리는 일정은 어떻게 되나요?

grow_in_place 메서드는 어떤 종류의 초과 용량도 반환하지 않습니다. 현재 레이아웃과 함께 usable_size 를 호출하고 할당을이 레이아웃에 맞게 _at least_로 확장하지만 할당이 해당 레이아웃 이상으로 확장되면 사용자는 알 방법이 없습니다.

alloc_excess 및 realloc_excess 보다 alloc 및 realloc 메서드의 장점을 이해하는 데 어려움을 겪고 있습니다.

할당자는 할당을 수행하기 위해 적합한 메모리 블록을 찾아야합니다.이를 위해서는 메모리 블록의 크기를 알아야합니다. 할당자가 포인터를 반환하는지 또는 튜플 "포인터 및 메모리 블록의 크기"는 측정 가능한 성능 차이를 만들지 않습니다.

따라서 alloc 및 realloc 는 API 표면을 늘리고 성능이 떨어지는 코드 작성을 권장하는 것 같습니다. API에 왜 그것들이 있습니까? 그들의 장점은 무엇입니까?

편집 : 또는 다시 말해 : API에서 잠재적으로 할당하는 모든 함수는 Excess 반환해야하며, 이는 기본적으로 모든 _excess 메서드에 대한 필요성을 제거합니다.

초과는 증가 할 수있는 어레이와 관련된 사용 사례에서만 흥미 롭습니다. 예를 들어 Box 또는 BTreeMap 에는 유용하지 않거나 관련이 없습니다. 초과 량을 계산하는 데 약간의 비용이있을 수 있으며 확실히 더 복잡한 API가 있으므로 초과 용량에 대해 신경 쓰지 않는 코드가 비용을 지불해야하는 것처럼 보이지 않습니다.

초과분을 계산하는 데 약간의 비용이있을 수 있습니다.

예를 들어 줄 수 있습니까? 메모리를 할당 할 수 있지만 실제로 할당하는 메모리 양을 알지 못하는 할당 자 ( Excess 는 실제 할당 된 메모리 양입니다. 이름을 바꿉니다).

이것이 약간 논쟁의 여지가있을 수있는 유일한 일반적으로 사용되는 Alloc ator는 POSIX malloc 이며, 항상 내부적으로 Excess 계산하더라도 C의 일부로 노출하지 않습니다. API. 그러나 요청 된 크기를 Excess 로 반환하는 것은 괜찮고, 이식 가능하고, 간단하며, 비용이 전혀 들지 않으며, POSIX malloc 사용하는 모든 사람들이 이미 가정하고있는 것입니다.

jemalloc 및 기본적으로 다른 Alloc ator는 비용을 발생시키지 않고 Excess 를 반환하는 API를 제공하므로 이러한 할당 자에 대해 Excess 반환은 0입니다. 비용도 마찬가지입니다.

초과 량을 계산하는 데 약간의 비용이있을 수 있으며 확실히 더 복잡한 API가 있으므로 초과 용량에 대해 신경 쓰지 않는 코드가 비용을 지불해야하는 것처럼 보이지 않습니다.

지금은 모두가 이미 메모리 할당을위한 두 개의 API를 가진 할당 자 특성의 대가를 지불하고 있습니다. 그리고 Excess -full one` 위에 Excess -less API를 빌드 할 수 있지만 그 반대는 사실이 아닙니다. 그래서 왜 이렇게되지 않는지 궁금합니다.

• Alloc 트레이 트 메서드는 항상 Excess 반환합니다.
• Alloc 메서드에서 Excess 제거하는 ExcessLessAlloc 특성을 추가하여 1) Alloc 를 사용할만큼 충분히 신경을 쓰지만 2) 사용하지 않는 모든 사용자를 위해 현재 할당되고있는 실제 메모리 양에 관심이 있습니다 (나에게 틈새 시장처럼 보이지만 여전히 그러한 API가 있으면 좋다고 생각합니다)
• 어느 날 누군가 발견하여 방법을 구현하는 경우 Alloc 에 대한 빠른 경로와의 ators Excess - 덜 방법을, 우리는 항상의 사용자 지정 구현을 제공 할 수 ExcessLessAlloc 그것에 대한합니다.

FWIW Alloc 위에 내가 원하는 것을 구현할 수 없기 때문에 방금이 스레드를 다시 시작했습니다. 이전에 grow_in_place_excess 가 누락되었다고 언급했지만 alloc_zeroed_excess 도 누락 되었기 때문에 다시 막혔습니다.

여기서 안정화가 먼저 Excess -full API를 안정화하는 데 초점을 맞추면 더 편안 할 것입니다. API가 모든 용도에 가장 인체 공학적이지는 않더라도 이러한 API는 최소한 설계에 결함이 없음을 보여주는 데 필요한 모든 용도를 허용합니다.

예를 들어 줄 수 있습니까? 메모리를 할당 할 수 있지만 실제로 할당하는 메모리 양을 알지 못하는 할당 자 ( Excess 는 실제 할당 된 메모리 양입니다. 이름을 바꿉니다).

오늘날 대부분의 할당자는 크기 클래스를 사용하는데, 각 크기 클래스는 특정 고정 크기의 객체 만 할당하고 특정 크기 클래스에 맞지 않는 할당 요청은 내부에 맞는 가장 작은 크기 클래스로 반올림됩니다. 이 체계에서는 크기 클래스 객체의 배열을 보유한 다음 classes[size / SIZE_QUANTUM].alloc() 를 수행하는 것과 같은 작업을 수행하는 것이 일반적입니다. 그 세계에서 어떤 크기 클래스가 사용되는지 파악하려면 let excess = classes[size / SIZE_QUANTUM].size 같은 추가 지침이 필요합니다. 많지는 않을 수 있지만 고성능 할당 자 (예 : jemalloc)의 성능은 단일 클록 주기로 측정되므로 특히 해당 크기가 일련의 함수 반환을 통과하는 경우 의미있는 오버 헤드를 나타낼 수 있습니다.

예를 들어 줄 수 있습니까?

최소한 alloc_jemalloc에 ​​대한 PR에서 alloc_excess 는 alloc 보다 더 많은 코드를 실행하고 있습니다 : https://github.com/rust-lang/rust/pull/45514/files.

이 방식에서는 크기 클래스 객체의 배열을 갖고 클래스 [size / SIZE_QUANTUM] .alloc ()를 수행하는 것과 같은 작업을 수행하는 것이 일반적입니다. 그 세계에서 어떤 크기의 클래스가 사용되는지 알아내는 것은 추가적인 지시를 필요로합니다 : 예를 들어, let exceed = classes [size / SIZE_QUANTUM] .size

그래서 내가 제대로 따라 가는지 보자.

// This happens in both cases:
let size_class = classes[size / SIZE_QUANTUM];
let ptr = size_class.alloc(); 
// This would happen only if you need to return the size:
let size = size_class.size;
return (ptr, size);

그게 다야?

적어도 PR에서 alloc_jemalloc으로 이동하면 alloc_excess는 alloc보다 더 많은 코드를 실행하고 있습니다.

그 PR은 버그 수정 (perf 수정이 아님)이었고, 현재 jemalloc 레이어의 perf-wise 상태에는 많은 문제가 있지만 그 PR 이후로 적어도해야 할 일을 반환합니다.

• nallocx 는 GCC 의미에서 const 함수, 즉 진정한 순수 함수입니다. 즉, 부작용이없고, 그 결과는 인수에만 의존하고, 전역 상태에 액세스하지 않으며, 인수가 포인터가 아니며 (따라서 함수가 전역 상태에 액세스 할 수 없으므로) LLVM이이를 사용할 수 있습니다. 결과가 사용되지 않는 경우 호출을 제거하기위한 정보. AFAIK Rust는 현재 FFI C 함수를 const fn 또는 이와 유사한 것으로 표시 할 수 없습니다. 따라서 이것은 수정 될 수있는 첫 번째 문제이며 인라인 및 최적화가 제대로 작동하는 한 초과분을 사용하지 않는 사람들에게 realloc_excess 제로 비용이 될 것입니다.
• nallocx 는 항상 mallocx 내부의 정렬 된 할당에 대해 계산됩니다. 즉, 모든 코드가 이미이를 계산하고 있지만 mallocx 는 결과를 버리므로 여기서 실제로 두 번 계산합니다. , 그리고 어떤 경우에는 nallocx 가 mallocx 만큼 비쌉니다 ... 저는 브랜치에서 이와 같은 것에 대한 벤치 마크가있는 jemallocator 포크 를 가지고 있지만, 이것은 업스트림에 의해 수정되어야합니다. 이것을 버리지 않는 API를 제공함으로써 jemalloc. 그러나이 수정 사항은 현재 Excess 사용중인 경우에만 영향을줍니다.
• 그리고 우리가 정렬 플래그를 두 번 계산하는 문제입니다.하지만 그것은 LLVM이 우리 측에서 최적화 할 수있는 것입니다 (그리고 수정하기가 사소한 것입니다).

예, 더 많은 코드처럼 보이지만이 추가 코드는 실제로 두 번 호출하는 코드입니다. 처음 호출했을 때 결과를 버렸습니다. 고치는 것은 불가능하지 않지만 아직 할 시간을 찾지 못했습니다.

편집 : @sfackler 나는 오늘 그것을 위해 약간의 시간을 확보 할 수 있었고 jemallocs 느린 경로에서 alloc 와 관련하여 alloc_excess "무료"를 만들 수 있었고 ~ 1ns의 오버 헤드 만 있습니다. jemallocs의 빠른 경로. 빠른 경로를 자세히 살펴본 적은 없지만이를 더 개선 할 수는 있습니다. 자세한 내용은 여기 : https://github.com/jemalloc/jemalloc/issues/1074#issuecomment -345040339

그게 다야?

예.

따라서 이것이 수정 될 수있는 첫 번째 문제이며 인라인 및 최적화가 제대로 작동하는 한 초과분을 사용하지 않는 사람들에게 realloc_excess를 제로 비용으로 만들 것입니다.

전역 할당 자로 사용하면이 중 어느 것도 인라인 될 수 없습니다.

API가 모든 용도에 가장 인체 공학적이지는 않더라도 이러한 API는 최소한 설계에 결함이 없음을 보여주는 데 필요한 모든 용도를 허용합니다.

alloc_excess 를 호출하는 Github에는 문자 그대로 코드가 없습니다. 이것이 매우 중요한 기능이라면 왜 아무도 그것을 사용하지 않았습니까? C ++의 할당 API는 초과 용량에 대한 액세스를 제공하지 않습니다. 성능을 향상 시킨다는 실제 구체적인 증거가 있고 실제로 사용하기에 충분히 관심이있는 사람이라면 향후 이러한 기능을 이전 버전과 호환되는 방식으로 추가 / 안정화하는 것이 매우 간단 해 보입니다.

전역 할당 자로 사용하면이 중 어느 것도 인라인 될 수 없습니다.

그렇다면 그것은 최소한 LTO 빌드의 경우 해결해야 할 문제입니다. jemalloc 와 같은 전역 할당자가 이것에 의존하기 때문입니다. nallocx 는 _by design_ 방식이며 첫 번째 권장 사항입니다. jemalloc의 개발자가 alloc_excess 성능과 관련하여 우리를 만들었습니다. 이러한 호출을 인라인해야하고 C 속성을 제대로 전파해야 컴파일러가 그렇지 않은 호출 사이트에서 nallocx 호출을 제거합니다. C 및 C ++ 컴파일러처럼 Excess 사용하십시오.

우리는 할 수 없습니다 경우에도 Excess API는 여전히 패치하여 제로 비용을 만들 수 있습니다 jemalloc API를 (내 녹 LANG 이러한 패치의 초기 구현을 / jemalloc 포크). API를 직접 유지하거나 업스트림에 배치 할 수 있지만, 업스트림에 도달하려면 다른 언어가 이러한 최적화를 수행 할 수 있고 Rust가 수행 할 수없는 이유에 대해 좋은 사례를 만들어야합니다. 이 새로운 API 속도가 매우 빠르고보다처럼 아니면, 또 다른 인수가 있어야합니다 mallocx + nallocx 필요성 않는 사용자를 위해 Excess .

이것이 매우 중요한 기능이라면 왜 아무도 그것을 사용하지 않았습니까?

그건 좋은 질문이야. std::Vec 는 Excess API를 사용하기위한 포스터 자식이지만 현재는 사용하지 않습니다. "이것이 Excess 에서 누락되었습니다. API "는 제가 Vec 사용하도록 만들려고했습니다. Excess API :

• Excess 를 전혀 반환하지 않았습니다 : https://github.com/rust-lang/rust/pull/45514
• grow_in_place_excess 및 alloc_zeroed_excess 와 같은 기능이 없습니다.
• FFI에서 C 속성을 제대로 전파 할 수 없습니다 : https://github.com/rust-lang/rust/issues/46046
• ... (여기서 끝나는 것 같지 않습니다)

아무도이 API를 사용하지 않는 이유를 알 수 없습니다. 그러나 std 라이브러리조차도 데이터 구조에 사용할 수 없다는 점을 감안할 때 ( Vec )에 가장 적합합니다. 추측해야한다면 주된 이유는 다음과 같습니다. 이 API는 현재 손상되었습니다.

더 자세히 추측해야한다면이 API를 설계 한 사람조차도 사용하지 않았다고 말할 수 있습니다. 주로 단일 std 컬렉션에서 사용하지 않기 때문입니다 (이 API가 처음에 테스트 될 것으로 예상하는 곳입니다). , 또한 _excess 및 Excess 를 사용하여 usable_size / allocation_size ) 의미하는 것은 프로그램에 매우 혼란 스럽거나 성가시기 때문입니다.

이는 아마도 Excess -less API에 더 많은 작업이 투입 되었기 때문일 것입니다. 두 개의 API가있는 경우 동기화를 유지하기 어렵고 사용자가 둘 다 발견하고 어떤 것을 사용해야하는지 알기 어렵습니다. 마지막으로 사용자가 올바른 일을하는 것보다 편리함을 선호하기가 어렵습니다.

즉, 두 개의 경쟁 API가 있고 작업의 100 %를 하나의 개선에, 작업의 0 %를 다른 하나의 개선에 투입한다면, 하나가 실제로 크게 작동하고 있다는 결론에 도달하는 것은 놀라운 일이 아닙니다. 다른 것보다 낫습니다.

내가 알 수있는 한, 다음은 Github의 jemalloc 테스트 외부에서 nallocx 대한 유일한 두 번의 호출입니다.

https://github.com/facebook/folly/blob/f2925b23df8d85ebca72d62a69f1282528c086de/folly/detail/ThreadLocalDetail.cpp#L182
https://github.com/louishust/mysql5.6.14_tokudb/blob/4897660dee3e8e340a1e6c8c597f3b2b7420654a/storage/tokudb/ft-index/ftcxx/malloc_utils.hpp#L91

둘 다 현재 alloc_excess API와 비슷하지 않지만 할당 크기를 계산하기 전에 독립형으로 사용됩니다.

Apache Arrow는 구현에 nallocx 를 사용하는 방법을 살펴 보았지만 제대로 작동하지 않는 것으로 나타났습니다.

https://issues.apache.org/jira/browse/ARROW-464

이것들은 기본적으로 내가 찾을 수있는 nallocx 대한 유일한 참조입니다. 할당 자 API의 초기 구현이 이러한 모호한 기능을 지원하는 것이 왜 중요한가요?

내가 알 수있는 한, 다음은 Github의 jemalloc 테스트 외부에서 nallocx에 대한 유일한 두 번의 호출입니다.

내 머리 꼭대기에서 나는 적어도 페이스 북의 벡터 유형이 페이스 북의 malloc 구현 ( malloc 및 fbvector 성장 정책을 통해 사용하고 있음을 알고 있습니다. 이는 페이스 북에서 C ++ 벡터의 큰 덩어리가 이것을 사용합니다) 그리고 채플이 String 유형의 성능 ( 여기 및 추적 문제 ). 그렇다면 오늘은 Github의 최고의 날이 아니 었나요?

할당 자 API의 초기 구현이 이러한 모호한 기능을 지원하는 것이 왜 중요한가요?

할당 자 API의 초기 구현은이 기능을 지원할 필요가 없습니다.

그러나이 기능에 대한 좋은 지원은 이러한 API의 안정화를 차단해야합니다.

나중에 이전 버전과 호환되도록 추가 할 수 있는데 안정화를 차단해야하는 이유는 무엇입니까?

나중에 이전 버전과 호환되도록 추가 할 수 있는데 안정화를 차단해야하는 이유는 무엇입니까?

적어도 저에게는 디자인 공간의 절반 만 충분히 탐구했음을 의미하기 때문입니다.

API의 과도하지 않은 관련 부분이 초과 관련 기능의 설계에 의해 영향을받을 것으로 예상하십니까? 나는 그 논의를 온전히 따랐지만 나에게는 그럴 것 같지 않다는 것을 인정한다.

이 API를 만들 수없는 경우 :

fn alloc(...) -> (*mut u8, usize) { 
   // worst case system API:
   let ptr = malloc(...);
   let excess = malloc_excess(...);
   (ptr, excess)
}
let (ptr, _) = alloc(...); // drop the excess

이것만큼 효율적입니다.

fn alloc(...) -> *mut u8 { 
   // worst case system API:
   malloc(...)
}
let ptr = alloc(...);

그러면 더 큰 문제가 있습니다.

API의 과도하지 않은 관련 부분이 초과 관련 기능의 설계에 의해 영향을받을 것으로 예상하십니까?

예, 좋은 초과 API가 과도하지 않은 관련 기능의 디자인에 큰 영향을 미칠 것으로 예상합니다. 완전히 제거됩니다.

그러면 동기화되지 않은 두 개의 API가 있고 초과 API가 과도하지 않은 API보다 기능이 적은 현재 상황을 방지 할 수 있습니다. 과도하게 가득 찬 API 위에 과도하지 않은 API를 빌드 할 수 있지만 그 반대는 사실이 아닙니다.

Excess 를 버리고 싶은 사람은 그냥 버려야합니다.

명확하게 말하면, 이전 버전과 호환되는 방식으로 사실 뒤에 alloc_excess 메서드를 추가하는 방법이 있다면 괜찮을까요? (물론 alloc_excess 없이 안정화한다는 것은 나중에 추가하는 것이 큰 변화가 될 것이라는 것을 의미합니다. 저는 귀하의 추론을 이해하도록 요청하는 것입니다.)

@joshlf 그렇게하는 것은 매우 간단합니다.

: bell : 지금은 위 의 에 따라 최종 댓글 기간을 입력합니다 . :벨:

Excess를 버리고 싶은 사람은 그냥 버려야합니다.

또는 초과 용량에 관심이있는 0.01 %의 사람들이 다른 방법을 사용할 수 있습니다.

@sfackler 이것은 녹에서 2 주간의 휴식을 취한 결과입니다-기본 메서드 impls를 잊어 버렸습니다. :)

또는 초과 용량에 관심이있는 0.01 %의 사람들이 다른 방법을 사용할 수 있습니다.

이 번호는 어디서 얻나요?

내 모든 Rust 데이터 구조는 메모리에서 평평합니다. 그렇게 할 수있는 능력이 내가 Rust를 사용하는 유일한 이유입니다. 모든 것을 Box 할 수 있다면 다른 언어를 사용할 것입니다. 그래서 저는 Excess 의 0.01% 에 대해 신경 쓰지 않고 항상 신경 씁니다.

나는 이것이 도메인에 따라 다르며 다른 도메인에서는 사람들이 Excess 에 대해 전혀 신경 쓰지 않을 것이라는 것을 이해하지만, Rust 사용자의 0.01 %만이 이것에 대해 신경 쓰는 것 같지 않습니다 (많은 사람들이 Vec 사용함을 의미합니다) String , 이는 Excess 의 포스터-하위 데이터 구조입니다.

나는 malloc을 사용하는 것들에 비해 nallocx를 사용하는 총 4 가지가 있다는 사실에서 그 숫자를 얻고 있습니다.

뿡뿡

처음부터 "올바르게"했다면 fn alloc(layout) -> (ptr, excess) 있고 fn alloc(layout) -> ptr 는 전혀 없을 것이라고 제안 하는가? 그것은 나에게 명백하지 않은 것 같습니다. 초과가 사용 가능하더라도 alloc_excess(layout).0 로 구현 되더라도 초과가 중요하지 않은 사용 사례 (예 : 대부분의 트리 구조)를 위해 후자의 API를 사용하는 것이 자연스러워 보입니다.

뿡뿡

그것은 나에게 명백하지 않은 것 같습니다. 초과가 사용 가능하더라도 초과가 중요하지 않은 사용 사례 (예 : 대부분의 트리 구조)를 위해 후자의 API를 사용하는 것은 당연한 것 같습니다. 이는 alloc_excess (layout) .0으로 구현 된 경우에도 마찬가지입니다.

현재, 과잉-풀 API는 과잉-적은 API 위에 구현됩니다. 초과하지 않는 할당자를 위해 Alloc 를 구현하려면 사용자가 alloc 및 dealloc 메서드를 제공해야합니다.

그러나 과도하게 가득 찬 할당 자에 대해 Alloc 를 구현하려면 더 많은 메서드를 제공해야합니다 (최소 alloc_excess ,하지만 realloc_excess 로 이동하면 커집니다. alloc_zeroed_excess , grow_in_place_excess , ...).

다른 방법으로하면, 즉, 과도하게 가득 찬 API 위에 과도하지 않은 API를 구현 한 다음 alloc_excess 및 dealloc 충분합니다. 두 가지 유형의 할당 자.

신경 쓰지 않거나 초과분을 반환하거나 질의 할 수없는 사용자는 입력 크기 나 레이아웃을 반환 할 수 있지만 (작은 불편 함), 초과분을 처리 할 수 ​​있고 처리하려는 사용자는 구현할 필요가 없습니다. 더 많은 방법.

뿡뿡

나는 malloc을 사용하는 것들에 비해 nallocx를 사용하는 총 4 가지가 있다는 사실에서 그 숫자를 얻고 있습니다.

Rust 생태계에서 _excess 사용에 대한 다음 사실을 감안할 때 :

• 녹 생태계에서 총 0 개 사용 _excess
• 총 0 _excess 는 rust std 라이브러리에서
• Vec 및 String 조차도 rust std 라이브러리에서 _excess API를 제대로 사용할 수 없습니다.

• _excess API는 불안정하고 과도하지 않은 API와 동기화되지 않았으며 최근까지 버그가 발생했습니다 ( excess 도 반환하지 않았 음) ...

  다른 언어에서 _excess 사용에 대한 다음 사실을 고려하면 :

• jemalloc의 API는 이전 버전과의 호환성으로 인해 C 또는 C ++ 프로그램에서 기본적으로 지원되지 않습니다.

• jemalloc의 초과 API를 사용하려는 C 및 C ++ 프로그램은 다음과 같은 방법으로 사용할 수 있습니다.
  
  
  
  • 시스템 할당 자 선택 해제 및 jemalloc (또는 tcmalloc)
  
  
  • 언어의 표준 라이브러리를 다시 구현합니다 (C ++의 경우 호환되지 않는 표준 라이브러리를 구현).
  
  
  • 이 호환되지 않는 표준 라이브러리 위에 전체 스택을 작성하십시오.
  
  
• 일부 커뮤니티 (파이어 폭스가이를 사용하고 페이스 북이 C ++ 표준 라이브러리의 컬렉션을 다시 구현하여 사용할 수 있도록합니다 ...)는 여전히 사용하지 않습니다.

이 두 가지 주장은 나에게 그럴듯 해 보인다.

• excess 에서 API std 그러므로, 사용할 수 없습니다 std 는 녹 생태계에서 한 번도 사용하지 않는 이유입니다, 라이브러리를 사용할 수 없습니다, 따라서 아무도 캔 .
• C와 C ++가이 API를 사용하는 것을 거의 불가능하게 만들지 만, 인력이있는 큰 프로젝트는이를 사용하기 위해 많은 시간을 들이기 때문에 적어도 잠재적으로 작은 사람들의 커뮤니티에서 _ 많은 _ 관심을 기울입니다.

당신의 주장 :

• 아무도 _excess API를 사용하지 않기 때문에 0.01 %의 사람들 만이 관심을 갖고 있습니다.

하지 않습니다.

@alexcrichton -> Result<*mut u8, AllocErr> 에서 -> *mut void 로 전환하기로 한 결정은 할당 자 RFC의 원래 개발을 따르는 사람들에게 큰 놀라움으로 다가올 수 있습니다.

나는 당신의 점수에 동의하지 않지만, 그럼에도 불구하고 상당수의 사람들이 null을 놓칠 가능성이 높아진 것보다 Result 의 "무거움"으로 살기를 원했을 것 같았다. 반환 된 값을 확인하십시오.

• @alexcrichton 과 같이 컴파일러 트릭을 통해 어떤 식 으로든 이러한 문제를 처리 할 수 ​​있다고 가정하기 때문에 ABI에서 부과 한 런타임 효율성 문제를 무시하고 있습니다.

우리가 그 자체로 늦은 변화에 대한 가시성을 증가 얻을 수있는 몇 가지 방법이 있나요?

한 가지 방법 (내 머리 꼭대기에서 벗어남) : 마스터 브랜치에서 자체 PR로 서명을 변경 하고 Allocator 는 여전히 불안정합니다. 그리고 누가 PR에 대해 불평하는지 (그리고 누가 축하하는지!)

• 손이 너무 무겁습니까? 이러한 변화를 안정화와 결합하는 것보다 정의상 덜 무거운 것 같습니다 ...

반환 여부의 주제에 *mut void 또는 반환하는 Result<*mut void, AllocErr> : 그것의 가능한 논의 된 바와 같이 우리는 "낮은 수준"할당 특성을 별도의 '높은 수준'의 아이디어를 재 방문 할 것을 할당 자 RFC의 II .

(분명히 *mut void 반환 값에 대해 심각한 이의가 있다면 fcpbot을 통해 우려 사항으로 제출할 것입니다. 그러나이 시점에서 저는 libs 팀의 판단을 거의 신뢰하고 있습니다. 이 할당 자 사가에 대한 피로로 인해 일부 부분.)

뿡뿡

-> Result<*mut u8, AllocErr> 에서 -> *mut void 로 전환하기로 한 결정은 할당 자 RFC의 원래 개발을 따르는 사람들에게 큰 놀라움이 될 수 있습니다.

후자는 논의했듯이 우리가 표현하고자하는 유일한 오류는 OOM이라는 것을 의미합니다. 따라서 실수로 인한 오류 확인 실패에 대한 보호의 이점이있는 약간 더 가벼운 중간 크기는 -> Option<*mut void> 입니다.

뿡뿡

std의 초과 API는 사용할 수 없으므로 std 라이브러리가 사용할 수 없으므로 아무도 사용할 수 없기 때문에 Rust 생태계에서 한 번도 사용되지 않습니다.

그럼 가서 고치세요.

뿡뿡

mut void 를 반환할지 아니면 < mut void, AllocErr> : take II에서 논의 된 것처럼 별도의 "고수준"및 "저수준"할당 자 특성에 대한 아이디어를 다시 검토해야 할 가능성이 있습니다. 할당 자 RFC의.

고수준 API가 alloc_one , alloc_array 등으로 Alloc 자체에있을 것이라는 점을 제외하면 기본적으로 우리의 생각이었습니다. 생태계에서 확장으로 먼저 개발할 수도 있습니다. 사람들이 어떤 API에 수렴하는지 확인합니다.

뿡뿡

내가 Layout을 Copy가 아닌 Clone 만 구현하도록 만든 이유는 Layout 유형에 더 많은 구조를 추가 할 수있는 가능성을 열어두고 싶었 기 때문입니다. 특히, 레이아웃이 그것을 구성하는 데 사용되는 모든 유형 구조 (예 : 16 배열의 struct {x : u8, y : [char; 215]})를 추적하려고 시도하여 할당자가 현재 콘텐츠가 어떤 유형에서 작성되는지보고하는 계측 루틴을 노출하는 옵션입니다.

이것이 어딘가에서 실험 되었습니까?

@sfackler 이미 대부분의 작업을 수행했으며 복제 된 API로 모든 작업을 수행 할 수 있습니다 (과잉 + _excess 메서드 없음). 지금은 두 개의 API가 있고 완전한 _excess API가 없어도 괜찮습니다.

여전히 나를 걱정하는 유일한 것은 할당자를 구현하려면 alloc + dealloc 를 구현해야하지만 alloc_excess + dealloc 도 작동해야한다는 것입니다. 나중에 alloc_excess 측면에서 alloc 에 기본 구현을 제공 할 수 있습니까? 아니면 불가능하거나 주요 변경 사항입니까? 실제로 대부분의 할당자는 어쨌든 대부분의 메소드를 구현할 것이므로 이것은 큰 문제는 아니지만 소원과 비슷합니다.

jemallocator 는 Alloc 두 번 구현합니다 ( Jemalloc 및 &Jemalloc ). 여기서 method 대한 Jemalloc 구현은 다음과 같습니다. &Jemalloc 구현에 메서드 호출을 전달하는 (&*self).method(...) 즉, Alloc 대해 Jemalloc Alloc 의 두 구현을 모두 수동으로 동기화해야합니다. &/_ 구현에 대해 다른 동작을 얻는 것이 비극적 일 수 있는지 여부는 모르겠습니다.

사람들이 실제로 Alloc 특성으로 실제로 무엇을하고 있는지 알아내는 것이 매우 어렵다는 것을 알게되었습니다. 내가 그것을 사용하는 유일한 프로젝트는 어쨌든 (서보, 산화 환원) 야간 사용을 유지하고 글로벌 할당자를 변경하는 데만 사용합니다. 컬렉션 유형 매개 변수로 사용하는 프로젝트를 찾을 수 없다는 것이 많이 걱정됩니다 (아마도 운이 좋지 않았고 일부가 있습니까?). 특히 Vec -like 유형 위에 SmallVec 및 ArrayVec 구현 예제를 찾고있었습니다 ( std::Vec 에는 Alloc 가 없으므로 Vec s와 다른 Alloc ator) 간의 복제가 어떻게 작동하는지 궁금합니다 ( Box 복제에도 동일하게 적용됨) Alloc ). 이러한 구현이 어딘가에 어떻게 보이는지에 대한 예가 있습니까?

내가 그것을 사용하는 유일한 프로젝트는 어쨌든 밤마다 사용하게 될 것입니다 (서보, 산화 환원)

그만한 가치를 위해 Servo는 가능한 경우 불안정한 기능에서 벗어나려고 노력하고 있습니다 : https://github.com/servo/servo/issues/5286

이것은 또한 닭고기와 달걀 문제입니다. 많은 프로젝트는 아직 불안정 하기 때문에 Alloc 사용하지 않습니다.

애초에 _excess API를 완전히 보완해야하는 이유가 명확하지 않습니다. 원래는 jemalloc의 실험적인 * allocm API를 반영하기 위해 존재했지만 전체 API 표면을 복제하지 않기 위해 몇 년 전 4.0에서 제거되었습니다. 우리가 그들의 리드를 따를 수있을 것 같습니까?

나중에 alloc_excess 측면에서 alloc에 ​​기본 구현을 제공 할 수 있습니까? 아니면 불가능하거나 주요 변경 사항입니까?

alloc_excess 측면에서 alloc 의 기본 구현을 추가 할 수 있지만 alloc_excess 에는 alloc 측면에서 기본 구현이 있어야합니다. 하나 또는 둘 다를 구현하면 모든 것이 잘 작동하지만 둘 중 하나를 구현하지 않으면 코드가 컴파일되지만 무한 반복됩니다. 이것은 이전에 (아마도 Rand ?에 대한 것입니다), 우리는 당신이 그 함수들 중 적어도 하나를 구현해야한다고 말할 수있는 방법을 가질 수 있지만 우리는 어떤 것을 신경 쓰지 않습니다.

컬렉션 유형 매개 변수로 사용하는 프로젝트를 찾을 수 없다는 것이 많이 걱정됩니다 (아마도 운이 좋지 않았고 일부가 있습니까?).

나는 그런 일을하는 사람을 모릅니다.

내가 그것을 사용하는 유일한 프로젝트는 어쨌든 밤마다 사용하게 될 것입니다 (서보, 산화 환원)

이것이 앞으로 나아가는 것을 막는 한 가지 큰 점은 stdlib 컬렉션이 아직 파라 메트릭 할당자를 지원하지 않는다는 것입니다. 대부분의 외부 컬렉션은 내부 컬렉션 ( Box , Vec 등)을 사용하기 때문에 대부분의 다른 상자도 제외됩니다.

내가 그것을 사용하는 유일한 프로젝트는 어쨌든 밤마다 사용하게 될 것입니다 (서보, 산화 환원)

이것이 앞으로 나아가는 것을 막는 한 가지 큰 점은 stdlib 컬렉션이 아직 파라 메트릭 할당자를 지원하지 않는다는 것입니다. 대부분의 외부 컬렉션은 내부 컬렉션 (Box, Vec 등)을 사용하기 때문에 대부분의 다른 상자도 제외됩니다.

이것은 나에게 적용됩니다-장난감 커널이 있고 Vec<T, A> 사용할 수 있다면 대신 내부 변경 가능한 전역 할당 자 파사드가 있어야합니다.

@remexre 내부 가변성으로 전역 상태를 피하기 위해 데이터 구조를 매개

내가 생각하는 내부 변경 가능한 전역 상태는 여전히 있지만 전역 set_allocator 함수를 사용하는 것보다 메모리가 완전히 매핑 될 때까지 전역 할당자를 사용할 수없는 설정을 갖는 것이 훨씬 안전하다고 느낍니다.

편집 : 그냥 내가 질문에 대답하지 않았다는 것을 깨달았습니다. 지금은 다음과 같은 것이 있습니다.

struct BumpAllocator{ ... }
struct RealAllocator{ ... }
struct LinkedAllocator<A: 'static + AreaAllocator> {
    head: Mutex<Option<Cons<A>>>,
}
#[global_allocator]
static KERNEL_ALLOCATOR: LinkedAllocator<&'static mut (AreaAllocator + Send + Sync)> =
    LinkedAllocator::new();

여기서 AreaAllocator 는 할당자가 실수로 "겹치는"(할당하는 주소 범위 측면에서) 아닌지 (런타임에) 확인할 수있는 특성입니다. BumpAllocator 는 RealAllocator 를 만들기 위해 나머지 메모리를 매핑 할 때 스크래치 공간으로 아주 초기에만 사용됩니다.

이상적으로는 Mutex<Option<RealAllocator>> (또는 "삽입 전용"으로 만드는 래퍼)가 유일한 할당 자이고 초기에 할당 된 모든 항목이 초기 부팅 BumpAllocator 의해 매개 변수화되도록하고 싶습니다.

뿡뿡

애초에 _excess API를 완전히 보완해야하는 이유가 명확하지 않습니다. 원래는 jemalloc의 실험적인 * allocm API를 반영하기 위해 존재했지만 전체 API 표면을 복제하지 않기 위해 몇 년 전 4.0에서 제거되었습니다. 우리가 그들의 리드를 따를 수있을 것 같습니까?

현재 shrink_in_place 는 실제 할당 크기를 반환하는 xallocx 를 호출합니다. shrink_in_place_excess 이 존재하지 않기 때문에이 크기를 버리고 사용자는 nallocx 를 호출하여 재 계산해야합니다. 비용은 할당 크기에 따라 달라집니다.

따라서 우리가 이미 사용하고있는 적어도 일부 jemalloc 할당 함수가 사용 가능한 크기를 반환하고 있지만 현재 API에서는이를 사용할 수 없습니다.

뿡뿡

장난감 커널을 작업 할 때 할당자가 설정 될 때까지 할당이 발생하지 않도록 글로벌 할당자를 피하는 것도 저의 목표였습니다. 내가 한 사람이 아니라는 소식을 듣게되어 기쁩니다!

기본 전역 할당 자에 Heap 라는 단어가 마음에 들지 않습니다. Default 아닌 이유는 무엇입니까?

또 다른 설명 : RFC 1974는 이 모든 것을 std::alloc 만 현재 std::heap 있습니다. 안정화를 위해 어떤 위치가 제안되고 있습니까?

@jethrogb "Heap"은 "malloc이 포인터를 제공하는 것"에 대한 꽤 정식 용어입니다.이 용어에 대해 우려하는 점은 무엇입니까?

뿡뿡

"malloc이 당신에게 포인터를 제공하는 것"

내 마음 속에서 그것이 System 것을 제외하고.

아 물론입니다. Global 는 다른 이름일까요? #[global_allocator] 를 사용하여 선택했기 때문입니다.

여러 힙 할당자가있을 수 있습니다 (예 : libc 및 접두사 jemalloc). std::heap::Heap 을 std::heap::Default , #[global_allocator] 을 #[default_allocator] 바꾸는 것은 어떻습니까?

달리 지정하지 않으면 얻을 수 있다는 사실 (예를 들어 Vec 가 할당 자에 대한 추가 유형 매개 변수 / 필드를 얻는 경우)이 "per"가 없다는 사실보다 더 중요합니다. -instances "상태 (또는 실제로 인스턴스).

이제 최종 댓글 기간이 완료되었습니다.

FCP와 관련하여 안정화를 위해 제안 된 API 부분 집합은 매우 제한적으로 사용된다고 생각합니다. 예를 들어 jemallocator 상자는 지원하지 않습니다.

어떤 방식으로? jemallocator는 기능 플래그 뒤에있는 불안정한 메서드의 일부를 표시해야 할 수도 있지만 그게 전부입니다.

경우 jemallocator 녹 예를 들어 구현할 수 없습니다 안정에 Alloc::realloc 호출하여 je_rallocx 기본 ALLOC에 의존하지만, 요구, 다음은 대한 허용 대체 +의 dealloc IMPL 아니다 복사 + 표준 도서관의 alloc_jemalloc 상자 IMO.

물론, 당신은 컴파일 뭔가를 얻을 수 있지만, 특히 유용한 것은 아니다.

왜? C ++는 할당 자 API에 전혀 재 할당 개념이 없으며 언어를 손상시키지 않는 것 같습니다. 분명히 이상적이지는 않지만 왜 받아 들일 수 없는지 이해할 수 없습니다.

C ++ 컬렉션은 일반적으로 realloc을 사용하지 않습니다. C ++ 이동 생성자는 realloc이 유용하지 않기 때문에 임의의 코드를 실행할 수 있기 때문입니다.

그리고 비교는 C ++가 아니라 내장 된 jemalloc 지원이있는 현재 Rust 표준 라이브러리와 비교됩니다. Alloc API의이 하위 집합 만 사용하여 표준을 벗어난 할당 자로 전환하는 것은 회귀입니다.

그리고 realloc 가 예입니다. jemallocator는 현재 alloc_zeroed , alloc_excess , usable_size , grow_in_place 등을 구현합니다.

alloc_zeroed는 안정화되도록 제안되었습니다. 내가 말할 수있는 한 (look upthread), 문자 그대로 alloc_excess 은 존재하지 않습니다. 기본 구현으로 돌아 가면 회귀하는 코드를 보여줄 수 있습니까?

그러나 더 일반적으로, 이것이 이러한 API의 일부를 안정화하는 것에 반대하는 이유를 알 수 없습니다. jemallocator를 사용하지 않으려면 계속 사용할 수 없습니다.

Layout::array<T>() const fn으로 만들 수 있습니까?

당장은 당황 할 수 있습니다.

당장은 당황 할 수 있습니다.

알겠습니다 ... Layout::<T>::repeat(1).0 상응하는 당황스럽지 않은 const fn Layout::array_elem<T>() 합니다.

@mzabaluev 나는 당신이 설명하는 것이 Layout::new<T>() 과 동일하다고 생각합니다. 현재는 당황 할 수 있지만 Layout::from_size_align 및 .unwrap() 사용하여 구현 되었기 때문에 다른 방식으로 수행 될 수 있습니다.

@joshlf 나는이 구조체의 크기가 5라고 생각하지만 배열의 요소로 정렬 때문에 8 바이트마다 배치됩니다.

struct Foo {
    bar: u32,
    baz: u8
}

Foo 배열이 크기 계산을위한 마지막 요소의 패딩을 포함할지 확신 할 수 없지만 이것이 저의 강한 기대입니다.

Rust에서 객체의 크기는 항상 배열의 배수이므로 배열의 n 번째 요소의 주소는 항상 array_base_pointer + n * size_of<T>() 입니다. 따라서 배열에있는 객체의 크기는 항상 자체적으로 해당 객체의 크기와 동일합니다. 자세한 내용은 repr (Rust) 의

좋아요, 구조체가 정렬에 패딩 된 것으로 밝혀졌지만 AFAIK 이것은 #[repr(C)] 제외하고는 안정적인 보장이 아닙니다.
어쨌든 Layout::new 을 const fn으로 만드는 것도 환영 할 것입니다.

이것은 안정된 함수의 문서화 된 (따라서 보장 된) 동작입니다.

https://doc.rust-lang.org/std/mem/fn.size_of.html

유형의 크기를 바이트 단위로 반환합니다.

보다 구체적으로 이것은 정렬 패딩을 포함하여 해당 항목 유형이있는 배열의 연속 요소 사이의 바이트 단위 오프셋입니다. 따라서 모든 유형 T 및 길이 n 경우 [T; n] 의 크기는 n * size_of::<T>() 입니다.

감사. Layout::new 의 결과를 곱하는 모든 const fn은 본질적으로 차례로 당황 할 것이라는 것을 깨달았으므로 ( saturating_mul 또는 일부로 수행하지 않는 한) 다시 원점으로 돌아 왔습니다. const fn 추적 문제의 패닉에 대한 질문을 계속합니다.

panic!() 매크로는 현재 상수 표현식에서 지원되지 않지만 확인 된 산술의 패닉은 컴파일러에 의해 생성되며 해당 제한의 영향을받지 않습니다.

error[E0080]: constant evaluation error
 --> a.rs:1:16
  |
1 | const A: i32 = i32::max_value() * 2;
  |                ^^^^^^^^^^^^^^^^^^^^ attempt to multiply with overflow

error: aborting due to previous error

이것은 Alloc::realloc 와 관련이 있지만 최소 인터페이스의 안정화와는 관련이 없습니다 ( realloc 는 일부가 아님).

현재 때문에 Vec::reserve/double 호출 RawVec::reserve/double 하는 호출 Alloc::realloc 의 기본 IMPL Alloc::realloc 복사합니다 (죽은 벡터 요소 [len(), capacity()) 범위) . capacity() + 1 요소를 삽입하여 재 할당하려는 거대한 빈 벡터의 터무니없는 경우에 모든 메모리를 건 드리는 데 드는 비용은 중요하지 않습니다.

이론적으로 기본 Alloc::realloc 구현도 "bytes_used"범위를 사용하는 경우 재 할당시 관련 부분 만 복사 할 수 있습니다. 실제로 적어도 jemalloc은 Alloc::realloc 호출로 rallocx Alloc::realloc 기본 impl을 재정의합니다. 관련 메모리 만 복사하는 alloc / dealloc 댄스를하는 것이 rallocx 호출보다 빠르거나 느린 지 여부는 아마도 여러 가지에 달려있을 것입니다 ( rallocx 제자리에서 블록을 확장하려면 얼마나 많은 불필요한 메모리를 rallocx 복사할까요? 등).

https://github.com/QuiltOS/rust/tree/allocator-error 저는 관련 오류 유형이 일반화 자체를 수행하여 컬렉션 및 오류 처리 문제를 해결한다고 생각하는 방법을 보여주기 시작했습니다. 특히 모듈에서 내가 어떻게 변경하는지 주목하십시오.

• 항상 재사용 Result<T, A::Err> 에 대한 구현 T 구현
• unwrap 또는 기타 부분적
• 없음 oom(e) 외부하지 AbortAdapter .

이것은 내가 만드는 변경이 매우 안전하고 무의미하다는 것을 의미합니다! 오류 반환 및 오류 중단을 모두 처리하려면 정신적 불변성을 유지하기 위해 추가 노력이 필요하지 않아야합니다. 유형 검사기가 모든 작업을 수행합니다.

나는 기억한다 --- @Gankro 의 RFC에서 생각 하는가? 또는 pre-rfc 스레드 --- Gecko / Servo 사람들은 컬렉션의 오류를 자신의 유형에 포함시키지 않는 것이 좋았다고 말했습니다. 음, #[repr(transparent)] 를 AbortAdapter 하여 컬렉션을 Foo<T, A> 에서 Foo<T, AbortAdapter<A>> (안전 래퍼 내에서)간에 안전하게 변환하여 자유롭게 사용할 수 있도록 할 수 있습니다. 모든 방법을 복제하지 않고 앞뒤로 전환합니다. [back-compat의 경우 표준 라이브러리 컬렉션은 모든 이벤트에서 복제되어야하지만 사용자 메서드가 Result<T, !> 일 필요는 없습니다. 요즘에는 작업하기가 매우 쉽습니다.]

불행히도 코드는 lang 항목 (상자)의 유형 매개 변수를 변경하면 컴파일러를 혼동하기 때문에 완전한 유형 검사가되지 않습니다 (놀랍습니다!). ICE를 유발하는 박스 커밋은 마지막 것입니다. @eddyb 은 # 47043에서

@joshlf 편집 https://github.com/rust-lang/rust/pull/45272 에 대해 알려주고 여기에 통합했습니다. 감사!

영구 메모리 (예 : http://pmem.io )는 그 다음으로 큰 역할을하며 Rust가 잘 작동하도록 배치되어야합니다.

최근에 영구 메모리 할당 자 (특히 libpmemcto)를위한 Rust 래퍼 작업을 해왔습니다. 이 API의 안정화와 관련하여 어떤 결정을 내리 든 다음을 수행해야합니다.

• libpmemcto와 같은 영구 메모리 할당 자에 대한 성능 래퍼를 지원할 수 있어야합니다.
• 할당 자별로 컬렉션 유형을 지정 (매개 변수화) 할 수 있습니다 (현재는 Box, Rc, Arc 등을 복제해야 함).
• 할당 자간에 데이터 복제 가능
• 영구 메모리 풀의 인스턴스화시 다시 초기화되는 필드가있는 영구 메모리 저장 구조체를 지원할 수 있어야합니다. 즉, 일부 영구 메모리 구조체에는 힙에 일시적으로 만 저장되는 필드가 있어야합니다. 현재 사용 사례는 할당에 사용되는 영구 메모리 풀과 잠금에 사용되는 임시 데이터에 대한 참조입니다.

제쳐두고, pmem.io 개발 (인텔의 PMDK)은 수정 된 jemalloc 할당자를 엄청나게 사용합니다. 따라서 jemalloc을 예제 API 소비자로 사용하는 것이 현명한 것 같습니다.

컬렉션에서 Alloc ators를 사용하는 데 더 많은 경험을 쌓을 때까지 GlobalAllocator 만 포함하도록이 범위를 줄이는 것이 가능할까요?

IIUC 이것은 이미 servo 의 요구를 충족시킬 것이며 우리가 병렬로 매개 변수화 컨테이너를 실험 할 수있게 해줄 것입니다. 앞으로는 GlobalAllocator 대신 사용하도록 컬렉션을 이동하거나 Alloc 대해 GlobalAllocator Alloc 의 블랭킷 impl을 추가하여 모든 컬렉션에 사용할 수 있습니다.

생각?

@gnzlbg #[global_allocator] 속성이 유용하려면 ( heap::System 를 선택하는 것 이상) Alloc 트레이 트도 안정적이어야 https : / 와 같은 상자로 구현할 수 있습니다 GlobalAllocator 라는 유형이나 특성이 없습니다. 새로운 API를 제안하고 있습니까?

현재 GlobalAllocator라는 유형이나 특성이 없습니다. 새로운 API를 제안하고 있습니까?

내가 제안한 것은 @alexcrichton이 여기 에서 안정화 하라고 제안한 "최소"API의 이름을 Alloc 에서 GlobalAllocator 하여 전역 할당 자만 나타내고 컬렉션이 다른 사용자에 의해 매개 변수화되도록하는 것입니다. 할당 자 특성 ( GlobalAllocator 특성으로 매개 변수화 할 수 없음을 의미하지는 않음).

IIUC servo 현재 전역 할당자를 전환 할 수만 있으면됩니다 (할당 자에 의해 일부 컬렉션을 매개 변수화 할 수있는 것과는 반대로). 따라서 두 사용 사례 모두에 대해 미래를 보장해야하는 솔루션을 안정화하려고하는 대신 지금 글로벌 할당 자 문제 만 해결하고 나중에 할당 자에 의한 컬렉션을 매개 변수화하는 방법을 알아낼 수 있습니다.

그게 말이되는지 모르겠어요.

IIUC 서보는 현재 전역 할당자를 전환 할 수만 있으면됩니다 (할당 자에 의해 일부 컬렉션을 매개 변수화 할 수있는 것과는 반대로).

맞지만 :

• 트레이 트와 그 메서드가 안정적으로 구현 될 수 있다면 std::heap::Heap 를 거치지 않고 직접 호출 할 수도 있습니다. 따라서 이는 특성 글로벌 할당 자일뿐만 아니라 할당 자에 대한 특성이며 (할당 자보다 일반적인 컬렉션에 대해 다른 것을 만들더라도) GlobalAllocator 는 특별히 좋은 이름이 아닙니다.
• jemallocator 크레이트는 현재 alloc_excess , realloc , realloc_excess , usable_size , grow_in_place , shrink_in_place 을 구현합니다. 제안 된 최소 API의 일부입니다. 기본 impl보다 더 효율적일 수 있으므로 제거하면 성능이 저하됩니다.

두 점 모두 의미가 있습니다. 이 기능의 안정화를 크게 가속화 할 수있는 유일한 방법은 컬렉션을 매개 변수화하는 데 좋은 특성이되는 종속성을 줄이는 것 뿐이라고 생각했습니다.

[서보가 (안정 | 공식 모질라 상자)와 같을 수 있고화물이 이것을 강제하여 여기에서 약간의 압력을 제거 할 수 있다면 좋을 것입니다.]

@ Ericson2314 서보는 이러한 API를 사용하려는 유일한 프로젝트가 아닙니다.

@ Ericson2314 이것이 의미하는 바를 이해하지 못합니다.

컨텍스트 : Servo는 현재 많은 불안정한 기능 ( #[global_allocator] )을 사용하고 있지만, 우리는 천천히 그로부터 벗어나려고 노력하고 있습니다 (일부 기능을 안정화 한 컴파일러로 업데이트하거나 안정적인 대안을 찾음). ) https://github.com/servo/servo/issues/5286 에서 추적됩니다 #[global_allocator] 안정화하는 것이 좋지만 서보 작업을 차단하지는 않습니다.

Firefox는 cdylib 컴파일 할 때 Rust std가 기본적으로 시스템 할당자를 사용한다는 사실에 의존하며, 동일한 바이너리로 연결되는 mozjemalloc은 malloc 및 free 와 같은 기호를 정의합니다 #[global_allocator] 를 사용하여 mozjemalloc을 명시 적으로 선택하여 전체 설정을보다 강력하게 만들고 싶습니다.

@SimonSapin 할당 자와 컬렉션을 더 많이 사용할수록 컬렉션을 Alloc 로 매개 변수화하고 싶지 않다고 생각하는 경향이 있습니다. 할당 자에 따라 컬렉션이 다른 API, 일부 작업의 복잡성 변경, 일부 컬렉션 세부 사항은 실제로 할당 자에 따라 달라집니다.

그래서 저는 여기서 발전 할 수있는 방법을 제안하고 싶습니다.

1 단계 : 힙 할당 자

처음에는 사용자가 안정적인 Rust에서 힙 (또는 시스템 / 플랫폼 / 글로벌 / 프리 스토어 할당 자 또는 선호하는 이름)에 대한 할당자를 선택하도록 제한 할 수 있습니다.

우리가 처음에 매개 변수화하는 유일한 것은 Box 이며, 메모리를 할당 ( new )하고 할당 해제 ( drop )하면됩니다.

이 할당 자 특성은 처음에는 @alexcrichton이 제안한 (또는 다소 확장 된) API를 가질 수 있으며,이 할당 자 특성은 야간에 std:: 컬렉션을 지원하기 위해 약간 확장 된 API를 가질 수 있습니다.

일단 우리가 거기에 도착하면 안정으로 마이그레이션하려는 사용자는 그렇게 할 수 있지만 불안정한 API로 인해 성능이 저하 될 수 있습니다.

2 단계 : 성능 저하없는 힙 할당 자

이 시점에서 성능 저하로 인해 안정적으로 이동할 수없는 사용자를 재평가하고이 API를 확장하고 안정화하는 방법을 결정할 수 있습니다.

3 ~ N 단계 : std 컬렉션에서 사용자 지정 할당자를 지원합니다.

첫째, 이것은 어렵 기 때문에 결코 일어나지 않을 수도 있고 결코 일어나지 않는 것이 나쁜 것이 아니라고 생각합니다.

사용자 지정 할당 자로 컬렉션을 매개 변수화하고 싶을 때 성능 문제 나 사용성 문제가 있습니다.

사용성 문제가있는 경우 일반적으로 SliceDeque 크레이트와 같이 사용자 지정 할당 자의 기능을 활용하는 다른 컬렉션 API를 원합니다. 사용자 지정 할당 자에 의한 컬렉션 매개 변수화는 여기서 도움이되지 않습니다.

성능 문제가있는 경우 사용자 지정 할당자가 나를 도와주는 것이 여전히 매우 어려울 것입니다. Vec 는 내가 가장 자주 다시 구현 한 컬렉션이기 때문에 다음 섹션에서만 고려할 것입니다.

시스템 할당 자 호출 수 감소 (Small Vector Optimization)

시스템 할당 자에 대한 호출 수를 줄이기 위해 Vec 개체 내부에 일부 요소를 할당하려면 오늘은 SmallVec<[T; M]> 합니다. 그러나 SmallVec 는 Vec 가 아닙니다.

• Vec 이동은 요소 수에서 O (1)이지만 SmallVec<[T; M]> 은 N <M 및 O (1) 이후에 O (N)입니다.

• Vec 요소에 대한 포인터는 len() <= M 아닌 경우 이동시 무효화됩니다. 즉, into_iter 와 같은 len() <= M 작업이 요소를 단지 포인터를 취하는 대신 반복기 객체 자체.

이것을 지원하기 위해 할당자를 통해 Vec 제네릭을 만들 수 있습니까? 모든 것이 가능하지만 가장 중요한 비용은 다음과 같습니다.

• 이렇게하면 Vec 구현이 더 복잡해져이 기능을 사용하지 않는 사용자에게 영향을 미칠 수 있습니다.
• Vec 의 문서는 일부 작업의 동작이 할당 자에 따라 달라지기 때문에 더 복잡해질 것입니다.

이러한 비용은 무시할 수없는 수준이라고 생각합니다.

할당 패턴 활용

Vec 의 성장 인자는 특정 할당 자에 맞게 조정됩니다. std 에서는 일반 할당 자에 맞게 조정할 수 있습니다. jemalloc / malloc / ...하지만 사용자 지정 할당자를 사용하는 경우에는 우리가 선택한 성장 요인이 될 가능성이 있습니다. 기본적으로 사용 사례에 가장 적합하지 않습니다. 모든 할당자가 vec와 유사한 할당 패턴에 대한 성장 인자를 지정할 수 있어야합니까? 나는 모르지만 내 직감은 나에게 말한다 : 아마 아닐 것이다.

시스템 할당 자의 추가 기능 활용

예를 들어 오버 커밋 할당자는 대부분의 Tier 1 및 Tier 2 대상에서 사용할 수 있습니다. Linux 계열 및 Macos 시스템에서 힙 할당자는 기본적으로 오버 커밋하는 반면 Windows API는 메모리를 예약하는 데 사용할 수있는 VirtualAlloc 를 노출하고 (예 : Vec::reserve/with_capacity ) push 에서 메모리를 커밋합니다.

현재 Alloc 특성은 메모리 커밋 및 예약 개념을 분리하지 않기 때문에 Windows에서 이러한 할당자를 구현하는 방법을 노출하지 않습니다 (리눅스에서는 비 과도 할당자가 해킹 될 수 있습니다. 각 페이지를 한 번만 터치하면됩니다). 또한 할당자가 alloc 에서 기본적으로 오버 커밋 여부를 지정하는 방법을 공개하지 않습니다.

즉, Vec 대해이를 지원하기 위해 Alloc API를 확장해야하며, 이는 약간의 승리를위한 IMO입니다. 그러한 할당자가 있으면 Vec 의미가 다시 변경되기 때문입니다.

• Vec 은 다시 성장할 필요가 없으므로 reserve 와 같은 작업은 의미가 없습니다.
• push 있다 O(1) 대신은 상각 O(1) .
• 라이브 객체에 대한 반복자는 객체가 살아있는 한 무효화되지 않으므로 일부 최적화가 가능합니다.

시스템 할당 자의 더 많은 추가 기능 활용

cudaMalloc / cudaMemcpy / ...와 같은 일부 시스템 할당자는 고정 된 메모리와 고정되지 않은 메모리를 구분하여 분리 된 주소 공간에 메모리를 할당 할 수 있습니다. 할당 특성), ...

그러나 Vec과 같은 컬렉션에서이를 사용하면 GPU 커널에서 수행하는지 호스트에서 수행하는지에 따라 벡터 인덱싱이 갑자기 정의되지 않은 동작을 호출하는지 여부와 같은 미묘한 방식으로 일부 작업의 의미를 다시 변경합니다.

마무리

모든 컬렉션 (또는 Vec )을 매개 변수화하는 데 사용할 수있는 Alloc API를 만드는 것은 어렵고 아마도 너무 어려울 것입니다.

global / system / platform / heap / free-store 할당 자 및 Box 얻은 후에 컬렉션을 다시 생각할 수 있습니다. Alloc 재사용 할 수도 있고, VecAlloc, VecDequeAlloc , HashMapAlloc`이 필요할 수도 있습니다. , 표준 컬렉션을 상자에 복사하여 붙여넣고 할당 자에 몰드합니다. " 아마도 가장 좋은 해결책은 보육원의 자체 크레이트 (또는 크레이트)에 std 컬렉션을 갖고 안정된 기능 만 사용하여이를 쉽게 만드는 것입니다.

어쨌든, 여기에서이 모든 문제를 한꺼번에 해결하고 모든 것에 좋은 Alloc 특성을 찾는 것은 너무 어렵다고 생각합니다. 우리는 0 단계에 있습니다. 1 단계와 2 단계로 빠르게 이동하는 가장 좋은 방법은 우리가 도착할 때까지 그림에서 컬렉션을 제외하는 것입니다.

일단 우리가 거기에 도착하면 안정으로 마이그레이션하려는 사용자는 그렇게 할 수 있지만 불안정한 API로 인해 성능이 저하 될 수 있습니다.

사용자 지정 할당자를 선택하는 것은 일반적으로 성능 향상에 관한 것이므로이 초기 안정화가 누구에게 제공 될지 모르겠습니다.

사용자 지정 할당자를 선택하는 것은 일반적으로 성능 향상에 관한 것이므로이 초기 안정화가 누구에게 제공 될지 모르겠습니다.

각자 모두? 적어도 지금은. 불만을 제기하는 대부분 의 방법은 초기 안정화 제안 (예 alloc_excess )에 누락되어 있으며 아직 표준 라이브러리에서 사용되지 않는 AFAIK입니다. 아니면 최근에 변경 되었습니까?

Vec (및 RawVec 의 다른 사용자)가 realloc 에서 push

뿡 빵뀨

jemallocator 크레이트는 현재 alloc_excess, realloc, realloc_excess, usable_size, grow_in_place 및 shrink_in_place를 구현합니다.

이러한 메서드에서 AFAIK realloc , grow_in_place 및 shrink_in_place 는 사용되지만 grow_in_place 는 jemalloc에 ​​대한 shrink_in_place 대한 순진한 래퍼 일뿐입니다. 적어도 우리가 기본 불안정 IMPL 구현하는 경우 grow_in_place 측면에서 shrink_in_place 에서 Alloc 특성, 그 두 가지 방법으로 상처를 다운 : realloc 와 shrink_in_place

사용자 지정 할당자를 선택하는 것은 일반적으로 성능 향상에 관한 것입니다.

이것이 사실이지만, 이러한 메서드가없는 잘못된 할당 자보다 더 적합한 할당자를 사용하면 더 많은 성능을 얻을 수 있습니다.

IIUC 서보의 주요 사용 사례는 두 번째 jemalloc 대신 Firefox jemalloc을 사용하는 것이 었습니다. 맞습니까?

초기 안정화에서 realloc 및 shrink_in_place 을 Alloc 특성에 추가하더라도 성능 불만이 지연 될뿐입니다.

예를 들어 std 컬렉션에서 사용하게되는 Alloc 트레이 트에 불안정한 API를 추가하는 순간 안정적인 성능을 얻을 수 없습니다. 야간에 탈 수 있습니다. 즉, 할당 트레이 트에 realloc_excess 및 shrink_in_place_excess 를 추가하고 Vec / String / ... 사용하면 realloc 안정화됩니다 shrink_in_place 은 (는) 단 한 번도 도움이되지 않았을 것입니다.

IIUC 서보의 주요 사용 사례는 두 번째 jemalloc 대신 Firefox jemalloc을 사용하는 것이 었습니다. 맞습니까?

일부 코드를 공유하지만 Firefox와 Servo는 두 개의 개별 프로젝트 / 애플리케이션입니다.

Firefox는 mozjemalloc을 사용하는데, 이는 많은 기능이 추가 된 이전 버전의 jemalloc의 포크입니다. 일부 unsafe FFI 코드는 Rust std에서 사용하는 mozjemalloc의 정확성과 건전성에 의존 한다고 생각 합니다.

Servo는 현재 실행 파일에 대한 Rust의 기본값 인 jemalloc을 사용하지만이 기본값을 시스템의 할당 자로 변경할 계획이 있습니다. Servo에는 실제로 사용되는 jemalloc의 건전성에 의존하는 unsafe 메모리 사용량보고 코드도 있습니다. ( Vec::as_ptr() 에서 je_malloc_usable_size )

Servo는 현재 실행 파일에 대한 Rust의 기본값 인 jemalloc을 사용하지만이 기본값을 시스템의 할당 자로 변경할 계획이 있습니다.

서보 타겟이되는 시스템의 시스템 할당자가 jemalloc과 같은 최적화 된 realloc 및 shrink_to_fit API를 제공하는지 아는 것이 좋습니다. realloc (및 calloc )는 매우 일반적이지만 shrink_to_fit ( xallocx )는 jemalloc 해당하는 AFAIK입니다. 아마도 가장 좋은 해결책은 초기 구현에서 realloc 및 alloc_zeroed ( calloc )를 안정화하고 나중에 shrink_to_fit 그대로 두는 것입니다. 이렇게하면 서보가 성능 문제없이 대부분의 플랫폼에서 시스템 할당 자와 함께 작동 할 수 있습니다.

Servo에는 실제로 사용되는 jemalloc의 건전성에 의존하는 안전하지 않은 메모리 사용보고 코드도 있습니다. (Vec :: as_ptr ()을 je_malloc_usable_size에 전달합니다.)

아시다시피 jemallocator 상자에는이를위한 API가 있습니다. 글로벌 할당 자 스토리가 안정화되기 시작하면 유사한 API를 제공하는 다른 할당 자에게 jemallocator 상자와 유사한 상자가 나타날 것으로 예상합니다. 이 API가 Alloc 트레이 트에 속하는지 전혀 생각하지 않았습니다.

malloc_usable_size 이 Alloc 특성에 있어야한다고 생각하지 않습니다. #[global_allocator] 를 사용하여 Vec<T> 어떤 할당자를 사용하는지 확인하고 jemallocator 크레이트의 함수를 별도로 사용하는 것은 괜찮습니다.

@SimonSapin Alloc 특성이 안정되면 Linux malloc 및 Windows 용 jemallocator 와 같은 상자를 갖게 될 것입니다. 이 상자들은 불안정의 할 수있는 부분을 구현하는 추가 기능을 가질 수 Alloc API를 (같은, 예를 들어, usable_size 의 상단에 malloc_usable_size ) 및 다른 것들을 그 mallinfo 위에있는 메모리보고와 같이 Alloc API의 일부가 아닙니다. 서보가 목표로하는 시스템에 사용할 수있는 상자가 있으면 Alloc 특성의 어느 부분이 안정화 우선 순위를 지정하는지 파악하는 것이 더 쉬울 것이며, 일부에 대해 최소한 실험해야하는 최신 API를 찾을 수있을 것입니다. 할당 자.

@gnzlbg 나는 https://github.com/rust-lang/rust/issues/32838#issuecomment -358267292의 것들에 약간 회의적입니다. 모든 시스템 특정 항목을 제외하고 alloc에 ​​대한 컬렉션을 일반화하는 것은 어렵지 않습니다. 통합하는 것은 별도의 도전처럼 보입니다.

@SimonSapin firefox에 불안정한 Rust 정책이 없나요? 나는 혼란스러워하고 있다고 생각한다. 파이어 폭스와 서보는 이것을 원하지만 만약 그렇다면 파이어 폭스의 사용 사례는 안정화에 압력을 가할 것이다.

@sfackler ^을 참조하십시오. 이 안정을 필요로하는 프로젝트와 원하는 프로젝트를 구분하려고했지만 서보는 그 차이의 반대편에 있습니다.

이것을 원하고 안정적이어야하는 프로젝트가 있습니다. Rust의 소비자로서 Servo 또는 Firefox에 대해 특별히 마법 같은 것은 없습니다.

@ Ericson2314 맞습니다. Firefox는 안정적인 https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox를 사용합니다. 오늘 작동하는 솔루션이 있지만 설명했듯이 이것은 실제 차단기가 아닙니다. #[global_allocator] 를 사용하는 것이 더 좋거나 더 강력 할 것입니다.

서보는 일부 불안정한 기능을 사용하지만 언급했듯이이를 변경하려고합니다.

FWIW, 파라 메트릭 할당자는 할당자를 구현하는 데 매우 유용합니다. 내부적으로 다양한 데이터 구조를 사용하고 더 간단한 할당 자 (예 : bsalloc )로 매개 변수화 할 수 있다면 성능에 덜 민감한 부기 관리가 훨씬 쉬워집니다. 현재 표준 환경에서이를 수행하는 유일한 방법은 첫 번째 단계를 사용하여 더 간단한 할당자를 전역 할당 자로 설정하고 두 번째 단계를 사용하여 더 크고 복잡한 할당자를 컴파일하는 데 사용되는 2 단계 컴파일을하는 것입니다. . no-std에서는 전혀 할 방법이 없습니다.

헉헉

모든 시스템 특정 항목을 제외하고 alloc에 ​​대한 컬렉션을 일반화하는 것은 어렵지 않습니다. 통합하는 것은 별도의 도전처럼 보입니다.

내가 볼 수있는 Vec + 사용자 지정 할당 자 위에 ArrayVec 또는 SmallVec 있습니까? 그것이 제가 언급 한 첫 번째 요점이고, 그것은 전혀 시스템 특정이 아닙니다. 아마도 그것은 상상할 수있는 가장 단순한 두 개의 할당 자일 것입니다. 하나는 스토리지로서의 원시 어레이이고, 다른 하나는 어레이의 용량이 부족한 경우 힙에 폴백을 추가하여 첫 번째 할당 자 위에 구축 할 수 있습니다. 주된 차이점은 이러한 할당자는 "글로벌"이 아니지만 각 Vec 에는 다른 모든 할당 자와 독립적 인 자체 할당자가 있으며 이러한 할당자는 상태 저장입니다.

또한 나는 이것을 결코하지 않는다고 주장하는 것이 아니다. 저는 이것이 매우 어렵다고 말하고 있습니다 : C ++는 30 년 동안 부분적인 성공만으로 시도해 왔습니다 : GPU 할당 자와 GC 할당자는 일반 포인터 유형으로 인해 작동하지만 ArrayVec 및 SmallVec Vec 위에 P0843r1 은 ArrayVec 에 대한 몇 가지 문제를 자세히 설명합니다).

따라서 앞으로 사용자 지정 컬렉션 할당자를 추구하지 않는 한 유용한 것을 제공하는 조각을 안정화 한 후에 이것을 추구하는 것이 좋습니다.

IRC에서 @SimonSapin 과 약간 이야기를 나눴으며 realloc 및 alloc_zeroed 초기 안정화 제안을 확장하면 Firefox의 Rust (안정적인 Rust 만 사용)를 사용할 수 있습니다. mozjemalloc 추가 해킹없이 안정적인 Rust의 전역 할당 자로서. @SimonSapin 에서 언급했듯이 Firefox는 현재이를위한 실행 가능한 솔루션을 가지고 있으므로 이것이 좋겠지 만 그다지 중요하지 않은 것 같습니다.

그래도 여기서 시작할 수 있으며 일단 거기에 도착하면 성능 손실없이 servo 을 안정적인 #[global_allocator] 로 이동합니다.

헉

FWIW, 파라 메트릭 할당자는 할당자를 구현하는 데 매우 유용합니다.

무슨 뜻인지 좀 더 자세히 설명해 주시겠습니까? Alloc 특성으로 사용자 지정 할당자를 매개 변수화 할 수없는 이유가 있습니까? 또는 사용자 지정 할당 자 특성을 사용하고 최종 할당 자에 Alloc 특성을 구현합니다 (이 두 특성이 반드시 같을 필요는 없음)?

"SmallVec = Vec + 특수 할당 자"의 사용 사례가 어디에서 왔는지 이해할 수 없습니다. 이전에 많이 언급 한 내용이 아닙니다 (Rust도 아니고 다른 문맥에서도 언급되지 않았습니다). 정확히 많은 심각한 문제가 있기 때문입니다. "특수 할당자를 사용하여 성능 향상"을 생각할 때 나는 전혀 생각하지 않습니다.

Layout API를 살펴보면서 from_size_align 와 align_to 사이의 오류 처리 차이에 대해 궁금합니다. 전자는 오류가 발생하면 None 를 반환합니다. , 후자는 패닉 (!).

적절하게 정의되고 유익한 LayoutErr 열거 형을 추가하고 두 경우 모두에서 Result<Layout, LayoutErr> 를 반환하는 것이 더 유용하고 일관 적이 지 않을까요? (그리고 아마도 현재 Option 반환하는 다른 함수에 사용할 수도 있습니다

뿡뿡

"SmallVec = Vec + 특수 할당 자"의 사용 사례가 어디에서 왔는지 이해할 수 없습니다. 이전에 많이 언급 한 내용이 아닙니다 (Rust도 아니고 다른 문맥에서도 언급되지 않았습니다). 정확히 많은 심각한 문제가 있기 때문입니다. "특수 할당자를 사용하여 성능 향상"을 생각할 때 나는 전혀 생각하지 않습니다.

Rust와 C ++에서 할당자를 사용하는 두 가지 독립적 인 방법이 있습니다. 기본적으로 모든 할당에 사용되는 시스템 할당 자와 일부 할당 자 특성에 의해 매개 변수화 된 컬렉션의 유형 인수로 사용되는 특정 컬렉션의 객체를 생성하는 방법입니다. 특정 할당자를 사용합니다 (시스템의 할당 자일 수 있음).

다음은이 두 번째 사용 사례에만 초점을 맞 춥니 다. 컬렉션과 할당 자 유형을 사용하여 특정 할당자를 사용하는 해당 컬렉션의 개체를 만듭니다.

C ++ 경험상 할당자를 사용하여 컬렉션을 매개 변수화하는 것은 두 가지 사용 사례를 제공합니다.

• 컬렉션이 특정 할당 패턴을 대상으로하는 사용자 지정 할당자를 사용하도록하여 컬렉션 개체의 성능을 개선합니다.
• 컬렉션에 새로운 기능을 추가하여 이전에는 할 수 없었던 작업을 수행 할 수 있습니다.

컬렉션에 새로운 기능 추가

이것은 C ++ 코드 기반에서 99 %의 시간 동안 볼 수있는 할당 자의 사용 사례입니다. 컬렉션에 새로운 기능을 추가하면 성능이 향상된다는 사실은 우연의 일치라고 생각합니다. 특히 다음 할당자는 할당 패턴을 대상으로 성능을 향상시키지 않습니다. @ Ericson2314에서 언급

• 작은 버퍼 최적화를위한 스택 할당 자 (Howard Hinnant의 stack_alloc 문서 참조 ). std::vector 또는 flat_{map,set,multimap,...} 하고 작은 버퍼 최적화에 추가하는 사용자 지정 할당자를 전달하여 ( SmallVec ) 또는 사용하지 않고 ( ArrayVec ) 힙 폴백. 예를 들어 스택 또는 정적 메모리 (그렇지 않으면 힙을 사용했을 것임)에 해당 요소가있는 컬렉션을 넣을 수 있습니다.

• 세그먼트 메모리 아키텍처 (예 : 16 비트 와이드 포인터 x86 타겟 및 GPGPU) 예를 들어 C ++ 17 Parallel STL은 C ++ 14 동안 Parallel Technical Specification이었습니다. 동일한 저자의 그것의 전구체 라이브러리 컨테이너 clases는 GPGPU 메모리 (예를 사용할 수 있도록 할당자를 포함 NVIDIA의 추력 라이브러리이다 추력 :: device_malloc_allocator ) 또는 고정 메모리 (예를 들어, 추력 :: pinned_allocator을 , 고정 된 메모리의 호스트 장치 간의 빠른 전송을 허용 일부 경우).

• 잘못된 공유 (예 : Intel Thread Building Blocks cache_aligned_allocator ) 또는 SIMD 유형의 과도한 정렬 요구 사항 (예 : Eigen3의 aligned_allocator )과 같은 병렬 처리 관련 문제를 해결하기위한 할당 자.

• 프로세스 간 공유 메모리 : Boost.Interprocess 에는 OS 프로세스 간 공유 메모리 기능 (예 : System V 공유 메모리)을 사용하여 컬렉션의 메모리를 할당하는 할당자가 있습니다. 이를 통해 std 컨테이너를 직접 사용하여 서로 다른 프로세스 간의 통신에 사용되는 메모리를 관리 할 수 ​​있습니다.

• 가비지 수집 : Herb Sutter의 지연 메모리 할당 라이브러리 는 사용자 정의 포인터 유형을 사용하여 메모리를 가비지 수집하는 할당자를 구현합니다. 예를 들어 벡터가 커지면 해당 메모리에 대한 모든 포인터가 파괴 될 때까지 이전 메모리 청크가 유지되어 반복기 무효화를 방지합니다.

• 계측 된 할당 자 : Bloomberg의 소프트웨어 라이브러리의 blsma_testallocator를 사용하면 사용하는 객체의 메모리 할당 / 할당 해제 (및 C ++ 특정 객체 생성 / 파괴) 패턴을 기록 할 수 있습니다. Vec reserve 이후에 할당되는지 여부를 모릅니다. 이러한 할당자를 연결하면 발생 여부를 알려줍니다. 이러한 할당 자 중 일부는 이름을 지정할 수 있으므로 여러 개체에서 사용할 수 있고 어떤 개체가 무엇을하고 있는지 로그를 얻을 수 있습니다.

이것이 제가 C ++에서 가장 자주 보는 할당 자 유형입니다. 앞서 언급했듯이 어떤 경우에 성능이 향상된다는 사실은 우연의 일치라고 생각합니다. 중요한 부분은 그들 중 어느 것도 특정 할당 패턴을 목표로하지 않는다는 것입니다.

성능 향상을 위해 할당 패턴을 타겟팅합니다.

AFAIK이 작업을 수행하는 널리 사용되는 C ++ 할당자는 없습니다. 왜 이것이 바로 이것이라고 생각하는지 설명하겠습니다. 다음 라이브러리는이 사용 사례를 대상으로합니다.

• C ++ Boost.Pool ,
• C ++ foonathan / 메모리
• D의 std.experimental.allocator

그러나 이러한 라이브러리는 특정 사용 사례에 대해 단일 할당자를 제공하지 않습니다. 대신 애플리케이션의 특정 부분에서 특정 할당 패턴을 대상으로하는 사용자 지정 할당자를 구축하는 데 사용할 수있는 할당 자 구성 요소를 제공합니다.

제가 C ++ 시절에 기억하는 일반적인 조언은 다음과 같은 이유로 "사용하지 마십시오"(마지막 수단)라는 것입니다.

• 시스템 할당 자의 성능을 일치시키는 것은 매우 어렵습니다.
• 다른 사람의 응용 프로그램 메모리 할당 패턴이 자신과 일치 할 가능성은 희박하므로 할당 패턴과 일치하는 데 필요한 할당 자 구성 요소를 알아야합니다.
• 서로 다른 공급 업체가 서로 다른 할당 패턴을 사용하는 서로 다른 C ++ 표준 라이브러리 구현을 가지고 있기 때문에 이식성이 없습니다. 공급 업체는 일반적으로 시스템 할당 자에서 구현을 목표로합니다. 즉, 한 공급 업체에 맞는 솔루션은 다른 공급 업체에서 끔찍하게 (시스템 할당 자보다 더 나쁘게) 수행 될 수 있습니다.
• 이를 사용하기 전에 소진 할 수있는 많은 대안이 있습니다. 다른 컬렉션 사용, 메모리 예약 등 대부분의 대안은 노력이 적고 더 큰 성과를 거둘 수 있습니다.

그렇다고이 사용 사례에 대한 라이브러리가 유용하지 않다는 의미는 아닙니다. 그렇기 때문에 foonathan / memory 와 같은 라이브러리가 개화하고 있습니다. 그러나 적어도 내 경험상 그들은 "추가 기능을 추가"하는 할당 자보다 야생에서 덜 사용됩니다. 왜냐하면 승리를 제공하려면 대부분의 사용자가 투자하려는 것보다 더 많은 시간이 필요한 시스템 할당자를 이겨야하기 때문입니다 (Stackoverflow가 가득 찼습니다). "Boost.Pool을 사용했는데 성능이 나빠졌습니다. 어떻게해야합니까? Boost.Pool을 사용하지 않습니다.").

마무리

IMO 저는 C ++ 할당 자 모델이 완벽하지는 않지만 두 가지 사용 사례를 모두 지원한다는 것이 대단하다고 생각하며, Rust의 표준 컬렉션이 할당 자에 의해 매개 변수화되면 두 가지 사용 사례도 모두 지원해야한다고 생각합니다. 두 경우 모두에 대한 C ++ 할당자가 유용한 것으로 밝혀졌습니다.

이 문제는 특정 응용 프로그램의 전역 / 시스템 / 플랫폼 / 기본 / 힙 / 무료 저장소 할당자를 사용자 지정할 수있는 것과 약간 직교하며 두 문제를 동시에 해결하려고하면 솔루션이 지연 될 수 있다고 생각합니다. 그들 중 불필요하게.

할당 자에 의해 매개 변수화 된 컬렉션으로 일부 사용자가 원하는 작업은 다른 사용자가 원하는 작업과 크게 다를 수 있습니다. @rkruppe 가 "일치하는 할당 패턴"에서 시작하고 "허위 공유 방지"또는 "힙

@gnzlbg 포괄적 인 글 주셔서 감사합니다. 그것의 대부분은 나의 원래 질문을 다루지 않고 나는 그것의 일부에 동의하지 않지만, 철자를 써서 서로 지나치지 않도록하는 것이 좋습니다.

내 질문은 특히이 응용 프로그램에 관한 것입니다.

작은 버퍼 최적화를위한 스택 할당 자 (Howard Hinnant의 stack_alloc 문서 참조). std :: vector 또는 flat_ {map, set, multimap, ...}을 사용하고이를 사용자 지정 할당 자에 전달하여 (SmallVec) 힙 폴백을 사용하거나 사용하지 않고 (ArrayVec) 작은 버퍼 최적화에 추가합니다. 예를 들어 스택 또는 정적 메모리 (그렇지 않으면 힙을 사용했을 것임)에 해당 요소가있는 컬렉션을 넣을 수 있습니다.

stack_alloc에 ​​대해 읽으면서 어떻게 작동하는지 깨달았습니다. 사람들이 일반적으로 SmallVec (버퍼가 컬렉션에 인라인으로 저장되는 곳)에서 의미하는 것은 아니기 때문에 해당 옵션을 놓친 이유는 아니지만 컬렉션이 이동할 때 포인터를 업데이트해야하는 문제를 해결하고 이러한 이동을 더 저렴하게 만듭니다. ). 또한 short_alloc을 사용하면 여러 컬렉션이 하나의 arena 를 공유 할 수 있으므로 일반적인 SmallVec 유형과는 훨씬 더 다릅니다. 이는 할당 된 공간이 부족할 때 힙 할당으로의 우아한 폴백을 제공하는 선형 / 범프 포인터 할당 자와 비슷합니다.

나는 이런 종류의 할당 자와 cache_aligned_allocator 가 근본적으로 새로운 기능을 추가하고 있다는 것에 동의하지 않습니다. 이들은 다르게 사용되며 "할당 패턴"의 정의에 따라 특정 할당 패턴에 최적화되지 않을 수 있습니다. 그러나 특정 사용 사례에 맞게 최적화되고 범용 힙 할당 자와 큰 동작 차이가 없습니다.

그러나 나는 "포인터"가 의미하는 바를 실질적으로 바꾸는 Sutter의 지연된 메모리 할당과 같은 사용 사례가 우리가 그것을 지원하고 싶다면 별도의 디자인이 필요할 수있는 별도의 애플리케이션이라는 데 동의합니다.

stack_alloc에 ​​대해 읽으면서 어떻게 작동하는지 깨달았습니다. 사람들이 일반적으로 SmallVec (버퍼가 컬렉션에 인라인으로 저장되는 곳)에서 의미하는 것은 아니기 때문에 해당 옵션을 놓친 이유는 아니지만 컬렉션이 이동할 때 포인터를 업데이트해야하는 문제를 해결하고 이러한 이동을 더 저렴하게 만듭니다. ).

stack_alloc 는 "a paper"가있는 유일한 할당 자이기 때문에 언급했지만 2009 년에 출시되었으며 C ++ 11보다 우선합니다 (C ++ 03은 컬렉션에서 상태 저장 할당자를 지원하지 않음).

이것이 C ++ 11 (상태 저장 할당자를 지원함)에서 작동하는 방식은 간단히 말해서 다음과 같습니다.

• 표준 : : 벡터 저장한다 Allocator 객체 그 안에 단지 녹 같은 RawVec 않습니다 .
• Allocator 인터페이스 에는 사용자 정의 할당자가 사용자 정의 할 수있는 Allocator :: propagate_on_container_move_assignment (지금부터 POCMA)라는 모호한 속성이 있습니다. 이 속성은 기본적으로 true 입니다. 이 속성이 false 경우 이동 할당시 할당자를 전파 할 수 없으므로 표준에 따라 컬렉션이 각 요소를 새 저장소로 수동으로 이동해야합니다.

따라서 시스템 할당자가있는 벡터가 이동되면 먼저 스택의 새 벡터에 대한 저장소가 할당 된 다음 할당자가 이동 (0 크기) 된 다음 3 개의 포인터가 이동되며 여전히 유효한 상태입니다. 이러한 움직임은 O(1) 입니다.

OTOHO, POCMA == true 할당자가있는 벡터가 이동되면 먼저 스택의 새 벡터에 대한 저장소가 할당되고 빈 벡터로 초기화 된 다음 이전 컬렉션은 drain ed 새로운 것, 그래서 이전 것은 비어 있고 새로운 것은 가득 찼습니다. 이렇게하면 이동 할당 연산자를 사용하여 컬렉션의 각 요소를 개별적으로 이동합니다. 이 단계는 O(N) 이며 요소의 내부 포인터를 수정합니다. 마지막으로, 이제 비어있는 원래 컬렉션이 삭제됩니다. 이것은 복제물처럼 보이지만 요소 자체가 복제되지 않고 C ++로 이동했기 때문이 아닙니다.

말이 돼?

C ++에서이 접근 방식의 주요 문제점은 다음과 같습니다.

• 벡터 성장 정책은 구현 정의입니다.
• 할당 자 API에 _excess 메서드가 없습니다.
• 위의 두 가지 문제의 조합은 벡터가 최대 9 개 요소를 보유 할 수 있다는 것을 알고 있다면, 벡터가 성장 인자가있는 8 개가있을 때 성장을 시도 할 수 있기 때문에 9 개 요소를 보유 할 수있는 스택 할당자를 가질 수 없음을 의미합니다. 따라서 18 개 요소에 대한 공간을 비관적으로 할당하고 할당해야합니다.
• 벡터 연산의 복잡성은 할당 자 속성에 따라 변경됩니다 (POCMA는 C ++ Allocator API에있는 많은 속성 중 하나 일뿐입니다. C ++ 할당자를 작성하는 것은 중요하지 않습니다). 이것은 벡터의 API를 지정하는 것을 어렵게 만듭니다. 왜냐하면 같은 유형의 서로 다른 할당 자간에 요소를 복사하거나 이동하면 추가 비용이 발생하여 작업의 복잡성이 변경되기 때문입니다. 또한 사양을 읽는 데 큰 어려움이 있습니다. cppreference와 같은 많은 온라인 문서 소스는 일반적인 경우를 앞에두고 사용자의 99 %를 괴롭히는 것을 방지하기 위해 할당 자 속성 하나가 참 또는 거짓 인 경우 변경되는 사항에 대한 모호한 세부 정보를 제공합니다.

예를 들어 _excess 메서드를 추가하고 표준 준수 컬렉션이이를 사용하도록 보장하는 등 C ++의 할당 자 API를 개선하여 이러한 문제를 해결하기 위해 노력하는 사람들이 많습니다.

나는 이러한 종류의 할당 자와 cache_aligned_allocator가 근본적으로 새로운 기능을 추가하고 있다는 데 동의하지 않습니다.

내가 의미하는 바는 상황에서 또는 이전에 사용할 수 없었던 유형에 대해 표준 컬렉션을 사용할 수 있다는 것입니다. 예를 들어 C ++에서는 스택 할당 자와 같은 것이 없으면 바이너리의 정적 메모리 세그먼트에 벡터 요소를 넣을 수 없습니다 (아직이를 수행하는 자체 컬렉션을 작성할 수 있음). OTOH, C ++ 표준은 SIMD 유형과 같이 과도하게 정렬 된 유형을 지원하지 않으며 new 로 힙 할당을 시도하면 정의되지 않은 동작을 호출합니다 ( posix_memalign 또는 이와 유사한 것을 사용해야 함). . 객체를 사용하면 일반적으로 segfault (*)를 통해 정의되지 않은 동작이 나타납니다. aligned_allocator 와 같은 것은 다른 할당자를 사용하여 정의되지 않은 동작을 호출하지 않고 이러한 유형을 힙 할당하고 std 컬렉션에 넣을 수도 있습니다. 물론 새로운 할당자는 다른 할당 패턴을 가지 겠지만 (이 할당자는 기본적으로 모든 메모리 btw ...), 사람들이이를 사용하는 목적은 이전에 할 수 없었던 일을 할 수 있다는 것입니다.

분명히 Rust는 C ++가 아닙니다. 그리고 C ++에는 Rust에없는 문제가 있습니다 (그 반대도 마찬가지입니다). 예를 들어 SIMD 유형에 문제가없는 Rust에서는 C ++에 새로운 기능을 추가하는 할당자가 필요하지 않을 수 있습니다.

(*) Eigen3 사용자는 C ++ 및 STL 컨테이너를 사용할 때 정의되지 않은 동작을 방지하기 위해 SIMD 유형 또는 SIMD 유형을 포함하는 유형 ( Eigen3 docs )으로부터 컨테이너를 보호해야하며 또한 자신을 보호해야합니다. new 연산자 new 를 오버로딩하여 유형에 대해 new new 을 사용했습니다 ( 더 많은 Eigen3 문서 ).

@gnzlbg 감사합니다. smallvec exmaple도 혼란 스러웠습니다. 그것은 움직일 수없는 유형과 Rust에서 일종의 alloca를 필요로 할 것입니다 .-- 두 개의 RFC를 검토하고 더 많은 후속 작업을 --- 그래서 지금은 그것에 대해 고민하지 않습니다. 필요한 모든 스택 공간을 항상 사용하는 기존 smallvec 전략은 현재로서는 괜찮아 보입니다.

또한 수정 된 목록에서 할당 자의 새로운 기능을 할당자를 사용하는 컬렉션에 알 필요가 없다는 @rkruppe에 동의합니다. 때로는 전체 Collection<Allocator> 에 새로운 속성이 있지만 (고정 된 메모리에 완전히 존재한다고 가정 해 보겠습니다) 할당자를 사용하는 것은 자연스러운 결과입니다.

여기에서 한 가지 예외는 단일 크기 / 유형 만 할당하는 할당 자입니다 (슬랩 할당 자처럼 NVidia도이 작업을 수행합니다). 일반 할당 자에 대해 포괄적으로 구현 된 별도의 ObjAlloc<T> 특성 : impl<A: Alloc, T> ObjAlloc<T> for A . 그런 다음 컬렉션은 몇 가지 항목 만 할당해야하는 경우 ObjAlloc 경계를 사용합니다. 그러나 나는 나중에 호환성있게 역방향으로 할 수 있어야하기 때문에 이것을 제기하는 것조차 다소 어리 석다.

말이 돼?

물론이지만 이동 생성자가 없기 때문에 Rust와는 관련이 없습니다. 따라서 포인터를 전달하는 메모리를 직접 포함하는 (이동 가능한) 할당자는 불가능합니다.

예를 들어 C ++에서는 스택 할당 자와 같은 것이 없으면 바이너리의 정적 메모리 세그먼트에 벡터 요소를 넣을 수 없습니다 (아직이를 수행하는 자체 컬렉션을 작성할 수 있음).

이것은 행동 변화가 아닙니다. 컬렉션이 메모리를 가져 오는 위치를 제어하는 ​​데는 여러 가지 타당한 이유가 있지만, 모두 성능, 링커 스크립트, 전체 프로그램의 메모리 레이아웃 제어 등과 같은 "외부 요소"와 관련이 있습니다.

alignment_allocator와 같은 것은 다른 할당자를 사용하여 정의되지 않은 동작을 호출하지 않고 이러한 유형을 힙 할당하고 std 컬렉션에 넣을 수도 있습니다.

이것이 내가 Eigen의 alignment_allocator가 아니라 TBB의 cache_aligned_allocator를 구체적으로 언급 한 이유입니다. cache_aligned_allocator는 문서에서 특정 정렬을 보장하지 않는 것 같습니다 (단지 "일반적으로"128 바이트라고 말함). 그렇게하더라도 일반적으로이 목적으로 사용되지 않습니다 (정렬이 일반에 비해 너무 클 수 있기 때문). 페이지 정렬 DMA와 같은 경우에는 SIMD 유형이 너무 작습니다. 당신이 말했듯이 그것의 목적은 거짓 공유를 피하는 것입니다.

뿡뿡

FWIW, 파라 메트릭 할당자는 할당자를 구현하는 데 매우 유용합니다.

무슨 뜻인지 좀 더 자세히 설명해 주시겠습니까? Alloc 특성으로 사용자 지정 할당자를 매개 변수화 할 수없는 이유가 있습니까? 또는 사용자 지정 할당 자 특성을 사용하고 최종 할당 자에 Alloc 특성을 구현합니다 (이 두 특성이 반드시 같을 필요는 없음)?

명확하지 않은 것 같습니다. 더 잘 설명해 드리겠습니다. 다음 중 하나를 사용할 것으로 예상되는 할당자를 구현한다고 가정 해 보겠습니다.

• 글로벌 할당 자로서
• 비표준 환경에서

그리고이 할당자를 구현하기 위해 후드 아래에서 Vec 를 사용하고 싶다고 가정 해 보겠습니다. 저는 Vec 오늘처럼 직접 사용할 수 없습니다.

• 내가 글로벌 할당 자라면 그것을 사용하면 나 자신에 대한 재귀 종속성이 생길 것입니다.
• 표준이 아닌 환경에있는 경우 현재 존재하는 Vec 가 없습니다.

따라서 내가 필요한 것은 간단한 내부 부기 관리를 위해 내부적으로 사용하는 다른 할당 자에서 매개 변수화 된 Vec 를 사용할 수있는 것입니다. 이것이 bsalloc 의 목표입니다 (이름의 출처-다른 할당자를 부트 스트랩하는 데 사용됨).

elfmalloc에서 우리는 여전히 다음을 통해 글로벌 할당자가 될 수 있습니다.

• 스스로 컴파일 할 때, 전역 할당 자로 jemalloc을 정적으로 컴파일하십시오.
• 다른 프로그램에서 동적으로로드 할 수있는 공유 개체 파일 생성

이 경우 시스템 할당자를 글로벌 할당 자로 사용하여 컴파일하지 않는 것이 중요합니다.로드되면 재귀 종속성을 다시 도입 할 것입니다. 그 시점에서 우리 는 시스템 할당 자이기 때문입니다.

그러나 다음과 같은 경우에는 작동하지 않습니다.

• 누군가는 "공식적인"방식으로 Rust에서 전역 할당 자로 우리를 사용하기를 원합니다 (먼저 공유 객체 파일을 생성하는 것과 반대)
• 우리는 표준이 아닌 환경에 있습니다.

OTOH, C ++ 표준은 SIMD 유형과 같이 과도하게 정렬 된 유형을 지원하지 않으며 new로 힙 할당을 시도하면 정의되지 않은 동작을 호출합니다 ( posix_memalign 또는 이와 유사한 것을 사용해야 함).

현재 Alloc 특성은 정렬을 매개 변수로 사용하므로이 문제 클래스 ( "다른 정렬 없이는 작업 할 수 없음"문제)가 사라진다고 가정합니다.

@gnzlbg- 포괄적 인 글 (감사합니다)이지만 어떤 사용 사례도 영구 메모리를 다루지 않습니다 *.

이 사용 사례 를 고려해야합니다. 특히, 옳은 일이 무엇인지에 강한 영향을 미칩니다.

• 둘 이상의 할당자가 사용 중이며, 특히 해당 할당자가 영구 메모리 용으로 사용될 때 시스템 할당자가 될 수 여러 개 있을 수 있음)
• 표준 컬렉션을 '재 구현'하는 데 드는 비용이 높고 타사 라이브러리와 호환되지 않는 코드가 발생합니다.
• 할당 자의 수명이 반드시 'static 필요는 없습니다.
• 영구 메모리에 저장된 객체는 힙에서 채워 져야하는 추가 상태가 필요합니다. 즉, 상태를 다시 초기화해야합니다. 이것은 특히 뮤텍스 등의 경우에 그렇습니다. 한때 일회용이었던 것은 더 이상 폐기되지 않습니다.

Rust는 여기에서 이니셔티브를 장악하고 HD, SSD 및 심지어 PCI 연결 스토리지를 대체 할 일류 플랫폼으로 만들 수있는 훌륭한 기회를 가지고 있습니다.

* 최근까지 조금 특별했기 때문에 놀랍지 않습니다. 이제 Linux, FreeBSD 및 Windows에서 널리 지원됩니다.

뿡 빵뀨

이것은 실제로 영구 기억을 해결하는 곳이 아닙니다. 예를 들어, 일반적인 접근 방식은 단순히 데이터 무결성을 이유로 더 빠른 디스크처럼 취급하는 것입니다.

이런 식으로 영구 메모리를 사용하는 사용 사례가 있다면 먼저 다른 곳에서 해당 사례를 만드는 것이 좋습니다. 프로토 타입을 만들고 할당 자 인터페이스에 대한보다 구체적인 변경 사항을 제시하고 이상적으로는 이러한 변경 사항이 평균 사례에 미치는 영향의 가치가있는 경우를 만듭니다.

뿡뿡

동의하지 않습니다. 이것이 바로 그것이 속한 장소입니다. 초점을 너무 좁히고 증거를 찾아서 디자인을 만드는 결정을 내리는 것을 피하고 싶습니다.

낮은 수준의 사용자 공간 지원을 위해 많은 노력이 집중되는 현재의 Intel PMDK는 할당 된 일반 메모리 (포인터가있는 일반 메모리)로 훨씬 더 접근합니다. 이는 mmap 를 통한 것과 유사한 메모리입니다. 실제로 Linux에서 영구 메모리로 작업하고 싶다면 현재로서는 이것이 거의 유일한 호출 포트라고 생각합니다. 본질적으로, 그것을 사용하기위한 가장 진보 된 툴킷 중 하나-당신이 원할 경우 널리 사용되는 툴킷-그것을 할당 된 메모리로 취급합니다.

프로토 타이핑에 관해서는-글쎄, 내가 한 말이 바로 그것입니다 .

최근에 영구 메모리 할당 자 (특히 libpmemcto)를위한 Rust 래퍼 작업을 해왔습니다.

( https://crates.io/crates/nvml 에서 내 상자의 초기 버전을 사용할 수 있습니다. cto_pool 모듈의 소스 제어에 대한 더 많은 실험이 있습니다).

내 프로토 타입은 실제 대규모 시스템에서 데이터 스토리지 엔진을 교체하는 데 필요한 것을 염두에두고 제작되었습니다. 비슷한 사고 방식이 많은 오픈 소스 프로젝트 뒤에 있습니다. 나는 수년에 걸쳐 최고의 표준과 마찬가지로 실제 사용에서 파생 된 최고의 라이브러리를 발견했습니다.

실제 할당자를 현재 인터페이스에 맞추는 것과 같은 것은 없습니다. 솔직히 Alloc 인터페이스를 사용한 다음 Vec 전체를 복사 한 다음 조정하는 것은 고통 스러웠습니다. 많은 곳에서 할당자가 전달되지 않았다고 가정합니다 (예 : Vec::new() .

이를 수행하면서 할당 자에 필요한 사항과 그러한 할당 자의 사용자에게 필요한 사항에 대한 원래 의견에서 몇 가지 관찰을했습니다. 나는 그것들이 할당 자 인터페이스에 대한 토론 스레드에서 매우 유효하다고 생각합니다.

좋은 소식은 https://github.com/rust-lang/rust/issues/32838#issuecomment -358940992의 처음 3 개의 글 머리 기호가 다른 사용 사례에서 공유된다는 것입니다.

비 휘발성 메모리를 목록에 추가하지 않았다고 추가하고 싶었습니다.
목록에는 컨테이너를 매개 변수화하는 할당 자의 사용 사례가 나열되어 있기 때문입니다.
적어도 내 경험상 "광범위하게"사용되는 C ++ 세계 (
내가 언급 한 alloctor는 대부분 많은 사람들이 사용하는 매우 인기있는 라이브러리에서 가져온 것입니다).
인텔 SDK (일부 라이브러리)의 노력을 알고 있지만
타겟 C ++) 나는 그들을 사용하는 프로젝트를 개인적으로 알지 못합니다.
std :: vector와 함께 사용할 수있는 할당 자? 나는 모른다). 이건 아니야
사용되지 않거나 중요하지 않음을 의미합니다. 나는 알고 싶어요
하지만 내 게시물의 요점은 매개 변수화
컨테이너에 의한 할당자는 매우 복잡합니다.
컨테이너 문을 닫지 않고 시스템 할당 자와 진행
(하지만 나중에 다뤄야합니다).

2018 년 1 월 21 일 17:36에 John Ericson [email protected] 은 다음과 같이 썼습니다.

좋은 소식은 # 32838 (댓글)의 처음 3 개의 글 머리 기호입니다.
https://github.com/rust-lang/rust/issues/32838#issuecomment-358940992
다른 사용 사례에서 공유됩니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32838#issuecomment-359261305 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AA3Npk95PZBZcm7tknNp_Cqrs_3T1UkEks5tM2ekgaJpZM4IDYUN
.

이미 쓰여진 내용의 대부분을 읽으려고했기 때문에 이것은 이미 여기에있을 수 있으며이 경우 놓친 경우 미안하지만 여기에 있습니다.

게임 (C / C ++에서)에서 상당히 일반적인 것은 "프레임 당 스크래치 할당"을 사용하는 것입니다. 이것은 특정 기간 동안 살아있는 할당에 사용되는 선형 / 범프 할당자가 있다는 것을 의미합니다 ( 게임 프레임) 다음 "파괴"됩니다.

이 경우 파괴되면 할당자를 시작 위치로 다시 재설정합니다. 이러한 개체는 POD 유형이어야하므로 개체의 "파괴"가 전혀 없습니다 (따라서 소멸자가 실행되지 않음).

이 같은 것이 Rust의 현재 할당 자 디자인에 맞는지 궁금합니다.

(편집 : 개체의 파괴가 없어야합니다)

@emoon

게임 (C / C ++에서)에서 상당히 일반적인 것은 "프레임 당 스크래치 할당"을 사용하는 것입니다. 이것은 특정 기간 동안 살아있는 할당에 사용되는 선형 / 범프 할당자가 있다는 것을 의미합니다 ( 게임 프레임) 다음 "파괴"됩니다.

이 경우 파괴되면 할당자를 시작 위치로 다시 재설정합니다. 이러한 개체는 POD 유형이어야하므로 개체의 "파괴"가 전혀 발생하지 않습니다 (따라서 소멸자가 실행되지 않음).

할 수 있어야합니다. 내 머리 꼭대기에서 경기장 자체에 대한 하나의 개체와 경기장의 프레임 당 핸들 인 다른 개체가 필요합니다. 그런 다음 해당 핸들에 대해 Alloc 를 구현하고 할당을 위해 높은 수준의 안전한 래퍼를 사용한다고 가정합니다 (예 : Box 가 Alloc 에서 매개 변수가된다고 가정). 수명은 프레임 당 핸들이 삭제되기 전에 할당 된 모든 개체가 삭제되었는지 확인합니다. dealloc 는 여전히 각 개체에 대해 호출되지만 dealloc 가 작동하지 않는 경우 전체 삭제 및 할당 해제 논리가 완전히 또는 대부분 최적화 될 수 있습니다.

Drop 구현하지 않는 사용자 지정 스마트 포인터 유형을 사용할 수도 있습니다. 이렇게하면 다른 곳에서 많은 작업이 더 쉬워집니다.

감사! 원래 게시물에 오타를 만들었습니다. 물체의 파괴가 없다고 말하는 것입니다.

할당 자에 대한 전문가가 아니고이 스레드를 따를 수없는 사람들을 위해 현재 합의는 무엇입니까 : stdlib 컬렉션 유형에 대한 사용자 지정 할당자를 지원할 계획입니까?

@alexreg 최종 계획이 무엇인지 잘 모르겠지만 그렇게하는 데 기술적 인 어려움이없는 것으로 확인되었습니다. 다음에 그 노출에 OTOH 우리는 좋은 방법이없는 std 기본 유형 변수가 의심하지만 난 그냥에게 만들기에 아무 문제가 없기 때문에 alloc 지금 정도를 전용 일을 우리 lib 측에서 방해받지 않고 진행할 수 있습니다.

@ Ericson2314 좋아요, 듣기 좋습니다. 기본 유형 변수가 아직 구현되어 있습니까? 아니면 RFC 단계에서? 당신이 말했듯이, 그들이 alloc / std::heap 과 관련된 것들로 제한된다면 모두 괜찮을 것입니다.

@alexreg https://github.com/rust-lang/rfcs/pull/2321 참조

AllocErr이 오류 여야한다고 생각합니다. 다른 모듈 (예 : io)과 더 일치합니다.

impl Error for AllocError 은 (는) 의미가 있고 아프지 않지만 개인적으로 Error 특성이 쓸모 없다는 것을 발견했습니다.

오늘 Layout :: from_size_align 함수를보고 있었는데 " align 는 2 ^ 31 (즉 1 << 31 )을 초과해서는 안됩니다."제한이 이해가되지 않았습니다. 그리고 git blame은 # 30170을 가리 켰습니다.

나는 그것이 u32에 맞는 align 에 대해 이야기하는 상당히기만적인 커밋 메시지라고 말해야한다. 이것은 단지 우연한 일이다. 실제로 "고정 된"(더 많은 작업)이 시스템 할당자가 오작동하는 경우이다.

"OSX / alloc_system is buggy on huge alignments"항목을 확인해서는 안됩니다 . 직접적인 문제가 해결되었지만 장기적으로는 수정이 옳다고 생각하지 않습니다. 시스템 할당자가 잘못 작동한다고해서 작동하는 할당자를 구현 하는 것을 막아서는 안됩니다. 그리고 Layout :: from_size_align에 대한 임의의 제한이이를 수행합니다.

@glandium 4GB 이상의 배수로 정렬을 요청하는 것이 유용합니까?

4GiB 할당을 4GiB에 맞추고 싶은 경우를 상상할 수 있습니다. 이것은 현재 불가능하지만 거의 더 이상 가능하지 않습니다. 하지만 지금은 그런 이유를 생각하지 않는다고해서 자의적인 제한이 추가되어야한다고 생각하지 않습니다.

4GiB 할당을 4GiB에 맞추고 싶은 경우를 상상할 수 있습니다.

그 경우는 무엇입니까?

4GiB 할당을 4GiB에 맞추고 싶은 경우를 상상할 수 있습니다.

그 경우는 무엇입니까?

구체적으로는, I는 임의로 큰 정렬을위한 지원을 추가 mmap-alloc 에 사용하기위한 큰 메모리 정렬 석판 할당을 지원하기 위해 elfmalloc . 아이디어는 메모리 슬랩을 크기에 맞게 정렬하여 해당 슬래브에서 할당 된 객체에 대한 포인터가 주어지면 포함하는 슬래브를 찾기 위해 하위 비트를 마스킹하기 만하면됩니다. 우리는 현재 크기가 4GB 인 슬래브를 사용하지 않습니다 (큰 객체의 경우 mmap으로 직접 이동), 그렇게 할 수없는 이유가 없으며, 그렇게하려는 큰 RAM 요구 사항이있는 애플리케이션을 완전히 상상할 수있었습니다. 즉, mmap의 오버 헤드를 허용하지 않을만큼 자주 다중 GB 객체를 할당 한 경우입니다.

> 4GiB 정렬에 대한 가능한 사용 사례는 다음과 같습니다. 큰 페이지 경계에 정렬. 4GiB 이상의 페이지를 지원하는 플랫폼이 이미 있습니다. 이 IBM 문서에서는 "POWER5 + 프로세서는 4KB, 64KB, 16MB 및 16GB의 4 가지 가상 메모리 페이지 크기를 지원합니다."라고 말합니다. x86-64도 멀지 않습니다. "거대한 페이지"는 일반적으로 2MiB이지만 1GiB도 지원합니다 .

Alloc 트레이 트의 모든 유형이 지정되지 않은 함수는 *mut u8 합니다. 즉, 널 포인터를 가져 오거나 반환 할 수 있으며 모든 지옥이 풀릴 것입니다. 대신 NonNull 를 사용해야합니까?

그들이 모든 지옥에서 돌아올 수있는 많은 포인터가 있습니다.
탈출하다.
2018 년 3 월 4 일 일요일 오전 3:56 Mike Hommey [email protected] 은 다음과 같이 썼습니다.

Alloc 트레이 트의 모든 유형이 지정되지 않은 함수는 * mut u8을 처리합니다.
즉, 널 포인터를 가져 오거나 반환 할 수 있으며 모든 지옥은
탈출하다. 대신 NonNull을 사용해야합니까?

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32838#issuecomment-370223269 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABY2UR2dRxDtdACeRUh_djM-DExRuLxiks5ta9aFgaJpZM4IDYUN
.

NonNull 를 사용하는 더 설득력있는 이유는 Alloc 메서드에서 현재 반환 된 Result s (또는 Options 전환하면 미래) 더 작게.

NonNull을 사용하는 더 설득력있는 이유는 Alloc 메서드에서 현재 반환 된 결과 (또는 나중에 옵션으로 전환 할 경우 옵션)가 더 작아 질 수 있기 때문입니다.

AllocErr 에는 두 가지 변형이 있기 때문에 그렇게 될 것이라고 생각하지 않습니다.

모든 지옥이 풀릴 수있는 많은 포인터가 있습니다.

그러나 널 포인터는 다른 포인터보다 분명히 더 잘못되었습니다.

녹 유형 시스템이 풋건에 도움이되며 불변을 인코딩하는 데 사용된다고 생각합니다. alloc 대한 문서에는 "이 메서드가 Ok(addr) 반환하면 반환 된 addr는 null이 아닌 주소가됩니다."라고 명시되어 있지만 반환 유형은 그렇지 않습니다. 사실, Ok(malloc(layout.size())) 은 분명히 그렇지 않은 경우 유효한 구현입니다.

Layout 크기에 대한 메모도 0이 아니어야하므로 NonZero로 인코딩해야합니다..

모든 기능이 본질적으로 안전하지 않아서 우리가 풋건 예방을하지 말아야하는 것은 아닙니다.

할당자를 사용 (편집 : 및 구현) 할 때 발생할 수있는 모든 오류 중에서 널 포인터를 전달하는 것은 추적하기 가장 쉬운 방법 중 하나입니다 (최소한 MMU가 있고 수행하지 않은 경우 항상 역 참조시 깨끗한 segfault를 얻습니다). 그것으로 매우 이상한 것들), 그리고 일반적으로 고쳐야 할 가장 사소한 것들 중 하나입니다. 안전하지 않은 인터페이스가 풋건을 막으려 고 할 수 있다는 것은 사실이지만,이 풋건은 다른 가능한 오류와 비교할 때, 유형 시스템에서이 불변을 인코딩하는 자세한 정도에 비해 불균형 적으로 작아 보입니다.

게다가 할당 자 구현은 "성능을 위해" NonNull 의 확인되지 않은 생성자를 사용하는 것 같습니다. 올바른 할당 자에서는 어쨌든 null을 반환하지 않으므로 NonNell::new(...).unwrap() 를 건너 뛰고 싶을 것입니다. 이 경우 실제로 어떤 유형의 풋건 예방도 얻지 못합니다. (실제라면 Result 사이즈 혜택은 여전히 ​​그럴만 한 이유가 될 수 있습니다.)

할당 자 구현은 NonNull의 확인되지 않은 생성자를 사용합니다.

요점은 할당 자 구현을 돕는 것이 사용자를 돕는 것보다 적습니다. MyVec 에 NonNull<T> 있고 Heap.alloc() 이미 NonNull 반환하는 경우 확인 또는 안전하지 않은 확인되지 않은 호출 중 하나를 만들어야합니다.

포인터는 반환 유형일뿐만 아니라 dealloc 및 realloc 입력 유형이기도합니다. 이러한 함수는 입력이 null인지 아닌지에 대해 강화되어야합니까? 문서는 아니오라고 말하는 경향이 있지만 유형 시스템은 예라고 말하는 경향이 있습니다.

layout.size ()와 매우 유사합니다. 할당 함수는 요청 된 크기를 어떻게 든 0으로 처리해야합니까?

(실제 인 경우 결과 크기 이점은 여전히 ​​그 이유가 될 수 있습니다.)

크기 이점이 있는지 의심 스럽지만 # 48741과 같은 코드 생성 이점이 있습니다.

API 사용자에게 더 유연하다는 원칙을 계속한다면, 포인터는 반환 유형에서 NonNull 이어야하지만 인수에는 포함되지 않아야합니다. (이것은 이러한 인수가 런타임에 null 검사를 받아야 함을 의미하지 않습니다.)

나는 Postel의 법칙 접근법이 여기서 취하기에 잘못된 것이라고 생각합니다. 있어요
Alloc 메소드에 널 포인터를 전달하는 것이 유효한 경우? 그렇지 않다면
그 유연성은 기본적으로 풋건에 약간 더
민감한 트리거.

2018 년 3 월 5 일 오전 8시, "Simon Sapin" [email protected]이 작성했습니다.

API 사용자에게 더 유연하다는 원칙을 계속한다면
포인터는 반환 유형에서 NonNull이어야하지만 인수에서는 안됩니다. (이
이러한 인수가 런타임에 null 검사되어야 함을 의미하지는 않습니다.)

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32838#issuecomment-370327018 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AA_2L8zrOLyUv5mUc_kiiXOAn1f60k9Uks5tbOJ0gaJpZM4IDYUN
.

요점은 할당 자 구현을 돕는 것이 사용자를 돕는 것보다 적습니다. MyVec에 NonNull이 포함 된 경우그리고 Heap.alloc ()은 이미 NonNull을 반환합니다.이 호출은 확인해야하거나 안전하지 않은 호출이 하나 적습니다.

아 말이 되네요. 풋건을 고치는 것이 아니라 책임을 중앙 집중화합니다.

포인터는 반환 유형일뿐만 아니라 dealloc 및 realloc에 ​​대한 입력 유형이기도합니다. 이러한 함수는 입력이 null인지 아닌지에 대해 강화되어야합니까? 문서는 아니오라고 말하는 경향이 있지만 유형 시스템은 예라고 말하는 경향이 있습니다.

Alloc 메소드에 널 포인터를 전달하는 것이 유효한 경우가 있습니까? 그렇지 않다면 그 유연성은 기본적으로 풋건에 약간 더 민감한 트리거를 제공합니다.

사용자 는 반드시 문서를 읽고 불변성을 염두에 두어야합니다. 많은 불변성은 유형 시스템을 통해 전혀 적용 할 수 없습니다. 가능하다면 함수는 처음부터 안전하지 않을 것입니다. 따라서 이것은 주어진 인터페이스에 NonNull을 넣는 것이 실제로 사용자에게 도움이되는지에 대한 질문입니다.

• 문서를 읽고 불변에 대해 생각하도록 상기
• 편의 제공 ( @SimonSapin 의 포인트 wrt 할당의 반환 값)
• 일부 재료 이점 제공 (예 : 레이아웃 최적화)

나는 예를 들어,의 인수 만드는 어떤 강점이 표시되지 않는 dealloc 로 NonNull . 이 API의 사용 클래스는 대략 두 가지입니다.

1. alloc 를 호출하고 반환 된 포인터를 어딘가에 저장하고 잠시 후 저장된 포인터를 dealloc 전달하는 비교적 사소한 사용입니다.
2. FFI, 많은 포인터 산술 등을 포함하는 복잡한 시나리오. 마지막에 dealloc 에 올바른 것을 전달하는 데 중요한 논리가 포함됩니다.

여기서 NonNull 를 사용하면 기본적으로 첫 번째 유형의 사용 사례에만 도움이됩니다. NonNull 를 멋진 장소에 저장하고 변경하지 않고 NonNull 전달하기 때문입니다. 이론적으로는 (통과 오타 방지 할 수 foo 당신이 의미하는 경우 bar 그들 중 당신이있는 거 저글링 여러 포인터와 하나의 경우) NonNull , 그러나 이것은하지 않는 것 너무 흔하거나 중요합니다. dealloc 원시 포인터 ( alloc 반환 NonNull 가 @SimonSapin 이 저를 설득했다고 가정 함)의 단점은 as_ptr 가 필요하다는 것입니다. 잠재적으로 성가 시지만 안전성에 영향을 미치지 않는 dealloc 호출.

두 번째 종류의 사용 사례는 전체 프로세스에서 NonNull 계속 사용할 수 없기 때문에 도움이되지 않으므로 얻은 원시 포인터에서 NonNull 를 수동으로 다시 만들어야합니다. 어떤 방법 으로든. 앞서 언급했듯이 이것은 실제 실행 시간 확인이 아닌 확인되지 않은 / unsafe 주장이 될 가능성이 높으므로 풋 건이 방지되지 않습니다.

이것은 내가 원시 포인터를 취하는 dealloc 에 찬성한다고 말하는 것이 아닙니다. 나는 풋건에 대해 주장 된 이점을 보지 못했습니다. 유형의 일관성은 아마도 기본적으로 승리 할 것입니다.

미안하지만 "많은 불변은 유형 시스템을 통해 전혀 적용 할 수 없습니다 ... 그러므로 시도도하지 말자"라고 읽었습니다. 완벽한 것이 선의 적이되도록 두지 마십시오!

NonNull 제공하는 보증과 NonNull 와 원시 포인터 사이를 앞뒤로 전환해야하는 인체 공학적 손실 사이의 절충점에 대한 것입니다. 나는 어느 쪽도 특별히 강한 의견을 가지고 있지 않습니다. 어느 쪽도 불합리 해 보이지 않습니다.

@cramertj 예,하지만 저는 그런 종류의 논쟁의 전제를 실제로 사지는 않습니다. 사람들은 Alloc 이 모호하고, 숨겨져 있으며, 대체로 안전하지 않은 사용 사례라고 말합니다. 글쎄요, 모호하고 읽기 어려운 코드에서는 가능한 한 많은 안전을 원합니다 .-- 정확히 그들이 거의 만지지 않기 때문에 원래 저자가 주변에 없을 가능성이 있기 때문입니다. 반대로 코드가 몇 년 후에 읽 히면 인체 공학을 망쳐 놓으십시오. 오히려 비생산적입니다. 코드는 매우 명시 적으로 작성하여 익숙하지 않은 독자가 지구상에서 무슨 일이 일어나고 있는지 더 잘 이해할 수 있도록 노력해야합니다. 더 적은 소음 <더 명확한 불변.

두 번째 종류의 사용 사례는 전체 프로세스에서 NonNull 계속 사용할 수 없기 때문에 도움이되지 않으므로 얻은 원시 포인터에서 NonNull 를 수동으로 다시 만들어야합니다. 어떤 방법 으로든.

이것은 기술적 인 불가피성이 아니라 단순히 조정 실패입니다. 물론 지금은 안전하지 않은 많은 API가 원시 포인터를 사용할 수 있습니다. 뭔가 리드하는 그래서 방법을 사용하여 뛰어난 인터페이스로 전환 NonNull 또는 다른 래퍼를. 그러면 다른 코드가 더 쉽게 따라갈 수 있습니다. 나는 그린 필드, 완전 녹슬고, 안전하지 않은 코드에서 읽기 어렵고 유익하지 않은 원시 포인터로 계속해서 되돌아 갈 이유가 없다고 봅니다.

안녕하세요!

Rust 커스텀 할당 자의 작성자 / 관리자로서 저는 NonNull 찬성합니다. 이 스레드에 이미 배치 된 모든 이유 때문입니다.

또한 @glandium 은 firefox의 jemalloc 포크의 관리자이며 할당 자에 대한 해킹 경험도

@ Ericson2314 와 다른 사람들에게 훨씬 더 많이 NonNull 의 안전 이점을 과장한다고 생각하는 것에 대해 논쟁했습니다 (물론 다른 이점도 있습니다). 그렇다고 안전상의 이점이 없다고 말하는 것은 아니지만 @cramertj가 말했듯이 트레이드 오프가 있으며 "프로"측면이 과장된 것 같습니다. 에 관계없이, 나는 이미 내가 사용 향하다 말했다 NonNull 에 준 이유 @SimonSapin을위한 - 다른 이유로 다양한 장소에서 alloc 에서 dealloc 일관성. 그러니 더 이상 접선에서 벗어나지 말자.

모든 사람이 참여하는 NonNull 사용 사례가 몇 가지 있다면 좋은 시작입니다.

우리는 아마 업데이트 할 수 있습니다 Unique 사용하고 친구를 NonNull 대신 NonZero 내에서 최소한의 마찰을 유지하기 위해 liballoc 낮은. 그러나 이것은 우리가 할당 자에 대한 하나의 추상화 수준에서 이미하고있는 것처럼 보이며 할당 자 수준에서도 이것을하지 않는 이유를 생각할 수 없습니다. 나에게 합리적인 변화 인 것 같습니다.

( Unique<T> 와 NonNull<T> 사이에서 안전하게 변환하는 From 트레이 트의 두 가지 구현이 이미 있습니다.)

안정적인 녹에서 할당 자 API와 매우 유사한 것이 필요하다는 점을 고려하여 녹 저장소에서 코드를 추출하여 별도의 상자에 넣었습니다.

• https://crates.io/crates/allocator_api
• https://github.com/glandium/allocator_api

이 / could /는 API의 실험적 변경을 반복하는 데 사용할 수 있지만 현재로서는 rust 저장소에있는 내용의 일반 사본입니다.

[Off topic] 네, std 가 트리에서 안정된 코드 상자를 사용할 수 있다면 좋을 것입니다. 그래서 안정된 코드에서 불안정한 인터페이스를 실험 할 수 있습니다. 이것이 제가 외관을 std 갖는 것을 좋아하는 이유 중 하나입니다.

std 는 crates.io의 크레이트 복사본에 의존 할 수 있지만 프로그램이 같은 크레이트에 의존한다면 어쨌든 rustc와 같은 크레이트 / 유형 / 특성처럼 보이지 않을 것입니다. 그것이 어떻게 도움이 될지 보지 못했습니다. 어쨌든 파사드에 관계없이 안정된 채널에서 불안정한 기능을 사용할 수 없게 만드는 것은 사고가 아니라 매우 신중한 선택입니다.

NonNull을 사용하는 데 동의하는 것 같습니다. 이것이 실제로 일어날 수있는 방법은 무엇입니까? 그냥 홍보하는거야? RFC?

무관하게 Boxing에서 생성 된 어셈블리를 살펴 봤는데 오류 경로가 상당히 큽니다. 그것에 대해 뭔가해야합니까?

예 :

pub fn bar() -> Box<[u8]> {
    vec![0; 42].into_boxed_slice()
}

pub fn qux() -> Box<[u8]> {
    Box::new([0; 42])
}

다음으로 컴파일됩니다.

example::bar:
  sub rsp, 56
  lea rdx, [rsp + 8]
  mov edi, 42
  mov esi, 1
  call __rust_alloc_zeroed<strong i="11">@PLT</strong>
  test rax, rax
  je .LBB1_1
  mov edx, 42
  add rsp, 56
  ret
.LBB1_1:
  mov rax, qword ptr [rsp + 8]
  movups xmm0, xmmword ptr [rsp + 16]
  movaps xmmword ptr [rsp + 32], xmm0
  mov qword ptr [rsp + 8], rax
  movaps xmm0, xmmword ptr [rsp + 32]
  movups xmmword ptr [rsp + 16], xmm0
  lea rdi, [rsp + 8]
  call __rust_oom<strong i="12">@PLT</strong>
  ud2

example::qux:
  sub rsp, 104
  xorps xmm0, xmm0
  movups xmmword ptr [rsp + 58], xmm0
  movaps xmmword ptr [rsp + 48], xmm0
  movaps xmmword ptr [rsp + 32], xmm0
  lea rdx, [rsp + 8]
  mov edi, 42
  mov esi, 1
  call __rust_alloc<strong i="13">@PLT</strong>
  test rax, rax
  je .LBB2_1
  movups xmm0, xmmword ptr [rsp + 58]
  movups xmmword ptr [rax + 26], xmm0
  movaps xmm0, xmmword ptr [rsp + 32]
  movaps xmm1, xmmword ptr [rsp + 48]
  movups xmmword ptr [rax + 16], xmm1
  movups xmmword ptr [rax], xmm0
  mov edx, 42
  add rsp, 104
  ret
.LBB2_1:
  movups xmm0, xmmword ptr [rsp + 16]
  movaps xmmword ptr [rsp + 80], xmm0
  movaps xmm0, xmmword ptr [rsp + 80]
  movups xmmword ptr [rsp + 16], xmm0
  lea rdi, [rsp + 8]
  call __rust_oom<strong i="14">@PLT</strong>
  ud2

그것은 상자를 만드는 모든 장소에 추가하는 다소 많은 양의 코드입니다. 할당 자 API가없는 1.19와 비교하십시오.

example::bar:
  push rax
  mov edi, 42
  mov esi, 1
  call __rust_allocate_zeroed<strong i="18">@PLT</strong>
  test rax, rax
  je .LBB1_2
  mov edx, 42
  pop rcx
  ret
.LBB1_2:
  call alloc::oom::oom<strong i="19">@PLT</strong>

example::qux:
  sub rsp, 56
  xorps xmm0, xmm0
  movups xmmword ptr [rsp + 26], xmm0
  movaps xmmword ptr [rsp + 16], xmm0
  movaps xmmword ptr [rsp], xmm0
  mov edi, 42
  mov esi, 1
  call __rust_allocate<strong i="20">@PLT</strong>
  test rax, rax
  je .LBB2_2
  movups xmm0, xmmword ptr [rsp + 26]
  movups xmmword ptr [rax + 26], xmm0
  movaps xmm0, xmmword ptr [rsp]
  movaps xmm1, xmmword ptr [rsp + 16]
  movups xmmword ptr [rax + 16], xmm1
  movups xmmword ptr [rax], xmm0
  mov edx, 42
  add rsp, 56
  ret
.LBB2_2:
  call alloc::oom::oom<strong i="21">@PLT</strong>

이것이 실제로 중요하다면 실제로 성가신 일입니다. 그러나 LLVM이 더 큰 프로그램을 위해 이것을 최적화 할 수 있습니까?

최신 Firefox 야간에 __rust_oom 에 대한 1439 번의 통화가 있습니다. Firefox는 rust의 할당자를 사용하지 않습니다. 그래서 우리는 malloc / calloc에 ​​대한 직접 호출을받은 다음, 일반적으로 두 개의 movq와 한 개의 lea 인 oom 준비 코드로 점프하는지 확인하고 AllocErr을 채우고 그 주소를 가져 오는 null 검사를받습니다. __rust__oom 에 전달합니다. 이것은 본질적으로 최상의 시나리오이지만 두 개의 movq와 lea에 대한 20 바이트의 기계 코드입니다.

ripgrep을 보면 85 개가 있고 모두 동일한 _ZN61_$LT$alloc..heap..Heap$u20$as$u20$alloc..allocator..Alloc$GT$3oom17h53c76bda5 0c6b65aE.llvm.nnnnnnnnnnnnnnn 함수에 있습니다. 모두 16 바이트 길이입니다. 이러한 래퍼 함수에 대한 685 개의 호출이 있으며, 대부분은 https://github.com/rust-lang/rust/issues/32838#issuecomment -377097485에 붙여 넣은 것과 유사한 코드가 앞에옵니다.

@nox 는 오늘 mergefunc llvm 패스를 활성화하려고했습니다. 여기에 차이가 있는지 궁금합니다.

mergefunc 분명히 여러 개의 동일한 _ZN61_$LT$alloc..heap..Heap$u20$as$u20$alloc..allocator..Alloc$GT$3oom17h53c76bda5 0c6b65aE.llvm.nnnnnnnnnnnnnnn 함수를 제거하지 않습니다 ( -C passes=mergefunc 에서 RUSTFLAGS -C passes=mergefunc 로 시도).

그러나 큰 차이를 만드는 것은의 생성을 떠나, 직접 파이어 폭스 통화의 malloc하게 actualy 무엇 인 LTO 인 AllocErr 호출하기 전에 오른쪽에 __rust_oom . 또한 할당자를 호출하기 전에 Layout 불필요하게 만들고 AllocErr 채울 때 남겨 둡니다.

이로 인해 __rust_oom 제외하고는 할당 기능이 인라인으로 표시되어야한다고 생각합니다.

BTW, 파이어 폭스에 대해 생성 된 코드를보고하는 데, 나는 이상적으로 사용하는 것이 바람직 할 것이라고 생각하고 있어요 moz_xmalloc 대신 malloc . 이것은 할당 자 특성의 조합없이 전역 힙 할당을 대체 할 수있는 것은 불가능하지만 할당 자 특성에 대한 사용자 지정 오류 유형에 대한 가능한 필요 제공 : moz_xmalloc 무오하고 경우에 결코 수익을 실패. IOW, OOM 자체를 처리하고이 경우 Rust 코드는 __rust_oom 를 호출 할 필요가 없습니다. 선택적으로 돌아가려면 할당 기능을위한 것이 바람직 할 것이다 ! 대신 AllocErr .

우리는 AllocErr 크기가 0 인 구조체로 만드는 것에 대해 논의했습니다. 여기에서도 도움이 될 것입니다. 포인터도 NonNull 를 만들면 전체 반환 값이 포인터 크기가 될 수 있습니다.

https://github.com/rust-lang/rust/pull/49669 는 전역 할당자를 포함하는 하위 집합을 안정화하는 것을 목표로 이러한 API를 여러 가지 변경합니다. 해당 하위 집합에 대한 추적 문제 : https://github.com/rust-lang/rust/issues/49668. 특히 새로운 GlobalAlloc 특성 이 도입되었습니다.

이 PR을 통해 곧 alloc: Alloc 에서 Vec::new_with_alloc(alloc) 같은 일을 할 수 있습니까?

트윗 담아 가기

@sfackler 흠, 왜 안돼? 그러기 전에 무엇이 필요합니까? 단순히 글로벌 할당자를 변경하는 것이 아니라면이 PR의 요점을 알 수 없습니다.

뿡뿡

단순히 글로벌 할당자를 변경하는 것이 아니라면이 PR의 요점을 알 수 없습니다.

단순히 글로벌 할당자를 변경하기위한 것이라고 생각합니다.

@alexreg 안정을 의미하는 경우, 안정화 할 준비가되지 않은 해결되지 않은 설계 질문이 많이 있습니다. Nightly에서는 RawVec 지원하며 , 작업하고 싶은 사람이라면 Vec 에 #[unstable] 를 추가해도 좋습니다.

그리고 예, PR에서 언급했듯이 그 요점은 전역 할당자를 변경하거나 Vec::with_capacity 하지 않고 할당 (예 : 사용자 지정 컬렉션 유형)을 허용하는 것입니다.

FWIW, https://github.com/rust-lang/rust/issues/32838#issuecomment -376793369에 언급 된 allocator_api 크레이트는 마스터에 RawVec<T, A> 및 Box<T, A> 가 있습니다. 브랜치 (아직 출시되지 않음). 나는 그것을 할당 유형에 대한 일반적인 콜렉션이 어떻게 보일 수 있는지에 대한 인큐베이터로 생각하고 있습니다 (안정적인 녹을 위해 Box<T, A> 유형이 필요하다는 사실 포함). 아직 Vec<T, A> 를 추가하기 위해 vec.rs 포팅을 시작하지 않았지만 PR은 환영합니다. vec.rs는 큽니다.

https://github.com/rust-lang/rust/issues/32838#issuecomment -377097485에 언급 된 코드 생성 "문제"는 # 49669의 변경 사항과 함께 사라져야합니다.

이제 계층에서 할당자를 구현하는 데 도움이되는 Alloc 특성을 사용하는 것에 대해 좀 더 생각해 보면 (적어도 나에게는) 유용 할 것이라고 생각하는 두 가지가 있습니다.

• 앞서 언급했듯이 선택적으로 다른 AllocErr 유형을 지정할 수 있습니다. 이는 ! 으로 만들거나 이제 AllocErr이 비어 있으므로 선택적으로 "실패"보다 더 많은 정보를 전달하도록하는 데 유용 할 수 있습니다.
• 선택적으로 다른 Layout 유형을 지정할 수 있습니다. 할당 자의 두 계층이 있다고 가정 해보십시오. 하나는 페이지 할당 용이고 다른 하나는 더 큰 영역 용입니다. 후자는 전자에 의존 할 수 있지만 둘 다 동일한 Layout 유형을 사용하는 경우 두 레이어 모두 자체 유효성 검사를 수행해야합니다. 가장 낮은 수준에서 해당 크기와 정렬은 페이지 크기의 배수입니다. 더 높은 수준에서는 그 크기와 정렬이 더 큰 지역의 요구 사항과 일치합니다. 그러나 이러한 수표는 중복됩니다. 특수화 된 Layout 유형을 사용하면 할당 자 자체가 아닌 Layout 생성에 유효성 검사를 위임 할 수 있으며 Layout 유형 간의 변환을 통해 중복 검사를 건너 뛸 수 있습니다.

@cramertj @SimonSapin @glandium 좋아요, 명확히 해주셔서 감사합니다. 다른 컬렉션 프라임 유형에 대한 PR을 제출할 수도 있습니다. allocator-api repo / crate, @glandium 또는 rust 마스터에 좋 습니까?

@alexreg # 49669의 Alloc 특성에 대한 주요 변경 사항의 양을 고려하면 먼저 병합 될 때까지 기다리는 것이 좋습니다.

@glandium 충분합니다. 착륙에서 너무 멀지 않은 것 같습니다. 방금 https://github.com/pnkfelix/collections-prime repo를 발견했습니다 ... 당신의 것과 관련하여 무엇입니까?

열린 질문을 하나 더 추가하겠습니다.

• Alloc::oom 은 (는) 당황 할 수 있습니까? 현재 문서에서는이 방법이 프로세스를 중단해야한다고 말합니다. 할당자를 사용하는 코드는 메모리 누수없이 적절하게 해제를 처리하도록 설계되어야하기 때문에 이는 의미가 있습니다.

로컬 할당 자의 실패가 반드시 글로벌 할당 자도 실패한다는 것을 의미하지는 않기 때문에 패닉을 허용해야한다고 생각합니다. 최악의 경우 전역 할당 자의 oom 가 호출되어 프로세스를 중단합니다 (그렇지 않으면 기존 코드가 손상됨).

@alexreg 아니에요. std / alloc / collections에있는 내용의 일반 사본 인 것 같습니다. 글쎄요, 2 년 된 사본입니다. 내 상자는 범위가 훨씬 더 제한적입니다 (게시 된 버전에는 몇 주 전에 Alloc 특성 만 있고 마스터 브랜치에는 RawVec 및 Box . 내 목표 중 하나는 안정적인 녹으로 건물을 유지하는 것입니다.

@glandium 좋아,이 경우 PR이 도착할 때까지 기다린 다음 녹 마스터에 대한 PR을 생성하고 태그를 지정하면 마스터로 병합되는시기를 알 수 있습니다 (그런 다음 상자에 병합 할 수 있음). , 공정한?

@alexreg 이 의미가 있습니다. 지금 작업을 / 할 수는 있지만 / 자전거 흘리기가 해당 PR에서 상황을 변경하면 사용자쪽에 약간의 이탈을 유발할 수 있습니다.

@glandium 지금은 Rust로 바쁘게

Alloc :: oom이 당황 할 수 있습니까? 현재 문서에서는이 방법이 프로세스를 중단해야한다고 말합니다. 할당자를 사용하는 코드는 메모리 누수없이 적절하게 해제를 처리하도록 설계되어야하기 때문에 이는 의미가 있습니다.

@Amanieu 이 RFC는 병합되었습니다 : https://github.com/rust-lang/rfcs/pull/2116 문서와 구현이 아직 업데이트되지 않았을 수 있습니다.

PR 제출을 고려하고있는 API에 대한 변경 사항이 하나 있습니다.

Alloc 특성을 "구현"과 "도우미"의 두 부분으로 나눕니다. 전자는 alloc , dealloc , realloc 등과 같은 함수이고 후자는 alloc_one , dealloc_one , alloc_array 등. 후자에 대한 사용자 정의 구현을 할 수 있다는 가설적인 이점이 있지만, 가장 일반적인 요구와는 거리가 멀고 일반 래퍼를 구현해야 할 때 (저는 믿을 수 없을 정도로 일반적이며, 실제로 사용자 지정 파생을 작성하기 시작한 시점까지) 랩피가 사용자 지정을 수행 할 수 있으므로 여전히 모든 항목을 구현해야합니다.

OTOH, Alloc 트레이 트 구현자가 예를 들어 alloc_one 에서 멋진 일을하려고하면 해당 할당에 대해 dealloc_one 가 호출 될 것이라는 보장이 없습니다. 여기에는 여러 가지 이유가 있습니다.

• 도우미는 일관되게 사용되지 않습니다. 한 가지 예를 들면 raw_vec 는 alloc_array , alloc / alloc_zeroed 의 혼합을 사용하지만 dealloc 만 사용합니다.
• 예를 들어 alloc_array / dealloc_array 를 일관되게 사용하더라도 Vec 를 Box 로 안전하게 변환 한 다음 dealloc 를 사용할 수 있습니다
• 그런 다음 존재하지 않는 API 부분이 있습니다 ( alloc_one / alloc_array 0 버전 없음).

따라서 예를 들어 alloc_one 전문화를위한 실제 사용 사례가 있지만 (사실상 저는 mozjemalloc이 필요합니다) 대신 특수 할당자를 사용하는 것이 좋습니다.

사실, 그것은 더 나쁘다, rust repo에서 정확히 alloc_array 사용이 있고 alloc_one , dealloc_one , realloc_array , dealloc_array 상자 구문도 alloc_one 사용하지 않고 exchange_malloc 를 사용하며 size 및 align 합니다. 따라서 이러한 기능은 구현 자보다 클라이언트의 편의를 의미합니다.

impl<A: Alloc> AllocHelpers for A (또는 AllocExt , 이름이 무엇이든 상관 없음)과 같은 방식으로 우리는 여전히 클라이언트를위한 이러한 기능의 편리함을 유지하면서 구현자가 생각할 때 스스로 발을 쏠 수 없게합니다. 그들은 그들을 재정의함으로써 멋진 ​​일을 할 것입니다 (그리고 사람들이 프록시 할당자를 구현하는 것을 더 쉽게 만듭니다).

PR 제출을 고려하고있는 API에 한 가지 변경 사항이 있습니다.

# 50436에서 그렇게했습니다.

@glandium

(그리고 사실, 나는 mozjemalloc에 ​​대한 그러한 필요가 있습니다),

이 사용 사례에 대해 자세히 설명해 주시겠습니까?

mozjemalloc에는 의도적으로 누출되는 기본 할당자가 있습니다. 무료 목록을 유지하는 한 종류의 개체를 제외하고. alloc_one 트릭을 수행하는 대신 할당자를 계층화하여이를 수행 할 수 있습니다.

할당 한 정확한 정렬로 할당을 해제해야합니까?

이 질문에 대한 답이 ' 예 '라는 것을 강조하기 위해 Microsoft 자체 에서 다음과 같은 멋진 인용문이

alignment_alloc ()은 C11이 구현과 호환되지 않는 방식으로 지정했기 때문에 절대 구현되지 않을 것입니다 (즉, free ()가 고도로 정렬 된 할당을 처리 할 수 ​​있어야 함).

Windows에서 시스템 할당자를 사용하면 고도로 정렬 된 할당을 올바르게 할당 해제하기 위해 할당을 해제 할 때 항상 정렬을 알아야합니다. 그러면 해당 질문을 해결 된 것으로 표시 할 수 있습니까?

Windows에서 시스템 할당자를 사용하면 고도로 정렬 된 할당을 올바르게 할당 해제하기 위해 할당을 해제 할 때 항상 정렬을 알아야합니다. 그러면 해당 질문을 해결 된 것으로 표시 할 수 있습니까?

부끄러운 일이지만 그대로입니다. 그러면 과도하게 정렬 된 벡터를 포기합시다. : 혼란 :

과도하게 정렬 된 벡터를 포기하고

어째서? 과다 정렬로 할당 및 할당 해제하는 Vec<T, OverAlignedAlloc<U16>> 있으면됩니다.

어째서? 과다 정렬로 할당 및 할당 해제하는 Vec<T, OverAlignedAlloc<U16>> 있으면됩니다.

나는 더 구체적이어야했다. 나는 즉, 컨트롤의 API를 외부에 소요 한 overaligned 벡터를 이동 의미 Vec<T> 하지 Vec<T, OverAlignedAlloc<U16>> . (예 : CString::new() .)

차라리 사용해야합니다

#[repr(align(16))]
struct OverAligned16<T>(T);

그런 다음 Vec<OverAligned16<T>> .

차라리 사용해야합니다

조건에 따라서. f32 의 벡터에 AVX 내장 함수 (256 비트 너비, 32 바이트 정렬 요구 사항)를 사용한다고 가정합니다.

• Vec<T, OverAlignedAlloc<U32>> 는 문제를 해결하고, AVX 내장 함수를 벡터 요소 (특히 정렬 된 메모리로드)에 직접 사용할 수 있으며, 벡터는 여전히 &[f32] 슬라이스로 역 참조되어 인체 공학적으로 사용할 수 있습니다.
• Vec<OverAligned32<f32>> 은 실제로 문제를 해결하지 못합니다. 각 f32 는 정렬 요구 사항으로 인해 32 바이트의 공간을 차지합니다. 도입 된 패딩은 f32 가 더 이상 연속 메모리에 있지 않기 때문에 AVX 작업의 직접적인 사용을 방지합니다. 그리고 저는 개인적으로 &[OverAligned32<f32>] 대한 deref가 처리하기가 조금 지루하다는 것을 알게되었습니다.

Box , Box<T, OverAligned<U32>> 대 Box<OverAligned32<T>> 의 단일 요소의 경우 두 접근 방식이 더 동등하며 두 번째 접근 방식이 실제로 더 바람직 할 수 있습니다. 어쨌든 두 가지 옵션을 모두 갖는 것이 좋습니다.

Alloc 특성에이 wrt 변경 사항을 게시했습니다. https://internals.rust-lang.org/t/pre-rfc-changing-the-alloc-trait/7487

이 문제의 상단에있는 추적 게시물은 매우 오래되었습니다 (2016 년에 마지막으로 편집 됨). 토론을 생산적으로 계속하려면 업데이트 된 활성 관심사 목록이 필요합니다.

토론은 또한 현재 해결되지 않은 질문과 설계 결정에 대한 근거가 포함 된 최신 설계 문서로부터 상당한 이점을 얻을 수 있습니다.

여러 채널 (rfc repo, rust-lang 추적 문제, 글로벌 할당 RFC, 내부 게시물, 많은 큰 PR 등), GlobalAlloc RFC에서 안정화되고있는 것은 원래 RFC에서 제안 된 것과 크게 다르지 않습니다.

이것은 우리가 문서와 참조 업데이트를 끝내기 위해 어쨌든 필요하며 현재 토론에서도 도움이 될 것입니다.

Alloc 트레이 트 안정화에 대해 생각하기 전에 먼저 모든 표준 라이브러리 컬렉션에서 할당 자 지원을 구현해야한다고 생각합니다. 이것은 우리에게이 특성이 실제로 어떻게 사용 될지에 대한 약간의 경험을 줄 것입니다.

Alloc 트레이 트 안정화에 대해 생각하기 전에 먼저 모든 표준 라이브러리 컬렉션에서 할당 자 지원을 구현해야한다고 생각합니다. 이것은 우리에게이 특성이 실제로 어떻게 사용 될지에 대한 약간의 경험을 줄 것입니다.

네 그럼요. 특히 Box 는 Box<T, A> 가 두 단어를 차지하지 않도록하는 방법을 아직 알지 못하기 때문입니다.

네 그럼요. 특히 Box, 우리는 아직 Box를 피하는 방법을 모르기 때문에두 단어를 취하십시오.

초기 구현을 위해 Box<T, A> 의 크기를 걱정할 필요는 없다고 생각합니다.하지만 이것은 나중에 지원하는 DeAlloc 특성을 추가하여 이전 버전과 호환되는 방식으로 추가 할 수 있습니다. 할당 해제.

예:

trait DeAlloc {
    fn dealloc(&mut self, ptr: NonNull<Opaque>, layout: Layout);
}

trait Alloc {
    // In addition to the existing trait items
    type DeAlloc: DeAlloc = Self;
    fn into_dealloc(self) -> Self::DeAlloc {
        self
    }
}

impl<T: Alloc> DeAlloc for T {
    fn dealloc(&mut self, ptr: NonNull<Opaque>, layout: Layout) {
        Alloc::dealloc(self, ptr, layout);
    }
}

Alloc 특성 안정화에 대해 생각하기 전에 먼저 모든 표준 라이브러리 컬렉션에서 할당 자 지원을 구현해야한다고 생각합니다. 이것은 우리에게이 특성이 실제로 어떻게 사용 될지에 대한 약간의 경험을 줄 것입니다.

@ Ericson2314 가 https://github.com/rust-lang/rust/issues/42774 에 따라 이에 대해 작업하고 있다고 생각

초기 구현을 위해 Box<T, A> 의 크기를 걱정할 필요는 없다고 생각합니다.하지만 이것은 나중에 지원하는 DeAlloc 특성을 추가하여 이전 버전과 호환되는 방식으로 추가 할 수 있습니다. 할당 해제.

그것은 하나의 접근 방식이지만 그것이 확실히 최고의 접근 방식이라는 것이 전혀 분명하지 않습니다. 그것은 포인터 때만 작동)는 것을, 예를 들어, 별개의 단점을 가지고 있습니다 -> 할당 조회가 가능하다 (이것은, 예를 들어, 대부분의 경기장 할당 자) 및, B)의 사실이 아니다 그것은 상당한 오버 헤드를 추가 dealloc (즉, 역방향 조회 수행). 그것은이 문제에 대한 최선의 해결책은 같은 일반적인 목적의 효과 나 상황에 맞는 시스템 인 경우 끝나게 할 수있다 이 제안 또는 이 제안은 . 아니면 전혀 다른 것일 수도 있습니다. 그래서 저는 이것이 Alloc 특성의 현재 화신과 역 호환되는 방식으로 해결하기 쉬울 것이라고 생각해서는 안됩니다.

@joshlf Box<T, A> 이 드롭 될 때만 자신에 액세스 할 수 있다는 사실을 고려할 때 이것이 안전한 코드로만 할 수있는 가장 좋은 방법입니다. 이러한 패턴은 dealloc 가없는 아레나와 같은 할당 자에 유용 할 수 있으며 할당자가 삭제 될 때 메모리 만 확보 할 수 있습니다.

할당자가 컨테이너 (예 : LinkedList )가 소유하고 여러 할당을 관리하는 더 복잡한 시스템의 경우 Box 가 내부적으로 사용되지 않을 것으로 예상합니다. 대신, LinkedList 내부는 LinkedList 개체에 포함 된 Alloc 인스턴스와 함께 할당되고 해제되는 원시 포인터를 사용합니다. 이렇게하면 모든 포인터의 크기가 두 배가되는 것을 방지 할 수 있습니다.

Box<T, A> 이 드롭 될 때만 자신에 액세스 할 수 있다는 사실을 고려할 때 이것은 안전한 코드로만 할 수있는 가장 좋은 방법입니다. 이러한 패턴은 dealloc 가없는 아레나와 같은 할당 자에 유용 할 수 있으며 할당자가 삭제 될 때 메모리 만 확보 할 수 있습니다.

맞습니다.하지만 Box 은 dealloc 이 (가) 작동하지 않는다는 것을 모릅니다.

할당자가 컨테이너 (예 : LinkedList )가 소유하고 여러 할당을 관리하는 더 복잡한 시스템의 경우 Box가 내부적으로 사용되지 않을 것으로 예상합니다. 대신, LinkedList 내부는 LinkedList 개체에 포함 된 Alloc 인스턴스와 함께 할당되고 해제되는 원시 포인터를 사용합니다. 이렇게하면 모든 포인터의 크기가 두 배가되는 것을 방지 할 수 있습니다.

컬렉션을 작성하기 위해 안전하지 않은 코드를 사용하도록 요구하는 것은 정말 부끄러운 일이라고 생각합니다. 목표가 모든 컬렉션 (아마도 표준 라이브러리 외부의 컬렉션 포함)을 할당 자에서 선택적으로 매개 변수화하는 것이고 Box 가 할당 자 매개 변수가 아닌 경우 컬렉션 작성자는 Box 사용하지 않아야합니다.

맞지만 Box는 dealloc이 작동하지 않는다는 것을 모릅니다.

C ++ unique_ptr 가하는 일을 왜 적응하지 않습니까?
즉, "상태 저장"인 경우 할당 자에 대한 포인터를 저장하고 할당자가 "상태 비 저장"인 경우 저장하지 않습니다.
(예 : malloc 또는 mmap 주위의 전역 래퍼).
이것은 현재 Alloc 훈련을 StatefulAlloc 및 StatelessAlloc 두 가지 특성으로 분할해야합니다.
나는 그것이 매우 무례하고 우아하지 않다는 것을 알고 있습니다 (그리고 아마도 누군가가 이미 이전 토론에서 그것을 제안했을 것입니다).
우아하지 않음에도 불구하고이 솔루션은 단순하고 이전 버전과 호환됩니다 (성능 저하없이).

컬렉션을 작성하기 위해 안전하지 않은 코드를 사용하도록 요구하는 것은 정말 부끄러운 일이라고 생각합니다. 목표가 모든 컬렉션 (아마 표준 라이브러리 외부의 컬렉션 포함)을 할당 자에서 선택적으로 매개 변수로 만드는 것이고 Box가 할당 자 매개 변수가 아닌 경우 컬렉션 작성자는 Box를 전혀 사용하지 않거나 안전하지 않은 코드를 사용해야합니다 (그리고 항상 비워 두는 것을 기억하는 것은 C와 C ++에서 가장 일반적인 메모리 안전하지 않은 유형 중 하나이므로 안전하지 않은 코드를 제대로 가져 오기가 어렵습니다). 그것은 불행한 거래처럼 보입니다.

목록, 트리 등과 같은 노드 기반 컨테이너를 안전하게 작성할 수있는 효과 또는 컨텍스트 시스템을 구현하는 데 너무 많은 시간이 걸릴 수 있습니다 (원칙적으로 가능하다면).
이 문제를 다루는 논문이나 학술 언어를 보지 못했습니다 (실제로 그러한 작업이 존재하는 경우 수정 해주십시오).

따라서 노드 기반 컨테이너를 구현할 때 unsafe 에 의존하는 것은 적어도 단기적인 관점에서는 필요한 악영향을 미칠 수 있습니다.

@eucpp unique_ptr 는 할당자를 저장하지 않고 Deleter 저장합니다 .

삭제자는 FunctionObject 또는 FunctionObject에 대한 lvalue 참조이거나 function에 대한 lvalue 참조 여야하며 unique_ptr 유형의 인수로 호출 가능해야합니다.:: 포인터`

이것은 우리가 분할 Alloc 및 Dealloc 트레이 트를 제공하는 것과 거의 동일하다고 생각합니다.

@cramertj 네, 맞아요. 여전히 상태 저장 및 상태 비 저장 Dealloc 두 가지 특성이 필요합니다.

ZST Dealloc으로 충분하지 않습니까?

2018 년 6 월 12 일 화요일 오후 3:08 Evgeniy Moiseenko [email protected]
썼다 :

@cramertj https://github.com/cramertj 네, 맞습니다. 그래도 두
특성이 필요합니다-Stateful 및 Stateless Dealloc.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32838#issuecomment-396716689 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEAJtWkpF0ofVc18NwbfV45G4QY6SCFBks5t8B_AgaJpZM4IDYUN
.

ZST Dealloc으로 충분하지 않습니까?

@remexre 나는 그것이 될 것이라고 생각한다 :)

Rust 컴파일러가 ZST를 즉시 지원한다는 것을 몰랐습니다.
C ++에서는 빈 기본 최적화에 대해 최소한 몇 가지 트릭이 필요합니다.
나는 Rust에서 꽤 새로운 사람이어서 명백한 실수에 대해 죄송합니다.

Stateful과 Stateless에 대해 별도의 특성이 필요하다고 생각하지 않습니다.

함께 Box 로 보강 A 입력 매개 변수, 그것의 값이 포함될 것이다 A 직접적이지 참조 또는 포인터 A . 이 유형은 상태 비 저장 (비) 할당 자에 대해 크기가 0 일 수 있습니다. 또는 A 자체는 여러 할당 된 개체간에 공유 할 수있는 상태 저장 할당 자에 대한 참조 또는 핸들과 같은 것일 수 있습니다. 따라서 impl Alloc for MyAllocator 대신 impl<'r> Alloc for &'r MyAllocator 같은 작업을 수행 할 수 있습니다.

그건 그렇고, 할당 해제 방법 만 알고 할당 방법을 모르는 Box 는 Clone 구현하지 않습니다.

그 기대 @SimonSapin Clone 만드는 것을 다시 할당을 지정할 필요 보내고, 같은 방법으로 새로운 Box (즉, 그것을 사용하여 수행되지 않을 것 Clone 특성).

@cramertj Vec 및 Clone 를 구현하는 다른 컨테이너와 비교할 때 일관성이 없지 않습니까?
인스턴스 저장의 단점은 무엇입니까 Alloc 내부 Box 보다는 Dealloc ?
그러면 Box 은 clone_with_alloc 뿐만 아니라 Clone 를 구현할 수 있습니다.

나는 이것이 분할 특성이 실제로 클론에 큰 영향을 미치지는 않습니다-impl은 impl<T, A> Clone for Box<T, A> where A: Alloc + Dealloc + Clone { ... } 처럼 보일 것입니다.

@sfackler 나는 그 impl에 반대하지는 않지만 clone_into 또는 제공된 할당자를 사용하는 무언가를 기대합니다.

alloc_copy 메소드가 Alloc 합리적일까요? 이것은 예를 들어 페이지의 쓰기시 복사 복제를 수행하여 대규모 할당에 대해 더 빠른 memcpy ( Copy/Clone ) 구현을 제공하는 데 사용될 수 있습니다.

기본 구현을 제공하는 것은 매우 멋지고 사소한 것입니다.

그러한 alloc_copy 함수를 사용하는 것은 무엇입니까? impl Clone for Box<T, A> ?

예, Vec 마찬가지입니다.

좀 더 자세히 살펴보면 적어도 한 수준 이상을 수행하려는 경우 hacky와 불가능 사이의 동일한 프로세스 범위 내에서 copy-on-write 페이지를 만드는 접근 방식처럼 보입니다. 따라서 alloc_copy 은 큰 이점이 아닙니다.

대신 미래의 가상 메모리 허위를 허용하는 더 일반적인 탈출구가 유용 할 수 있습니다. 즉, 할당이 크고, 어쨌든 mmap에 의해 뒷받침되고 상태 비 저장이면 할당자는 할당에 대한 향후 변경 사항을 알지 못하도록 약속 할 수 있습니다. 그런 다음 사용자는 해당 메모리를 파이프로 이동하거나 매핑을 해제하거나 이와 유사한 것을 할 수 있습니다.
또는 멍청한 mmap-all-the-things 할당 자와 try-transfer 함수가있을 수 있습니다.

대신 미래의 가상 메모리를 허용하는보다 일반적인 탈출구

메모리 할당 자 (malloc, jemalloc, ...)는 일반적으로 메모리에서 어떤 종류의 메모리도 훔치도록 허용하지 않으며 일반적으로 자신이 소유 한 메모리의 속성을 쿼리하거나 변경할 수 없습니다. 그렇다면이 일반적인 탈출구는 메모리 할당 자와 어떤 관련이 있습니까?

또한 가상 메모리 지원은 플랫폼마다 크게 다르기 때문에 가상 메모리를 효과적으로 사용하려면 종종 완전히 다른 보장과 함께 플랫폼마다 다른 알고리즘이 필요합니다. 가상 메모리에 대한 이식 가능한 추상화를 보았지만 "이동성"으로 인해 일부 상황에서 쓸모가 없을 정도로 손상되지 않은 것은 아직 보지 못했습니다.

네가 옳아. 이러한 사용 사례 (대부분 플랫폼 별 최적화를 생각하고 있었음)는 처음에 사용자 지정 할당자를 사용하는 것이 가장 좋습니다.

Andrei Alexandrescu가 CppCon 프레젠테이션에서 설명한 Composable Allocator API에 대한 의견이 있습니까? 비디오는 여기 YouTube에서 볼 수 있습니다 : https://www.youtube.com/watch?v=LIb3L4vKZ7U (그는 26:00 경에 그의 제안 된 디자인을 설명하기 시작하지만, 그 이야기는 당신이 그것을 보는 것을 선호 할 수있을만큼 충분히 재미 있습니다) .

이 모든 것의 피할 수없는 결론은 컬렉션 라이브러리가 일반적인 WRT 할당이어야하고 앱 프로그래머 자신이 건설 현장에서 할당 자와 컬렉션을 자유롭게 구성 할 수 있어야한다는 것입니다.

Andrei Alexandrescu가 CppCon 프레젠테이션에서 설명한 Composable Allocator API에 대한 의견이 있습니까?

현재 Alloc API를 사용하면 구성 가능한 할당 자 (예 : MyAlloc<Other: Alloc> )를 작성할 수 있으며 특성 및 전문화를 사용하여 Andreis 토크에서 달성 한 거의 모든 것을 달성 할 수 있습니다. 그러나 그렇게 할 수 있어야한다는 "아이디어"를 넘어서, Andrei가 API를 빌드하는 방식이 제약없는 제네릭 + SFINAE / 정적 (처음부터 시작 및 Rust의 제네릭 시스템)에 있기 때문에 Andrei의 이야기에서 거의 아무것도 Rust에 적용 할 수 없습니다. 그것과는 완전히 다릅니다.

나머지 Layout 메서드의 안정화를 제안하고 싶습니다. 이는 현재 전역 할당 자 API에서 이미 유용합니다.

이것이 당신이 의미하는 모든 방법입니까?

• pub fn align_to(&self, align: usize) -> Layout
• pub fn padding_needed_for(&self, align: usize) -> usize
• pub fn repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>
• pub fn extend(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>
• pub fn repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>
• pub fn extend_packed(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>
• pub fn array<T>(n: usize) -> Result<Layout, LayoutErr>

@gnzlbg 예.

@Amanieu 괜찮아 보이지만이 문제는 이미 거대합니다. 개별적으로 FCP 할 수있는 별도의 문제 (또는 안정화 PR)를 제출하는 것을 고려 하시겠습니까?

할당 자 및 수명 :

1. (할당 자 impls의 경우) : 할당 자 값을 이동하면 미해결 메모리 블록이 무효화되지 않아야합니다.

   모든 클라이언트는 코드에서 이것을 가정 할 수 있습니다.

   따라서 클라이언트가 할당 자에서 블록을 할당 한 다음 (a1이라고 함) a1이 새 위치 (예 : vialet a2 = a1;)로 이동하면 클라이언트가 a2를 통해 해당 블록의 할당을 해제하는 것은 소리가 남습니다.

이것은 할당 자가 Unpin 이어야 함을 의미합니까?

잘 잡아!

Alloc 트레이 트가 여전히 불안정하기 때문에 RFC의이 부분을 수정하고 싶다면 여전히 규칙을 변경해야한다고 생각합니다. 그러나 실제로 명심해야 할 사항입니다.

@gnzlbg 예, 제네릭 시스템의 큰 차이점을 알고 있으며 그가 자세히 설명하는 모든 것이 Rust에서 동일한 방식으로 구현 될 수있는 것은 아닙니다. 그래도 게시물을 올린 이후로 도서관에서 일하고 있으며 좋은 진전을 보이고 있습니다.

이것은 할당자가 _must_ Unpin 여야 함을 의미합니까?

그렇지 않습니다. Unpin 는 Pin 래핑 될 때 유형의 동작에 관한 것으로이 API에 대한 특별한 연결은 없습니다.

그러나 Unpin 을 사용하여 언급 된 제약 조건을 적용 할 수 없습니까?

dealloc_array 에 관한 또 다른 질문 : 함수가 Result 반환하는 이유는 무엇입니까? 현재 구현에서는 다음 두 가지 경우에 실패 할 수 있습니다.

• n 은 (는) 0입니다.
• n * size_of::<T>() 용량 초과

처음에는 두 가지 경우가 있습니다 (문서에서와 같이 구현자는 다음 중에서 선택할 수 있습니다).

• 할당은 0이 된 n Ok 에 대해 dealloc_array 도 Ok 반환해야합니다.
• 할당은 0이 된 n => dealloc_array 전달할 수있는 포인터가 없을 때 Err 를 반환합니다.

두 번째는 다음과 같은 안전 제약에 의해 보장됩니다.

[T; n] 의 레이아웃은 해당 메모리 블록에 맞아야 합니다.

즉, 할당에서와 동일한 n 로 dealloc_array 를 호출 해야합니다 . n 요소가있는 배열을 할당 할 수있는 경우 n 는 T 대해 유효합니다. 그렇지 않으면 할당이 실패했을 것입니다.

편집 : 마지막 요점에 관하여 : usable_size 이 n * size_of::<T>() 보다 높은 값을 반환하더라도 이것은 여전히 ​​유효합니다. 그렇지 않으면 구현이이 특성 제약을 위반합니다.

블록의 크기는 [use_min, use_max] 범위에 있어야합니다. 여기서 :

• [...]
• use_max 는 alloc_excess 또는 realloc_excess 호출을 통해 블록이 할당 된 경우 (만약) 반환되었거나 반환되었을 용량입니다.

특성에는 unsafe impl 필요하기 때문에 이것은 유효합니다.

처음에는 두 가지 경우가 있습니다 (문서에서와 같이 구현자는 다음 중에서 선택할 수 있습니다).

• 할당은 0이 된 n Ok 을 반환합니다.

이 정보는 어디서 얻었습니까?

문서의 모든 Alloc::alloc_ 메서드는 0 크기 할당의 동작이 "Safety"절에서 정의되지 않음을 지정합니다.

core::alloc::Alloc (관련 부분 강조 표시) :

크기가 0 인 유형 및 크기가 0 인 레이아웃에 대한 참고 : Alloc 특성의 많은 메서드는 할당 요청이 0이 아닌 크기 여야하며 그렇지 않으면 정의되지 않은 동작이 발생할 수 있습니다.

• 그러나 일부 상위 수준 할당 방법 ( alloc_one , alloc_array )은 크기가 0 인 유형에 대해 잘 정의되어 있으며 선택적으로 지원할 수 있습니다 . Err 반환 여부는 구현 자에게 달려 있습니다 로 Ok 를 반환합니다.

• 이 경우 Alloc 구현이 Ok 를 반환하도록 선택하면 (즉, 포인터가 0 크기의 액세스 할 수없는 블록을 나타냄) 반환 된 포인터는 "현재 할당 됨"으로 간주되어야합니다. 이러한 할당 자에서 현재 할당 된 포인터를 입력으로 사용하는 모든 메서드는 정의되지 않은 동작 을 일으키지

• 즉, 크기가 0 인 포인터가 할당 자 밖으로 흐를 수있는 경우 해당 할당자는 마찬가지로 할당 해제 및 재 할당 메서드로 다시 흐르는 포인터를 수락해야합니다 .

따라서 dealloc_array 의 오류 조건 중 하나는 확실히 의심 스럽습니다.

/// # Safety
///
/// * the layout of `[T; n]` must *fit* that block of memory.
///
/// # Errors
///
/// Returning `Err` indicates that either `[T; n]` or the given
/// memory block does not meet allocator's size or alignment
/// constraints.

[T; N] 가 할당 자 크기 또는 정렬 제약 조건을 충족하지 않으면 AFAICT가 할당 메모리 블록에 맞지 않으며 동작이 정의되지 않습니다 (안전 조항에 따라).

다른 오류 조건은 "산술 오버플로시 항상 Err 반환"입니다. 꽤 일반적입니다. 유용한 오류 조건인지 여부를 말하기는 어렵습니다. 각 Alloc 특성 구현에 대해 이론적으로 랩할 수있는 산술을 수행 할 수있는 다른 특성을 생각 해낼 수 있으므로 🤷‍♂️

core::alloc::Alloc (관련 부분 강조 표시) :

과연. 너무 많은 메서드 (예 : Alloc::alloc )에서 크기가 0 인 할당이 정의되지 않은 동작이라고 명시하는 것이 이상하지만 구현 정의 동작으로 Alloc::alloc_array(0) 만 제공합니다. 어떤 의미에서 Alloc::alloc_array(0) 는 할당자가 0 크기 할당을 지원하는지 여부를 확인하는 리트머스 테스트입니다.

[T; N] 가 할당 자 크기 또는 정렬 제약 조건을 충족하지 않으면 AFAICT가 할당 메모리 블록에 맞지 않으며 동작이 정의되지 않습니다 (안전 조항에 따라).

예,이 오류 조건은 중복되므로 삭제할 수 있다고 생각합니다. 안전 조항이나 오류 조건 중 하나가 필요하지만 둘 다 필요한 것은 아닙니다.

다른 오류 조건은 "산술 오버플로시 항상 Err 반환"입니다. 꽤 일반적입니다. 유용한 오류 조건인지 여부를 말하기는 어렵습니다.

IMO, 위와 동일한 안전 조항에 의해 보호됩니다. [T; N] 의 용량이 오버플로되면 할당을 해제 할 메모리 블록에 맞지 않습니다. @pnkfelix 가 이것에 대해 자세히 설명 할 수 있습니까?

어떤 의미에서 Alloc::alloc_array(1) 는 할당자가 0 크기 할당을 지원하는지 여부를 확인하는 리트머스 테스트입니다.

Alloc::alloc_array(0) 찾으셨습니까?

IMO, 위와 동일한 안전 조항에 의해 보호됩니다. [T; N] 의 용량이 오버플로되면 해당 메모리 블록이 할당 해제되지 않습니다.

이 특성은 사용자 지정 할당 자에 대해 사용자가 구현할 수 있으며 이러한 사용자는 이러한 메서드의 기본 구현을 재정의 할 수 있습니다. 따라서 이것이 산술 오버플로에 대해 Err 를 반환해야하는지 여부를 고려할 때 기본 메서드의 현재 기본 구현이 수행하는 작업에 초점을 둘뿐만 아니라 다른 사용자를 위해이를 구현하는 사용자에게 의미가있을 수있는 사항도 고려해야합니다. 할당 자.

Alloc::alloc_array(0) 찾으셨습니까?

네 죄송합니다.

이 특성은 사용자 지정 할당 자에 대해 사용자가 구현할 수 있으며 이러한 사용자는 이러한 메서드의 기본 구현을 재정의 할 수 있습니다. 따라서 이것이 산술 오버플로에 대해 Err 를 반환해야하는지 여부를 고려할 때 기본 메서드의 현재 기본 구현이 수행하는 작업에 초점을 둘뿐만 아니라 다른 사용자를 위해이를 구현하는 사용자에게 의미가있을 수있는 사항도 고려해야합니다. 할당 자.

하지만 Alloc 구현에는 unsafe impl 하며 구현자는 https://github.com/rust-lang/rust/issues/32838#issuecomment -467093527에 언급 된 안전 규칙을 따라야합니다. .

추적 문제를 위해 여기에서 가리키는 모든 API는 Alloc 트레이 트이거나 Alloc 트레이 트와 관련이 있습니다. @ rust-lang / libs, https://github.com/rust-lang/rust/issues/42774 외에도 이것을 열어 두는 것이 유용하다고 생각

간단한 배경 질문 : ZST의 유연성 뒤에있는 동기는 무엇입니까? 컴파일 타임에 유형이 ZST라는 것을 알고 있다면 할당 (상수 값 반환)과 할당 해제를 모두 완벽하게 최적화 할 수있는 것 같습니다. 이를 감안할 때 다음 중 하나를 말해야 할 것 같습니다.

• ZST를 지원하는 것은 항상 구현 자에게 달려 있으며 ZST에 대해 Err 를 반환 할 수 없습니다.
• ZST를 할당하는 것은 항상 UB이며이 경우 단락하는 것은 호출자의 책임입니다.
• 일종의있다 alloc_inner 발신자가 구현하는 것이 방법, 그리고 alloc 짧은 단락을 수행하는 기본 구현 방법; alloc 는 ZST를 지원해야하지만 alloc_inner 는 ZST를 위해 호출되지 않을 수 있습니다 (특성 정의에있는 단일 위치에서 단락 논리를 순서대로 추가 할 수 있도록하기위한 것입니다) 구현 자에게 약간의 상용구를 저장하기 위해)

현재 API에 대한 유연성이 필요한 이유가 있습니까?

현재 API에 대한 유연성이 필요한 이유가 있습니까?

트레이드 오프입니다. 틀림없이 Alloc 특성은 구현 된 것보다 더 자주 사용되므로 ZST에 대한 기본 지원을 제공하여 Alloc을 가능한 한 쉽게 사용하는 것이 합리적 일 수 있습니다.

이것은 Alloc 특성의 구현자가 이것을 처리해야한다는 것을 의미하지만, 더 중요한 것은 Alloc 특성을 발전시키려는 사람들이 모든 API 변경에 대해 ZST를 염두에 두어야한다는 것입니다. 또한 ZST가 처리되는 방법 (또는 "구현 정의"인 경우)을 설명하여 API 문서를 복잡하게 만듭니다.

C ++ 할당자는 할당자가 다양한 문제를 해결하려고하는이 접근 방식을 추구합니다. 이로 인해 구현 및 발전이 더 어려워 졌을뿐만 아니라 이러한 모든 문제가 API에서 상호 작용하는 방식으로 인해 사용자가 실제로 사용하기가 더 어려워졌습니다.

ZST를 처리하고 원시 메모리를 할당 / 해제하는 것은 두 가지 직교적이고 다른 문제라고 생각하므로 처리하지 않고 Alloc 특성 API를 단순하게 유지해야합니다.

libstd와 같은 Alloc 사용자는 예를 들어 각 컬렉션에서 ZST를 처리해야합니다. 그것은 확실히 풀 가치가있는 문제이지만, Alloc 특성이 그것을위한 장소라고 생각하지 않습니다. 필자는이 문제를 해결하는 유틸리티가 필요에 따라 libstd 내에서 튀어 나올 것으로 예상하고, 그럴 때 그러한 유틸리티를 RFC하고 std :: heap에 노출 할 수 있습니다.

그 모든 것이 합리적으로 들립니다.

ZST를 처리하고 원시 메모리를 할당 / 해제하는 것은 두 가지 직교적이고 다른 문제라고 생각하므로 처리하지 않고 Alloc 특성 API를 단순하게 유지해야합니다.

API가 구현 정의가 아닌 ZST를 명시 적으로 처리하지 않아야 함을 의미하지 않습니까? IMO, "지원되지 않는"오류는 대부분의 호출자가 대체 경로를 정의 할 수 없기 때문에 런타임에별로 도움이되지 않으며 따라서 ZST가 지원되지 않는다고 가정해야합니다. API를 단순화하고 지원되지 않음을 선언하는 것이 더 깔끔해 보입니다.

alloc 사용자가 ZST를 처리하기 위해 전문화를 사용합니까? 아니면 if size_of::<T>() == 0 수표?

alloc 사용자가 ZST를 처리하기 위해 전문화를 사용합니까? 아니면 if size_of::<T>() == 0 수표?

후자는 충분해야합니다. 적절한 코드 경로는 컴파일 타임에 사소하게 제거됩니다.

API가 구현 정의가 아닌 ZST를 명시 적으로 처리하지 않아야 함을 의미하지 않습니까?

저에게 중요한 제약은 0 크기 할당을 금지하면 Alloc 메서드가 전달 된 Layout 가 크기가 0이 아니라고 가정 할 수 있어야한다는 것입니다.

이를 달성하는 방법에는 여러 가지가 있습니다. 하나는 Layout 크기가 0이면 동작이 정의되지 않음을 나타내는 다른 Safety 절을 모든 Alloc 메서드에 추가하는 것입니다.

또는 제로 크기 Layout 금지 할 수 있습니다. 그러면 Alloc 는 제로 크기 할당에 대해 아무 말도 할 필요가 없습니다. 이것이 안전하게 발생할 수 없기 때문입니다. 그러나 그렇게하면 몇 가지 단점이 있습니다.

예를 들어, HashMap 같은 일부 유형은 여러 Layout 에서 Layout 를 빌드하고 최종 Layout 은 크기가 0이 아닐 수 있습니다. 중간 항목은 (예 : HashSet ) 일 수 있습니다. 따라서 이러한 유형은 "다른 것"(예 : LayoutBuilder 유형)을 사용하여 최종 Layout 를 구축하고 "0이 아닌"수표를 지불해야합니다 (또는 Layout 로 변환 할 때 _unchecked ) 메서드.

할당 사용자가 ZST를 처리하기 위해 전문화를 사용합니까? 또는 size_of ::() == 0 검사?

우리는 아직 ZST를 전문화 할 수 없습니다. 현재 모든 코드는 size_of::<T>() == 0 합니다.

이를 달성하는 방법에는 여러 가지가 있습니다. 하나는 Layout 크기가 0이면 동작이 정의되지 않음을 나타내는 다른 Safety 절을 모든 Alloc 메서드에 추가하는 것입니다.

이것을 컴파일 타임 보장으로 만드는 방법이 있는지 고려하는 것은 흥미로울 것입니다. 그러나 레이아웃이 0이 아닌 debug_assert 조차도 99 %의 버그를 잡기에 충분합니다.

할당 자에 대한 논의에 전혀 관심을 기울이지 않았기 때문에 죄송합니다. 그러나 나는 할당자가 할당하는 값의 유형에 액세스 할 수 있기를 오랫동안 바랬습니다. 그것을 사용할 수있는 할당 자 설계가있을 수 있습니다.

그렇다면 우리는 아마도 C ++와 동일한 문제를 가질 것이며 할당 자 API입니다.

그러나 나는 할당자가 할당하는 값의 유형에 액세스 할 수 있기를 오랫동안 바랬습니다. 티

이게 무엇을 위해 필요합니까?

@gnzblg @brson 오늘 저는 할당되는 가치의 유형에 대해 _something_을 아는 잠재적 인 사용 사례가있었습니다.

저는 스레드 로컬 할당 자, 잠금이있는 전역 할당 자, 사용할 코 루틴을위한 3 가지 기본 할당 자 사이에서 전환 할 수있는 전역 할당자를 작업 중입니다. 아이디어는 네트워크 연결을 나타내는 코 루틴을 최대로 제한 할 수 있다는 것입니다. 동적 메모리 사용량 (컬렉션의 할당자를 제어 할 수없는 경우, 특히 타사 코드의 경우) *.

스레드간에 이동할 수있는 값 (예 : Arc)과 그렇지 않은 값을 할당하는지 아는 것이 유용 할 수 있습니다. 아니면 그렇지 않을 수도 있습니다. 그러나 가능한 시나리오입니다. 현재 전역 할당 자에는 사용자가 할당을 수행 할 할당자를 알리기 위해 사용하는 스위치가 있습니다 (재 할당 또는 해제에는 필요하지 않습니다. 메모리 주소 만 볼 수 있습니다).

* [또한 잠금없이 가능한 한 NUMA 로컬 메모리를 사용할 수 있으며 1 코어 1 스레드 모델을 사용하여 총 메모리 사용량을 제한 할 수 있습니다.]

뿡 빵뀨

저는 글로벌 할당 자에서 일하고 있습니다

이 중 어떤 것도 GlobalAlloc 트레이 트에 적용될 수 있다고 생각하지 않습니다. Alloc 트레이 트에는 이미 유형 정보를 사용할 수있는 일반 메서드가 있습니다 (예 : alloc_array<T>(1) 는 단일 T alloc_array<T>(1) 할당합니다. 여기서 T 는 실제 유형이므로 할당자는 할당을 수행하는 동안 유형을 고려할 수 있습니다. 유형 정보를 사용하는 할당자를 구현하는 코드를 실제로 보는 것이이 토론의 목적에 더 유용 할 것이라고 생각합니다. 나는 왜 이러한 메소드가 할당 자 API의 일부가되거나 다른 할당 자 특성의 일부가되는 것이 아니라 일반적인 할당 자 특성의 일부가되어야하는지에 대한 좋은 주장을 듣지 못했습니다.

Alloc 의해 매개 변수화 된 유형 중 어떤 유형을 유형 정보를 사용하는 할당 자와 결합 할 계획인지, 그리고 어떤 결과를 기대하는지 아는 것도 매우 흥미로울 것이라고 생각합니다.

AFAICT, 그 유일한 흥미 유형은 것 Box 그것이 할당하기 때문에 T 직접. std 거의 모든 다른 유형은 T 할당하지 않지만 할당자가 알 수없는 일부 비공개 내부 유형입니다. 예를 들어 Rc 및 Arc 는 (InternalRefCounts, T) , List / BTreeSet / 등을 할당 할 수 있습니다. 내부 노드 유형 Vec 할당 할 수 있습니다. Deque / ... T 의 배열을 할당하지만 T 자체는 할당하지 않습니다.

Box 및 Vec 경우 할당자가 할 수있는 Alloc 대한 블랭킷 impls가있는 BoxAlloc 및 ArrayAlloc 트레이 트를 하위 호환 방식으로 추가 할 수 있습니다. 일반적인 방식으로 이러한 문제를 공격 할 필요가있는 경우 이러한 문제가 어떻게 작동하는지 하이재킹하는 데 특화되어 있습니다. 그러나 유형 정보를 악용하기 위해 할당 자와 공모하는 자체 MyAllocBox 및 MyAllocVec 유형을 제공하는 것이 실행 가능한 솔루션이 아닌 이유가 있습니까?

이제 할당 자 WG에 대한 전용 저장소 가 있고 OP의 목록이 오래되었으므로이 문제를 한곳에서 논의하고 추적하기 위해이 문제를 닫을 수 있습니까?

@TimDiekmann 좋은 포인트! 계속해서 해당 저장소의 토론 스레드를 위해 이것을 닫을 것입니다.

이것은 여전히 ​​일부 #[unstable] 속성이 가리키는 추적 문제입니다. 이러한 기능이 안정화되거나 사용되지 않을 때까지 닫아서는 안된다고 생각합니다. (또는 다른 문제를 가리 키도록 속성을 변경할 수 있습니다.)

그래, git master에서 참조되는 불안정한 기능에는 확실히 공개 추적 문제가 있어야합니다.

동의합니다. 또한 OP에 대한 알림 및 링크를 추가했습니다.