Question regarding JVM crashes in GC

[Stefan Johansson]

On 2017-04-06 13:42, Michael Rasmussen wrote:
> On 6 April 2017 at 12:58, Stefan Johansson <stefan.johansson at oracle.com> wrote:
>> Interesting, the GC (or rather reference processing) actually do have some
>> assumptions when it comes to the fields in reference objects. We expect the
>> referent, discovered and next fields to be at certain offsets. You mentioned
>> earlier that such assumptions might be problematic, are you doing any kind
>> of instrumentation that could change those offsets?
> Generally, we are doing instrumentation that add fields to classes, so
> can change those offsets, but it doesn't seem to affect the Reference
> classes.
> I ran some tests with and without JRebel, printing out the results of
> unsafe::objectFieldOffset and unsafe::staticFieldOffset for all
> declared fields on PhantomReference, WeakReference, SoftReference and
> Reference. The offsets were identical. So assuming those unsafe
> methods return the equivalent of what's used internally, then we don't
> modify the offset.
Sounds good, but still suspicious since we seem to be crashing on 
references.
> We are using a JVMTI agent for instrumenting the early classes
> (classes loaded before premain is called), I'm currently trying to
> investigate if this is causing some side effects, since when doing the
> equivalent using --patch-module, I cannot reproduce it with a simple
> main() { System.gc(); } test class.
One thing that is a bit strange is that you don't reproduce this with 
SerialGC, G1 and Serial currently share a lot of the Full GC code, but 
there is a optimization only used for serial that skips objects in the 
beginning of the heap, could you try running with -XX:+UseSerialGC 
-XX:MarkSweepDeadRatio=0 -XX:MarkSweepAlwaysCompactCount=1 and see if 
you run into the same issues with Serial as the other collectors?

Thanks,
Stefan
>
> /Michael