Closed Bug 386025 Opened 13 years ago Closed 13 years ago

Expose cycle collection exports

Categories

(Core :: XPCOM, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
mozilla1.9alpha8

People

(Reporter: Mook, Assigned: benjamin)

References

()

Details

Attachments

(1 file)

Currently, it is not possible to build a cycle collector participant in non-libxul code because a few necessary functions are not exposed for linking.  They're in xpcombase_s but don't get exposed via libxul.

The missing exports are:
nsCycleCollector_forget
nsCycleCollector_suspect
nsXPCOMCycleCollectionParticipant::UnmarkPurple
nsXPCOMCycleCollectionParticipant::Unroot
nsXPCOMCycleCollectionParticipant::Unlink
nsXPCOMCycleCollectionParticipant::Root
nsXPCOMCycleCollectionParticipant::Traverse
Looks to me like nsXPCOMCycleCollectionParticipant can be moved directly into the glue.

We'd have to expose nsCycleCollector_forget and nsCycleCollector_suspect as XPCOM frozen exports, which I think would be ok.
Flags: blocking1.9?
Assignee: nobody → benjamin
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Attachment #273827 - Flags: review?(graydon)
For the record, I developed and tested this on Windows... I'm trying a Linux build with pragma visibility overnight.

And I copied/symlinked nsCycleCollectionParticipant.{cpp,h} from xpcom/base to xpcom/glue for the patch. I will just cvs remove/add them for the final commit.
I don't know enough about xpcom guts to say if that patch solves the problem, but the collector's client interface does properly include suspectCurrent, registerRuntime and forgetRuntime.
Well, I know the patch *works* ;-)

The decision I need you to comfortable with is exposing NS_CycleCollectorSuspect and NS_CycleCollectorForget as frozen exported functions which are supported "forever", where forever is the life of the 1.9 and 1.9.1 stable branches.
Comment on attachment 273827 [details] [diff] [review]
Export cyclecollector necessities, rev. 1

Long term support for these functions is, I think, not a problem: it is not detectable from the caller whether the functions do anything, so in the worst case if you wanted to remove the collector and leave in no-op stubs it would be harmless.
Attachment #273827 - Flags: review?(graydon) → review+
Target Milestone: --- → mozilla1.9 M8
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.