Add ability to browse / view instances that are parented to `nil`

There are innumerable code patterns that generate instances that will never GC, in situations where you cannot just destroy them or infer when they will be destroyed. Not to mention, programmers make mistakes.


Instances cant be memory checked with the workflow I use in other places because of their funky GC behaviour when it comes to Lua.

Lua references can be tracked by seeing if a weak table drops it on a GC cycle, this cant be ensured with Instances because their Lua objects can get GC’d even if it wasn’t destroyed.

This would be a neat feature. We could see if GC would be working the way we intend it to, too.


This is still needed in 2023! Can we get a response to this?


Still much needed!! Get this post some attention…

1 Like

getnilinstances when?


I just now thought that this could be part of the tooling such as the microprofiler, I think some use cases such as:

  • viewing in real time instances that are parented to nil in the explorer
  • having an API to get the instances from lua code

to be too hard to implement, but maybe having something like snapshots or recording similar to the way microprofiler works, would allow for offline processing without real time requirements.

I think if we could dump we could benefit from fine-grained details of memory usage such as instances, when and where it was allocated from what script for example. Actually my mind may just have related to this announcement

Maybe this could make it possible.

1 Like

This is a good idea, but you could easily get all game objects and see what its parented to using tostring()

Can we get some of the synapse people on this now that, well… they’re more available? :smiley:


Please add a feature. As a plugin developer it is essential to be able to properly locate nil instances especially when the PluginToolbar class is parented to nil and I need to reference it to be able to unify my plugins to use the same toolbar.

The below code is a really hacky way to get a unified plugin toolbar be creating a toolbar and then parenting it to something that isn’t nil.

local PluginGuiService = game:GetService("PluginGuiService")

-- Find the PluginToolbar class, or create it if it doesn't exist
local PluginToolbars: Folder = PluginGuiService:FindFirstChild("PluginToolbars")
if PluginToolbars == nil then
	PluginToolbars ="Folder")
	PluginToolbars.Archivable = false -- Don't want to save this to the place file
	PluginToolbars.Name = "PluginToolbars"
	PluginToolbars.Parent = PluginGuiService

local PluginToolbar: table = {}
local plugin = nil -- Unfortunately, even if this module is require()'d in a plugin context, this does not exist

-- Creates a new toolbar with the given name
local function CreateNewToolbar(name: string): PluginToolbar
	local toolbar: PluginToolbar = plugin:CreateToolbar(name)
	toolbar.Name = name
	toolbar.Parent = PluginToolbars
	return toolbar

-- Creates a new button on the given toolbar
function PluginToolbar:CreateToolbar(name: string): PluginToolbar
		typeof(name) == "string",
		"Incorrect parameter type for param 'name' (expected string, got " .. typeof(name) .. ")"
	assert(#name > 0, "Cannot have zero-length toolbar name.")
	return PluginToolbars:FindFirstChild(name) or CreateNewToolbar(name)

-- Sets the reference stored in the plugin variable.
-- Returns the table for chaining calls (e.g. you can call this in-line on the require function itself)
function PluginToolbar:SetPlugin(reference: Plugin): table
	plugin = reference
	return self

return PluginToolbar

All of get these two plugins using the same toolbar.


If there was something like game:GetNilInstances() it would be so much better.

local pluginToolbar = game:GetNilInstances():FindFirstChild("PluginToolbars")
    or plugin:CreateToolbar("PluginToolbars")

Now wouldn’t that be easy.

Or we could just not parent PluginToolbar to nil. I still want to be able to detect stuff in nil still though

1 Like

Would be nice if this was an engine-wide feature. Indexing the nil space. Then you could do something like nil:GetChildren() or

They would need to make nil an instance of itself to do that though, which would hinder performance.

1 Like

nil is a reserved keyword in Lua, as well as this, there be dragons with accessing destroyed instances that otherwise wouldn’t have any references.

getnilinstancenames, which just returns the names of objects, is likely more than enough to figure out if nil-space still contains my object.


Came on New Year’s Day to say this would incredibly helpful to find data leaks instead of just trial and error

1 Like

Funny how developers are starting to ask for exploit functions like getnilinstances. Aside from that, I believe this would be good for debugging.

there are so many core events parented as “nil” so it will lack security.

Why couldn’t they just not list anything thats from the core? I feel like a possible security issue is outweighed when compared to how this can help developers.

You’re already completely prevented from interacting with or modifying things used by Roblox’s corescripts or core gui. Not only would you not be able to do anything with them in the first place, I don’t think it’d exactly be hard for them to just exclude them from the list as Trio said

Upon reading the OP post again, I believe the root request is solved by the new Luau VM memory tools. (finding references to nil-parented objects)


Thank you @Mauio64 for the link.
That tool is made to solve this feature request as one its features.

Lost this topic over time, but we are working on a system to track feature requests better, similar to
improvements we made in the ‘Bug Reports’ category.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.