uniqueness of script ids and other questions

37 views
Skip to first unread message

Brian Slesinsky

unread,
Mar 13, 2017, 6:27:41 PM3/13/17
to Dart VM Observatory Discuss
To get a script you call getObject with an isolate id and a script id. I'm wondering if this implies that I should use (isolate id, script id) as a cache key to store a script? That is, is it possible for scripts in two different isolates (in the same VM) to have the same id?

Also, the docs [1] say that "fixed" ids can expire when the object is garbage collected, and the id might be reused. Is this the case for scripts? If so, how would I know when to invalidate the cache entry for a script?

(And by the way, the docs mention a "fixedId" property once but nowhere else. Where would "fixedId" appear? Is this still used?)

[1] https://github.com/dart-lang/sdk/blob/master/runtime/vm/service/service.md#ids-and-names

John Mccutchan

unread,
Mar 13, 2017, 6:37:15 PM3/13/17
to Brian Slesinsky, Dart VM Observatory Discuss
Hi Brian,

On Mon, Mar 13, 2017 at 3:22 PM, 'Brian Slesinsky' via Dart VM Observatory Discuss <observato...@dartlang.org> wrote:
To get a script you call getObject with an isolate id and a script id. I'm wondering if this implies that I should use (isolate id, script id) as a cache key to store a script? That is, is it possible for scripts in two different isolates (in the same VM) to have the same id?


isolateId + scriptId will be unique for a given VM.

It's best to think of service protocol ids as opaque but I'll break down the script id:

"libraries/<library-private-key>/scripts/<script-uri>/<load-timestamp>"

<library-private-key> is a special key the VM generates for the given library
<script-uri> is just the uri of the loaded script
<load-timestamp> was the timestamp at the time the script was loaded

<library-private-key> can/will be different in each isolate
<script-uri> will be the same in each isolate
<load-timestamp> can/will be different in each isolate

Note that when a library is hot reloaded, new scripts with new scriptIds will be generated. The new scriptId will probably only differ from the old scriptId by the <load-timestamp>.

Also, the docs [1] say that "fixed" ids can expire when the object is garbage collected, and the id might be reused. Is this the case for scripts? If so, how would I know when to invalidate the cache entry for a script?


1) You won't see a reused scriptId. It's impossible given the above scheme.
2) There is no notification when a script is collected. You can know that a Script has been collected by invoking getObject on it and observing the Collected Sentinel value. 
 
(And by the way, the docs mention a "fixedId" property once but nowhere else. Where would "fixedId" appear? Is this still used?)


"fixedId" is a key that will be next to the "id" key. It is still used and can be observed on many of the service protocol objects (Isolate, Library, Script being examples).

HTH,
John

Brian Slesinsky

unread,
Mar 14, 2017, 5:43:40 PM3/14/17
to John Mccutchan, Dart VM Observatory Discuss
Thanks!

Another question: are line and column numbers zero or one-based? (I can figure it out, but it seems like the doc should say?)

On Mon, Mar 13, 2017 at 3:37 PM, 'John Mccutchan' via Dart VM Observatory Discuss <observato...@dartlang.org> wrote:
Hi Brian,

--
You received this message because you are subscribed to the Google Groups "Dart VM Observatory Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to observatory-discuss+unsub...@dartlang.org.

John Mccutchan

unread,
Mar 14, 2017, 6:36:31 PM3/14/17
to Brian Slesinsky, Dart VM Observatory Discuss
Hi,

Line and column numbers start at 1.

John

On Tue, Mar 14, 2017 at 2:43 PM, 'Brian Slesinsky' via Dart VM Observatory Discuss <observato...@dartlang.org> wrote:
Thanks!

Another question: are line and column numbers zero or one-based? (I can figure it out, but it seems like the doc should say?)

--
To unsubscribe from this group and stop receiving emails from it, send an email to observatory-discuss+unsubscribe...@dartlang.org.

Reply all
Reply to author
Forward
0 new messages