How to pin/avoid gc for an oop?

[Jon V.]

My knowledge of the JVM is limited to the GC and memory allocation, but I
think I can be helpful.  You are correct, switching from InVM to InNative
to prevent the GC from running would be a bad idea if you plan on spending
a long time inside your atomic block.

I don't remember how Handles work.

OOPs are managed in a ptr table.  When you get a ptr to an OOP it is
actually a pointer to the ptr table.  Dereferencing it will get you the
actual OOP.  This is done that way to keep the references valid across GC
intervals when the actual object may be moved in memory.

I'm not aware of any way to create an OOP where you own the lifecycle.
Creating OOPs outside of the JVM lifecycle causes all sorts of errors when
the JVM tries to count references.

For the reasons above the undo log is going to be expensive in terms of
garbage creation.

The atomic scope heap undo log might be the only way to do it without
requiring extensive modifications to the JVM.

On Fri, Mar 10, 2017 at 3:56 AM, Christian <ch-hagedorn at hispeed.ch> wrote:

> Hi Jon,
>
> The STM is to be integrated into the JVM, but the transactional
> execution only affects modifications to the managed memory done by
> bytecode instructions. JVM internal structures are unaffected.
>
> Here an example:
>
> class X {
>    int f;
>
>    public static update(X x, int _new) {
>       atomic { // tx start
>          // (1) update field f of x:
>
>          // undo log maintains a reference to x and old value of f
>          // note: x contains a direct reference to the lock
>
>          x.f = _new;
>
>          // (2) assume GC is run
>          // Note: The atomic section can be large and blocking,
>          // thus, inhibiting a GC run is not an option.
>
>          // (3) End of the atomic section (tx end):
>          // 1. In case of abort: restore old value
>          // 2. Release lock (obtained via reference to x)
>       }
>    }
> }
>
> How can I assure that the reference to x in the undo log that I made at
> (1) remains valid at (3), even though a GC run may occur at (2)? I
> thought that Handles (share/vm/runtime/handles.hpp) may be an option,
> but I might have misunderstood what they are used for. I can of course
> make the undo log in the managed heap as well, but I hoped that this can
> be done directly in the JVM.
> Am 9. März 2017, um 21:12, "Jon V." <sybersnake at gmail.com> schrieb:
>>
>> Are you trying to build a transactional memory system for the JVM or your
>> own Java code?
>>
>> On Thu, Mar 9, 2017 at 2:33 PM Christian < ch-hagedorn at hispeed.ch>
>> wrote:
>>
>>> Hi Jon,
>>>
>>> I need this for an undo log of a transactional memory system with
>>> pessimistic locking/eager version management.
>>> Am 9. März 2017, um 19:00, "Jon V." < sybersnake at gmail.com> schrieb:
>>>
>>> Can you clarify what you mean by Undo and why you think this should be
>>> done at the VM level so we can better understand the request.
>>>
>>> If you don't want something to be garbage collected then simply don't
>>> dereference it.
>>>
>>> On Thu, Mar 9, 2017 at 12:38 PM Christian Hagedorn <
>>> ch-hagedorn at hispeed.ch> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I want to implement an undo functionality and thus need to access an oop
>>> even when it is out of scope in the Java code. How can I pin such an oop
>>> to
>>> avoid garbage collection of its used memory?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Christian
>>>
>>>