These are the functions that a GC built as a DLL must export. Some functions may be optional and are marked as such.
This is a global include file which provides to the VM an interface to the GC. This interface is the only supported interface that the VM should call to talk to the GC. All routines in this C interface will begin with gc_
.
The GC expects that there is a vm_gc.h
file holding the only interface that the GC will use to talk to the VM.
In order to eliminate dependency on certain types such as (VTable *) we have eliminated them from this interface and replace them with (void *). While this might appear to be unfortunate it allows us to eliminate any knowledge of the class and VTable structures that are not of interest to the GC.
Routines to support the functionality required by the Java language specification | |
#define | GC_OBJECT_ALIGNMENT 4 |
Granularity of object alignment. | |
void | gc_force_gc () |
API for the VM to force a GC, typically in response to a call to java.lang.Runtime.gc . | |
int64 | gc_total_memory () |
API for the VM to determine the current GC heap size, typically in response to a call to java.lang.Runtime.totalMemory . | |
int64 | gc_max_memory () |
API for the VM to determine the maximum GC heap size, typically in response to a call to java.lang.Runtime.maxMemory . | |
int64 | gc_free_memory () |
API for the VM to get an approximate view of the free space, typically in response to a call to java.lang.Runtime.freeMemory . | |
Boolean | gc_is_object_pinned (Managed_Object_Handle obj) |
| |
void | gc_class_prepared (Class_Handle ch, VTable_Handle vth) |
The VM calls this function after a new class has been prepared. | |
int64 | gc_get_collection_count () |
int64 | gc_get_collection_time () |
Routines to support threads | |
typedef void * | Thread_Handle |
Opaque handle for threads. | |
void | gc_thread_init (void *gc_information) |
This routine is called during thread startup to set an initial nursery for the thread. | |
void | gc_thread_kill (void *gc_information) |
This is called just before the thread is reclaimed. | |
VMEXPORT void | vm_iterate_threads () |
GC may call this function asynchronously any time it wants to get thread list. | |
void | gc_iterate_thread (Thread_Handle thread) |
VM calls this method repeatedly to iterate over the list of java threads, initiated earlier by calling vm_iterate_threads() . | |
VMEXPORT void | vm_suspend_thread (Thread_Handle thread) |
GC calls this method to request VM to suspend an individual thread. | |
void | gc_thread_suspended (Thread_Handle thread) |
VM calls this GC callback when it's accomplished the requested operation of suspending a thread in gc-safe point. | |
VMEXPORT void | vm_enumerate_thread_root_set (Thread_Handle thread) |
GC calls this function to command VM to enumerate a thread, which was earlier suspenden using vm_suspend_thread() . | |
VMEXPORT void | vm_enumerate_global_root_set () |
GC calls this function to command VM to enumerate global slots. | |
Defines | |
#define | GCExport __declspec(dllexport) |
GCExport is used to declare functions exported by GC. | |
#define | BITS_PER_BYTE 8 |
#define | NEXT_TO_HIGH_BIT_SET_MASK (1<<((sizeof(unsigned) * BITS_PER_BYTE)-2)) |
#define | NEXT_TO_HIGH_BIT_CLEAR_MASK ~NEXT_TO_HIGH_BIT_SET_MASK |
Functions | |
unsigned int | gc_time_since_last_gc () |
API for the VM to get the time since the last GC happened. | |
void * | gc_heap_base_address () |
| |
void * | gc_heap_ceiling_address () |
| |
Routines to support the initialization and termination of GC | |
int | gc_init () |
Is called by VM to start GC initialization sequence. | |
void | gc_test_safepoint () |
May be called at various points the VM decides are GC-safe. | |
Boolean | gc_supports_frontier_allocation (unsigned *offset_of_current, unsigned *offset_of_limit) |
If the GC supports a "bump-the-pointer" style allocation, where the GC's thread-local information contains a "current" pointer and a "limit" pointer, then it should return TRUE , and it should set *offset_of_current to be the offset into the GC thread block of the "current" pointer, and similar for *offset_of_limit and the "limit" pointer. | |
void | gc_vm_initialized () |
This API is used by the VM to notify the GC that the VM has completed bootstrapping and initialization, and is henceforth ready to field requests for enumerating live references. | |
void | gc_wrapup () |
This is called once the VM has no use for the heap or the garbage collector data structures. | |
void | gc_add_root_set_entry (Managed_Object_Handle *ref, Boolean is_pinned) |
Is called by the VM to enumerate the root reference. | |
void | gc_add_compressed_root_set_entry (uint32 *ref, Boolean is_pinned) |
Resembles gc_add_root_set_entry() but is passed the address of a slot containing a compressed reference. | |
void | gc_add_weak_root_set_entry (Managed_Object_Handle *slot, Boolean is_pinned, Boolean is_short_weak) |
Is called by the VM to enumerate weak root reference. | |
void | gc_add_root_set_entry_managed_pointer (void **slot, Boolean is_pinned) |
Enumerate a managed pointer. | |
void | gc_add_root_set_entry_interior_pointer (void **slot, int offset, Boolean is_pinned) |
Call from the VM to the gc to enumerate an interior pointer. | |
Managed_Object_Handle | gc_alloc_fast (unsigned size, Allocation_Handle type, void *thread_pointer) |
This routine is the primary routine used to allocate objects. | |
Managed_Object_Handle | gc_alloc (unsigned size, Allocation_Handle type, void *thread_pointer) |
This routine is used to allocate an object. | |
Managed_Object_Handle | gc_pinned_malloc_noclass (unsigned size) |
For bootstrapping situations, when we still don't have a class for the object. | |
Managed_Object_Handle | gc_alloc_pinned (unsigned size, Allocation_Handle type, void *thread_pointer) |
Allocate pinned forever object. | |
Routines to support write barriers | |
Boolean | gc_requires_barriers () |
| |
Routines to support various write barriers | |
Boolean | gc_supports_compressed_references () |
| |
void | gc_write_barrier (Managed_Object_Handle p_base_of_obj_with_slot) |
These interfaces are marked for replacement for the IPF by the following gc_heap_write_mumble interface. | |
void | gc_heap_wrote_object (Managed_Object_Handle p_base_of_object_just_written) |
There are two flavors for historical reasons. | |
void | gc_heap_write_global_slot (Managed_Object_Handle *p_slot, Managed_Object_Handle value) |
By calling this function VM notifies GC that a heap reference was written to global slot. | |
void | gc_heap_write_global_slot_compressed (uint32 *p_slot, Managed_Object_Handle value) |
VM should call this function on heap reference writes to global slots. | |
void | gc_heap_write_ref (Managed_Object_Handle p_base_of_object_with_slot, unsigned offset, Managed_Object_Handle value) |
VM should call this function on heap reference writes to heap objects. | |
void | gc_heap_slot_write_ref (Managed_Object_Handle p_base_of_object_with_slot, Managed_Object_Handle *p_slot, Managed_Object_Handle value) |
VM should call this function on heap reference writes to heap objects. | |
void | gc_heap_slot_write_ref_compressed (Managed_Object_Handle p_base_of_object_with_slot, uint32 *p_slot, Managed_Object_Handle value) |
VM should call this function on heap reference writes to heap objects. | |
void | gc_pin_object (Managed_Object_Handle *p_object) |
Pin object. | |
void | gc_unpin_object (Managed_Object_Handle *p_object) |
Unpin object. | |
int32 | gc_get_hashcode (Managed_Object_Handle object) |
Get identity hashcode. | |
Managed_Object_Handle | gc_get_next_live_object (void *iterator) |
Iterate all live objects in heap. | |
void | gc_iterate_heap () |
Iterates all objects in the heap. | |
void | gc_finalize_on_exit () |
Moves all finalizable objects to vm finalization queue. | |
void | gc_set_mutator_block_flag () |
Sets the mutator need block flag in case of heavy finalizable object load. | |
Boolean | gc_clear_mutator_block_flag () |
Clears the mutator need block flag when heavy finalizable object load lightens. | |
Boolean | gc_supports_class_unloading () |
| |
Routines to support soft, weak, and phantom reference objects | |
void JNICALL | Java_java_lang_ref_Reference_enqueue_reference (JNIEnv *the_env, jobject p_obj) |
reference - the reference object to register. | |
jobject JNICALL | Java_java_lang_ref_Reference_get (JNIEnv *the_env, jobject p_obj) |
reference - the reference object to register. | |
void JNICALL | Java_java_lang_ref_Reference_register_phantom_ref (JNIEnv *the_env, jobject p_obj, jobject referent) |
reference - the reference object to register. | |
void JNICALL | Java_java_lang_ref_Reference_register_soft_ref (JNIEnv *the_env, jobject p_obj, jobject referent) |
reference - the reference object to register. | |
void JNICALL | Java_java_lang_ref_Reference_register_weak_ref (JNIEnv *the_env, jobject p_obj, jobject referent) |
reference - the reference object to register. |
#define GCExport __declspec(dllexport) |
GCExport
is used to declare functions exported by GC.
#define BITS_PER_BYTE 8 |
#define NEXT_TO_HIGH_BIT_SET_MASK (1<<((sizeof(unsigned) * BITS_PER_BYTE)-2)) |
#define NEXT_TO_HIGH_BIT_CLEAR_MASK ~NEXT_TO_HIGH_BIT_SET_MASK |
#define GC_OBJECT_ALIGNMENT 4 |
Granularity of object alignment.
Objects are aligned on 4 or 8 bytes. If they are aligned on 8 bytes then Arrays will be required to start on the indicated alignement. This means that for 8 byte alignment on the IA32 the header will look like this:
uint32 gc_header_lock_hash VTable *vt uint32 array_length uint32 padding the array elements.
typedef void* Thread_Handle |
Opaque handle for threads.
int gc_init | ( | ) |
void gc_test_safepoint | ( | ) |
Boolean gc_supports_frontier_allocation | ( | unsigned * | offset_of_current, | |
unsigned * | offset_of_limit | |||
) |
If the GC supports a "bump-the-pointer" style allocation, where the GC's thread-local information contains a "current" pointer and a "limit" pointer, then it should return TRUE
, and it should set *offset_of_current
to be the offset into the GC thread block of the "current" pointer, and similar for *offset_of_limit
and the "limit" pointer.
If not, then it should return FALSE
.
void gc_vm_initialized | ( | ) |
This API is used by the VM to notify the GC that the VM has completed bootstrapping and initialization, and is henceforth ready to field requests for enumerating live references.
Prior to this function being called the GC might see some strange sights such as NULL
or incomplete vtables. The GC will need to consider these as normal and work with the VM to ensure that bootstrapping works. This means that the GC will make few demands on the VM prior to this routine being called.
However, once called the GC will feel free to do stop-the-world collections and will assume that the entire gc_import.h
interface is available and fully functioning.
If this routine is called twice the result is undefined.
void gc_wrapup | ( | ) |
This is called once the VM has no use for the heap or the garbage collector data structures.
The assumption is that the VM is exiting but needs to give the GC time to run destructors and free up memory it has gotten from the OS. After this routine has been called the VM can not relie on any data structures created by the GC.
Errors: If gc_enumerate_finalizable_objects
has been called and gc_wrapup
gc discovers an object that has not had it finalizer run then it will attempt to report an error.
void gc_add_root_set_entry | ( | Managed_Object_Handle * | ref, | |
Boolean | is_pinned | |||
) |
Is called by the VM to enumerate the root reference.
void gc_add_compressed_root_set_entry | ( | uint32 * | ref, | |
Boolean | is_pinned | |||
) |
Resembles gc_add_root_set_entry()
but is passed the address of a slot containing a compressed reference.
void gc_add_weak_root_set_entry | ( | Managed_Object_Handle * | slot, | |
Boolean | is_pinned, | |||
Boolean | is_short_weak | |||
) |
Is called by the VM to enumerate weak root reference.
slot | - a pointer to the slot, containing the weak root | |
is_pinned | - TRUE denotes that object pointed-to from this slot should not be moved during garbage collection | |
is_short_weak | - TRUE means that the weak root must be cleared before object becomes eligible for finalization |
void gc_add_root_set_entry_managed_pointer | ( | void ** | slot, | |
Boolean | is_pinned | |||
) |
Enumerate a managed pointer.
The pointer can be declared as pinned. The pointer can point to the managed heap or any other area where data can be stored: stack or static fields. It is the responsibility of the GC to ignore pointers that are not in the managed heap.
void gc_add_root_set_entry_interior_pointer | ( | void ** | slot, | |
int | offset, | |||
Boolean | is_pinned | |||
) |
Call from the VM to the gc to enumerate an interior pointer.
**ref
is a slot holding a pointer into the interior of an object. The base of the object is located at *ref
- offset. The strategy employed is to place the slot, the object base and the offset into a slot_base_offset
table. We then call gc_add_root_set_entry
with the slot in the table holding the base of the object. Upon completion of the garbage collection the routine fixup_interior_pointers
is called and the slot_base_offset
table is traversed and the new interior pointer is calculated by adding the base of the object and the offset. This new interior pointer value is then placed into the slot.
This routine can be called multiple times with the same interiour pointer without any problems. The offset is checked to make sure it is positive but the logic is not dependent on this fact.
Managed_Object_Handle gc_alloc_fast | ( | unsigned | size, | |
Allocation_Handle | type, | |||
void * | thread_pointer | |||
) |
This routine is the primary routine used to allocate objects.
It assumes nothing about the state of the VM internal data structures or the runtime stack. If gc_malloc_or_null is able to allocate the object without invoking a GC or calling the VM then it does so. It places p_vtable into the object, ensures that the object is zeroed and then returns a ManagedObject pointer to the object. If it is not able to allocate the object without invoking a GC then it returns NULL.
size | - the size of the object to allocate. If the high bit set then various constraints as described above are placed on the allocation of this object. | |
type | - a pointer to the vtable of the class being allocated. This routine will place this value in the appropriate slot of the new object. | |
thread_pointer | - a pointer to the GC's thread-local space |
gc_malloc_or_null
, except that it passes a pointer to the thread's GC-specific space as a third argument. This prevents the GC from having to immediately call vm_get_thread_curr_alloc_block()
as its first task.
gc_malloc_with_thread_pointer()
. Managed_Object_Handle gc_alloc | ( | unsigned | size, | |
Allocation_Handle | type, | |||
void * | thread_pointer | |||
) |
This routine is used to allocate an object.
See the above discussion on the overloading of size. {link allocation}
size | - the size of the object to allocate. If the high bit set then various constraints as described above are placed on the allocation of this object. | |
type | - a pointer to the vtable of the class being allocated. This routine will place this value in the appropriate slot of the new object. | |
thread_pointer | - a pointer to the GC's thread-local space |
gc_malloc_or_null_with_thread_pointer()
. Managed_Object_Handle gc_pinned_malloc_noclass | ( | unsigned | size | ) |
For bootstrapping situations, when we still don't have a class for the object.
This routine is only available prior to a call to the call gc_vm_initialized
. If it is called after the call to
gc_vm_initialized
then the results are undefined. The GC places NULL
in the vtable slot of the newly allocated object.
The object allocated will be pinned, not finalizable and not an array.
size - the size of the object to allocate. The high bit will never be set on this argument. gc_alloc_pinned_noclass()
to comply with accepted naming conventions.
Managed_Object_Handle gc_alloc_pinned | ( | unsigned | size, | |
Allocation_Handle | type, | |||
void * | thread_pointer | |||
) |
Allocate pinned forever object.
Boolean gc_requires_barriers | ( | ) |
void gc_thread_init | ( | void * | gc_information | ) |
This routine is called during thread startup to set an initial nursery for the thread.
gc_thread_init
and gc_thread_kill
assume that the current thread is the one we are interested in. If we passed in the thread then these things could be cross inited and cross killed. void gc_thread_kill | ( | void * | gc_information | ) |
This is called just before the thread is reclaimed.
VMEXPORT void vm_iterate_threads | ( | ) |
GC may call this function asynchronously any time it wants to get thread list.
This function signals VM to obtain thread lock and start thread iteration.
gc_iterate_thread(thread)
void gc_iterate_thread | ( | Thread_Handle | thread | ) |
VM calls this method repeatedly to iterate over the list of java threads, initiated earlier by calling vm_iterate_threads()
.
Thread creation and termination is locked during this iteration.
gc may do one of the following: 1. store thread handle for later use 2. enumerate thread right now, while holding thread lock (using vm_suspend_thread(thread)
and vm_enumerate_thread_root_set(thread)
).
VMEXPORT void vm_suspend_thread | ( | Thread_Handle | thread | ) |
GC calls this method to request VM to suspend an individual thread.
After the thread is suspended, 0 is returned on success
Thread may have been terminated already, in this case non-zero value is returned, and no additional actions are taken.
GC calls this VM function when it wants a thread to be suspended for stack enumeration or read/write barrier change.
blocks until synchronously call gc_thread_suspended(thread)
or asynchronously delegate enumeration to thread (self-enumeration)
Not implemented.
void gc_thread_suspended | ( | Thread_Handle | thread | ) |
VM calls this GC callback when it's accomplished the requested operation of suspending a thread in gc-safe point.
May be called synchronously from the same context as vm_suspend_thread()
in case of cross-enumeration, or may be called asynchronously from the specified thread context in case of self-enumeration.
After this function completes, the thread is resumed automatically.
GC is expected to call a limited subset of GC-VM interface functions from this callback:
vm_enumerate_thread_root_set(thread)
vm_install_write_barrier(...)
(hypothetical, not designed yet) VMEXPORT void vm_enumerate_thread_root_set | ( | Thread_Handle | thread | ) |
GC calls this function to command VM to enumerate a thread, which was earlier suspenden using vm_suspend_thread()
.
In response to this call, VM repeatedly calls gc_add_root_set_entry()
to enumerate thread stacks and local handles
VMEXPORT void vm_enumerate_global_root_set | ( | ) |
GC calls this function to command VM to enumerate global slots.
During enumeration of global root set, either all threads need to be suspended, or write barrier installed.
Apparently some operations should be blocked in VM, like class loading, which itself creates new global reference slots. It is not clear to me if we should require stopping the world to use this function or introduce new system-wide lock on operations that change the number of global reference slots.
This function calls gc_add_root_set_entry()
for all global reference slots.
void gc_force_gc | ( | ) |
API for the VM to force a GC, typically in response to a call to java.lang.Runtime.gc
.
int64 gc_total_memory | ( | ) |
API for the VM to determine the current GC heap size, typically in response to a call to java.lang.Runtime.totalMemory
.
int64 gc_max_memory | ( | ) |
API for the VM to determine the maximum GC heap size, typically in response to a call to java.lang.Runtime.maxMemory
.
int64 gc_free_memory | ( | ) |
API for the VM to get an approximate view of the free space, typically in response to a call to java.lang.Runtime.freeMemory
.
Boolean gc_is_object_pinned | ( | Managed_Object_Handle | obj | ) |
TRUE
if the object is pinned. Routine to support the functionality required by JNI to see if an object is pinned.
void gc_class_prepared | ( | Class_Handle | ch, | |
VTable_Handle | vth | |||
) |
The VM calls this function after a new class has been prepared.
The GC can use a call interface to gather relevant information about that class and store it in area of the VTable that is reserved for GC. The information cached in the VTable should be used by the GC in performance sensitive functions like object scanning.
int64 gc_get_collection_count | ( | ) |
The number of collections that have been executed by this collector. A value of -1
means that collection counts are undefined for this collector.
int64 gc_get_collection_time | ( | ) |
The approximate, cumulative time (in microseconds) spent executing collections for this collector.
Boolean gc_supports_compressed_references | ( | ) |
TRUE
if references within objects and vector elements are to be treated as offsets rather than raw pointers.
void gc_write_barrier | ( | Managed_Object_Handle | p_base_of_obj_with_slot | ) |
These interfaces are marked for replacement for the IPF by the following gc_heap_write_mumble
interface.
void gc_heap_wrote_object | ( | Managed_Object_Handle | p_base_of_object_just_written | ) |
There are two flavors for historical reasons.
The compiler for IA32 will produce code for the version using an offset.
void gc_heap_write_global_slot | ( | Managed_Object_Handle * | p_slot, | |
Managed_Object_Handle | value | |||
) |
By calling this function VM notifies GC that a heap reference was written to global slot.
There are some global slots that are shared by different threads. Write barriers implementation needs to know about writes to these slots. One example of such slots is in the string pools used by the class loader.
void gc_heap_write_global_slot_compressed | ( | uint32 * | p_slot, | |
Managed_Object_Handle | value | |||
) |
VM should call this function on heap reference writes to global slots.
The "compressed" versions of the functions support updates to slots containing compressed references that are heap offsets; these functions handle details of converting raw reference pointers to compressed references before updating slots.
void gc_heap_write_ref | ( | Managed_Object_Handle | p_base_of_object_with_slot, | |
unsigned | offset, | |||
Managed_Object_Handle | value | |||
) |
VM should call this function on heap reference writes to heap objects.
void gc_heap_slot_write_ref | ( | Managed_Object_Handle | p_base_of_object_with_slot, | |
Managed_Object_Handle * | p_slot, | |||
Managed_Object_Handle | value | |||
) |
VM should call this function on heap reference writes to heap objects.
void gc_heap_slot_write_ref_compressed | ( | Managed_Object_Handle | p_base_of_object_with_slot, | |
uint32 * | p_slot, | |||
Managed_Object_Handle | value | |||
) |
VM should call this function on heap reference writes to heap objects.
void gc_pin_object | ( | Managed_Object_Handle * | p_object | ) |
Pin object.
void gc_unpin_object | ( | Managed_Object_Handle * | p_object | ) |
Unpin object.
int32 gc_get_hashcode | ( | Managed_Object_Handle | object | ) |
Get identity hashcode.
Managed_Object_Handle gc_get_next_live_object | ( | void * | iterator | ) |
Iterate all live objects in heap.
Should be use only in classloader for class unloading purposes.
void gc_iterate_heap | ( | ) |
Iterates all objects in the heap.
This function calls vm_iterate_object()
for each iterated object. Used for JVMTI Heap Iteration. Should be called only in stop-the-world setting
vm_gc.h.vm_iterate_object()
void gc_finalize_on_exit | ( | ) |
Moves all finalizable objects to vm finalization queue.
void gc_set_mutator_block_flag | ( | ) |
Sets the mutator need block flag in case of heavy finalizable object load.
Boolean gc_clear_mutator_block_flag | ( | ) |
Clears the mutator need block flag when heavy finalizable object load lightens.
Boolean gc_supports_class_unloading | ( | ) |
TRUE
if references within objects and vector elements are to be treated as offsets rather than raw pointers.
void JNICALL Java_java_lang_ref_Reference_enqueue_reference | ( | JNIEnv * | the_env, | |
jobject | p_obj | |||
) |
reference - the reference object to register.
referent - the referent of the reference object that is to be retrieved with the get method.
The weak reference code written in Java and the support code provide by the VM must agree on what the layout of a Java.lang.ref.Reference
object looks like and agree that any subclassing will only append fields to the agreed upon layout. This seems reasonable.
In addition the support code will have exclusive knowledge and control of a single field (called the_referent
) which holds the reference to the target object. The java code will assume that this field is a read only integer and should not be traced by the gc. The Java.lang.ref.ReferenceQueue
layout needs to also be known by the supporting code so that it can move reference objects onto the queues at the appropriate times. The Java code uses normal mechanisms to load the Reference classes and to create a reference.
The constructor code however needs to call the appropriate register function listed below based upon whether we have a soft, weak, or phantom reference. The VM support code will fill in the referent field. The routine gc_get_referent
will return the value in this field.
gc_get_referent
but instead just return NULL
as required by the spec.XXX Why are they in gc_export.h? -salikh
jobject JNICALL Java_java_lang_ref_Reference_get | ( | JNIEnv * | the_env, | |
jobject | p_obj | |||
) |
reference - the reference object to register.
referent - the referent of the reference object that is to be retrieved with the get method.
The weak reference code written in Java and the support code provide by the VM must agree on what the layout of a Java.lang.ref.Reference
object looks like and agree that any subclassing will only append fields to the agreed upon layout. This seems reasonable.
In addition the support code will have exclusive knowledge and control of a single field (called the_referent
) which holds the reference to the target object. The java code will assume that this field is a read only integer and should not be traced by the gc. The Java.lang.ref.ReferenceQueue
layout needs to also be known by the supporting code so that it can move reference objects onto the queues at the appropriate times. The Java code uses normal mechanisms to load the Reference classes and to create a reference.
The constructor code however needs to call the appropriate register function listed below based upon whether we have a soft, weak, or phantom reference. The VM support code will fill in the referent field. The routine gc_get_referent
will return the value in this field.
gc_get_referent
but instead just return NULL
as required by the spec.XXX Why are they in gc_export.h? -salikh
void JNICALL Java_java_lang_ref_Reference_register_phantom_ref | ( | JNIEnv * | the_env, | |
jobject | p_obj, | |||
jobject | referent | |||
) |
reference - the reference object to register.
referent - the referent of the reference object that is to be retrieved with the get method.
The weak reference code written in Java and the support code provide by the VM must agree on what the layout of a Java.lang.ref.Reference
object looks like and agree that any subclassing will only append fields to the agreed upon layout. This seems reasonable.
In addition the support code will have exclusive knowledge and control of a single field (called the_referent
) which holds the reference to the target object. The java code will assume that this field is a read only integer and should not be traced by the gc. The Java.lang.ref.ReferenceQueue
layout needs to also be known by the supporting code so that it can move reference objects onto the queues at the appropriate times. The Java code uses normal mechanisms to load the Reference classes and to create a reference.
The constructor code however needs to call the appropriate register function listed below based upon whether we have a soft, weak, or phantom reference. The VM support code will fill in the referent field. The routine gc_get_referent
will return the value in this field.
gc_get_referent
but instead just return NULL
as required by the spec.XXX Why are they in gc_export.h? -salikh
void JNICALL Java_java_lang_ref_Reference_register_soft_ref | ( | JNIEnv * | the_env, | |
jobject | p_obj, | |||
jobject | referent | |||
) |
reference - the reference object to register.
referent - the referent of the reference object that is to be retrieved with the get method.
The weak reference code written in Java and the support code provide by the VM must agree on what the layout of a Java.lang.ref.Reference
object looks like and agree that any subclassing will only append fields to the agreed upon layout. This seems reasonable.
In addition the support code will have exclusive knowledge and control of a single field (called the_referent
) which holds the reference to the target object. The java code will assume that this field is a read only integer and should not be traced by the gc. The Java.lang.ref.ReferenceQueue
layout needs to also be known by the supporting code so that it can move reference objects onto the queues at the appropriate times. The Java code uses normal mechanisms to load the Reference classes and to create a reference.
The constructor code however needs to call the appropriate register function listed below based upon whether we have a soft, weak, or phantom reference. The VM support code will fill in the referent field. The routine gc_get_referent
will return the value in this field.
gc_get_referent
but instead just return NULL
as required by the spec.XXX Why are they in gc_export.h? -salikh
void JNICALL Java_java_lang_ref_Reference_register_weak_ref | ( | JNIEnv * | the_env, | |
jobject | p_obj, | |||
jobject | referent | |||
) |
reference - the reference object to register.
referent - the referent of the reference object that is to be retrieved with the get method.
The weak reference code written in Java and the support code provide by the VM must agree on what the layout of a Java.lang.ref.Reference
object looks like and agree that any subclassing will only append fields to the agreed upon layout. This seems reasonable.
In addition the support code will have exclusive knowledge and control of a single field (called the_referent
) which holds the reference to the target object. The java code will assume that this field is a read only integer and should not be traced by the gc. The Java.lang.ref.ReferenceQueue
layout needs to also be known by the supporting code so that it can move reference objects onto the queues at the appropriate times. The Java code uses normal mechanisms to load the Reference classes and to create a reference.
The constructor code however needs to call the appropriate register function listed below based upon whether we have a soft, weak, or phantom reference. The VM support code will fill in the referent field. The routine gc_get_referent
will return the value in this field.
gc_get_referent
but instead just return NULL
as required by the spec.XXX Why are they in gc_export.h? -salikh
unsigned int gc_time_since_last_gc | ( | ) |
void* gc_heap_base_address | ( | ) |
API for VM to determine the starting and ending adddresses of the heap.
void* gc_heap_ceiling_address | ( | ) |
Genereated on Tue Mar 11 19:25:34 2008 by Doxygen.
(c) Copyright 2005, 2008 The Apache Software Foundation or its licensors, as applicable.