Fix warnings on MSVC

Removed unused variables

After materialization, we used to replace all appearances of the old cooked
oop with the new cooked oop along JVMState. This isn't correct if the
old cooked oop is alive in the map of an ancester.

When C2 encounters a real call, it needs to aggregate debug edges from
all ancestors. If we replace the old cook oop in materization before, we
may end up with a bad graph. The late control of the new cooked oop is
higher than its early control in dominator tree.

Co-authored-by: Xin Liu <xxinliu@amazon.com>

Cached prototype

* Introduce Deconstructor <: MemberPattern <: Executable

* Fix MemberPattern.setAccessible

* Retain signature of unreflectDeconstructor

Update bsd-port with changes to restore OpenBSD support and include changes from the jdku24-freebsd branch.

Implement reset_free_region_timestamps() method that resets ALL free region
timestamps after GC operations. This prevents time-based uncommit from
interfering with GC-based heap sizing decisions.

The problem: Regions that were already free before GC retain their old
timestamps. When time-based evaluation runs, these regions appear idle
even though GC just evaluated them, causing too many regions to be uncommitted.

The fix: After GC completes (both young and full), reset ALL free region
timestamps to give them a fresh baseline. This ensures time-based uncommit
only considers regions that became idle AFTER the most recent GC.

Addresses critical issue openjdk#9 and related issue openjdk#29 from Thomas review

Implement reset_free_region_timestamps() method that resets ALL free region
timestamps after GC operations. This prevents time-based uncommit from
interfering with GC-based heap sizing decisions.

The problem: Regions that were already free before GC retain their old
timestamps. When time-based evaluation runs, these regions appear idle
even though GC just evaluated them, causing too many regions to be uncommitted.

The fix: After GC completes (both young and full), reset ALL free region
timestamps to give them a fresh baseline. This ensures time-based uncommit
only considers regions that became idle AFTER the most recent GC.

Addresses critical issue openjdk#9 and related issue openjdk#29 from Thomas review

…penjdk#10, openjdk#12: comment updates and default-initialize _last_access_timestamp

…penjdk#10, openjdk#12: comment updates and default-initialize _last_access_timestamp