distinguishing object reference and primitive value when GC

[Sunghwan Ihm]

Hi,

I'm not sure where I have to put this kind of question, so please let
me know if it should belong to somewhere else.

My question is how GC can tell if the register value is a reference to
an object or some primitive (int, float, etc.) value. By seeing the
code in dalvik/vm/Thread.c:gcScanInterpStackReferences() at line 3158,

int i;
for (i = method->registersSize - 1; i >= 0; i--) {
u4 rval = *framePtr++;
//TODO: wrap markifobject in a macro that does pointer checks
if (rval != 0 && (rval & 0x3) == 0) {
dvmMarkIfObject((Object *)rval);
}
}

I guess it tries to check some page boundary and if the address really
belongs to the heap. But isn't it possible to have a false positive? I
understand for GC, it is okay to have a false positive, since the only
bad thing is we don't reclaim that object. I just want to make sure if
I understand it correctly. Possibly, because DVM is a little bit
different from a conventional JVM, is it possible to get the exact
information without any false positive?

Thanks,
Sunghwan

[fadden]

On Jul 17, 11:53 am, Sunghwan Ihm <sunghwan....@gmail.com> wrote:
> My question is how GC can tell if the register value is a reference to
> an object or some primitive (int, float, etc.) value.

In 1.5, it can't; the scan of the interpreted stack is
"conservative". It's possible to false-positive in various ways, the
most common being stale register data on the stack. (Method A calls
method B. B puts some references on the stack, and returns. A calls
method C. Before C can overwrite the previous contents, a GC starts.)

In a future release, Dalvik will have "type-precise" GC. For each
method there will be a "register map", essentially a bitmap that says
which registers hold references at any point in the method.
Unfortunately the register maps add about 9% to the size of the DEX
file, so we may not be able to support it on the G1 due to lack of
space on the internal flash filesystem.

[Chen Yang]

Hi fadden:
Would you like to share some performance related results from the precise GC? Thanks.
--
 Chen

[Sunghwan Ihm]

Thank you for the clarification, fadden. Could you please tell me a
little bit more about "type-precise" GC? My questions are:

1) how do you generate a "register map"? I assume "dx" runs some sort
of type inference algorithm on a .class file when generating a. dex
file, or is it a runtime analysis?

2) what's the rough time frame like? will it be included in donut release?

Thanks,
Sunghwan

[fadden]

On Jul 17, 11:31 pm, Chen Yang <sunsety...@gmail.com> wrote:
> Would you like to share some performance related results from the precise
> GC? Thanks.

No meaningful difference in execution time. You can avoid "is this an
object" tests, but you add "is the bit set in the register map". We
have run into a few cases where objects that should be collected but
weren't now are, so it does help in that respect.

Class verification got a little slower because of the additional work
required to generate and output the maps.

This was really more about enabling other GC changes, such as
compaction, that don't work as well if you have to pin everything you
find on the stack.

[fadden]

On Jul 20, 9:56 am, Sunghwan Ihm <sunghwan....@gmail.com> wrote:
> 1) how do you generate a "register map"? I assume "dx" runs some sort
> of type inference algorithm on a .class file when generating a. dex
> file, or is it a runtime analysis?

The bytecode verifier knows exactly what's in every register at every
point. This just adds an extra bit of work to retain a subset of what
the verifier knows.

It needs to be done on the device for the same reason that
verification needs to be done there: we can't trust that somebody
didn't send us a deliberately bad map in an attempt to make us crash.
(For Android it doesn't really matter, since we don't rely on the VM
for security, but we try to do the Right Thing(tm).)

> 2) what's the rough time frame like? will it be included in donut release?

I don't know which release it will be in (such things are subject to
change, blah blah blah).

[Sunghwan Ihm]

Thanks again. It seems that generating the register map is already in
the source code. (dalvik/vm/analysis/RegisterMap.c) I'll try them out.

--Sunghwan

[fadden]

On Jul 20, 11:39 am, Sunghwan Ihm <sunghwan....@gmail.com> wrote:
> Thanks again. It seems that generating the register map is already in
> the source code. (dalvik/vm/analysis/RegisterMap.c) I'll try them out.

Not really. Note in particular the "UNDER CONSTRUCTION" at the top of
RegisterMap.c. I don't think the working version is available
externally.

[Chen Yang]

Thanks fadden, it helps.
Is there some plan on the support of compaction soon?
--
 Chen

[fadden]

On Jul 21, 6:04 am, Chen Yang <sunsety...@gmail.com> wrote:
> Is there some plan on the support of compaction soon?

We do plan to support it in a future release. I can't be specific
about when.