From ef5ca4967ddcedd45400f8f5eeb882e5e46dd376 Mon Sep 17 00:00:00 2001 From: Richard Kistruck Date: Thu, 4 Jan 2007 16:33:03 +0000 Subject: [PATCH] Mps design/shield: minor text changes for clarity. Copied from Perforce Change: 161393 ServerID: perforce.ravenbrook.com --- mps/design/shield/index.html | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/mps/design/shield/index.html b/mps/design/shield/index.html index a065b611248..65c14cf65e8 100644 --- a/mps/design/shield/index.html +++ b/mps/design/shield/index.html @@ -77,13 +77,13 @@

On common OSs, the only way to allow collector access is to allow access from the whole process, including the mutator. So if the shield is asked to allow collector access but deny mutator access, it will halt all mutator threads to prevent any mutator access. The MPS Shield performs suspension and restart; normal collector code does not need to worry about it.

-

Collector code can make multiple sequential, overlapping, or nested calls to ShieldExpose on the same segment. (Each must be balanced by a ShieldCover before ShieldLeave is called). A usage count is maintained in seg->depth: a positive "depth" means a positive number of outstanding reasons why the segment must be exposed to the collector.

+

Collector code can make multiple sequential, overlapping, or nested calls to ShieldExpose on the same segment. (Each must be balanced by a ShieldCover before ShieldLeave is called). A usage count is maintained in seg->depth: a positive "depth" means a positive number of outstanding reasons why the segment must be exposed to the collector. When the usage count reaches zero, there is no longer any reason the segment should be unprotected, and the Shield could re-instate hardware protection.

-

When the usage count reaches zero, the Shield could re-instate hardware protection. However, as a performance-improving hysteresis, it defers this, maintaining a cache of the last 16 times a segment no longer had a reason to be collector-accessible. Presence in the cache counts as a 'reason': segments in the cache have seg->depth increased by one. As segments get pushed out of the cache, or at ShieldLeave, this artificial 'reason' is decremented from seg->depth, and (if depth is now zero) the deferred reinstatement of hardware protection happens.

+

However, as a performance-improving hysteresis, the Shield defers re-protection, maintaining a cache of the last 16 times a segment no longer had a reason to be collector-accessible. Presence in the cache counts as a 'reason': segments in the cache have seg->depth increased by one. As segments get pushed out of the cache, or at ShieldLeave, this artificial 'reason' is decremented from seg->depth, and (if depth is now zero) the deferred reinstatement of hardware protection happens.

So whenever hardware protection is temporarily removed to allow collector access, there is a 'nurse' that will ensure this protection is re-established: the nurse is either the balancing ShieldCover call in collector code, or an entry in the shield cache.

-

[Why is there a fixed-size cache? This is not the simple approach! All we need is a chain of segs that might need their hardware protection to be sync'd with their shield mode. Head in the shield, and one pointer in each seg struct. I guess we try hard to avoid bloating SegStruct. But is 16 the right size? A cache-miss wastes two kernel calls. RHSK 2006-12-19]

+

[Why is there a fixed-size cache? This is not the simple approach! All we need is a chain of segs that might need their hardware protection to be sync'd with their shield mode. Head in the shield, and one pointer in each seg struct. I guess we try hard to avoid bloating SegStruct (to maintain residency in the processor cache). But is 16 the right size? A cache-miss wastes two kernel calls. RHSK 2006-12-19]

[Also, I don't like the cache code. For example, why does ShieldFlush break out early if arena->shDepth is 0? This should never happen until the cache is completely flushed, ie. we have reached shCacheLimit. Why does ShieldFlush not reset shCacheLimit? Why does flush() silently accept NULL cache entries? RHSK 2006-12-19]

@@ -93,6 +93,8 @@

Initial Ideas

+

There never was an initial design document.

+

See this very helpful overview of protected tracing ∅. @@ -131,20 +133,16 @@

B. Document History

- - - - - - - -
2006-12-19RHSKCreated: Guide, plus links to initial ideas.
+
+  2006-12-19  RHSK  Created: Guide, plus links to initial ideas.
+  2007-01-04  RHSK  Minor text changes for clarity.
+

C. Copyright and License

-

This document is copyright © 2006 Ravenbrook Limited. All rights reserved. This is an open source license. Contact Ravenbrook for commercial licensing options.

+

This document is copyright © 2006-2007 Ravenbrook Limited. All rights reserved. This is an open source license. Contact Ravenbrook for commercial licensing options.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: