@@ -17,8 +17,9 @@ use crate::plan::AllocationSemantics;
1717use crate :: plan:: { Mutator , MutatorContext } ;
1818use crate :: scheduler:: WorkBucketStage ;
1919use crate :: scheduler:: { GCWork , GCWorker } ;
20+ use crate :: util:: alloc:: allocator:: AllocationOptions ;
2021use crate :: util:: alloc:: allocators:: AllocatorSelector ;
21- use crate :: util:: constants:: { LOG_BYTES_IN_PAGE , MIN_OBJECT_SIZE } ;
22+ use crate :: util:: constants:: LOG_BYTES_IN_PAGE ;
2223use crate :: util:: heap:: layout:: vm_layout:: vm_layout;
2324use crate :: util:: opaque_pointer:: * ;
2425use crate :: util:: { Address , ObjectReference } ;
@@ -139,11 +140,28 @@ pub fn flush_mutator<VM: VMBinding>(mutator: &mut Mutator<VM>) {
139140 mutator. flush ( )
140141}
141142
142- /// Allocate memory for an object. For performance reasons, a VM should
143- /// implement the allocation fast-path on their side rather than just calling this function.
143+ /// Allocate memory for an object.
144144///
145- /// If the VM provides a non-zero `offset` parameter, then the returned address will be
146- /// such that the `RETURNED_ADDRESS + offset` is aligned to the `align` parameter.
145+ /// When the allocation is successful, it returns the starting address of the new object. The
146+ /// memory range for the new object is `size` bytes starting from the returned address, and
147+ /// `RETURNED_ADDRESS + offset` is guaranteed to be aligned to the `align` parameter. The returned
148+ /// address of a successful allocation will never be zero.
149+ ///
150+ /// If MMTk fails to allocate memory, it will attempt a GC to free up some memory and retry the
151+ /// allocation. After triggering GC, it will call [`crate::vm::Collection::block_for_gc`] to suspend
152+ /// the current thread that is allocating. Callers of `alloc` must be aware of this behavior.
153+ /// For example, JIT compilers that support
154+ /// precise stack scanning need to make the call site of `alloc` a GC-safe point by generating stack maps. See
155+ /// [`alloc_with_options`] if it is undesirable to trigger GC at this allocation site.
156+ ///
157+ /// If MMTk has attempted at least one GC, and still cannot free up enough memory, it will call
158+ /// [`crate::vm::Collection::out_of_memory`] to inform the binding. The VM binding
159+ /// can implement that method to handle the out-of-memory event in a VM-specific way, including but
160+ /// not limited to throwing exceptions or errors. If [`crate::vm::Collection::out_of_memory`] returns
161+ /// normally without panicking or throwing exceptions, this function will return zero.
162+ ///
163+ /// For performance reasons, a VM should implement the allocation fast-path on their side rather
164+ /// than just calling this function.
147165///
148166/// Arguments:
149167/// * `mutator`: The mutator to perform this allocation request.
@@ -158,24 +176,46 @@ pub fn alloc<VM: VMBinding>(
158176 offset : usize ,
159177 semantics : AllocationSemantics ,
160178) -> Address {
161- // MMTk has assumptions about minimal object size.
162- // We need to make sure that all allocations comply with the min object size.
163- // Ideally, we check the allocation size, and if it is smaller, we transparently allocate the min
164- // object size (the VM does not need to know this). However, for the VM bindings we support at the moment,
165- // their object sizes are all larger than MMTk's min object size, so we simply put an assertion here.
166- // If you plan to use MMTk with a VM with its object size smaller than MMTk's min object size, you should
167- // meet the min object size in the fastpath.
168- debug_assert ! ( size >= MIN_OBJECT_SIZE ) ;
169- // Assert alignment
170- debug_assert ! ( align >= VM :: MIN_ALIGNMENT ) ;
171- debug_assert ! ( align <= VM :: MAX_ALIGNMENT ) ;
172- // Assert offset
173- debug_assert ! ( VM :: USE_ALLOCATION_OFFSET || offset == 0 ) ;
179+ #[ cfg( debug_assertions) ]
180+ crate :: util:: alloc:: allocator:: assert_allocation_args :: < VM > ( size, align, offset) ;
174181
175182 mutator. alloc ( size, align, offset, semantics)
176183}
177184
178- /// Invoke the allocation slow path. This is only intended for use when a binding implements the fastpath on
185+ /// Allocate memory for an object.
186+ ///
187+ /// This allocation function allows alternation to the allocation behaviors, specified by the
188+ /// [`crate::util::alloc::AllocationOptions`]. For example, one can allow
189+ /// overcommit the memory to go beyond the heap size without triggering a GC. This function can be
190+ /// used in certain cases where the runtime needs a different allocation behavior other than
191+ /// what the default [`alloc`] provides.
192+ ///
193+ /// Arguments:
194+ /// * `mutator`: The mutator to perform this allocation request.
195+ /// * `size`: The number of bytes required for the object.
196+ /// * `align`: Required alignment for the object.
197+ /// * `offset`: Offset associated with the alignment.
198+ /// * `semantics`: The allocation semantic required for the allocation.
199+ /// * `options`: the allocation options to change the default allocation behavior for this request.
200+ pub fn alloc_with_options < VM : VMBinding > (
201+ mutator : & mut Mutator < VM > ,
202+ size : usize ,
203+ align : usize ,
204+ offset : usize ,
205+ semantics : AllocationSemantics ,
206+ options : crate :: util:: alloc:: allocator:: AllocationOptions ,
207+ ) -> Address {
208+ #[ cfg( debug_assertions) ]
209+ crate :: util:: alloc:: allocator:: assert_allocation_args :: < VM > ( size, align, offset) ;
210+
211+ mutator. alloc_with_options ( size, align, offset, semantics, options)
212+ }
213+
214+ /// Invoke the allocation slow path of [`alloc`].
215+ /// Like [`alloc`], this function may trigger GC and call [`crate::vm::Collection::block_for_gc`] or
216+ /// [`crate::vm::Collection::out_of_memory`]. The caller needs to be aware of that.
217+ ///
218+ /// *Notes*: This is only intended for use when a binding implements the fastpath on
179219/// the binding side. When the binding handles fast path allocation and the fast path fails, it can use this
180220/// method for slow path allocation. Calling before exhausting fast path allocaiton buffer will lead to bad
181221/// performance.
@@ -196,6 +236,34 @@ pub fn alloc_slow<VM: VMBinding>(
196236 mutator. alloc_slow ( size, align, offset, semantics)
197237}
198238
239+ /// Invoke the allocation slow path of [`alloc_with_options`].
240+ ///
241+ /// Like [`alloc_with_options`], This allocation function allows alternation to the allocation behaviors, specified by the
242+ /// [`crate::util::alloc::AllocationOptions`]. For example, one can allow
243+ /// overcommit the memory to go beyond the heap size without triggering a GC. This function can be
244+ /// used in certain cases where the runtime needs a different allocation behavior other than
245+ /// what the default [`alloc`] provides.
246+ ///
247+ /// Like [`alloc_slow`], this function is also only intended for use when a binding implements the
248+ /// fastpath on the binding side.
249+ ///
250+ /// Arguments:
251+ /// * `mutator`: The mutator to perform this allocation request.
252+ /// * `size`: The number of bytes required for the object.
253+ /// * `align`: Required alignment for the object.
254+ /// * `offset`: Offset associated with the alignment.
255+ /// * `semantics`: The allocation semantic required for the allocation.
256+ pub fn alloc_slow_with_options < VM : VMBinding > (
257+ mutator : & mut Mutator < VM > ,
258+ size : usize ,
259+ align : usize ,
260+ offset : usize ,
261+ semantics : AllocationSemantics ,
262+ options : AllocationOptions ,
263+ ) -> Address {
264+ mutator. alloc_slow_with_options ( size, align, offset, semantics, options)
265+ }
266+
199267/// Perform post-allocation actions, usually initializing object metadata. For many allocators none are
200268/// required. For performance reasons, a VM should implement the post alloc fast-path on their side
201269/// rather than just calling this function.
0 commit comments