ruby
# Observe basic Ruby GC stats
# This script demonstrates how to access Ruby's internal GC statistics.
# Run this in your terminal: ruby your_script_name.rb

require 'pp'

puts "--- Initial GC Stats ---"
pp GC.stat # pp for pretty print, requires 'pp' library or use 'p'

# Simulate object allocation to trigger GC activity
# Allocate many short-lived strings to provoke minor GC cycles.
100_000.times do
  "a string to allocate".dup
end

puts "\n--- GC Stats after allocations ---"
pp GC.stat

# Force a full GC cycle and observe stats
# GC.start triggers a full garbage collection. Use with caution in production.
GC.start
puts "\n--- GC Stats after forced GC.start ---"
pp GC.stat

# Example of how compaction might be manually triggered (Ruby 2.7+)
# Note: GC.compact is an expensive operation and should be used judiciously.
# It aims to reduce memory fragmentation by moving live objects together.
if GC.respond_to?(:compact)
  puts "\n--- Running GC.compact (if available) ---"
  GC.compact
  puts "--- GC Stats after GC.compact ---"
  pp GC.stat
else
  puts "\n--- GC.compact not available (requires Ruby 2.7+) ---"
end

ruby
# Example of setting GC environment variables via a shell script or directly in Ruby
# For production, these are typically set in environment files (e.g., .env, systemd unit files, Dockerfiles).
# IMPORTANT: These values are examples. Optimal values depend entirely on your application's memory profile.

# --- Shell Script Example (e.g., start_app_tuned.sh) ---
# export RUBY_GC_HEAP_INIT_SLOTS=1000000    # Initial heap slots for objects
# export RUBY_GC_HEAP_FREE_SLOTS=500000     # Minimum free slots after GC
# export RUBY_GC_HEAP_GROWTH_FACTOR=1.2     # Heap growth factor when memory is needed
# export RUBY_GC_MALLOC_LIMIT=16000000      # Malloc limit in bytes to trigger GC
# export RUBY_GC_OLDMALLOC_LIMIT=16000000   # Oldgen malloc limit in bytes to trigger GC

# ruby my_memory_intensive_app.rb
# -------------------------------------------------------------------------

# --- Ruby Code Example (for testing/development, not recommended for prod) ---
# It's generally better to set these via environment variables before Ruby starts,
# but for illustrative purposes, Ruby allows some GC parameters to be set dynamically.

# These settings influence how the Ruby VM manages its object heap.
ENV['RUBY_GC_HEAP_INIT_SLOTS'] = '1000000' # Start with 1 million object slots.
ENV['RUBY_GC_HEAP_FREE_SLOTS'] = '500000'  # Aim for 500k free slots after GC.
ENV['RUBY_GC_HEAP_GROWTH_FACTOR'] = '1.2' # Grow heap by 20% when expansion is needed.
ENV['RUBY_GC_MALLOC_LIMIT'] = '16000000'  # Trigger GC if C-allocated memory reaches ~16MB.
ENV['RUBY_GC_OLDMALLOC_LIMIT'] = '16000000' # Same limit for old generation C-allocated memory.

# The above environment variables are read by the Ruby VM at startup.
# Changing them dynamically might not always take full effect on a running VM
# for all parameters, but can be used for testing.

puts "Ruby GC tuning parameters activated via ENV (for demonstration)."
puts "RUBY_GC_HEAP_INIT_SLOTS: #{ENV['RUBY_GC_HEAP_INIT_SLOTS']}"
puts "RUBY_GC_HEAP_FREE_SLOTS: #{ENV['RUBY_GC_HEAP_FREE_SLOTS']}"
puts "RUBY_GC_HEAP_GROWTH_FACTOR: #{ENV['RUBY_GC_HEAP_GROWTH_FACTOR']}"
puts "RUBY_GC_MALLOC_LIMIT: #{ENV['RUBY_GC_MALLOC_LIMIT']}"
puts "RUBY_GC_OLDMALLOC_LIMIT: #{ENV['RUBY_GC_OLDMALLOC_LIMIT']}"

# Small allocation loop to demonstrate the application context
# In a real app, you would run your core logic here and then profile its memory behavior.
sum = 0
1_000_000.times { sum += rand(100) }
puts "Simulation complete. Sum: #{sum}"

# You would then profile your application with tools like 'memory_profiler' or 'stackprof'
# to see the effect of these settings on GC frequency and memory footprint.

ruby
# Example 1: Using String#freeze for immutable strings
# Freezing strings prevents their modification, which can lead to memory optimizations
# and reduce allocations of new string objects from concatenations or modifications.

puts "--- String#freeze Demo ---"

# Without freeze: Each interpolation or modification creates a new string object.
name = "Alice"
greeting_unfrozen = "Hello, #{name}!" # A new string object is created.
greeting_unfrozen_2 = "Hello, #{name}!" # Another new string object (likely different object_id).

puts "Unfrozen greeting object_id: #{greeting_unfrozen.object_id}"
puts "Unfrozen greeting 2 object_id: #{greeting_unfrozen_2.object_id}"

# With freeze: The base string literal is frozen. While interpolation still produces a new string,
# freezing constants can prevent unintended copies and optimize memory in other contexts.
FROZEN_GREETING_PREFIX = "Hello, ".freeze
FROZEN_GREETING_SUFFIX = "!".freeze

def create_greeting(name_str)
  # Although concatenation creates a new string, using frozen literals for components
  # ensures these components themselves are stable and potentially optimized.
  FROZEN_GREETING_PREFIX + name_str + FROZEN_GREETING_SUFFIX
end

puts "Frozen prefix object_id: #{FROZEN_GREETING_PREFIX.object_id}"
puts "Frozen greeting (generated): #{create_greeting("Bob")}"

# Example 2: Simple Object Pooling Concept
# Object pooling is effective for objects that are expensive to create and are frequently
# used and then discarded. It reuses existing objects instead of allocating new ones,
# reducing GC overhead.

puts "\n--- Object Pooling Demo ---"

# A simple class representing a resource-intensive object.
class ReusableObject
  attr_accessor :data

  def initialize
    @id = object_id # Use object_id as a unique identifier for demonstration.
    puts "ReusableObject ##{@id} initialized."
  end

  def reset
    @data = nil # Clear any transient data to prepare for reuse.
    # Perform any necessary cleanup for reuse here.
  end
end

# The ObjectPool manages a collection of ReusableObjects.
class ObjectPool
  def initialize(pool_size)
    @pool = Array.new(pool_size) { ReusableObject.new } # Pre-populate the pool.
    @in_use = [] # Track objects currently in use.
  end

  # Acquire an object from the pool. If the pool is empty, create a new one.
  def acquire
    obj = @pool.pop || ReusableObject.new
    @in_use << obj
    obj
  end

  # Release an object back to the pool. Reset its state.
  def release(obj)
    obj.reset
    @in_use.delete(obj)
    @pool.push(obj) unless @pool.include?(obj) # Prevent adding duplicates if released multiple times.
  end

  def status
    puts "Pool status: Available in pool: #{@pool.size}, Currently in use: #{@in_use.size}"
  end
end

pool = ObjectPool.new(2) # Create a pool with 2 initial objects.
pool.status

obj1 = pool.acquire
obj1.data = "Task 1 data"
puts "Acquired obj1 (ID: #{obj1.object_id})"
pool.status

obj2 = pool.acquire
obj2.data = "Task 2 data"
puts "Acquired obj2 (ID: #{obj2.object_id})"
pool.status

# Acquire beyond pool size - this will create a new object because the pool is empty.
obj3 = pool.acquire
obj3.data = "Task 3 data"
puts "Acquired obj3 (ID: #{obj3.object_id}) - A new object was created."
pool.status

pool.release(obj1)
puts "Released obj1 (ID: #{obj1.object_id})"
pool.status

# Acquire again - obj1 should be reused now.
obj4 = pool.acquire
puts "Acquired obj4 (ID: #{obj4.object_id}) - Should be the same as obj1's ID."
pool.status

pool.release(obj2)
pool.release(obj3)
pool.release(obj4)
pool.status # All objects returned to pool (or discarded if pool capacity was limited differently).

ruby
# Example of using GC.stat to gather runtime statistics
# This is a fundamental tool for understanding GC behavior within your application.

require 'pp'

puts "--- Application Startup GC Stats ---"
pp GC.stat

# Simulate a section of code with potential high object allocation
# In a real application, this would be a critical path or a background job.
def perform_memory_intensive_task
  data_array = []
  100_000.times do |i|
    # Simulating creation of many small objects (Hash and String objects here).
    # This pattern can lead to significant object allocation and GC activity.
    data_array << { id: i, name: "Item_#{i}", value: rand(1000) }
  end
  data_array # Return value to prevent premature GC of the array itself if it were local.
end

puts "\n--- Before Memory Intensive Task ---"
before_gc_stats = GC.stat
pp before_gc_stats

start_time = Time.now
task_result = perform_memory_intensive_task
end_time = Time.now

puts "\n--- After Memory Intensive Task ---"
after_gc_stats = GC.stat
pp after_gc_stats

# Analyze the difference in key metrics to understand GC activity during the task.
puts "\n--- GC Stat Deltas (during task execution) ---"
puts "Total GC runs (count): #{after_gc_stats[:count] - before_gc_stats[:count]}"
puts "Major GC runs (major_gc_count): #{after_gc_stats[:major_gc_count] - before_gc_stats[:major_gc_count]}"
puts "Minor GC runs (minor_gc_count): #{after_gc_stats[:minor_gc_count] - before_gc_stats[:minor_gc_count]}"
# total_allocated_objects represents total objects ever allocated since VM start.
puts "Allocated objects during task (approx.): #{after_gc_stats[:total_allocated_objects] - before_gc_stats[:total_allocated_objects]}"
puts "Heap live slots (after task): #{after_gc_stats[:heap_live_slots]}"
puts "Heap free slots (after task): #{after_gc_stats[:heap_free_slots]}"
puts "Task execution time: #{(end_time - start_time).round(4)} seconds"

# For more advanced profiling:
# You would typically integrate gems like 'memory_profiler' or 'stackprof' here.
# Example with memory_profiler (requires `gem install memory_profiler`)
# require 'memory_profiler'
#
# report = MemoryProfiler.report do
#   perform_memory_intensive_task
# end
# report.pretty_print(top: 10) # Shows top allocated objects and their sources.
#
# Example with stackprof (requires `gem install stackprof`)
# require 'stackprof'
#
# StackProf.run(mode: :wall, out: 'stackprof.dump') do # profile wall-clock time
#   perform_memory_intensive_task
# end
# puts "StackProf dump generated to stackprof.dump. Analyze with `stackprof stackprof.dump`"