Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.

This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.

Further, for enhanced error detection (any reference to such an object is an error) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.

With JDK-8210708 the prev bitmap will effectively be removed; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the information about whether there is a reference to any dead object/dead area with verification turned on.

This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.

This has the following benefits:

- keep this error detection (actually making it much simpler) and allowing similar verification for other collectors.

- this also makes it "easy" to detect such errors in debugging tools - you only need to know the two klasses to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.

This causes some minor changes to external behavior involved:

- logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of  j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway.

- if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM.

The change will take care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue.