Re: [rvm-research] Questions about Jikes GC

Hi Javier,

On 12/28/2016 11:31 AM, Javier Pimás wrote:
> Hi! I'm new to the list, I just have some general questions about how 
> GC is done in Jikes, with a specific focus in dynamicity:

Welcome!

> 1. How are VM objects organized in the heaps in memory? Classes, 
> VTables, Methods, Native code, Compiler objects, and GC objects, do 
> they live in separate heaps or with application objects?

All of those objects (i.e., all application and VM objects) live in the 
same heap. However, MMTk divides the heap into different spaces. 
Application and VM objects can live in the same space (e.g., the nursery 
and the default old space), but some special VM objects get allocated 
into immortal or non-moving spaces (see below).

> 2. Do those objects move when GC passes? I guess Compiler objects do 
> as they are created and destroyed dynamically. But Classes, TIBs, etc 
> maybe don't move? Are they fixed or new ones can be loaded dynamically?

Most VM-allocated objects can move during GC. Certain objects such as 
TIBs are allocated in a non-moving space (e.g., an immortal or 
mark-sweep space), to avoid having to update all pointers to them during GC.

> 3. Are TIBs, and classes referenced from object headers normal 
> objects? or maybe there is a duplicate representation of classes and 
> metaobjects?

I think just about everything is a regular object. I think a TIB might 
be represented as an array of primitives, even though some of its slots 
are references, but I'm not sure about that. A method's compiled machine 
code is an array of bytes, even though it's actually executable code.

> 4. What happens if the GC has to move a class or other metaobject, is 
> there any restriction in GC code? For example, consider placing a 
> forwarding address in a class object as it is being moved in a copying 
> collector. That would render the class unusable for a while, is that 
> possible in Jikes GC? does it happen?

Certain VM-allocated objects are automatically allocated into non-moving 
spaces (see #2). Note that many of these objects are VM code and class 
metadata, which gets added to the boot image when building the boot 
image, which is a non-moving space. For other types of objects that 
shouldn't move when MMTK / Jikes RVM code executes, GC pre-copies them, 
i.e., copies them before doing the full transitive closure that might 
use more of MMTk / Jikes RVM.

Cheers,
Mike

>
> Well, those are my initial questions :P, thanks for reading.
>
> Cheers,
> Javier
>
> -- 
> Javier Pimás
> Ciudad de Buenos Aires
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers