Object enumeration also returns the space name and the region

[qinsoon]

No description provided.

[qinsoon]

@wks This PR changes the type of the argument in the object enumeration closure from ObjectReference to an enum. Can you quickly look at the PR and let me know what you think?

An alternative is to keep the old interface/argument, and wrap the current code (so internally we use EnumeratedObject, but in the API, we only expose ObjectReference). In this case, if we want to know region/space, we need to start an enumeration from within MMTk core (not from bindings).

[wks]

I feel that there is no real difference between visit_block and visit_address_range except the former returns the address range each object is in. The notion of "block" is only meaningful if the user intends to inspect the heap with knowledge of the GC algorithm (i.e. the plan).

I think the public API enumerate_objects with the new EnumeratedObject is in an awkward position because

• For a user who is agnostic about the GC algorithm and only wants to enumerate objects, EnumeratedObject provides irrelevant (and perhaps confusing) details.
• For a user introspecting the heap for GC debugging, this interface seems too simple.

Users who debug GC may expect a richer interface than this. For example, if they know there is an Immix space, it would want an iterator that iterate blocks and, within blocks, it iterates lines. When they inspect a CopySpace, they may iterate through all blocks, too, because our BumpAllocator also allocates in blocks. For the native MallocSpace, users may inspect each size class. I even think the user may want to plot the block/line occupancy in a GUI like the GCSpy.

I think a better API looks like this:

{
    let inspector = mmtk.inspect_heap(); // Stops the world.
    let immix_inspector = inspector.space("immixspace").unwrap();

    // Some users only want some basic statistics.
    eprintln!("Space occupancy: {}", immix_inspector.used_pages() as f64 / immix_inspector.total_pages());

    for block in immix_inspector.blocks() {
        // Some users are only interested in blocks.
        eprintln!("Block {} - {}", block.start(), block.end());
        for object in block.objects() {
            eprintln!("object: {object}");
        }
    }
    for block in immix_inspector.blocks() {
        // Other users are interested in lines, too.
        for line in block.lines() {
            for object in line.objects() {
                  eprintln!(".....");
            }
        }
    }
} // re-starts the world.

The point is, if the user wants to know the details of a plan/space, we just expose those details explicitly. Here we let the user see space/block/line types and provide high-level explicit methods for introspecting and iterating over them.

I don't know whether this is too much for a public API. If we only want it for debug purposes, we can choose to enable it with a Cargo feature. But if we want the VM binding to implement GCSpy or Java Management Extension, we can expose it (or a subset of it) by default.