RFR: 8247879: Rework WeakHandle and OopHandle to dynamically support different OopStorages

Stefan Karlsson stefan.karlsson at oracle.com
Thu Jun 18 22:09:28 UTC 2020


Hi all,

Please review this patch to rework WeakHandle and OopHandle to 
dynamically support different OopStorages.

https://cr.openjdk.java.net/~stefank/8247879/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8247879

Today WeakHandle has a template parameter and specialization of 
get_storage() to get hold of the backing OopStorage. Coleen, ErikÖ and I 
talked about different ways to rewrite that, so that we wouldn't have to 
write specializations for all weak oop storages, and so that we don't 
have to carry around the type information about the weak oop storage.

Instead of writing:
WeakHandle<vm_weak_data> w = WeakHandle<vm_weak_data>::create(obj)

we could instead write:
WeakHandle w(OopStorageSet::vm_weak(), obj)

OopHandle is today hard-coded to use OopStorageSet::vm_global(). The 
proposal is to change OopHandle to look like WeakHandle, and allow more 
than one OopStorage. Something that might will become important going 
forward, when we are going to move more things into separate OopStorages.

So, instead of writing:
OopHandle h = OopHandle::create(obj)

one will have to specify the OopStorage explicitly:
OopHandle h(OopStorageSet::vm_global(), obj)

This change has a slight drawback that the OopStorage used for the 
allocation of the handle, needs to be provided when the handle is released.

To make this safer, so that you don't use strong OopStorages when 
allocating WeakHandles, or weak OopStorages when allocating OopHandles, 
I've created two subclasses to OopStorage: StrongOopStorage and 
WeakOopStorage. They are just two tiny wrappers around OopStorage, to 
allow us ensure correct usage during compile time. The oopStorageSet.hpp 
files seems to be intentionally written to *not* know about the 
OopStorage implementation. To do proper casting of the OopStorage*s I 
need to include the definition of StrongOopStorage and WeakOopStorage. 
I've therefore moved all OopStorageSet::<name_of_oop_storage>() getters 
out to an inline header. This adds a lot of new includes. If we don't 
think that it's important to inline these, then I can move it over to 
the cpp file instead.

Thanks,
StefanK



More information about the hotspot-dev mailing list