Re: Add custom field to Object type definition

[Joel Dice]

On Fri, 17 May 2013, benjamin...@gmail.com wrote:

> I wish to add a 64 bit integer field to Avian's Object type definition. The
> aim is to use it as a tag associated to a Java object. Which file I have to
> create/modify ?

I'm afraid there's no easy way to do that. There's a lot of code in the
VM that assumes Object has no fields, and that would all have to change if
you added one.

What is the purpose of the tag you want to add? Perhaps you could use a
WeakHashMap to associate tags with objects instead.

[Joel Dice]

On Tue, 21 May 2013, benjamin...@gmail.com wrote:

> I'm currently designing a security model for Java virtual machines (I'll
> make a short presentation about it during ISORC 2013). My first
> implementation relies on JVMTI and works as expected. But JVMTI were not
> designed to such kind of use and thus it have poor performances.
>
> A specifically instrumented JVM will surely solve this limitation (seehttps://www.usenix.org/conference/esos13/mandatory-access-control-android-d
> alvik-virtual-machine).
>
> What I need is a way to set a security identifier (basically a 64 bit
> unsigned integer) on java classes, objects and methods (for performance
> reasons). Avian's source code looks easier to patch than OpenJDK or VMKit.

Does this help?
https://github.com/dicej/avian/commit/3a69f42e1ccf627f3710bb8157e8806bad61d4f8

[Simon Ochsenreither]

Does this help?
https://github.com/dicej/avian/commit/3a69f42e1ccf627f3710bb8157e8806bad61d4f8

It looks like this could also be useful when playing with alternative garbage collector implementations (e. g. ones that require bits for marking).

[Joel Dice]

On Fri, 24 May 2013, Simon Ochsenreither wrote:

>
> Does this help?
> https://github.com/dicej/avian/commit/3a69f42e1ccf627f3710bb8157e8806bad61d

> 4f8
>
>
> It looks like this could also be useful when playing with alternative
> garbage collector implementations (e. g. ones that require bits for
> marking).

Perhaps, but if you only need a few extra bits per object, there may be
more memory-efficient ways to track them than adding a whole extra word to
each instance. If you separate the bitsets from the objects themselves,
you can store those bitsets much more compactly. For example, if objects
are allocated on 64KB pages and you need 2 bits per object for GC marking,
you only need 2KB per page to store the bitsets, which is about 3%
overhead, whereas if your average object size is 3 words, you end up with
a 33% overhead when you add another word to each of them.

[Simon Ochsenreither]

Perhaps, but if you only need a few extra bits per object, there may be
more memory-efficient ways to track them than adding a whole extra word to
each instance.  If you separate the bitsets from the objects themselves,
you can store those bitsets much more compactly.  For example, if objects
are allocated on 64KB pages and you need 2 bits per object for GC marking,
you only need 2KB per page to store the bitsets, which is about 3%
overhead, whereas if your average object size is 3 words, you end up with
a 33% overhead when you add another word to each of them.

Agree, although if only a few bits were necessary, it would also be possible to steal those bits from the class pointer (similar to Oracles compressed OOPS). Might be an interesting benchmark: it would add a shift operation to every access of the class pointer but would probably be more cache efficient than having a separate mark region.

I really wish that there existed some garbage-collection FAQ on the internet, where one could look up all these “I have idea X, does it make sense”-questions and get answers why it works/doesn't work. :-)

[Joel Dice]

On Fri, 24 May 2013, Simon Ochsenreither wrote:

>

> Perhaps, but if you only need a few extra bits per object, there
> may be
> more memory-efficient ways to track them than adding a whole
> extra word to

> each instance. �If you separate the bitsets from the objects
> themselves,
> you can store those bitsets much more compactly. �For example,

> if objects
> are allocated on 64KB pages and you need 2 bits per object for
> GC marking,
> you only need 2KB per page to store the bitsets, which is about
> 3%
> overhead, whereas if your average object size is 3 words, you
> end up with
> a 33% overhead when you add another word to each of them.
>
>
> Agree, although if only a few bits were necessary, it would also be possible
> to steal those bits from the class pointer (similar to Oracles compressed
> OOPS). Might be an interesting benchmark: it would add a shift operation to
> every access of the class pointer but would probably be more cache efficient
> than having a separate mark region.

We already do that, actually. We use one bit to determine whether or not
the object is copyable and another to determine whether its identity hash
code has been calculated (which is based on its address, so we need to
remember the original address if it is moved elsewhere in memory). That's
something I'd like to get away from, though, because it means we have to
mask the class pointer every time we want to follow it, including every
virtual method call. I don't know how much that impacts performance in
practice, but it certainly makes the code more complicated and ugly.

[Simon Ochsenreither]

Hi Joel,

We already do that, actually.  We use one bit to determine whether or not
the object is copyable and another to determine whether its identity hash
code has been calculated (which is based on its address, so we need to
remember the original address if it is moved elsewhere in memory).

 

I stand corrected, I didn't know that!
 

That's
something I'd like to get away from, though, because it means we have to
mask the class pointer every time we want to follow it, including every
virtual method call.  I don't know how much that impacts performance in
practice, but it certainly makes the code more complicated and ugly.

I think compared to most options which often incur a cache line miss, masking or shifting is incredibly cheap.

Bye,

Simon