Isolating the GC code from the jvm to run on external accelerator
ofirg6 at gmail.com
Tue May 5 07:25:41 UTC 2020
Another question after reading the mark-compact based on the Epsilon GC
tutorial - I still don't understand how it gets from oop_iterate to
preorming the closure's do_oop_work method which actually does the marking..
I understand that if I want to implement a new GC i don't need to mind
that, but I'm trying to understand all the dependencies in the marking dlow
for the existing GCs, so I need to figure out how is the call to
do_oop_work is being made and where? what is the complete flow?
בתאריך יום ג׳, 5 במאי 2020 ב-9:39 מאת Ofir Gordon <ofirg6 at gmail.com
> Thanks a lot!
> I will read the documents you attached and look for the Epsilon GC.
> Regarding my other question, is it possible to do something like this? to
> take the gc into an external program that compiles and runs independently
> from the jvm?
> בתאריך יום ב׳, 4 במאי 2020 ב-15:48 מאת Aleksey Shipilev <
> shade at redhat.com>:
>> On 5/4/20 2:37 PM, Ofir Gordon wrote:
>> > If there any other advice how to use run the gc on an external hardware
>> > (than the one running the jvm) or if someone had expirience with such a
>> > task, I'll be glad to hear about it.
>> From the problem description, I would suggest to look at Epsilon to
>> understand where it is hooked
>> into runtime interface in allocation paths, and then this post  that
>> builds the trivial
>> mark-compact over it. I think it would then be evident how marking is
>> done, and how objects are
>> iterated with shared code . After that, understanding other collectors
>> would hopefully be simpler.
>>  https://shipilev.net/jvm/diy-gc/
>>  https://shipilev.net/jvm/diy-gc/#_marking
More information about the hotspot-gc-dev