मक्खी पर चरित्र प्रकार उत्पन्न करना (या जंग के साथ पागल)

इस लेख में, हम रस्ट प्रोग्रामिंग भाषा, और विशेष रूप से, विशेषता वस्तुओं का मजाक उड़ाएंगे।

जब मैं रस्ट से परिचित हुआ, तो टाइप ऑब्जेक्ट्स के कार्यान्वयन का एक विवरण मुझे दिलचस्प लगा। अर्थात्, आभासी फ़ंक्शन तालिका डेटा में ही नहीं है, लेकिन इसके लिए "मोटी" सूचक में है। प्रत्येक प्रकार के ऑब्जेक्ट के लिए एक पॉइंटर) डेटा के लिए एक पॉइंटर होता है, साथ ही एक वर्चुअल टेबल के लिए एक लिंक होता है, जहां दिए गए ढांचे के लिए इस प्रकार के ऑब्जेक्ट को लागू करने वाले कार्यों के पते स्थित होंगे (लेकिन जब से यह कार्यान्वयन विवरण है, तो व्यवहार बदल सकता है।

चलो एक साधारण उदाहरण से शुरू करते हैं जो मोटे बिंदुओं को प्रदर्शित करता है। निम्न कोड 64-बिट आर्किटेक्चर 8 और 16 पर आउटपुट करेगा:

fn main () { let v: &String = &"hello".into(); let disp: &std::fmt::Display = v; println!("  : {}", std::mem::size_of_val(&v)); println!("   -: {}", std::mem::size_of_val(&disp)); } 

यह दिलचस्प क्यों है? जब मैं एंटरप्राइज़ जावा में लगा हुआ था, एक कार्य जो नियमित रूप से उत्पन्न होता था, वह मौजूदा वस्तुओं के दिए गए इंटरफेस का अनुकूलन था। यही है, ऑब्जेक्ट पहले से मौजूद है, एक लिंक के रूप में जारी किया गया है, लेकिन इसे निर्दिष्ट इंटरफ़ेस के अनुकूल होना चाहिए। और आप इनपुट ऑब्जेक्ट को बदल नहीं सकते, यह वही है जो यह है।

मुझे कुछ इस तरह करना था:

 Person adapt(Json value) { // ...- , , ,  "value"  //   Person return new PersonJsonAdapter(value); } 

इस दृष्टिकोण के साथ विभिन्न समस्याएं थीं। उदाहरण के लिए, यदि एक ही वस्तु दो बार "एडैप्ट" होती है, तो हमें दो अलग-अलग Person मिलते हैं (लिंक तुलना के दृष्टिकोण से)। और यह तथ्य कि आपको हर बार नई वस्तुएं बनानी होती हैं, किसी तरह बदसूरत होती हैं।

जब मैंने Rust में टाइप ऑब्जेक्ट्स को देखा, तो मुझे अंदाजा था कि Rust में यह बहुत अधिक सुरुचिपूर्ण ढंग से किया जा सकता है! आप डेटा के लिए एक और वर्चुअल टेबल भी ले सकते हैं और एक नई विशेषता प्राप्त कर सकते हैं! और प्रत्येक उदाहरण के लिए मेमोरी आवंटित न करें। एक ही समय में, "उधार" का पूरा तर्क जगह पर रहता है - हमारा अनुकूलन कार्य कुछ इस तरह दिखेगा fn adapt<'a>(value: &'a Json) -> &'a Person (अर्थात, हम एक तरह से उधार लेते हैं) स्रोत डेटा)।

इससे भी अधिक, आप एक ही प्रकार (उदाहरण के लिए, String ) को विभिन्न प्रकार के व्यवहार के साथ, कई बार हमारे प्रकार की वस्तु को लागू करने के लिए "बाध्य" कर सकते हैं। क्यों? लेकिन आप कभी नहीं जानते कि उद्यम में क्या जरूरत हो सकती है! "

आइए इसे लागू करने का प्रयास करें।

समस्या का बयान

हम कार्य को इस तरह सेट करते हैं: annotate फ़ंक्शन बनाते हैं, जो नियमित String प्रकार के लिए निम्न प्रकार की वस्तु "असाइन" करता है:

 trait Object { fn type_name(&self) -> &str; fn as_string(&self) -> &String; } 

और annotate स्वयं कार्य करता है:

 ///    - `Object`,   , ///   "" -- ,    `type_name`. fn annotate<'a>(input: &'a String, type_name: &str) -> &'a dyn Object { // ... } 

चलिए अभी एक टेस्ट लिखते हैं। सबसे पहले, सुनिश्चित करें कि "असाइन किया गया" प्रकार अपेक्षित से मेल खाता है। दूसरी बात, हम यह सुनिश्चित करेंगे कि हम मूल पंक्ति प्राप्त कर सकें और यह एक ही पंक्ति होगी (बिंदुओं के दृष्टिकोण से):

 #[test] fn test() { let input: String = "hello".into(); let annotated1 = annotate(&input, "Widget"); let annotated2 = annotate(&input, "Gadget"); // -   ,    assert_eq!("Widget", annotated1.type_name()); assert_eq!("Gadget", annotated2.type_name()); let unwrapped1 = annotated1.as_string(); let unwrapped2 = annotated2.as_string(); //       --   assert_eq!(unwrapped1 as *const String, &input as *const String); assert_eq!(unwrapped2 as *const String, &input as *const String); } 

दृष्टिकोण संख्या 1: और हमारे बाद कम से कम बाढ़!

सबसे पहले, चलो पूरी तरह से अनुभवहीन कार्यान्वयन बनाने की कोशिश करते हैं। बस हमारे डेटा को "रैपर" में लपेटें, जिसमें इसके अलावा type_name :

 struct Wrapper<'a> { value: &'a String, type_name: String, } impl<'a> Object for Wrapper<'a> { fn type_name(&self) -> &str { &self.type_name } fn as_string(&self) -> &String { self.value } } 

अभी तक कुछ खास नहीं हुआ। जावा में सब कुछ जैसा है। लेकिन हमारे पास कूड़ा उठाने वाला नहीं है, हम इस रैपर को कहां रखेंगे? हमें लिंक वापस करने की आवश्यकता है, ताकि annotate फ़ंक्शन को कॉल करने के बाद यह वैध बना रहे। हम Box में कुछ डरावना रख देंगे ताकि Wrapper ढेर पर प्रकाश डाला जाए। और फिर हम इसके लिंक को वापस कर देंगे। और ताकि रैपर annotate फ़ंक्शन को कॉल करने के बाद भी जीवित रहे, हम इस बॉक्स को "लीक" करेंगे:

 fn annotate<'a>(input: &'a String, type_name: &str) -> &'a dyn Object { let b = Box::new(Wrapper { value: input, type_name: type_name.into(), }); Box::leak(b) } 

... और परीक्षा पास!

लेकिन यह कुछ संदिग्ध निर्णय है। न केवल हम अभी भी प्रत्येक "एनोटेशन" के साथ मेमोरी आवंटित करते हैं, इसलिए मेमोरी लीक हो जाती है ( Box::leak पर संग्रहीत डेटा के लिए एक लिंक देता है, लेकिन एक ही समय में "बॉक्स" को भूल जाता है, अर्थात, स्वत: डीटोकेशन नहीं होगा) )।

दृष्टिकोण 2: अखाड़ा!

शुरू करने के लिए, आइए इन रैपरों को कहीं और सहेजने की कोशिश करें ताकि वे किसी बिंदु पर जारी न हों। लेकिन एक ही समय में annotate हस्ताक्षर को बनाए रखना जैसा कि यह है। यही है, संदर्भ गिनती के साथ एक लिंक लौटाना (उदाहरण के लिए, Rc<Wrapper> ) काम नहीं करता है।

सबसे सरल विकल्प एक सहायक संरचना, एक "प्रकार प्रणाली" बनाना है, जो इन रैपरों को संग्रहीत करने के लिए जिम्मेदार होगा। और जब हम समाप्त कर लेंगे, हम इस संरचना और इसके साथ सभी आवरणों को छोड़ देंगे।

कुछ इस तरह। typed-arena लाइब्रेरी का उपयोग रैपरों को संग्रहीत करने के लिए किया जाता है, लेकिन आप Vec<Box<Wrapper>> साथ प्राप्त कर सकते हैं, मुख्य बात यह है कि Wrapper कहीं भी स्थानांतरित नहीं होता है (रात में जंग आप पिन एपीआई का उपयोग कर सकते हैं):

 struct TypeSystem { wrappers: typed_arena::Arena<Wrapper>, } impl TypeSystem { pub fn new() -> Self { Self { wrappers: typed_arena::Arena::new(), } } ///     `input`,      , ///    (  ,    , ///        )! pub fn annotate<'a: 'b, 'b>( &'a self, input: &'b String, type_name: &str ) -> &'b dyn Object { self.wrappers.alloc(Wrapper { value: input, type_name: type_name.into(), }) } } 

लेकिन Wrapper प्रकार के लिंक के जीवनकाल के लिए जिम्मेदार पैरामीटर कहां गया? हमें इससे छुटकारा पाना था, क्योंकि हम टाइप किए typed_arena::Arena<Wrapper<'?>> में कुछ निश्चित जीवनकाल का गुण नहीं कर सकते। प्रत्येक रैपर में input आधार पर एक अद्वितीय पैरामीटर input !

इसके बजाय, हम आजीवन समय के पैरामीटर से छुटकारा पाने के लिए थोड़ा असुरक्षित जंग छिड़कते हैं:

 struct Wrapper { value: *const String, type_name: String, } impl Object for Wrapper { fn type_name(&self) -> &str { &self.type_name } ///   -- ,     (  /// `annotate`),     (    - /// `&Object`)  ,      (`String`). fn as_string(&self) -> &String { unsafe { &*self.value } } } 

और परीक्षण फिर से पास होते हैं, जिससे हमें निर्णय की शुद्धता पर भरोसा होता है। unsafe साथ असहज महसूस करने के अलावा (जैसा कि यह होना चाहिए, असुरक्षित जंग के साथ मजाक नहीं करना बेहतर है!)।

लेकिन फिर भी, वादा किए गए विकल्प के बारे में क्या है, जिसे रैपर के लिए अतिरिक्त मेमोरी आवंटन की आवश्यकता नहीं है?

दृष्टिकोण # 3: नरक के द्वार खोलें

आइडिया। प्रत्येक अद्वितीय "प्रकार" ("विजेट", "गैजेट") के लिए, हम एक वर्चुअल टेबल बनाएंगे। कार्यक्रम के निष्पादन के दौरान हाथ। और हम इसे डेटा द्वारा हमें दिए गए लिंक पर ही असाइन करते हैं (जो, जैसा कि हम याद करते हैं, बस String )।

सबसे पहले, जो हमें प्राप्त करने की आवश्यकता है उसका एक संक्षिप्त विवरण। तो, एक प्रकार की वस्तु का संदर्भ, यह कैसे व्यवस्थित किया जाता है? वास्तव में, ये सिर्फ दो पॉइंटर्स हैं, एक डेटा के लिए और दूसरा वर्चुअल टेबल पर। तो हम लिखते हैं:

 #[repr(C)] struct TraitObject { pub data: *const (), pub vtable: *const (), } 

( #[repr(C)] हमें मेमोरी में सही स्थान की गारंटी देने की आवश्यकता है)।

ऐसा लगता है कि सब कुछ सरल है, हम दिए गए मापदंडों के लिए एक नई तालिका तैयार करेंगे और टाइप ऑब्जेक्ट के लिए "इकट्ठा" करेंगे! लेकिन इस तालिका में क्या है?

इस प्रश्न का सही उत्तर होगा "यह एक कार्यान्वयन विवरण है।" लेकिन हम ऐसा करेंगे; हमारी परियोजना की जड़ में एक rust-toolchain फ़ाइल बनाएं और इसे वहां लिखें: nightly-2018-12-01 । आखिरकार, एक निश्चित विधानसभा को स्थिर माना जा सकता है, है ना?

अब जब हमने रस्ट संस्करण को ठीक कर लिया है (वास्तव में, हमें नीचे दिए गए पुस्तकालयों में से एक के लिए रात की विधानसभा की आवश्यकता होगी)।

इंटरनेट पर कुछ खोज के बाद, हमें पता चलता है कि तालिका प्रारूप सरल है: पहले विध्वंसक की एक कड़ी है, फिर मेमोरी (प्रकार आकार और संरेखण) के आवंटन से जुड़े दो क्षेत्र हैं, और फिर फ़ंक्शन एक के बाद एक (आदेश कंपाइलर के विवेक पर हैं) केवल दो कार्य, इसलिए अनुमान लगाने की संभावना बहुत अधिक है, 50%)।

तो हम लिखते हैं:

 #[repr(C)] #[derive(Clone, Copy)] struct VirtualTableHeader { destructor_fn: fn(*mut ()), size: usize, align: usize, } #[repr(C)] struct ObjectVirtualTable { header: VirtualTableHeader, type_name_fn: fn(*const String) -> *const str, as_string_fn: fn(*const String) -> *const String, } 

इसी तरह, स्मृति में सही स्थान की गारंटी के लिए #[repr(C)] आवश्यकता है। मैं दो संरचनाओं में विभाजित हुआ, थोड़ी देर बाद यह हमारे लिए उपयोगी होगा।

अब आइए हमारे प्रकार के सिस्टम को लिखने का प्रयास करें, जो annotate फ़ंक्शन प्रदान करेगा। हमें उत्पन्न तालिकाओं को कैश करने की आवश्यकता होगी, तो आइए कैश प्राप्त करें:

 struct TypeInfo { vtable: ObjectVirtualTable, } #[derive(Default)] struct TypeSystem { infos: RefCell<HashMap<String, TypeInfo>>, } 

हम RefCell की आंतरिक स्थिति का उपयोग करते हैं ताकि हमारे TypeSystem::annotate फ़ंक्शन एक साझा लिंक के रूप में प्राप्त &self कर सकें। यह महत्वपूर्ण है, क्योंकि हम TypeSystem से "उधार लेते हैं" यह सुनिश्चित करने के लिए कि हमने जो वर्चुअल टेबल उत्पन्न की है, वह उस प्रकार की वस्तु के संदर्भ से अधिक समय तक रहती है, जिसे हम annotate से लौटाते हैं।

चूंकि हम कई उदाहरणों को एनोटेट करने में सक्षम होना चाहते हैं, इसलिए हम एक परस्पर लिंक के रूप में उधार नहीं ले सकते हैं।

और हम इस कोड को स्केच करेंगे:

 impl TypeSystem { pub fn annotate<'a: 'b, 'b>( &'a self, input: &'b String, type_name: &str ) -> &'b dyn Object { let type_name = type_name.to_string(); let mut infos = self.infos.borrow_mut(); let imp = infos.entry(type_name).or_insert_with(|| unsafe { //    ,  ? let vtable = unimplemented!(); TypeInfo { vtable } }); let object_obj = TraitObject { data: input as *const String as *const (), vtable: &imp.vtable as *const ObjectVirtualTable as *const (), }; //       - unsafe { std::mem::transmute::<TraitObject, &dyn Object>(object_obj) } } } 

हमें यह तालिका कहां से मिली? इसमें पहले तीन प्रविष्टियाँ निर्दिष्ट प्रकार के लिए किसी अन्य आभासी तालिका के लिए प्रविष्टियों से मेल खाएँगी। इसलिए, बस उन्हें कॉपी और कॉपी करें। सबसे पहले, आइए इसे टाइप करें:

 trait Whatever {} impl<T> Whatever for T {} 

यह हमारे लिए बहुत ही उपयोगी है "किसी भी अन्य आभासी तालिका।" और फिर, हम उससे ये तीन प्रविष्टियाँ कॉपी करते हैं:

 let whatever = input as &dyn Whatever; let whatever_obj = std::mem::transmute::<&dyn Whatever, TraitObject>(whatever); let whatever_vtable_header = whatever_obj.vtable as *const VirtualTableHeader; let vtable = ObjectVirtualTable { //  ! header: *whatever_vtable_header, type_name_fn: unimplemented!(), as_string_fn: unimplemented!(), }; TypeInfo { vtable } 

असल में, हम std::mem::size_of::<String>() माध्यम से आकार और संरेखण प्राप्त कर सकते हैं std::mem::size_of::<String>() और std::mem::align_of::<String>() । लेकिन और कहाँ से विनाशकारी "चोरी" हो सकता है, मुझे नहीं पता।

ठीक है, लेकिन हमें इन फ़ंक्शंस के पते type_name_fn , type_name_fn और as_string_fn ? आप देख सकते हैं कि as_string_fn की आमतौर पर आवश्यकता नहीं होती है, डेटा पॉइंटर हमेशा टाइप ऑब्जेक्ट के प्रतिनिधित्व में पहले रिकॉर्ड के रूप में जाता है। यही है, यह फ़ंक्शन हमेशा समान होता है:

 impl Object for String { // ... fn as_string(&self) -> String { self } } 

लेकिन दूसरे फ़ंक्शन के साथ यह इतना आसान नहीं है! यह हमारे नाम "प्रकार", type_name पर भी निर्भर करता है।

इससे कोई फर्क नहीं पड़ता, हम केवल रनटाइम में इस फ़ंक्शन को उत्पन्न कर सकते हैं। आइए इस के लिए dynasm पुस्तकालय लें (फिलहाल, इसे रास्ट बिल्ड बनाने की आवश्यकता है)। के बारे में पढ़ें
समारोह कॉल सम्मेलनों ।

सादगी के लिए, मान लें कि हम केवल मैक ओएस और लिनक्स में रुचि रखते हैं (इन सभी मज़ेदार परिवर्तनों के बाद, संगतता वास्तव में अब और नहीं परेशान करती है?)। और, हाँ, विशेष रूप से x86-64, बिल्कुल।

दूसरा फ़ंक्शन, as_string को लागू करना आसान है। हमें वादा किया जाता है कि पहला पैरामीटर RDI रजिस्टर में होगा। और RAX को मान लौटाएं। अर्थात्, फ़ंक्शन कोड कुछ इस प्रकार होगा:

 dynasm!(ops ; mov rax, rdi ; ret ); 

लेकिन पहला कार्य थोड़ा पेचीदा है। सबसे पहले, हमें वापस लौटने की जरूरत है, जो एक मोटी पॉइंटर है। इसका पहला भाग स्ट्रिंग के लिए एक संकेतक है, और दूसरा भाग स्ट्रिंग टुकड़ा की लंबाई है। सौभाग्य से, उपरोक्त सम्मेलन आपको दूसरे भाग के लिए EDX रजिस्टर का उपयोग करके 128-बिट परिणाम वापस करने की अनुमति देता है।

यह एक स्ट्रिंग स्लाइस का लिंक पाने के लिए बना हुआ है जिसमें हमारा स्ट्रिंग type_name । हम type_name पर भरोसा नहीं करना चाहते हैं (हालांकि जीवन भर के एनोटेशन के माध्यम से हम गारंटी दे सकते हैं कि type_name दिए गए मान से अधिक समय तक जीवित रहेगा)।

लेकिन हमारे पास इस पंक्ति की एक प्रति है, जिसे हम हैश टेबल में रखते हैं। अपनी उंगलियों को पार करते हुए, हम यह धारणा String::as_str कि स्ट्रिंग स्लाइस का स्थान जो String::as_str नहीं String::as_str वह String को स्थानांतरित करने से नहीं बदलता String (और String को String::as_str के आकार को बदलने की प्रक्रिया में स्थानांतरित किया जाएगा जहां यह स्ट्रिंग कुंजी द्वारा संग्रहीत है)। मुझे नहीं पता कि मानक लाइब्रेरी इस व्यवहार की गारंटी देती है, लेकिन क्या हम इसे आसानी से निभा रहे हैं?

हमें आवश्यक घटक मिलते हैं:

 let type_name_ptr = type_name.as_str().as_ptr(); let type_name_len = type_name.as_str().len(); 

और यह फ़ंक्शन लिखें:

 dynasm!(ops ; mov rax, QWORD type_name_ptr as i64 ; mov rdx, QWORD type_name_len as i64 ; ret ); 

और अंत में, अंतिम annotate कोड:

 pub fn annotate<'a: 'b, 'b>(&'a self, input: &'b String, type_name: &str) -> &'b Object { let type_name = type_name.to_string(); //       let type_name_ptr = type_name.as_str().as_ptr(); let type_name_len = type_name.as_str().len(); let mut infos = self.infos.borrow_mut(); let imp = infos.entry(type_name).or_insert_with(|| unsafe { let mut ops = dynasmrt::x64::Assembler::new().unwrap(); //     `type_name` let type_name_offset = ops.offset(); dynasm!(ops ; mov rax, QWORD type_name_ptr as i64 ; mov rdx, QWORD type_name_len as i64 ; ret ); //     `as_string` let as_string_offset = ops.offset(); dynasm!(ops ; mov rax, rdi ; ret ); let buffer = ops.finalize().unwrap(); //      let whatever = input as &dyn Whatever; let whatever_obj = std::mem::transmute::<&dyn Whatever, TraitObject>(whatever); let whatever_vtable_header = whatever_obj.vtable as *const VirtualTableHeader; let vtable = ObjectVirtualTable { header: *whatever_vtable_header, type_name_fn: std::mem::transmute(buffer.ptr(type_name_offset)), as_string_fn: std::mem::transmute(buffer.ptr(as_string_offset)), }; TypeInfo { vtable, buffer } }); assert_eq!(imp.vtable.header.size, std::mem::size_of::<String>()); assert_eq!(imp.vtable.header.align, std::mem::align_of::<String>()); let object_obj = TraitObject { data: input as *const String as *const (), vtable: &imp.vtable as *const ObjectVirtualTable as *const (), }; unsafe { std::mem::transmute::<TraitObject, &dyn Object>(object_obj) } } 

dynasm उद्देश्यों के लिए dynasm हमें buffer फ़ील्ड को अपने TypeInfo संरचना में TypeInfo । यह फ़ील्ड उस मेमोरी को नियंत्रित करती है जो हमारे उत्पन्न कार्यों के कोड को संग्रहीत करती है:

 #[allow(unused)] buffer: dynasmrt::ExecutableBuffer, 

और सभी टेस्ट पास कर लेते हैं!

हो गया, मालिक!

इतनी आसानी से और स्वाभाविक रूप से आप रस्ट कोड में टाइप ऑब्जेक्ट्स का अपना कार्यान्वयन उत्पन्न कर सकते हैं!

बाद वाला समाधान सक्रिय रूप से कार्यान्वयन विवरण पर निर्भर करता है और इसलिए उपयोग के लिए अनुशंसित नहीं है। लेकिन वास्तव में, आपको वही करना होगा जो आपको करना है। हताश समय के लिए हताश उपायों की आवश्यकता होती है!

हालाँकि, एक (अधिक) एक विशेषता है जो मैं यहाँ पर निर्भर करता हूँ। अर्थात्, यह तालिका द्वारा वस्तुतः कब्जा की गई स्मृति को मुक्त करने के लिए सुरक्षित है क्योंकि इसके उपयोग करने वाले प्रकार के ऑब्जेक्ट के लिए कोई संदर्भ नहीं है। एक तरफ, यह तर्कसंगत है कि आप केवल टाइप ऑब्जेक्ट्स के संदर्भों के माध्यम से वर्चुअल टेबल का उपयोग कर सकते हैं। दूसरी ओर, रस्ट द्वारा प्रदान की गई तालिकाओं में एक 'static जीवनकाल होता है। कुछ कोड को मान लेना पूरी तरह से संभव है जो तालिका को इसके कुछ उद्देश्यों के लिए लिंक से अलग करेगा (आप कभी नहीं जानते हैं, उदाहरण के लिए, इसकी कुछ गंदी चाल के लिए )।

स्रोत कोड यहां पाया जा सकता है ।